> On 11 Sep 2019, at 04:03, Morgan, Iain (ARC-TN)[InuTeq, LLC] > <[email protected]> wrote: > > > > On 9/10/19, 04:44, "Ludwig Krispenz" <[email protected]> wrote: > > > On 09/10/2019 02:37 AM, William Brown wrote: >> >>> On 10 Sep 2019, at 09:58, Morgan, Iain (ARC-TN)[InuTeq, LLC] >>> <[email protected]> wrote: >>> >>> >>> >>> On 9/8/19, 15:40, "William Brown" <[email protected]> wrote: >>> >>> >>> >>>> On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC] >>>> <[email protected]> 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. > > > Yes, this is truly a stand-alone server. It's currently being used for > testing of locally written administrative scripts and no replication ID, > replication agreements, or changelog modifications have been configured. The > changes thus far have largely been limited to the password policy and TLS > configuration. > > Your hypothesis seems reasonable. The next step in our testing is to create > another instance and test replication. Hopefully, these errors will disappear > once we get to that stage in our testing.
This seems like the case. I have opened an issue to investigate the false-errors you are seeing and why. https://pagure.io/389-ds-base/issue/50593 Please let us know if once you enable replication you continue to see issues like this. I hope we have helped, and we are always happy to answer any questions you have. — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
