A question I was recently asked was how to monitor an Identity Manager (IDM) driver to make sure it was running. Doing this is a fairly simple task that can be executed securely and regularly. The two methods discussed will be ‘dxcmd’, a utility shipped with IDM, and LDAP.
An important thing to note up front is that the Driver State is stored in eDirectory as an attribute on the driver object itself. This attribute is readable by all, so we should not need to have sensitive user information including passwords stored to access the required information, unless our method to check the status requires a login. In those cases using a regular limited user is highly recommended. Also important to note is that the Driver-State attribute is stored per-replica, meaning that one server can have the driver running while another (for failover) may not be. ‘dxcmd’ can be pointed to any desired replica and should read that specific replica. LDAP can also be pointed to any desired server, and as long as that server hosts DirXML, it should work properly for reading the attribute.
To find out more about the ‘dxcmd’ parameters you can type
In the demo tree a LoopBack driver is located at the following LDAP-based DN:
The userID for a random user whose password is ‘asdfasdf’ is located at the following location:
With that all in mind, the following command would work to retrieve the state of the driver from the command line (this should be fairly platform-independent, though the demo is on a Linux server):
dxcmd -user test002.suse.myorgs -password asdfasdf -getstate LB0.DrvrSet0.idm.services.system
With ‘dxcmd’ it may not be obvious at first where the desired return value is to be found. The output from the command looks like this:
DirXML Command Line Utility version 1.0 Copyright (C) 2003-2005 Novell Inc., All Rights Reserved Logging in using: host: idm0lin-0/22.214.171.124 user: test002.suse.myorgs DirXML version is 126.96.36.199638. Driver set DrvrSet0.idm.services.system.IDM0TREE. is associated with the server.
Note that it does not actually tell you the state at this point. The state is returned as an integer as the script’s return value. This is in line with regular command returns found in all operating systems. To retrieve that value from the shell, use the following command:
The number 0 will show up for a stopped driver; 2 indicates a running driver; 1 and 3 are for starting and stopping, respectively. This can be used in a scripted scenario to compare against previous values to detect changes of driver state (running to stopped, for example) or just to send a notification whenever a driver is not running. Creating the script and running a cron job (or ‘at’ job on Microsoft Windows) can automated this, with notifications as flexible as computers can make them. Note that ‘dxcmd’ can be pointed to another server to retrieve the state from that server.
For an LDAP-based solution, the following is an option:
ldapsearch -h 188.8.131.52 -p 389 -x -s base -b cn=LB0,cn=DrvrSet0,dc=idm,dc=services,dc=system DirXML-State
The return in this case includes the desired state:
# extended LDIF # # LDAPv3 # base
with scope base # filter: (objectclass=*) # requesting: DirXML-State # # LB0, DrvrSet0, idm.services.system dn: cn=LB0,cn=DrvrSet0,dc=idm,dc=services,dc=system DirXML-State: 2 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
Parsing through this output for the desired value (DirXML-State: 2) is simple enough in any scripting language. Also, this inherently is pulling the value from the server specified in the ldapsearch command. This command is available on all operating systems and included on most by default (Microsoft Windows being the most notable exception).
With the information included above it should be fairly trivial to create a solution that notifies you when a driver stops or does not restart (power outages, hardware failures, etc.). Note that there are many other potential return values that could be read from servers in either case if some types of disasters take place (no connection to server, DS failing, etc.) and those should be tested and planned for. Also note that having the cron job e-mail you over and over and over could cause other issues (for example, if this is running every minute and you go on vacation).