389 Directory Server 1.3.x Replication
Last time we added users and groups to our directory, see 389 Directory Server 1.3.x Users, Groups and ACIs.
Let's create some redundancy by using multi-master replication today. The outline is as following (first supplier isldap01, second supplier will be
ldap02):
- Install a second VM with an empty userRoot, but with the same TLS and password policy settings
- Enable the change log
- Configure read-write replicas (replication settings and replication manager)
- Set up replication agreements
- Start the replication on the first supplier, pushing all changes to the second supplier
We have to create another 389-ds instance on a new VM, see 389 Directory Server 1.3.x on Red Hat Enterprise Linux 7.6. We just have to change a single line in setup.inf. Instead of /tmp/userRoot.ldif make it InstallLdifFile=none.
Done that? Fresh 389-ds instance ldap02
up and running? Same suffix (dc=unix,dc=mycompany,dc=com)? SSL key/certificate created and TLS enabled? Password policy (you can't set passwordAdminDN right now because the directory is empty, you'll have to do that later when both directory servers are in sync) in place? Good!
Let's start with the changelog, replica settings and replication manager on ldap01
.
dirsrv@ldap01 $ ldapadd -D "cn=Directory Manager" -y /etc/dirsrv/.dmpw -x -ZZ dn: cn=changelog5,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-$(hostname -s)/changelogdb # Red Hat recommends setting the maximum changelog age to 7 days. # the following attribute should match nsds5ReplicaPurgeDelay (604800s == 7d) nsslapd-changelogmaxage: 7d dn: cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config changetype: add objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=unix,dc=mycompany,dc=com # set a unique ID for suppliers nsDS5ReplicaId: 1 # 3 consumer/supplier (updateable) nsDS5ReplicaType: 3 # 1: The replica writes to the changelog; this is the default for hubs and suppliers. nsDS5Flags: 1 # the following attribute should match nsslapd-changelogmaxage (7d == 604800s) nsDS5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=Replication Manager,cn=config ^D dirsrv@ldap01 $ RMPW="$(pwmake 192)" dirsrv@ldap01 $ echo -n $RMPW > /etc/dirsrv/.rmpw dirsrv@ldap01 $ chmod 400 /etc/dirsrv/.rmpw dirsrv@ldap01 $ ldapadd -D "cn=Directory Manager" -xy /etc/dirsrv/.dmpw -ZZ dn: cn=Replication Manager,cn=config objectClass: top objectClass: device objectClass: simpleSecurityObject cn: Replication Manager userPassword: $(pwdhash -s PBKDF2_SHA256 $(< /etc/dirsrv/.rmpw)) passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0 ^D
Let's do the same on ldap02
. The only difference here is nsDS5ReplicaId which has to be unique.
dirsrv@ldap02 $ ldapadd -D "cn=Directory Manager" -y /etc/dirsrv/.dmpw -x -ZZ dn: cn=changelog5,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-$(hostname -s)/changelogdb nsslapd-changelogmaxage: 7d dn: cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config changetype: add objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=unix,dc=mycompany,dc=com # set a unique ID for suppliers! nsDS5ReplicaId: 2 nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=Replication Manager,cn=config ^D dirsrv@ldap02 $ RMPW="$(pwmake 192)" dirsrv@ldap02 $ echo -n $RMPW > /etc/dirsrv/.rmpw dirsrv@ldap02 $ chmod 400 /etc/dirsrv/.rmpw dirsrv@ldap02 $ ldapadd -D "cn=Directory Manager" -xy /etc/dirsrv/.dmpw -ZZ dn: cn=Replication Manager,cn=config objectClass: top objectClass: device objectClass: simpleSecurityObject cn: Replication Manager userPassword: $(pwdhash -s PBKDF2_SHA256 $(< /etc/dirsrv/.rmpw)) passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0
That's it for ldap02
for now, back to ldap01
. Next on the list is the replication agreement. We need the clear-text Replication Manager password (see /etc/dirsrv/.rmpw) from ldap02
for this. Let's do a connection test, too, before we start the replication refresh.
dirsrv@ldap01 $ openssl s_client -connect ldap02.mycompany.com:389 -starttls ldap -CAfile /etc/openldap/certs/CA.crt < /dev/null
...
Verify return code: 0 (ok)
...
dirsrv@ldap01 $ ldapadd -D "cn=Directory Manager" -xy /etc/dirsrv/.dmpw -ZZ
dn: cn=ReplicaAgreement,cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5ReplicationAgreement
cn: ReplicaAgreement
nsDS5ReplicaHost: ldap02.mycompany.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsDS5ReplicaCredentials: ***clear-text RMPW from ldap02***
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaTransportInfo: TLS
nsDS5ReplicaRoot: dc=unix,dc=mycompany,dc=com
description: replication agreement between ldap01 and ldap02
nsDS5ReplicaUpdateSchedule: 0000-2359 0123456
dn: cn=ReplicaAgreement,cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config
changetype: modify
replace: nsDS5BeginReplicaRefresh
nsDS5BeginReplicaRefresh: start
^D
dirsrv@ldap01 $ tail /var/log/dirsrv/slapd-$(hostname -s)/errors
[...] NSMMReplicationPlugin - repl5_tot_run - Finished total update of replica "agmt="cn=ReplicaAgreement" (ldap02:389)". Sent 207 entries.
dirsrv@ldap02 $ tail /var/log/dirsrv/slapd-$(hostname -s)/errors
[...] NSMMReplicationPlugin - multimaster_be_state_change - Replica dc=unix,dc=mycompany,dc=com is coming online; enabling replication
And do the same on ldap02
. We're not starting a nsDS5BeginReplicaRefresh here because the sync was already done on ldap01
.
dirsrv@ldap02 $ ldapadd -D "cn=Directory Manager" -xy /etc/dirsrv/.dmpw -ZZ dn: cn=ReplicaAgreement,cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config objectClass: top objectClass: nsds5ReplicationAgreement cn: ReplicaAgreement nsDS5ReplicaHost: ldap01.mycompany.com nsDS5ReplicaPort: 389 nsDS5ReplicaBindDN: cn=Replication Manager,cn=config nsDS5ReplicaCredentials: ***clear-text RMPW from ldap01 *** nsDS5ReplicaBindMethod: SIMPLE nsDS5ReplicaTransportInfo: TLS nsDS5ReplicaRoot: dc=unix,dc=mycompany,dc=com description: replication agreement between ldap02 and ldap01 nsDS5ReplicaUpdateSchedule: 0000-2359 0123456 ^D dirsrv@ldap02 $ ldapsearch -LLL -D "cn=Directory Manager" -xy /etc/dirsrv/.dmpw -ZZ \ -b 'cn=ReplicaAgreement,cn=replica,cn=dc\=unix\,dc\=mycompany\,dc\=com,cn=mapping tree,cn=config' \ nsds5replicaLastUpdateStatus dn: cn=ReplicaAgreement,cn=replica,cn=dc\3Dunix\2Cdc\3Dmycompany\2Cdc\3Dcom,cn =mapping tree,cn=config nsds5replicaLastUpdateStatus: Error (0) Replica acquired successfully: Increme ntal update succeeded
And that's it. Our directory is nicely replicated to another instance and all changes made on any server are transferred to the other now.
Read the next part at 389 Directory Server 1.3.x LDAP client authentication.
Links
- Administration Guide / Configuring Multi-Master Replication
- Administration Guide / Creating the Supplier Bind DN Entry
- Administration Guide / Configuring Single-Master Replication
- Administration Guide / Replicating Account Lockout Attributes
- Administration Guide / Monitoring Replication Status
- Configuration, Command, and File Reference / Chapter 3. Core Server Configuration Reference
No comments:
Post a Comment