Yup, you are using two different suffixes/backends between the suppliers
and consumers. The consumers are only accepting replication updates for
"dc=test,dc=co,dc=uk", but the supplier is trying to replicate
"dc=conscious,dc=co,dc=uk". They have to be the same ;-)
Mark
On 3/24/22 11:17 AM, Lewis Robson wrote:
> Thanks, here is the results:
>
> # extended LDIF
> #
> # LDAPv3
> # base <cn=config> with scope subtree
> # filter: objectclass=nsds5replica
> # requesting: ALL
> #
>
>
> dn: cn=replica,cn=dc\3Dtest\2Cdc\3Dco\2Cdc\3Duk,cn=mapping
> tree,cn=config
> objectClass: nsDS5Replica
> objectClass: top
> nsDS5ReplicaRoot: dc=test,dc=co,dc=uk
> nsDS5ReplicaType: 2
> nsDS5Flags: 0
> nsds5ReplicaPurgeDelay: 0
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> cn: replica
> nsDS5ReplicaId: 65535
> nsState:: //8AAAAAAACOWzxiAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
> nsDS5ReplicaName: d0393002-ab6811ec-80f38dbb-204096f4
> nsds5ReplicaChangeCount: 0
> nsds5replicareapactive: 0
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
>> Can you also provide provide the other information I requested from
>> the RHEL 8 server?
>> slapd-consciousldap replication get --suffix dc=conscious,dc=co,dc=uk
>> dn: cn=replica,cn=dc\3Dconscious\2Cdc\3Dco\2Cdc\3Duk,cn=mapping
>> tree,cn=config
>> cn: replica
>> nsDS5Flags: 1
>> nsDS5ReplicaBindDN: cn=replication manager,cn=config
>> nsDS5ReplicaId: 1
>> nsDS5ReplicaName: 3309fd02-4dfd11ec-b026c7f3-953dc3fe
>> nsDS5ReplicaRoot: dc=conscious,dc=co,dc=uk
>> nsDS5ReplicaType: 3
>> nsState:: AQAAAAAAAACkHTNiAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
>> nsds5ReplicaChangeCount: 34
>> nsds5replicareapactive: 0
>> objectClass: top
>> objectClass: nsds5Replica
>>
>>
>>
>>
> dsconf slapd-consciousldap repl-agmt list --suffix
> dc=conscious,dc=co,dc=uk
> dn:
> cn=copy,cn=replica,cn=dc\3Dconscious\2Cdc\3Dco\2Cdc\3Duk,cn=mapping
> tree,cn=config
> cn: copy
> description: copy
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> nsDS5ReplicaBindMethod: simple
> nsDS5ReplicaCredentials: {AES- stuff was here ive removed it for the
> email)
> nsDS5ReplicaHost: linuxtestserver
> nsDS5ReplicaPort: 636
> nsDS5ReplicaRoot: dc=conscious,dc=co,dc=uk
> nsDS5ReplicaTransportInfo: LDAPS
> nsds5replicaChangesSentSinceStartup:
> nsds5replicaLastInitEnd: 19700101000000Z
> nsds5replicaLastInitStart: 20220324141215Z
> nsds5replicaLastInitStatus: Error (6) Replication error acquiring
> replica: no such replica
> nsds5replicaLastInitStatusJSON: {"state": "red", "ldap_rc": "0",
> "ldap_rc_text": "Success", "repl_rc": "6", "repl_rc_text": "no such
> replica", "conn_rc": "0", "conn_rc_text": "operation success", "date":
> "2022-03-24T14:12:15Z", "message": "Error (6) Replication error
> acquiring replica: no such replica"}
> nsds5replicaLastUpdateEnd: 19700101000000Z
> nsds5replicaLastUpdateStart: 19700101000000Z
> nsds5replicaLastUpdateStatus: Error (6) Replication error acquiring
> replica: Unable to acquire replica: there is no replicated area on the
> consumer server. Replication is aborting. (no such replica)
> nsds5replicaLastUpdateStatusJSON: {"state": "red", "ldap_rc": "0",
> "ldap_rc_text": "Success", "repl_rc": "6", "repl_rc_text": "no such
> replica", "date": "2022-03-24T14:12:15Z", "message": "Error (6)
> Replication error acquiring replica: Unable to acquire replica: there
> is no replicated area on the consumer server. Replication is aborting.
> (no such replica)"}
> nsds5replicaUpdateInProgress: FALSE
> nsds5replicareapactive: 0
> objectClass: top
> objectClass: nsds5replicationagreement
>
> Cheers
>
>
>>>
>>>
>>> sidenote, If i run the below without any filtering applied by me
>>>
>>>
>>> ldapsearch -x -b "dc=test,dc=co,dc=uk,cn=config" -H ldaps://myserver
>>> -D "cn=replication manager,cn=config" -W
>>> Enter LDAP Password:
>>
>> Is "dc=test,dc=co,dc=uk,cn=config" really an entry under cn=config.
>> This looks wrong.
>>
>> Mark
>>
>>>
>>>
>>> i get:
>>>
>>>
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base <dc=test,dc=co,dc=uk,cn=config> with scope subtree
>>> # filter: (objectclass=*)
>>> # requesting: ALL
>>> #
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>>
>>> # numResponses: 1
>>>
>>>
>>>
>>>
>>>
>>> My other concern is about the error message above, is that from a
>>> RHEL 8 replica?
>>>
>>> this is from the var/log/dirsrv/slapd-host/* logs
>>>
>>>
>>>
>>>
>>> If so, this indicates replication is not setup properly on that
>>> suffix, but you say all the rhel 8 replicas are working.
>>>
>>> we only have the 1 master node on 8, apologies for any confusion.
>>>
>>>
>>> Thanks
>>>
>>> -Lewis
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> 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
>>>>
--
Directory Server Development Team
_______________________________________________
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
No comments:
Post a Comment