Since the release of eDirectory 8.8.0 support for multiple instances of eDirectory on a single box has been available. Using the ndsconfig and especially the newer ndsmanage tool configuring multiple instances of eDirectory is also very easy to do. One feature that has been missing since that time has been the ability to start/stop multiple instances as easily as one can start/stop the first root-based eDirectory instance of a root-installed eDirectory during startup/shutdown. The time has come to overcome that.
To this day the eDirectory init script (/etc/init.d/ndsd) only starts the first instance of eDirectory it finds in the /etc/opt/novell/eDirectory/conf/.edir/instances.0 file which only works for a root-based eDirectory installation. Starting/stopping other instances isn’t a terrible thing to do, but if you forget to stop your instance before rebooting all of the other instances (besides the aforementioned first instance) are killed (which could lead to corruption of the DIB eventually), and if you forget to start your other eDirectory instances you can have more downtime than desired. Creating a script from /etc/init.d/skeleton for this task is fairly simple but I need to make note of a few decisions made during this process just to help make sure everything is clear with the script.
First, I presume in most cases this will be used for root-based installations of eDirectory. With that in mind I believe this script, with one minor but planned-for modification, will work with non-root installations of eDirectory. A variable defined as $EDIR_BASE_PATH exists which specifies the base of the eDirectory application installation, which by default is a null value. This is the prefix before /opt/novell/eDirectory…. or /var/opt/novell/eDirectory which does not exist for a root-based installation. Change this one variable to the location where a non-root eDirectory installation is extracted and I believe this script will work for those, though I have not tested that at all at this point.
Second, I assume the script, when running, will have ‘root’ rights. Modifying it to not need that should be possible but as this is made to be a startup/shutdown script it doesn’t make sense to me to do that. Copy/paste code to do that kind of thing if you’d like but having a system where this is not needed but starting/stopping multiple instances is while having multiple users owning the instances seems like a fairly odd situation.
Third, I assume ‘sudo’ is okay on your system. As this runs as ‘root’ I can’t imagine it’s a huge deal since SUSE’s /etc/sudoers file allows root to do whatever no matter what. Other distros (I have not tested RedHat) may have complaints, but workarounds in /etc/sudoers should be trivial. I tried going with startproc but because (in theory) all of the eDirectory instances use the same binary and since I did not want to duplicate what the ‘ndsmanage’ or ‘ndsd’ scripts do already in creating my own PID file I am using sudo. It does the job nicely and if you would like to change things that is fine but this is the way it is for now.
Fourth I decided to create a log file for this script in (by default) /var/opt/novell/eDirectory/log/ndsd-multi.log which is root-owned. Currently default permissions are set by the system and you can change them. This log file is never truncated or rotated so keep track of it if you reboot often.
Fifth, the script uses the ‘logger’ command when it starts/stops instances since implementing that could be useful and was trivial to enable syslog events from the script overall. The logger output is very basic and not dependent on success/failure at all….. just there so you can keep track and do a little debugging of this script’s interactions with eDirectory.
Sixth, because multiple instances are involved and any number could be up/down at a time the start/stop statuses are not reliable at all. I’m open to suggestions on how to make this perfect; my only idea currently is to sum up all of the return codes from sudo and if any of them are non-zero the sum will be non-zero and that can be the status, but I hate doing weird stuff like that since it just means everything shows up broken instead of everything showing up working.
Seventh, the script works for multiple users on the same system. I did this by creating a configuration file located at (by default) /etc/opt/novell/eDirectory/conf/ndsd-multi.conf which has one nds.conf file (which corresponds to one eDirectory instance each) per line. These files are case-sensitive as always and there should be no spaces before/after them… just one eDirectory configuration file per line. The script determines who owns that eDirectory instance and then tries to start it appropriately with the existing ndsmanage command. Logs are written as mentioned above.
Eighth, I opted to have the ‘status’ feature of this script call ndsstat for each instance that is configured. This can have a large annoying delay if an instance is down though that should not be the norm. Also the status output is not written to the log file mentioned above as it doesn’t seem to be as useful (you’re already getting the status somehow and presumably using the output) and it could cause the file to bloat more than expected (a fair bit of output can come from the ndsstat command).
Ninth, so far this script does not like my Solaris 10 box. For reasons like this I like writing in Perl that just works across platforms a bit more nicely than Bash, but oh well for Solaris users at this point in time. I imagine an experienced Solaris admin can port this in about ten minutes after they finish laughing at my poor coding.
Tenth, this should not be used on the instance already managed by the /etc/init.d/ndsd script as it duplicates that effort. Either do not use the other at all or do not use this one for that one’s eDirectory instance.
Eleventh, and hopefully this is obvious, but use bunzip2, bzcat, file-roller or something like that to extract the script from the compressed file attached to this post.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.