Highlighted
Magic999
Bronze

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.

Tags (1)
0 Kudos
5 Replies
Scamander
Copper

Re: OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

This was definitely helpful. Just did a similar install with similar observations. Thanks for sharing. This saved me some time.

0 Kudos
Magic999
Bronze

Re: OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

Just installed OMSA 6.4.0 and the above bugs are still there, except perhaps for the second one, that I did not notice this time. Fortunately, same bugs, same workarounds.

0 Kudos
Magic999
Bronze

Re: OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

OMSA 6.5.0 still has these bugs, except for problem #2. In this version the location of config files was changed, thus the workaround for problem #1 should now be:

chmod 640 /etc/opt/dell/srvadmin/omarolemap

Also line numbers in the workaround for problem #5 are no longer valid (but the modification itself is still good).

0 Kudos
pramsey
Copper

Re: OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

Big help to me, especially since information like this is a bit hard to come by. Thank you for taking the time to put it out there.

0 Kudos

Re: OMSA 6.3.0 on Ubuntu 10.04 LTS (Lucid)

Many thanks - this saved me some hair tearing when I couldn't get out of the poweruser role because of the permission problem on the omarolemap file...

0 Kudos