OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

I have recently installed OpenManage Server Administrator 6.3.0 on 64-bit Ubuntu Lucid running on PowerEdge R510. I have run into some problems and would like to share workarounds that I found.

Problem 1: OMSA command log contains messages "Rolemap file has incorrect permissions set: Assigning default permissions to the user". These messages are added after every login to OMSA web UI.It is also not possible to modify any permissions by editing that file, as it is ignored.

Solution:  Change rolemap file's permissions to 640:
chmod 640 /opt/dell/srvadmin/etc/omarolemap

Problem 2: During boot the following mesages appear in syslog: "dataeng.hotplug: /etc/omreg.cfg not found"

Solution: File omreg.cfg is in /opt/dell/srvadmin/etc/, rather than /etc. We can create in /etc a link pointing to the correct location:
ln -s /opt/dell/srvadmin/etc/omreg.cfg /etc/omreg.cfg

Problem 3: During boot the following messages appear on screen: "touch: cannot touch `/var/lock/subsys/dsm_om_connsvc': No such file or directory" and "touch: cannot touch `/var/lock/subsys/ipmi': No such file or directory". If you use plymouth splash screen, these messages can be found in /var/log/boot.log.

Solution: /var/lock is a tmpfs filesystem, which gets created at every boot and destroyed on every shutdown. If we create a subdirectory "subsys" there, it will be wiped out on shutdown. Instead we will edit one of OMSA init scripts to create this directory. A good script is /etc/init.d/instsvcdrv, to which we add the following line just after "start)":
mkdir -p /var/lock/subsys
Option -p causes mkdir to silently proceed if the subsys directory already exists.

Problem 4: There is a 20-45 second lag when running command "omreport system platformevents" and when accessing certain OMSA web pages, such as "System | Alert Management | Platform Events". It is possible that other omreport commands and other pages suffer from this problem as well. Curiously, everything works fine during first two minutes of server operation, and the lag starts occurring only after OMSA daemons had been up for more than 2 minutes.

Analysis: This problem is quite mysterious. It appears that the lag is caused by process "kipmi0" not running. According to strace, omreport attempts to contact this process several times, waits in vain for reply, and then times out and proceeds successfully. Process kipmi0 is started by one of OMSA init scripts, but then is killed 2 minutes later. The code for this appears to reside in library libdchipm.so. I must admit that I do not understand this behavior. In OMSA 6.0.1 (older version available for Ubuntu), process kipmi0 was not killed, and the lag did not occur. My testing shows that preventing this process from being killed fixes the issue and does not introduce any noticeable problems.

Workaround: A proper solution would be to prevent OMSA from querying process kipmi0, as it is clearly superfluous. Also the library libdchipm.so could be modified not to kill kipmi0. However, as debugging and compiling OMSA code is not an attractive proposition, here is an ugly hack. As luck has it, libdchipm.so does not kill kipmi0 directly, but does so by calling the script /etc/init.d/instsvcdrv with parameter "disablethread". We can then modify this script to ignore such requests. We will do so by finding the following section of code:
        disablethread)
                instsvcdrv_openipmi_force_thread disable $2
                EXIT_STATUS=$?
                ;;
and changing it to:
        disablethread)
                EXIT_STATUS=0
                ;;

Problem 5: There is an approximately 25 second lag when stopping or restarting OMSA web server dsm_om_connsvc, for example by running the command "service dsm_om_connsvc stop" or "service dsm_om_connsvc restart".

Analysis: Process dsm_om_connsvc exits without deleting its pid file (/var/run/dsm_om_connsvc.pid), which confuses logic in the init script. The script would loop 5 times, each time waiting for 5 seconds for the pid file to vanish, which will not happen because the dsm_om_connsvc had already exited.

Workaround: A proper fix would be to modify dsm_om_connsvc code to delete the pid file. The hack below goes around this by modifying /etc/init.d/dsm_om_connsvc, so that it deletes the pid file if it is still present 5 second after process in question was killed. This way the lag is reduced fivefold. The following patch modifies /etc/init.d/dsm_om_connsvc:

--- dsm_om_connsvc.orig 2010-10-13 14:19:19.000000000 -0500
+++ dsm_om_connsvc      2010-10-13 14:52:54.000000000 -0500
@@ -218,2 +218,3 @@
        STATUSVAL=$?
+       PID_FILE="/var/run/${DAEMON}.pid"
        #wait for the process to close down if porcess is running or the pid file is there
@@ -227,2 +228,8 @@
                STATUSVAL=$?
+               #If daemon is dead but pid file is still there, delete the file
+               if [ $STATUSVAL == 1 ]
+               then
+                       rm -f ${PID_FILE}
+                       STATUSVAL=2
+               fi
        done

Hope it helps someone.