#184 Command execution on resource fails

[XeRO]

I'm using version 4.7. (Not sure about the category I put this bug in.)

As Michael pointed out on the mailinglist (subject "Dropbear commands not executed on resource"), commands on a resource are not executed properly, when the OpenQRM server was installed with a different prefix /usr/local/openqrm for example.

This happens because the command submitted via dropbear uses the $OPENQRM_SERVER_BASE_DIR to also build the command line on the resource

/usr/local/openqrm/bin/dbclient -K 10 -y -i /usr/local/openqrm/etc/dropbear/dropbear_rsa_host_key -p
1667 root@192.168.1.10 "/usr/local/openqrm/bin/openqrm-cmd reboot"

If the server image of the resource is (OpenQRM-wise) untouched, the OpenQRM binaries will be located in /usr/share/openqrm.

Michael put a patch in his posting which fixes this behaviour in sbin/openqrm-exec (I attached Michaels patch). Yesterday I stumbled across another problem when using KVM. But I don't exactly remember where it happend. My solution to this problem was to create a link inside the server image from /usr/local/openqrm to /usr/share/openqrm.

So a global solution could be to create a link inside the image, whenever $OPENQRM_SERVER_BASE_DIR is not /usr/share/openqrm.

[XeRO]

Michael's patch

[XeRO]

I found another workaround for this problem. The easiest way seems to be to just set a link on the openqrm server.

I installed openqrm in /usr/local/openqrm instead of the standard path.

For this workaround I set a link to /usr/share
ln -s /usr/local/openqrm /usr/share

After that I reset the OPENQRM_SERVER_BASE_DIR to /usr/share in etc/openqrm-server.conf which was /usr/local in my case.

[Matt]

Hi,

ok, accepted bug. Thanks for reporting!
We will care about it for the upcoming releases.

many thanks + have a nice day,

Matt Rechenburg
Project Manager openQRM