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(a)nasa.gov> wrote:
>
>
>
> On 9/8/19, 15:40, "William Brown" <wbrown(a)suse.de> wrote:
>
>
>
>> On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC]
<iain.morgan(a)nasa.gov> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
--
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