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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to
389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Lewis Robson
Systems Administrator
Conscious Solutions Limited
Tel: 0117 325 0200
Web: https://www.conscious.co.uk
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
