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
Does anyone know anything that I could check for the error to get around this?
Thankyou kindly.
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?
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Thanks Thierry,
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'.
the replication manager account was set up from the cockpit ui, replication as per the below, for the nsDS5ReplicaRoot, how would I go about adding this?
Resending replacing images with text explanations as email got put into queue.
Thanks Thierry,
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'.
the replication manager account was set up from the cockpit ui, replication as per the below, for the nsDS5ReplicaRoot, how would I go about adding this?
(images were here, they showed:)
(image 1, configuration tab)
replica role: Supplier
Replica ID: 1
configuration tab: replication managers: cn=replication manager,cn=config
(Image two, replication agreement) port 636
bind DN cn=replication manager,cn=config
LDAPS
authentication method SIMPLE
Hello Both,
I got the 389ds replicated this morning, Thankyou very much for your help.
Enjoy your friday
-Lewis
Thanks Mark, please see responses below
Couple things here, are the RHEL 7 servers set up as replication consumers? that is correct, in the 389 console under configuration > replication > userRoot, dedicated consumer
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?
heres the output of the below command, is this what you mean?
ldapsearch -x -b "dc=test,dc=co,dc=uk" -H ldaps://myserver -D "cn=replication manager,cn=config" -W "objectclass=nsds5replica" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=test,dc=co,dc=uk> with scope subtree # filter: objectclass=nsds5replica # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
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:
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 3/24/22 10:34 AM, Lewis Robson wrote:
Thanks Mark, please see responses below
Couple things here, are the RHEL 7 servers set up as replication consumers? that is correct, in the 389 console under configuration > replication > userRoot, dedicated consumer
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?
heres the output of the below command, is this what you mean?
ldapsearch -x -b "dc=test,dc=co,dc=uk" -H ldaps://myserver -D "cn=replication manager,cn=config" -W "objectclass=nsds5replica" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=test,dc=co,dc=uk> with scope subtree # filter: objectclass=nsds5replica # requesting: ALL #
# search result search: 2 result: 0 Success
# numResponses: 1
You need to search under "cn=conifg" for objectclass=nsds5replica. not the database suffix, and you should do so as the directory manager account:
ldapsearch =D "cn=directory manger" -W -b cn=config objectclass=nsds5replica
Can you also provide provide the other information I requested from the RHEL 8 server?
# dsconf slapd-YOUR_INSTANCE replication get --suffix dc=test,dc=co,dc=uk
# dsconf slapd-YOUR_INSTANCE repl-agmt list --suffix dc=test,dc=co,dc=uk
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
nice one thankyou, Ill change this over tomorrow and see how it goes :D
On 24/03/2022 17:14, Mark Reynolds wrote:
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.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
389-users@lists.fedoraproject.org