With the recent security updates, but also in Debian Unstable I noticed
that some installations did no more report to the correct server or the
same list of servers anymore.

All those had one or more older server IPs in the debconf database and a
different set in /etc/default/xymon-client, either manually edited or
via config management like ansible.

xymon-client.postinst edits two variables in /etc/default/xymon-client
unconditionally and always sets the IP address(es) stored in the debconf
database.

It though only occurred to me often enough to see the pattern in the
past months — and it's unclear to me why not earlier. Because the
xymon-client.postinst script hasn't been touched since 2015. And the
last changes to the debconf part were in 2014 when the question about
automatic migration had been added. And the most recent bigger change
was in 2012.

There's a though chance that I ran into it more often, because I toyed
around with reporting to multiple Xymon servers as well as with Xymon
reporting over SSL and IPv6 via stunnel and probably edited
/etc/default/xymon-client manually rather often than using
"dpkg-reconfigure -plow xymon-client" for it (which is the way to
workaround this issue permanently — until the next manual edit of the
file ;-).

So it overwrites the configure file with local changes by the local
admin with a value set by the local admin (earlier). So both are local
configurations with two differents systems/styles/methods. They'rejust
not kept in sync and any diversion is not reported or cared about.

I just reread
https://www.debian.org/doc/debian-policy/ch-files.html#behavior
(§10.7.3) — but actually both, "must not overwrite or otherwise mangle
the user’s configuration without asking" and "must not ask unnecessary
questions (particularly during upgrades)" applies and seems to
contradict here (a bit at least).

I though tend to have the opinion that the current state is not good,
especially annoying and potentially a policy violation (§10.7.3) —
although it's mostly two local config sources not being in sync, but
both are local changes from the local admin. The admin is though likely
not aware of it.

Potential solutions:

* ucf — Potentially complex and error-prone. The function
  create_sshdconfig() from /var/lib/dpkg/info/openssh-server.postinst
  could be used as a pattern for a solution based on ucf.

* Adding a hint to the file that the values of two variables in the file
  are maintained via debconf and might be overwritten upon package
  (security) upgrades if their values are edited manually. (Probably
  doesn't help much if a configuration management ala Ansible is used.)

Suggestions, comments and opinions on this issue are welcome — and
actually wanted, hence the moreinfo tag. :-)

Hi Axel!

I also observed this on some servers.
Today I had a deep dive into all the debconf and postinst scripts of
xymon-client and found the root cause in xymon-client.config:

if [ -e $CONFIGFILE ]; then
   . $CONFIGFILE || true
fi

# if there is no value configured, look for debconf answers
if [ -z "$HOBBITSERVERS" ] ; then
        db_get hobbit-client/HOBBITSERVERS
        HOBBITSERVERS="$RET"
fi

This reads HOBBITSERVERS from /etc/default/xymon, but this isn't set
(since it was overwritten by XYMONSERVERS some time ago).
Since now the current setting XYMONSERVERS isn't found in
/etc/default/xymon (because it searches for HOBBITSERVERS, that isn't
set), it takes the (old) default from debconf database and breaks
/etc/default/xymon.

I'm working on a new Debian release of xymon, that removes all the pre
4.3.7 hobbit to xymon migration logic (available since Debian 8, so it
can not be removed) and also rename these hobbit-client and
HOBBITSERVERS debconf fields to xymon-client and XYMONSERVERS (with a
fallback to the old variables, if the new ones are not found).

Greetings
Roland