William,

Thank you for your reply. So it looks like running the following command:

# /usr/lib64/dirsrv/slapd-YOURID/db2index -n MYBACKEND -t entryrdn

And then initializing the master that was having the errors, it did not fix
the issue... in fact, I am getting the same exact issue. Here is something
interesting though, if I move one of the affected users in Active Directory
to another group, it replicates back over to the LDAP side and I can
reinitialize the affected master fine.... But when I move the user back to
the group container that he is supposed to be in, the users failed to sync
to the affected master again...

[04/Feb/2016:09:01:41 -0600] - import userRoot: WARNING: Skipping entry
"uid=user1,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" which
has no parent, ending at line 0 of file "(bulk import)"
[04/Feb/2016:09:01:41 -0600] - import userRoot: WARNING: bad entry: ID 29


OU Search:
# ldapsearch -D "cn=manager-name" -W -xLLL -b
"ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" entryid
Enter LDAP Password:
dn: ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net
entryid: 55

Bad user who is in this group contain, does not show up
# ldapsearch -D "cn=directory manager" -W -xLLL -b
"ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" uid=user1
entryid
Enter LDAP Password:

Known Good users in this same container
# ldapsearch -D "cn=directory manager" -W -xLLL -b
"ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net" uid=gooduser
entryid
Enter LDAP Password:
dn: uid=gooduser,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net
entryid: 1422



On Tue, Feb 2, 2016 at 6:01 PM, William Brown <[email protected]> wrote:

> On Tue, 2016-02-02 at 17:11 -0600, Derek Belcher wrote:
> > I recently added a new Muilt-Master and Consumer to my existing LDAP
> > infrastructure and I am having issues when I go to initialize the new
> > servers. On the new servers I am getting the following errors:
> >
> > [02/Feb/2016:15:27:17 -0600] NSMMReplicationPlugin -
> > multimaster_be_state_change: replica dc=alertlogic,dc=net is going
> > offline;
> > disabling replication
> > [02/Feb/2016:15:27:17 -0600] - WARNING: Import is running with
> > nsslapd-db-private-import-mem on; No other process is allowed to
> > access the
> > database
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping
> > entry
> > "uid=user1,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net"
> > which
> > has no parent, ending at line 0 of file "(bulk import)"
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping
> > entry
> > "uid=user2,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net"
> > which
> > has no parent, ending at line 0 of file "(bulk import)"
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry:
> > ID 29
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: Skipping
> > entry
> > "uid=user3,ou=Users,ou=Place1,ou=Place2,ou=Groups,dc=mydomain,dc=net"
> > which
> > has no parent, ending at line 0 of file "(bulk import)"
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry:
> > ID 30
> > [02/Feb/2016:15:27:17 -0600] - import userRoot: WARNING: bad entry:
> > ID 31
> >
> >
> > I could not find much on these errors and was thinking that I may
> > need to
> > re-index my source master LDAP server. I have verified that all of
> > the OU's
> > exist on the new servers. When I re-initalize these two new servers
> > it does
> > put the bulk of the users into the OU's but is failing on a few users
> > (as
> > shown above). I found the following post and have surmised my
> > strategy from
> > it:
> >
> > http://www.spinics.net/linux/fedora/389-users/msg17329.html
> >
> >
> > I am planning on running the following command on my source server:
> >
> > # /usr/lib64/dirsrv/slapd-YOURID/db2index -n MYBACKEND -t entryrdn
>
> I would do;
>
> /usr/sbin/db2index -Z YOURID -n MYBACKEND -t entryrdn
>
> The per-instance scripts are "out of favour".
>
>
> >
> > Questions:
> > 1) Is this the right command and am I thinking about this issue in
> > the
> > correct manner?
>
> It appears to be the same issues. However, there is no response from
> the user that this corrected their problem.
>
> I would advise that you should stop outgoing replication from the
> affected master (IE, set nsds5ReplicaEnabled=off on the affected
> master.). This should still let you push the re-initialise into the
> affected, but mithout the risk of data going back out in the case of an
> issue.
>
> > 2) If this is the corrent command to run, after running it, do I need
> > to
> > break all replications and re-initialize all of my Masters, then
> > consumers,
> > then setup all of the replication agreements again? Or do I just run
> > the
> > db2index.pl and then let the established replication agreements just
> > do
> > their thing?
> > 3) Is there anything else that I should be aware of or do before I
> > take
> > this action?
>
> Backup. Always backup before you start anything. Paranoia is a good
> thing.
>
> db2ldif -r is probably what you want to use.
>
> >
> >
> > All servers are running CentOS 6.xx
> >
> > # rpm -qa 389*
> > 389-ds-console-1.2.6-1.el6.noarch
> > 389-ds-1.2.2-1.el6.noarch
> > 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64
> > 389-dsgw-1.1.11-1.el6.x86_64
> > 389-admin-console-1.1.8-1.el6.noarch
> > 389-ds-console-doc-1.2.6-1.el6.noarch
> > 389-console-1.1.7-1.el6.noarch
> > 389-admin-1.1.35-1.el6.x86_64
> > 389-admin-console-doc-1.1.8-1.el6.noarch
> > 389-adminutil-1.1.19-1.el6.x86_64
> > 389-ds-base-1.2.11.15-48.el6_6.x86_64
> >
> >
> > Thank you all for your time and I really appreciate all of your help!
> > --Derek
> > --
> > 389 users mailing list
> > 389-users@%(host_name)s
> > http://lists.fedoraproject.org/admin/lists/[email protected]
> > ect.org
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
> --
> 389 users mailing list
> 389-users@%(host_name)s
>
> http://lists.fedoraproject.org/admin/lists/[email protected]
>
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/[email protected]

Reply via email to