On 09/10/2019 02:37 AM, William Brown wrote:
On 10 Sep 2019, at 09:58, Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan@xxxxxxxx> wrote:
On 9/8/19, 15:40, "William Brown" <wbrown@xxxxxxx> wrote:
On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan@xxxxxxxx> wrote:
Hello Marc,
Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no memberOf plugin errors. The actual modrdn operations have error=0.
If we may, can we ask what the modrdn operations were, and to ask a little about your tree layout so we could try to understand more about this?
Sure, there's nothing unusual regarding the tree layout. There's a single backend with ou=People,.... and ou=Groups,.... One thing that may be relevant is that this is a stand-alone server -- replication has not been configured.
Have you configured the replica id, replication agreement or changelog though? I want to follow up with our replication expert about why URP is getting involved here, when you say replication isn't configured.
if this is really a standalone consumer without replication configured,
this is probably a consequence of splitting the multimaster(mmr) and the
other plugin calls and the mmr plugin could be called and do nothing,
just try :-(
so the messages is harmless although annoying and we should fix it.
From the access log:
[09/Sep/2019:15:05:08.577399600 -0700] conn=2233897 op=2 SRCH base="ou=Groups,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(cn=temp)(cn=testgroup))" attrs="cn"
[09/Sep/2019:15:05:08.577630700 -0700] conn=2233897 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000323261
[09/Sep/2019:15:05:08.578316196 -0700] conn=2233897 op=3 MODRDN dn="cn=temp,ou=Groups,dc=nas,dc=nasa,dc=gov" newrdn="cn=testgroup" newsuperior="(null)"
[09/Sep/2019:15:05:08.581595207 -0700] conn=2233897 op=3 RESULT err=0 tag=109 nentries=0 etime=0.0003326527
From the errors log:
[09/Sep/2019:15:05:08.580235717 -0700] - ERR - conn=2233897 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
I think you can ignore this - with no replication cenotaphs not being added is not an issue. If you were in a replication topology this would be a more significant error. Cenotaphs are needed to resolve some replication edge cases in update resolution and are an internal part of our replication system. But as mentioned, I will follow up why URP is being accessed here, so I need some more information from you.
Thanks, hope this helps,
--
Iain Morgan
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
