port puppet-managed configs to Debian bookworm

as part of the %Debian 12 bookworm upgrade, we have config files in Puppet to the new stuff in bookworm.

we haven't kept an inventory of those, as far as I know, but we should check.

also, as part of the %Debian 11 bullseye upgrade, we did identify issues that were still unfixed and should be fixed here. this used to be in the bullseye milestone, but that was closed to focus on %TPA-RFC-71: emergency email deployments, phase B and %TPA-RFC-33-A: emergency Icinga retirement, so that work was carried over here instead.

• /etc/apt/apt.conf.d/50unattended-upgrades: to be investigated. probably mostly whitespace changes, but also possibly missing features. complicated by the fact that this is a third party Puppet module and would require significant work to catchup with the Debian package

• /etc/unbound/unbound.conf: switch to include-toplevel after the fleet is upgraded (does not work in buster)

• /etc/sudoers: use @include instead of #include, former added only in bullseye and later. should be split out in a sudoers.d file to avoid future conflicts and, generally, split in snippets per service instead of this monolithic file

• /etc/syslog-ng/syslog-ng.conf: silly version number logic in the template, needs to be ported to newer config or replaced with rsyslog or journald

• /etc/ferm/ferm.conf: web-cymru-01 had diffs pending from the previous upgrade (presumably?), might be worth catching up to buster, that is, unless we just ditch ferm completely (#40554) the latter

• /etc/lvm/lvm.conf: same as above

• /etc/bind/named.conf.options: TBD, on fallax fallax retired

• /etc/postfix/main.cf: getting those warnings on eugeni: Nov 18 18:44:23 eugeni/eugeni postfix/smtpd[6111]: using backwards-compatible default setting smtpd_relay_before_recipient_restrictions=no to reject recipient foo@torproject.org from client ... in general run postfix relaod and fix warnings

if a file is added in the above list, do not forget to add it to the conflicts resolution list in the upgrade procedure.

more such issues could come up, but for now that's what I got. for now the diff for those has been minimized as much as possible and the proposed version from the Debian package should generally be ignored.