A strange start-up problem occurs with the Lotus Notes Driver on Linux (or Solaris, or AIX). The Driver does not answer to the driver identification query from the Remote Loader (see the trace below). In addition, the zz_ndxml.id file that is normally created in the Domino data directory (i.e. /local/notesdata) is not created. (By the way, what is this zz_ndxml.id file for?)
The Remote Loader seems to be running correctly as a user with full rights to the notes directory. Creating files with this user in the directory works fine. The ndsrep configuration file, dsrepcfg.nsf, is also created successfully. See the Example below for a trace snippet showing the problem.
The first thing to check is the Notes User password that is set in the Notes Driver Configuration (application password). Reset it to the correct password that corresponds with the Notes Driver’s user.id file (under driver settings) and try again. This problem can occur the first time this driver has started up at a specific location. It is possible that the driver is stalled inside a Lotus API waiting for a password to be typed in at the user interface. This issue sometimes happens, even though a correct password has been appropriately provided via the driver’s configuration.
Apparently the Lotus Notes authentication API prompts for the password regardless if the correct one was supplied to the API method. Because you are running on Solaris (or Linux, or AIX), rdxml is probably running as a daemon. So, there is no user interface for the Lotus API to get the password, but it is waiting anyway. If the password were typed in, then zz_ndxml.id would be created. zz_ndxml.id is a Lotus Notes id file, created by the driver. It has no password set (a null password). zz_ndxml.id has no rights anywhere within the Notes system. Once zz_ndxml.id is created, it is used by NotesDriverShim.jar to initially authenticate to Notes, and because zz_ndxml.id has a null password, no password is prompted for by the Lotus Notes authentication API.
Once this initial authentication has happened, then the NotesDriverShim.jar uses the Notes Driver user.id file specified by the driver configuration to “switch” the authentication to the Notes Driver User. Thus, zz_ndxml.id is an API workaround used by the NotesDriverShim.jar to avoid Lotus Notes API password prompting.
What can you do?
Option 1: Run the Remote Loader from the command line using the “pure java” remote loader instead of rdxml. This will allow the Lotus Notes API to prompt for a password within the console box running the remote loader. The password can then be typed in when prompted for. zz_ndxml.id will be created, and hopefully the driver will start up successfully. Restart the driver, and it shouldn’t prompt for a password anymore. If everything starts OK (without password prompting), you can return to using rdxml in the typical fashion.
Option 2. Create your own User.id file with a null password. Use a client on the Notes system to do this. The rights you apply to the idFile are not necessarily important for the operation of the driver, so give it no rights. Remember to give it an expiration date far, far, far in the future. Name (or rename) this user.id file to zz_ndxml.id and place it in the Domino data folder (i.e. /local/notesdata). Start the driver and see if everything starts OK.
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.