Am 05.06.2014 15:37, schrieb Axel Beckert:
Hi Alex,
Alexander Bech wrote:
the client update process from a central plugins-repository fails.
Just to be sure: That's not a regression, right? Did it work in the
past? Or have you tried that feature just the first time?
In the following I assume that it's not a regression.
It is not a regression.
It is a feature that does not work.
From "man clientupdate":
...
"clientupdate is part of the Xymon client. It is responsible for
updating an existing client installation from a central reposi‐
tory of client packages stored on the Xymon server".
...
OPERATION
clientupdate runs in two steps:
Re-exec step
The first step is when clientupdate is first invoked from the
xymonclient.sh script with the "--re-exec" option. This step
copies the clientupdate program from $XYMONHOME/bin/ to a temporary file
in the $XYMONTMP directory. This is to avoid
conflicts when the update procedure installs a new version of the
clientupdate utility itself. Upon completion of this
step, the clientupdate utility automatically launches the next step by
running the program from the file in $XYMONTMP.
Update step
The second step downloads the new client software from the Xymon server.
The new software must be packed into a tar file,
which clientupdate then unpacks into the $XYMONHOME directory.
...
I've changed ownership manually after each "apt-get install xymon-client".
That allows using a more comfortable method to manage many of the
xymon-clients from the central server.
For hundreds of client-instances, this is very practical.
In addition, clientupdate must write the file clientversion.cfg to
directory /etc/xymon.
Hrm, I'm not really that happy with xymon-client having write access
to its own configuration. Such files should IMHO rather go to
/var/run/xymon/. Leaves the question how they are included, but it
should be doable.
But this isprovided like that by clientupdate.c:
Clientupdate does:
#define CLIENTVERSIONFILE "etc/clientversion.cfg"
versionfn = (char *)malloc(strlen(xgetenv("XYMONHOME")) +
strlen(CLIENTVERSIONFILE) + 2);
...
This results by symlink => /etc/xymon/clientversion.cfg
...
chdir(xgetenv("XYMONHOME"). This is "/usr/lib/xymon/client".
Download and unpack the tar-file.
Create the new version file: /etc/xymon/clientversion.cfg
If these directories are not writable, clientupdate fails.
The problem could possibly be solved by adding this to the
xymon-client.postinst:
chown -R xymon:xymon /usr/lib/xymon
chown -R xymon:xymon /etc/xymon
Nope, that would violate multiple sections of the Debian Policy.
Basically /usr/lib/ is just for packaged contents and should only be
changed by package updates.
If that feature is used in conjunction with the Debian package, all
downloaded files should go somewhere else, e.g. to
/usr/local/lib/xymon/ or maybe even somewhere under /var/run/xymon/.
Or /var/lib/xymon ?
Wouldn't it be a policy-problem to give ownership of the entire
/var/lib/xymon to the xymon user?
So unless someone comes up with a patch so that xymon-client first
looks in /usr/local/lib/xymon/ before looking into /usr/lib/xymon/, we
may add support for this feature to the Debian package.
I could try...
Otherwise this
is rather a "won't fix", sorry.
Regards, Axel
Regards,
Alex
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
