The Vrdim modules are the NDS modules for DirXML for Linux.

generally, you would not need to know about Vrdim except when Troubleshooting DirXML

Typical location #


-rwxr-xr-x 1 root bin   1309 Jun  1  2012 libvrdim.la
lrwxrwxrwx 1 root bin     17 Jul 16 13:31 libvrdim.so -> libvrdim.so.3.0.0
lrwxrwxrwx 1 root bin     17 Jul 16 13:31 libvrdim.so.3 -> libvrdim.so.3.0.0
-rwxr-xr-x 1 root bin 343787 Jun  1  2012 libvrdim.so.3.0.0

Loading and unloading#

Normally, the modules will load anytime the binaries are installed.

If required, you can manually unload and load vrdim.

Troubleshooting DirXML#

Following an upgrade to EDirectory, we could no longer start DirXML and received this error:

DirXML SE Multiple eDirectory instances are installed. After we add a new server to the driverSet. When we try to start a driver on the server we obtain the following dialog:

Unable to start the driver IDV to Unix.DriverSet.esc.willeke.com

com.novell.admin.common.exceptions.UniqueSPIException: (Error -783) The DirXML Interface Module [VIRDIM] is not currently loaded into NetWare or into DHost.

Also, when we perform:

ndstrace -c modules --config-file /data/nds/idv/nds.conf|grep 'vrdim' 
Not Loaded vrdim 
The vrdim module must be loaded for IDM to work. Re-booting the server does not fix the issue.

Although manually loading the module, appeared to load,

ndstrace -c "load vridm' --config-file /data/nds/idv/nds.conf 
we still get the (Error-783)

Prevent DirXML from autoloading when eDirectory (NDSD) starts [1]#

Be careful!
Also, This will not work with IDM 4.7. (We do not know what to do with IDM 4.7)

If you must get eDirectory running without DirXML, you may wish to try moving the libvrdim.so.?.?.? to another location outside of the path and restart eDirectory. IDM engine running on Linux/Solaris/AIX Platform (pre IDM 4.7):

  • Stop ndsd with the command "/etc/init.d/ndsd stop" (without the double-quotes)
  • Move the libvrdim.* files from their original directory to a different directory
    • in eDirectory 8.7.3.x they reside at /usr/lib/nds-modules/
    • in eDirectory 8.8.x 32 bit: they reside at /opt/novell/eDirectory/lib/nds-modules/
    • in eDirectory 8.8.x 64 bit: they reside at /opt/novell/eDirectory/lib64/nds-modules/
  • Start ndsd with the command "/etc/init.d/ndsd start" (without the double-quotes)
  • Start ndstrace
  • Within ndstrace, type:
    • set ndstrace=nodebug
    • set ndstrace=+time
    • set ndstrace=+tags
    • set ndstrace=+misc
    • set ndstrace=+dxml
    • set ndstrace=+dvrs
    • ndstrace file on
  • Leave ndstrace it running on screen
  • Move the libvrdim.* files back to their original location
  • Back on the ndstrace screen, type "load vrdim"
  • After you see the errors, stop ndstrace. The trace file will show messages related to why the VRDIM module (IDM Engine) won't start

This will allow you to start ndsd and set the heap settings to something else.

Then move the libraries back and restart ndsd or use:

ndstrace -c "load vridm' --config-file /data/nds/idv/nds.conf
from within ndstrace.[1][2]

In this case#

As it turned out, the issue was with the EDirectory upgrade that changed the DirXML Engine JVM We also would see these entries within the trace logs:
2013091584 MISC: [2014/07/29 15:52:52.7] Entry .DriverSet.esc.willeke.com. has an Illegal Attr Name: .sssActiveServerList.[Attribute Definitions].[Schema Root], failed, illegal attribute (-608)

The key was finding this error in the trace files:

The Identity Manager 4.0.x engine fails to load and the following error messages are shown in ndstrace +dxml:
DirXML starting.
Error initializing DirXML: java.lang.UnsupportedClassVersionError: novell/jclient/JCContext
at com.novell.nds.dirxml.engine.MiscDS.createLocalContext(MiscDS.java:73)
at com.novell.nds.dirxml.engine.DirXML.run(DirXML.java:255)
at java.lang.Thread.run(Unknown Source)

DirXML shutting down...
DirXML shutting down.

The " java.lang.UnsupportedClassVersionError" issue pointed us to DirXML Engine JVM which leads us to Java Versions And Running Programs.

After poking around we found that there the Driverset had the following ACL (eDirectory Attribute) for SssActiveServerList:

ACL: 2#entry#[Public]#sssActiveServerList

More Information#

There might be more information for this subject on one of the following: