On 22/10/2018 21:27, Florence Blanc-Renaud wrote:
On 10/22/18 2:10 PM, Roderick Johnstone via FreeIPA-users wrote:
> Hi
>
> This is ipa-server-4.5.4-10.el7_5.4.4.x86_64 on RHEL7.5.
>
> I've got four preserved accounts (out of a few hundred preserved
> accounts).
>
> On two of the servers they are showing up correctly as preserved with
> this command:
> ipa user-show <username>.
>
> On the third server the same command shows the users with the
> preserved attribute set to false.
>
> Based on a few tests changing (other) accounts it seems that
> replication is generally working fine between all the servers.
>
> But:
>
> 1) The ipa_check_consistency script is showing all three servers with
> the same (correct) number of preserved and active users and is showing
> a good replication status for all server replication agreements.
>
> So its not showing fewer preserved accounts on one server correctly.
>
> 2) I'm not seeing any replication conflicts on any of the servers
> through commands like this:
>
> # ldapsearch -x -D "cn=directory manager" -W -b
"dc=example,dc=com"
> "nsds5ReplConflict=*" \* nsds5ReplConflict
Hi,
which version of 389-ds is installed? In recent versions (>= 1.3.7.4,
please see ticket 49043 [1]), you need to use the following search to
retrieve the conflict entries:
ldapsearch -x -D "cn=Directory Manager" -W -b "dc=example,dc=com"
"(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict
(without objectclass=ldapsubentry, the search won't return any result).
flo
[1]
https://pagure.io/389-ds-base/issue/49043
Hi Flo
Thanks for the info here. We are on: 389-ds-base-1.3.7.5-28.el7_5.x86_64
so indeed need the new command to see replication conflicts.
But, even with that I'm not seeing any conflicts. I've run it on each
server (with my real domain) and still just get:
[root@calxw ~]# ldapsearch -x -D "cn=Directory Manager" -W -b
"dc=example,dc=com"
"(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))"
\* nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))
# requesting: * nsds5ReplConflict
#
# search result
search: 2
result: 0 Success
# numResponses: 1
So, I'm still confused as to why one of my servers is out of sync with
the other two and yet there are apparently no replication conflicts showing.
Would still appreciate advice on the best way to resolve this when its
more obvious whats going on.
Thanks again.
Roderick
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <dc=example,dc=com> with scope subtree
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> 3) The dirsrv error log on server with the users not showing as
> preserved is showing the following entries from last May:
>
> [11/May/2018:10:09:31.330807982 +0100] - ERR - managed-entries-plugin
> - mep_mod_post_op - Unable to find config for origin entry
> "uid=<user>,cn=deleted
> users,cn=accounts,cn=provisioning,dc=example,dc=com".
> [11/May/2018:10:09:36.294657019 +0100] - ERR - NSMMReplicationPlugin -
> write_changelog_and_ruv - Can't add a change for
> uid=<user>,cn=users,cn=accounts,dc=example,dc=com (uniqid:
> f132de25-54fa11e8-b4d6ec15-cd33af38, optype: 64) to changelog csn
> 5af55dc9000600040000
>
> I'd appreciate any thoughts as to why there might be an inconsistency
> between servers despite there apparently being no replication
> conflicts and no indication in the ipa_check_consistency script output.
>
> What might be the best way to resolve this inconsistency between servers?
>
> Thanks
>
> Roderick Johnstone
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>