#986393 dnss: Recent update overwrote modified configuration files - broke DNS

Package:
dnss
Source:
dnss
Description:
Proxy for using DNS over HTTPS
Submitter:
se
Date:
2021-04-07 17:09:19 UTC
Severity:
important
#986393#5
Date:
2021-04-05 01:45:09 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
- running "apt upgrade"

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
- had to restore all 3 confuration files from backup:
   /etc/default/dnss
   /lib/systemd/system/dnss.socket
   /lib/systemd/system/dnss.service

   * What was the outcome of this action?
- restoring from backup and re-enabling and re-starting dnss restored function

   * What outcome did you expect instead?
- asking about modified configuratiuon files before overwriting them.
- not breaking DNS resolution.

*** End of the template - remove these template lines ***

#986393#10
Date:
2021-04-05 09:04:16 UTC
From:
To:
Hi, thanks for reporting this, and sorry you run into this!

The dnss package uses the standard Debian way of packaging configuration
files, so the behaviour should match what you see in other packages.

- /etc/default/dnss appears in conffiles, which is what tells apt that
   it is a configuration file that *shouldn't* be overwritten if the user
   has made changes, and you should get asked what to do (see [1] and
   [2]).

- The /lib/systemd/ files do not appear in conffiles and *will* get
   overwritten. I think that's expected, since for overriding systemd
   configuration the expectation is that you do it in /etc/systemd/ (see
   [3]). I'm not saying I love it, but it's how systemd configuration
   file layout is designed to work.
   I'm sorry that you had to restore these from backups, but this will
   happen with _any_ package, it was probably just bad luck that you saw
   it with dnss.

So, /lib/systemd/ files being silently overwritten is working as
intended (as unfortunate as that is), but /etc/default/dnss should not
be automatically overwritten under normal conditions.


Was this an unattended upgrade? If so, do you have a log of the upgrade?
Like /var/log/unattended-upgrades/unattended-upgrades.log and
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log.

Do you have any special apt configuration that might be behind this? An
"apt-config dump" should show the full apt configuration, it might be
useful to include it as well.

Thanks again,
		Alberto

[1]: https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[2]: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
[3]: https://wiki.debian.org/systemd#Creating_or_altering_services

#986393#15
Date:
2021-04-05 09:04:16 UTC
From:
To:
Hi, thanks for reporting this, and sorry you run into this!

The dnss package uses the standard Debian way of packaging configuration
files, so the behaviour should match what you see in other packages.

- /etc/default/dnss appears in conffiles, which is what tells apt that
   it is a configuration file that *shouldn't* be overwritten if the user
   has made changes, and you should get asked what to do (see [1] and
   [2]).

- The /lib/systemd/ files do not appear in conffiles and *will* get
   overwritten. I think that's expected, since for overriding systemd
   configuration the expectation is that you do it in /etc/systemd/ (see
   [3]). I'm not saying I love it, but it's how systemd configuration
   file layout is designed to work.
   I'm sorry that you had to restore these from backups, but this will
   happen with _any_ package, it was probably just bad luck that you saw
   it with dnss.

So, /lib/systemd/ files being silently overwritten is working as
intended (as unfortunate as that is), but /etc/default/dnss should not
be automatically overwritten under normal conditions.


Was this an unattended upgrade? If so, do you have a log of the upgrade?
Like /var/log/unattended-upgrades/unattended-upgrades.log and
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log.

Do you have any special apt configuration that might be behind this? An
"apt-config dump" should show the full apt configuration, it might be
useful to include it as well.

Thanks again,
		Alberto

[1]: https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[2]: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
[3]: https://wiki.debian.org/systemd#Creating_or_altering_services

#986393#20
Date:
2021-04-05 19:31:43 UTC
From:
To:
Hi Alberto,
Thanks for replying so quickly.

I really appreciate being able to use dnss.  In Canada, our domain
registrar (CIRA.CA) also provides safe and secure DNS resolution
services including DOH and dnss is the perfect open-source solution.

I think that the dnss setup is more easily configured using the
/lib/systemd files than using /etc/default/dnss for specifying
everything; as mentioned, I made changes to all 3 files.  I don't
understand why /lib/systemd are not considered configuration files -
perhaps this is the real bug.

In any case, I always run "apt upgrade" manually because I always want
to see and evaluate any configuration files changes.  I did not see the
usual configuration file changes prompts from apt (dpkg) when dnss was
updated.  Unfortunately, dpkg.log does not include such details.
However, /var/log/apt/term.log does and there is no record of any such
prompting about /etc/default/dnss for this update:

  Preparing to unpack .../dnss_0.0~git20200927.0.6aad832e-1+b1_amd64.deb ...
  Unpacking dnss (0.0~git20200927.0.6aad832e-1+b1) ...
  Setting up dnss (0.0~git20200927.0.6aad832e-1+b1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/dnss.service → /lib/systemd/system/dnss.service.
  Created symlink /etc/systemd/system/sockets.target.wants/dnss.socket → /lib/systemd/system/dnss.socket.
  Job failed. See "journalctl -xe" for details.
  A dependency job for dnss.service failed. See 'journalctl -xe' for details.

I don't think I have any configuration issues with apt.  As mentioned,
I am used to being prompted about configuration file changes.  I have
included the details as requested in the attached file
apt-config.dump.out.txt.

Thank you for your work on the dnss package.  I hope that you find my
experience useful to your work.

Best regards,
 - Steve Ellis <bugz@mbse.ca>



On Mon, 5 Apr 2021 10:04:16 +0100 Alberto Bertogli <albertito@blitiri.com.ar> wrote:

#986393#25
Date:
2021-04-06 18:46:18 UTC
From:
To:
Thank you, I'm glad to hear you find it useful :)

I understand (and to a large degree share) the frustration about
/lib/systemd, but that's beyond dnss, it's a Debian-wide policy based on
how systemd works.

If you have other packages where you've overridden their systemd files
in /lib/systemd, the same thing will happen when they change.

What I do for overriding systemd default configs is to create your own
service files in /etc/systemd, which will take precedence if they exist.
This (and a couple of variants) is documented in
https://wiki.debian.org/systemd#Creating_or_altering_services.

Honestly I don't know what might have caused you not getting a prompt on
/etc/default/dnss. I will try to reproduce it in a VM and will report
back, but this seems more of a Debian issue than a dnss issue :(

Sorry for the super trivial question, but are you sure /etc/default/dnss
was also overriden by you, and not just the systemd files, right?

In any case, maybe someone more well versed in Debian can help identify
what's going on here.

Thanks again for your kind words, and for taking the time to report
bugs and help troubleshoot the problem!

		Alberto

#986393#30
Date:
2021-04-07 17:06:20 UTC
From:
To:
Hi Alberto,
Thanks for this information.  I haven't taken the time to learn as much
about systemd as I should have before fiddling with its files...

I must have been mistaken about apt overwriting /etc/default/dnss.
I haven't been able to replicate overwriting of /etc/default/dnss by
apt.  It appears that apt simply ignores when it has been changed.  I
have tried both "apt reinstall dnss" and "apt remove dnss" followed by
"apt install dnss".

Please feel free to close this bug.  I caused the issue and you helped
me correct it.  Thanks again.

Best regards,
 - Steve


On Tue, 6 Apr 2021 19:46:18 +0100 Alberto Bertogli <albertito@blitiri.com.ar> wrote: