If you have used Novell Identity Manager, you'll be familiar with the concept of a Remote Loader. An interesting question would be, which remote loader should I use? There are at least four different styles of Remote Loaders available.

Some drivers (like the Novell Integration Manager, aka Composer, aka the very powerful screen scraper from SilverStream, that alas is sadly deprecated, and will never return, I mourn for its loss) deploy and run in the eDirectory server's memory space and process. This is astonishingly annoying during development, because any changes to an underlying file require an eDirectory restart. More pedestrian a concern is that a problem in the driver code then has the possibility of causing a problem for eDirectory.

In general, most drivers can be run as Remote Loaders. Some exceptions are things that are really just belong in the eDirectory memory space, such as the Loopback driver, Work Order driver, Null driver, and eDirectory driver. These drivers really do not have a remote box to run on; they run on eDirectory only.

1: Remote Loader for Windows

Probably the most commonly deployed driver with a remote loader is the Active Directory driver - the first of the four types. This has a Win32 GUI front end that generates the filename.conf file based on the settings you select. It has the fun "feature" that if your console session (Terminal Services, VNC, or even local on a VMWare box) is not at high enough resolution, the fields at the bottom are unreachable and there is no easy access, short of blindly tabbing to control the values - nor is there any way to resize the window. Of course you could just edit the config text file, if you know the correct values to control it.

Click to view.

This Remote Loader has the distinction of being able to run Win32 native DLL driver shims on the Windows platform, as well as Java-based driver shims. Many drivers can use this Remote Loader if you are running it on Windows.

Driver shims are the code that runs the driver, whether it be run by the Remote Loader, or run by eDirectory in its memory space.

Also, you get a nice GUI to control one or many Remote Loaders on the Win32 box. A little annoying is the fact that you cannot edit the configuration of a running instance. It requires that you stop the remote loader instance to edit the settings. It would be nice to be able to edit it while it is running, then just restart it.

Click to view.

2: Remote Loader for AS400, *nix, and Mainframes

The next Remote Loader is much less commonly deployed, but is probably the nicest of the set. The group that develops the Scripting driver and the Bidirectional drivers for AS400 (Midrange or i5OS), Linux/Unix, and Mainframes have their own Remote loader.

It has one the nicest features of the entire set. It is a four- or five-option menu that runs on the native platform (compiled for the Midrange OS, or the Mainframe, or for Unix's). It is a very simple menu-driven interface, which can be much more effective than a poorly constructed GUI.

The really nice part is how they handle getting the certificate needed for SSL. You need to provide the public key of the Tree Certificate Authority's self-signed, Trusted Root Certificate. Every certificate that the Tree CA touches is based on that trusted root certificate. This Remote Loader uses the fact that the certificate that uses an LDAP over SSL/TLS instance for this driver's eDirectory is also based on the same trusted root, and that TLS allows them to extract it from an LDAP TLS bind.

The remote loader configuration asks you to specify the LDAP server IP address and port. The remote loader makes a TLS connection, gets the trusted roots public key, and adds it to the keystore. Done - no fuss no muss, no possibility of error. (No worrying, did I export the right public key? Should it be .der or .b64? (B64 for Windows, DER for other platforms) How do I get it to the remote machine?).

This Remote Loader is possibly the simplest to configure. All the functionality you need is still there, since there is a configuration file (depends on the OS you are running on), such as /etc/i5osdrv.conf for AS400, or /etc/nxdrv.conf for the Linux/Unix driver) that supports all the options that the other Remote loaders support.

3: Java-based Remote Loader - Full Featured

The last two Remote Loaders are somewhat similar - they are Java-based Remote Loaders. There is a more full-featured one that comes with its own JRE/JVM - it is very self contained, is relatively easy to get going, and is available on pretty much any platform that eDirectory runs on. I suppose you should be able to get it to run on Windows if you had to, but I am not sure why you would bother.

The configuration file is in the same basic format. In fact, if you were truly lazy, you could probably use the GUI from the Win32 Remote Loader to generate a configuration file to use on it.

The downside to this remote loader is that because it includes its own JRE/JVM, it launches it as binaries, making it harder to configure unique parameters.

The other big issue you can run into is a 32/64-bit problem. The included JRE/JVM is compiled (usually by the vendor of the OS) as 32-bit, and it should run on your 64-bit server. This should work fine, calling purely Java-based driver shims. But the moment you need to start calling a native library (such as a .DLL on Windows - not applicable in this case, but just as an example - an .so file on Unix'es, or a library file on an AS400 midrange server) you can run into issues of having a 32-bit JVM trying to load a 64-bit native code library. In general, this should be pretty rare. The SAP drivers (HR and User) use a Java Connect library (sapjco.jar) that has native modules compiled for the platform and can run into this issue.

This Remote Loader runs from the /etc/init.d/rdxml (on Linux'ey variants) or /etc/rdxml (on AIX) start script. It provides commands like start|stop|status|restart and then calls a script to set a couple of variables, which is where the customization is done. In ps -ef on Unix platforms it would look something like this:

/opt/novell/dirxml/bin/rdxml.bin -config /etc/opt/novell/dirxml/rdxml/rdxml-driver.conf

You would edit the file /opt/novell/dirxml/bin/rdxml, which sets the variables (like LIBPATH, CLASSPATH if you want, DHOST_JVM_OPTIONS if you need them). Then the /opt/novell/dirxml/bin/rdxml.bin file is called to actually run the Java class with the correct parameters.

4: Java-based Remote Loader - Simple

The final Remote Loader is the simplest of them all, the dirxml_jremote (in the \java_remoteloader on the install media). This assumes a JVM is present and configured. It also assumes that the system PATH and CLASSPATH variables are set and working, and that you created a proper configuration file.

If all those things are done, it is one of the simplest and easiest remote loaders to get working. If you are not familiar with all the steps I just labeled, then it may not be so easy.

This remote loader does not include a start/stop script, so you are expected to provide it yourself. You can reuse the /etc/init.d/rdxml if you want, by changing some of the executable paths. The key feature of this Remote Loader is its small size. It is the smallest footprint, relying on existing JVM's (32- or 64-bit, whatever is installed and configured) and puts the fewest files in the file system.

There is possibly a fifth type of Remote Loader, but I have never used it, so I cannot comment directly. The old Novell Account Management tools that became IDM drivers, (usually the not-bidirectional AS400, Mainframe, and Unix - sometimes called the fanout drivers) may have a slightly different variant of Remote Loader than the ones presented above.

Did I miss any? Please respond and let me know!

And looks like there are more possibilities here, details to follow.