Using Scripts to Start and Stop IDM Drivers at the Server Console

Absent Member.
Absent Member.
0 2 6,842
0 Likes
Novell's Identity Manager (IDM) is a tremendously powerful and flexible product to synchronize user accounts from a great number of different systems and directories, including Novell’s eDirectory, Microsoft’s Active Directory, LDAP directories, Linux/Unix servers, Lotus Notes, and many others.

Once you have the IDM product up and running, you're always looking for ways to simplify and automate various maintenance tasks.

Problem



The standard method for starting, stopping and checking the state of IDM drivers is as follows:

1) Launch iManager on a workstation.

2) Log in to a particular server,

3) Select Identity Manager > Identity Manager Overview in the navigation pane.

4) Select the desired Driver Set,

5) and then finally select the particular IDM driver and click on the driver control button to Start, Stop, or Get Current Status for that driver.

This process can be slow or limiting, especially if you are at the NetWare server console, and you just want to quickly start, stop, or view the current state of a driver.

Solution



Novell Identity Manager (beginning with version 2) provides a basic server-side utility, DXCMD, which allows the operator to control the IDM drivers from the server console. DXCMD is a very basic interactive menu-driven utility and not particularly easy to use. But it also accepts command-line parameters, which allows you to script certain operations.

Below are some simple DXCMD scripts you can implement on IDM servers in order to facilitate the starting/stopping of IDM drivers from the server console. To better use these scripts, in each eDirectory tree we would create a service account (in my examples, named IDMservice), and give the accounts Compare, Read and Write attribute rights to the DriverSet object in each respective eDirectory tree. This service account is used by the DXCMD utility in the scripts. The script files would be copied to the SYS:\SYTEM directory.

Sample Scripts

IDMSTART.NCF


;### IDMSTART.NCF ###
dxcmd -user IDMservice.org -password password* -start %1.DriverSet.org



IDMSTOP.NCF


;### IDMSTOP.NCF ###
dxcmd -user IDMservice.org -password password* -stop %1.DriverSet.org



LDDXCMD.NCF


;### LDDXCMD.NCF ###
dxcmd -user IDMservice.org -password password*



Note: You need to supply the password of the IDMservice account here.

Usage

In order to use these scripts, we have to supply the name of the IDM driver as an argument, such as:


idmstart Driver1 - starts the driver: Driver1.DriverSet.org
idmstop Driver1 - stops the driver: Driver1.DriverSet.org



If the wrong driver name is provided as the argument, the DXCMD simply fails to execute. The error message can be seen in the logger screen, such as:


java: Class com.novell.nds.dirxml.util.DxCommand exited with status -601



The LDDXCMD.NCF script is used merely to load the DXCMD utility using the IDMservice account. This is useful for checking the current status of all drivers on the server.

A word on security: these scripts contain the service account password in clear text. This is mitigated to a degree by the fact that this is a non-admin account, with only specific Compare, Read and Write attribute rights to the driverset in eDirectory. In addition, the scripts are stored in SYS:\SYSTEM, where only admins have file system rights. Also, since the scripts can only be run at the NetWare console, only admins should have access to the console to execute them. If non-admin personnel have direct access (or remote access) to the NetWare console, the game is over, anyway.

However, if you choose, you can omit the “-password” parameter in the scripts, and DXCMD will pause to prompt you for the password.

Linux Scripts

Up to this point we have been assuming that IDM is running on a NetWare server. That’s fine, but what if we are now running IDM on a Linux server? After all, eDirectory and Novell Identity Manager are completely cross-platform applications and can run equally well on NetWare, Linux, Windows and Solaris. So let’s look at the Linux (or Unix) version of these same scripts.

idmstart


### idmstart ###
dxcmd -user IDMservice.org -password password* -start $1.DriverSet.org



idmstop


### idmstop ###
dxcmd -user IDMservice.org -password password* -stop $1.DriverSet.org



lddxcmd


### lddxcmd ###
dxcmd -user IDMservice.org -password password*



Note: You need to supply the password of the IDMservice account here.

Linux Usage

Because the DXCMD utility is cross-platform, these are essentially the same commands as we saw on the NetWare platform. Notice that although eDirectory is not case-sensitive (for the NCP names such as IDMservice.org), the Linux/Unix operating system is case-sensitive. So “idmstart”, “IDMSTART”, and “IDMstart” all refer to different files. Also, there is no need for file extensions, such as “.ncf”.

Also, these files would need to be located where the Linux search path can find them, such as the bin directory for the current user, or the /usr/bin directory (for all users), or another available search path.

Also note the slight difference in syntax: the “%1” used in the NetWare script, which refers to Argument1, is replaced with “$1” in the Linux variant of the script.

Once again, to use these scripts, we have to supply the name of the IDM driver as an argument, as in:


idmstart Driver1 - starts the driver: Driver1.DriverSet.org
idmstop Driver1 - stops the driver: Driver1.DriverSet.org



On the Linux platform, if the wrong driver name is provided as the argument, the DXCMD again simply fails to execute. But this time the error message is simply written to the console, such as:


Linux1:~# idmstart wrongname
-601
Linux1:~#



Of course, if you look up the eDirectory error code -601, you see that it refers to “no such entry”, indicating that you have referenced an eDirectory object that does not exist.

Once you have gotten into scripting to automate tasks (especially in the Linux realm), then you quickly find out that there are lots and lots of time-saving things you can do, utilizing different command-line parameters within your scripts.

And I must not omit this standard “disclaimer”:

Scripting (in general), whether in NetWare, Windows, or Linux, can do wonders to automate and schedule repetitive tasks, but we must always be very careful with it. The wonderful thing about scripted tasks is that they perform commands exactly as we tell them to do, quickly and repeatedly. The terrible thing about scripted tasks is also that they perform commands exactly as we tell them to do (not especially as we think that we are telling them to do), quickly and repeatedly.

Well-written scripts can do a world of good. Poorly-written scripts can put you into a world of hurt. So always, always test your scripts (repeatedly) in a test lab (non-production) environment, and then carefully test them again in very limited fashion in the production environment, before full-scale use.
2 Comments
Absent Member.
Absent Member.
A HUGE thanks for supporting NetWare with your script examples. Some folks are forgetting that IDM still runs on NetWare (at least until the next IDM release) when they write up their solutions or tips.
Absent Member.
Absent Member.
Great tip, thanks. There is one thing that should be considered. Assume the driver is not completed its transaction (ex: slow database or poorly written queries). If you run a "stop" command on it with dxcmd, the driver will stuck at "shutting down" state until it completes its transaction even if it seems "STOPPED" when you check with dxcmd. IDM version 3.0.1, platform SLES 10..
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.