Creating a master-forwarder-replica topology

Transcription

1 Creating a master-forwarder-replica topology

2 ii Creating a master-forwarder-replica topology

3 Contents Creating a master-forwarder-replica topology Changing the replica to a forwarding server....1 Using the command line: iii

4 iv Creating a master-forwarder-replica topology

5 Creating a master-forwarder-replica topology The following diagram shows a master-forwarder-replica topology: Server1 Master Server o=ibm,c=us (supplier) (consumer) server2 Forwarding o=ibm,c=us (supplier) (consumer) server3 Replica o=ibm,c=us Figure 1. Master-forwarding server-replica topology To define a master-forwarder-replica topology, you must do the following: 1. Create a master server and a replica server. See "Creating a master-replica topology" in the "Replication" chapter of the IBM Tivoli Directory Server version 6.0 Administration Guide. 2. Create a new replica server for the original replica. See "Adding a replica server" in the "Replication" chapter of the IBM Tivoli Directory Server version 6.0 Administration Guide. 3. Copy data to the replicas. See "Copying data to the replica" in the "Replication" chapter of the IBM Tivoli Directory Server version 6.0 Administration Guide. Changing the replica to a forwarding server Note: Before starting to set up your replication topology, make a backup copy of your original ibmslapd.conf file for each server. You can use this backup copy to restore your original configuration if you encounter difficulties with replication. If you have set up a replication topology with a master (server1) and a replica (server2), you can change the role of server2 to that of a forwarding server. To do this you must create a new replica (server3) under server2. Using the command line: This scenario assumes that you are creating a new replicated subtree and that only server1 contains any entry data. All other servers are newly installed, have a configured database, and have been started at least once for initialization purposes. 1

6 (Be sure to read Appendix I. Synchronizing two-way cryptography between server instances in the IBM Tivoli Directory Server version 6.0 Administration Guide before you start the server instances.) Note: The subtree you want to create is the following: dn: o=ibm,c=us objectclass: organization objectclass: ibm-replicationcontext o: ibm If this entry already exists, then modify it to add objectclass=ibmreplicationcontext instead of adding the entire entry. This procedure is similar to the one for a single master and replica, except that the entire topology must be added to each of the servers and the content of the agreement information file is more complex. The file now includes information for the forwarding server and supplier-consumer information. The supplier-consumer relationship for this scenario is: v The master is a supplier to the forwarder. v The forwarder has two roles: 1. A consumer of the master 2. A supplier to the replica v The replica is a consumer of the forwarder. To create the master (server1), a forwarder (server2), and replica (server3) for the subtree o=ibm,c=us: 1. At the computer where the master server is located, create a file to contain the agreement information; for example myreplicainfofile where myreplicainfofile contains the following: Note: Replace all occurrences of <server1-uuid> in the following files with the value of the ibm-slapdserverid attribute from the master server s cn=configuration entry. This value is generated by the server the first time it is started. You can find it either by performing an idsldapsearch of the cn=configuration entry or by using the grep command on the ibmslapd.conf file, if you have an AIX, Linux, Solaris, or HP-UX system. Similarly, all occurrences of the <server2-uuid> and the <server3-uuid> must be replaced with the value of the ibm-slapdserverid attribute from the respective server s cn=configuration entry. dn: cn=replication,cn=ibmpolicies objectclass: container dn: o=ibm,c=us objectclass: organization objectclass: ibm-replicationcontext dn: ibm-replicagroup=default, o=ibm,c=us objectclass: ibm-replicagroup ibm-replicagroup: default dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies objectclass: ibm-replicationcredentialssimple #or ibm-replicationcredentialsexternal or #ibm-replicationcredentialskerberos 2 Creating a master-forwarder-replica topology

7 cn: server2 BindCredentials replicabinddn: cn=any replicacredentials: secret description: Bindmethod of server 1 (the master) to server2 dn: cn=server3 BindCredentials,cn=replication,cn=IBMpolicies objectclass: ibm-replicationcredentialssimple cn: server3 BindCredentials replicabinddn: cn=any replicacredentials: secret description: Bindmethod of server2 (the forwarder) to server3 (the replica) dn: ibm-replicaserverid=<server1-uuid>,ibm-replicagroup=default,o=ibm,c=us objectclass: ibm-replicasubentry ibm-replicaserverid: <server1-uuid> #whatever the ID is in the config ibm-replicationserverismaster: true #true if master, false if forwarder cn: server1 description: master ibm-replicasubentry dn: ibm-replicaserverid=<server2-uuid>,ibm-replicagroup=default,o=ibm,c=us objectclass: ibm-replicasubentry ibm-replicaserverid: <server2-uuid> ibm-replicationserverismaster: false cn: server2 description: forwarder ibm-replicasubentry dn: cn=forwarder1,ibm-replicaserverid=<server1-uuid>, ibm-replicagroup=default,o=ibm,c=us objectclass: ibm-replicationagreement cn: server2 ibm-replicaconsumerid: <server2-uuid> ibm-replicaurl: ldap://server2:389 ibm-replicacredentialsdn: cn=server2 BindCredentials,cn=replication, cn=ibmpolicies description: server1 (the master) to server2 (the forwarder) agreement dn: cn=server3,ibm-replicaserverid=<server2-uuid>, ibm-replicagroup=default,o=ibm,c=us objectclass: ibm-replicationagreement cn: server3 ibm-replicaconsumerid: <server3-uuid>-uuid ibm-replicaurl: ldap://server3:389 ibm-replicacredentialsdn: cn=server3 BindCredentials,cn=replication, cn=ibmpolicies description: server2 (the forwarder) to server3 (the replica) agreement 2. Stop the master, if it is not already stopped, by using the following command: ibmdirctl -h server1 -D <admindn> -w <adminpw> -p 389 stop 3. To load the new replication topology to the master, issue the command: idsldif2db -r no -i <myreplicainfofile> -I <instance_name> 4. To generate a file with all of the data to synchronize the new replica, issue the command: idsdb2ldif -o <masterfile.ldif> -I <instance_name> -s o=ibm,c=us -k <key seed> -t <key salt> Note: You must use the -I option if there is more than one directory server instance. You must use the -k and -t options if keys on the server are Creating a master-forwarder-replica topology 3

