"copy the NICISDI.KEY " is invalid. This will force ther creation of a new tree key. This is because is cannot be read due to that file being wrapped by the other server's NICI storage key.
From time to time a hardware malfunction, network outage or simple a disaster can occur, so it is a very good idea to have a disaster recovery plan available and updated.
The following document describes the process of cloning an eDirectory box in a “Offline” fashion. It is very useful when you need to restore a previous eDirectory box that was lost for any reason.
Basically what the process does is clone the information from an eDirectory healthy box (Source server) to a server that need to be recovered / inserted to the replica ring (Target Server)
eDirectory server which information will be cloned (highly recommended to be the Master sever). In this case the source server is tqidnlabedir01
eDirectory box that receives the clone. In this case the source server is tqidnlabedir03
The current situation is something like this:
We have an eDirectory replica ring conformed by 2 servers (tqidnlabedir01 and tqidnlabedir02). We use to have a third eDirectory box (tqidnlabedir03) but after a hardware malfunction it was lost... so we need to clone the tqidnlabedir01and restore the tqidnlabedir03
Note: The following process is only applicable if the eDirectory replica ring is installed under Linux.
Basically the requirements are the following:
Access to the eDirectory boxes (source and target) as root
The admin account and password of eDirectory tree
Ensure that the eDirectory replica ring is healthy (i.e. ndsrepair -E reports no errors)
Time is syncronized between servers (replica ring)
Ensure that the eDirectory source box is not receiving ldap requests during the process (i.e. remove it from any load balancer configuration or set it as not operational)
Note 1: Do not use an IDM box as a source server, because the process generates unnecessary TAO files
Note 2: To ensure that the eDirectory source box is not receiving ldap requests during the process (in case of the presence of Load Balancers) you can use the following ldapsearch instruction (few times in a row)
# ldapsearch -LLL -h <Virtual_load_balancer_IP> -p 389 -b "" -s base "objectclass=*" -D <eDir_admin_user_in_formar_cn=,ou=> -x -w <eDir_admin_user_password> dsaName | grep dsaName
The query must return an ldap server name of any of the servers in the replica ring, but not the source's box server name. If you don't remove the source box from the load balancer configuration, the clients consuming the ldap service can get an “database locked error”.
It is also important that the eDirectory servers are able to reach each other through their DNS and host name, the easiest way to do so is by ensuring that the /etc/hosts entries are correct
Additionally it is necessary to verify that no references of the target server exist in the TREE. A very good way to check this out is by doing an ldap query to the source server asking for any object pointing to the Target server. In other words if you execute the following command and it returns nothing, you are good to go.
# ldapsearch -LLL -h <Source_Server_HostName>-D <ldap_user_to_query>-b <organization> -s sub -x -w <password> cn=*<Target_server>* cn
#ldapsearch -LLL -h tqidnlabedir01 -D cn=admin,o=novell -b o=sat -s sub -x -w novell cn=*tqidnlabedir03* cn
In the case of the previous query it returned an entry, so it needs to be removed it (through iManager, ldapdelete instruction, or any other tool)
You have to do that for every reference that appears pointing to the Target server
The following table shows the most common set of objects that eDirectory creates for each server in the replica ring
SSL DNS certificate
dn: cn=SSL CertificateDNS - tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL|
dn: cn=DNS AG tqidnlabedir03.novell.com - tqidnlabedir03,ou=SERVIDORES, ou=SERVICIOS,o=NOVELL
SSL IP Certificate
dn: cn=SSL CertificateIP - tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
IP AG Object
dn: cn=IP AG 10.10.251.85 - tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
dn: cn=SAS Service – tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
dn: cn=SNMP Group – tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
LDAP group object
dn: cn=LDAP Group – tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
LDAP server object
dn: cn=LDAP Server - tqidnlabedir03,ou=SERVIDORES,ou=SERVICIOS,o=NOVELL
The very first thing to do in the dibclone process is to start the ndsclone module in the source server,, an easy way to check if the module is already running is by typing the following command:
# ndstrace -c modules | grep clone
In case the module is running, you will see the following screen:
In case the module is not running, you will need to add the following line in the ndsmodules.conf file (located under /etc/opt/novell/eDirectory/conf/)
ndsclone auto #Clone eDir
After that restart the ndsd service
Go to iMonitor in the source server and run the DIB Clone Configuration ( “Agent Configuration > Clone DIB Set > Create New Clone”)
Specify the fqdn of the Target server and make sure that the “Clone DIB Online box” is unchecked and the click in the Submit button
iMonitor will report an “- 663 URL: /nds/agent/clone/status/data” error which is expected, since the offline dib clone process locks the database in the source server
Manually copy the *.nds, nds*, and nds.rfl/*.* files (usually located under /var/opt/novell/eDirectory/data/dib) from the source server’s DIB directory to a Target server in the same directory (Usually /var/opt/novell/eDirectory/data/dib)
sudo rsync -P --log-file /var/log/rsync-dib-201501-nds -avz *.nds email@example.com:/var/opt/novell/eDirectory/data/dib/
sudo rsync -P --log-file /var/log/rsync-dib-201501-nds_ -avz nds* firstname.lastname@example.org:/var/opt/novell/eDirectory/data/dib/
tqidnlabedir01:/var/opt/novell/eDirectory/data/dib # sudo rsync -P --log-file /var/log/rsync-dib-201501-rfl -avz nds.rfl/*.* email@example.com:/var/opt/novell/eDirectory/data/dib
Copy the nds.conf file from source to target server and edit it according to the target server name ips and hostnames
In order to disable the inbound sync (avoiding updates in the source server ) export the “NDSD_DISABLE_INBOUND=Y” variable
After exporting the variable, restart the ndsd service in the origin server
# /etc/init.d/ndsd stop
# /etc/init.d/ndsd start
Make sure that the target server is an eDirectory box (it has the ndsd binaries) and the DIB clone file set is properly located (usually under /var/opt/novell/eDirectory/data/dib )
Make sure that the master replica is up and running, because the target server will communicate with it once the ndsd service in the target server is started, to do so... run the following command in the Master server
#ndsrepair -P -Ad
Stop the ndsd service in the target server in case it is running
# /etc/init.d/ndsd stop
Copy the NICISDI.KEY file from the source server to the target server
#scp /var/opt/novell/nici/0/nicisdi.key firstname.lastname@example.org:/var/opt/novell/nici/0/
Start the ndsd service in the target server.
# /etc/init.d/ndsd start
You will see an error referring to the LDAP certificate which is expected. In the next steps this error will be addressed:
Run the following command in order to create the SAS, LDAP and SNMP objects related to the target service
# ndsconfig upgrade
The message “The instance at /etc/opt/novell/eDirectory/conf/nds.cof is upgraded successfully” is the key. If you see it, everything goes ok so far.
Enable the inbound synchronization by executing the following command in the source server
1. Enter in ndstrace
2. In the ndstrace command line, type the following
# set ndstrace =!e
3. Depending on the flags that are enabled you will see something like this:
export NDSD_DISABLE_INBOUND=N; /etc/init.d/ndsd stop; sleep 5 ;/etc/init.d/ndsd start
Verify the health in the replica ring and the references of the target server by following these commands in the source and target server and if everything goes ok, you will see 0 errors
# ndsrepair -E
# ndsrepair -N
Voilá, you will have an eDirectory ring conformed by 3 servers, the target server is now back to life!
By doing the nds offline process you are able to restore an eDirectory box in case of a disaster of by adding a new server in case the DIB files are too big and you don't time enough to let the natural sync process to do its job.