Using the command line

Edit online

You can issue the commands provided here at the command line to create subtree.

About this task

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. The suffix of the replicated subtree must already be configured on other servers. (Be sure to read Synchronizing two-way cryptography between server instances, in the Administering section of the IBM® Security Verify Directory documentation before you start the server instances.)
Note: The subtree you want to create is shown here: 
dn: o=sample
objectclass: organization
objectclass: ibm-replicationContext
o: sample
If this entry already exists, then modify it to add objectclass=ibm-replicationContext instead of adding the entire entry.
  1. Create an ldif file suffix_update.ldif with the following information to add the objectclass=ibm-replicationContext to the already existing suffix or branch:
    dn: o=sample
changetype: modify
add: objectclass
objectclass: ibm-replicationContext
  2. Use the idsldapmodify command to modify the suffix entry on server1. On server1 issue the following command:
    idsldapmodify -D <adminDN> -w <adminPW> -i suffix_update.ldif

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:

  • The master is a supplier to the forwarder.
  • The forwarder has two roles:
    1. A consumer of the master
    2. A supplier to the replica
  • The replica is a consumer of the forwarder.

To create the master (server1), a forwarder (server2), and replica (server3) for the subtree o=sample:

Procedure

  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 setting:
    Note: Replace all occurrences of &ltserver1-uuid&gt;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™, or Solaris system. Similarly, all occurrences of the &ltserver2-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=sample 
objectclass: organization 
objectclass: ibm-replicationContext

dn: ibm-replicaGroup=default, o=sample 	 
objectclass: top
objectclass: ibm-replicaGroup 
ibm-replicaGroup: default

dn: cn=server2 BindCredentials,cn=replication,cn=IBMpolicies 
objectclass: ibm-replicationCredentialsSimple 	 
cn: server2 BindCredentials 
replicaBindDN: cn=any
replicaCredentials: secret123
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=sample
objectclass: top 
objectclass: ibm-replicaSubentry
ibm-replicaServerId: server1-uuid
ibm-replicationServerIsMaster: true		
#true if master, false if forwarder 
cn: server1
description: master ibm-replicaSubentry

dn: ibm-replicaServerId=server2-uuid,ibm-replicaGroup=default,o=sample
objectclass: top 
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=sample
objectclass: top 
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=sample
objectclass: top 
objectclass: ibm-replicationAgreement
cn: server3 
ibm-replicaConsumerId: <server3-uuid> 
ibm-replicaUrl: ldap://server3:389
ibm-replicaCredentialsDN: cn=server3 BindCredentials,cn=replication,cn=IBMpolicies 
description: server2 (the forwarder) to server3 (the replica) agreement
    Note:

    This replicaBindDN must be unique and cannot be same as any already existing DN's.

  2. Stop the master, if it is not already stopped, by using the following command:
    idsslapd -I <instance_name> -k
    where <instance_name>is the name of the directory server instance you want to stop.
  3. To load the new replication topology to the master, issue the command:
    idsldif2db -r no -i <myreplicainfofile> -I <instance_name>
    where -r no prevents replication of the set of entries.
  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=sample -k <key seed> -t <key salt>
    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 not synchronized. See the idsdb2ldif command information in the Command Reference 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 Synchronizing two-way cryptography between server instances, in the Administering section of the IBM Security Verify Directory documentation 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-8859-1 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 ASCII characters from 33 to 126, in the Administering section of the IBM Security Verify Directory documentation 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 <instance_name> -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.
    idsslapd -I <instance_name> -k
    where <instance_name>is the name of the directory server instance you want to stop.
  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 <instance_name> -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.
    idsslapd -I <instance_name> -k
    where <instance_name>is the name of the directory server instance you want to 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>
    where -r no prevents replication of the set of entries.
  16. After completing the data import, issue the command idsrunstats to optimize the table statistics:
    idsrunstats -I <instance_name>
  17. Start the master (server1), the forwarder (server2) and the replica (server3). On each of the servers issue the command:
    idsslapd -I <instance_name> -n