8 not synchronized. See the idsdb2ldif command information in the IBM Tivoli Directory Server version 6.0 Administration Guide for more information. Attention: If you are exporting data that will be imported into an Advanced Encryption Standard (AES)-enabled server and if the two servers are not cryptographically synchronized, see "Appendix I. Synchronizing two-way cryptography between server instances," in the IBM Tivoli Directory Server version 6.0 Administration Guide for information about cryptographic synchronization of servers. When the source server (the server you are exporting data from) and the destination server (the server into which you will be importing the data) are using non-matching directory key stash files, and you specify the encryption seed and salt values of the destination server, any AES-encrypted data will be decrypted using the source server's AES keys, then re-encrypted using the destination server's encryption seed and salt values. This encrypted data is stored in the LDIF file. The encryption seed is used to generate a set of AES secret key values. These values are stored in a directory stash file and used to encrypt and decrypt directory stored password and secret key attributes. The encryption seed must contain only printable ISO ASCII characters with values in the range of 33 to 126, and must be a minimum of 12 and a maximum of 1016 characters in length. See Appendix D, "ASCII characters from 33 to 126," in the IBM Tivoli Directory Server version 6.0 Administration Guide for information about these characters. The encryption salt is a randomly generated value that is used to generate AES encryption keys. You can obtain the destination server's salt value by searching (using the idsldapsearch utility) the destination server's "cn=crypto,cn=localhost" entry. The attribute type is ibm-slapdcryptosalt. 5. Copy the <masterfile.ldif> file to the computer where server2 is located. 6. Start the forwarder, server2, in configuration only mode. idsslapd -I <LDAPinstance> -a 7. You must configure server2 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server2. On server2 issue the following command: idsldapadd -D <admindn> -w<adminpw> -i<filename> where <filename> contains: dn: cn=master Server, cn=configuration objectclass: ibm-slapdreplication cn: Master Server ibm-slapdmasterdn: cn=any ibm-slapdmasterpw: secret ibm-slapdmasterreferral: ldap://server1:389/ #referral to master when trying to add to consumer. #Referral can also be added to replicacontext, which would be #checked first for a valid server. Note: The ibm-slapdmasterdn and ibm-slapdmasterpw values must match the values stored on the master server, server1, in the entry cn=server2 BindCredentials. 8. Stop server2. 4 Creating a master-forwarder-replica topology ibmdirctl -h server2 -D <admindn> -w <adminpw> -p 389 stop

9 9. Save the ibmslapd.conf file. 10. Copy the <masterfile.ldif> file to the computer where server3 is located. 11. Start the replica, server3, in configuration only mode. idsslapd -I <LDAPinstance> -a 12. You must configure server3 to be a replica server. Use the idsldapadd command to add the following entry to the ibmslapd.conf file on server3. On server3 issue the following command: idsldapadd -D <admindn> -w<adminpw> -i<filename> where <filename> contains: dn: cn=master Server, cn=configuration objectclass: ibm-slapdreplication cn: Master Server ibm-slapdmasterdn: cn=any ibm-slapdmasterpw: secret ibm-slapdmasterreferral: ldap://server2:389/ Note: The ibm-slapdmasterdn and ibm-slapdmasterpw values must match the values stored on the master server, server1, in the entry cn=server3 BindCredentials. 13. Stop server3. ibmdirctl -h server3 -D <admindn> -w <adminpw> -p <port> stop 14. Save the ibmslapd.conf file. 15. At the computers where server2 and server3 are located, issue the following command: idsldif2db -r no -i <masterfile.ldif> -I <instance_name> 16. Start the master (server1), the forwarder (server2) and the replica (server3). On each of the servers issue the command: idsslapd -I <LDAPinstance> Note: Remember to ensure that all the servers have been added to the topology under cn=ibmpolicies in order to replicate global updates such as cn=schema. Creating a master-forwarder-replica topology 5