Package: check-mk
Version: 1.2.6p5-1
Severity: minor
During the check-mk build, when setup.sh is run (with DESTDIR set),
the following warnings occur:
chown: cannot access '/etc/nagios/htpasswd.users': No such file or
directory
The htpasswd.user chown call in setup.sh isn't using DESTDIR:
========================================================================
# make htpasswd writable by apache, since we need this for
# WATO. Also create an empty and Apache-writable auth.serials
serials_file=$DESTDIR${htpasswd_file%/*}/auth.serials &&
touch "$serials_file" &&
(chown $wwwuser "$serials_file" || true) &&
(chown $wwwuser "$htpasswd_file" || true) &&
========================================================================
The variable $htpasswd_file does not include (and shouldn't, since it
gets used in places that need the installed path). So perhaps its chown
line should include $DESTDIR but there are a couple problems:
1) When using DESTDIR to install to pseudoroot for packaging purposes
that file is probably not going to exist anyway.
2) If you were going to do this, it should be done when installing on
the actual check_mk server. Sometimes you are actually running
setup.sh on the actual server (in which case maybe it's OK as is) but
sometimes you are creating distro packages (in which case you would
want to do this in a package configuration script that runs at install
time).
Maybe what would be best is if $DESTDIR is set to skip the htpasswd_file
and serials_file stuff. But...
3) Should the check-mk setup.sh script be changing files that do not
belong to it? I understand why they want to do this, but what would be
better is if there was a generic mechanism by which check-mk could
setup nagios users and the auth.serials stuff. Also it's probably a
security risk to allow $wwwuser write access to that file, it would
allow a bug in one web script to escalate to total nagios site access.
Currently the errors are harmless, it just means check_mk won't be
able to automatically setup users since the file won't exist with
the right permissions. That is probably the right behavior for Debian
until we can come up with a better way of doing things.
I will ask upstream for their opinion.
--
Matt Taggart
tagg...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
