[389-users] Re: unconventional replication, alma 8 master to centos 7 slave: Unable to acquire replica: error: no such replica

On 3/24/22 2:17 PM, Mark Reynolds wrote:
>
> On 3/24/22 8:38 AM, Lewis Robson wrote:
>> Hello all,
>>
>> i am working to do multi master with two different versions of OS
>> (alma 8 and centos 7), this means that the 389 on alma 8 is using
>> dsidm and cockpit and the 389 on centos 7 is using 389console with
>> ldap commands.
>>
>>
>> the alma 8 directory tree is how we want it to be, users inside, all
>> working as expected.
>>
>> the 7 directory tree is the complete standard given when 389ds is setup.
>>
>>
>> on the 7 machine (slave) I have the bind dn information of
>> cn=replication manager,cn=config.
>> This has been set up on the 8 mschine via cockpit in the replication
>> agreement to connect with these credentials. an ldapsearch lets me
>> connect with them and purposely typing the username or password wrong
>> for the agreement gives a different error so im confident the account
>> is okay.
>>
>>
>> The error I see, when i try and initiliaze the agreement from the 8
>> cockpit view to the slave machine is:
>>
>> ERR - NSMMReplicationPlugin -
>> multimaster_extop_StartNSDS50ReplicationRequest - conn=289 op=3
>> replica="unknown": Unable to acquire replica: error: no such replica
>
> Couple things here, are the RHEL 7 servers set up as replication
> consumers?  Yes you need the replication manager setup, but the suffix
> needs to be enabled for replication as well.  Can you do a ldapsearch
> on cn=config searching for "objectclass=nsds5replica" and share the
> output?


I agree with Mark, an issue is likely in replication agreement
definition. According to the error message it looks the consumer (centos
7) can not retrieve the replicaroot from the replication extop. A
possibility is that the replication agreement (on alma 8) is missing
'nsDS5ReplicaRoot'.


>
> My other concern is about the error message above, is that from a RHEL
> 8 replica?  If so, this indicates replication is not setup properly on
> that suffix, but you say all the rhel 8 replicas are working.  Are you
> using multiple backends/suffixes or just one? If you are using
> multiple backends then maybe you have a mismatch in your replication
> config?  Becuase that error about "unknown" replica means the "suffix"
> was not configured for replication. Was this error from a RHEL 8
> replica?  If so run these commands:
>
> Change the suffix value to your suffix:
>
> # dsconf slapd-YOUR_INSTANCE replication get --suffix dc=example,dc=com
>
> # dsconf slapd-YOUR_INSTANCE repl-agmt list --suffix dc=example,dc=com
>
> If nothing sticks out try turning on replication logging
> (nsslapd-erorrlog-level: 8192) - you can do this from the Cockpit UI
> as well.
>
> Thanks,
>
> Mark
>
>
>>
>>
>> Does anyone know anything that I could check for the error to get
>> around this?
>>
>>
>> Thankyou kindly.
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure