97 lines
4.3 KiB
Text
97 lines
4.3 KiB
Text
Random packaging notes
|
|
|
|
|
|
debconf
|
|
~~~~~~~
|
|
|
|
Debconf handling is done in a wrong way. It should feed its initial
|
|
values from the live system (from actual main.cf, etc files) instead
|
|
of using values previously stored in the database, - unless there's
|
|
no initial configuration found, in which case default values stored
|
|
in the debconf should be used. This avoids re-setting configuration
|
|
to debconf values on every upgrade, - we have multiple bugs about
|
|
that. See https://bugs.debian.org/734401
|
|
|
|
|
|
alias handling
|
|
~~~~~~~~~~~~~~
|
|
|
|
up to 3.9.1 postfix postinst hardcoded hash:/etc/aliases as the only
|
|
place for aliases, created this file on every upgrade (despite it
|
|
might be unused or moved), and adds (or tries to add) root alias to
|
|
this file too. It might as well take a look at $alias_maps.
|
|
|
|
Root alias handling (root_address debconf question) logic is wrong:
|
|
it adds root alias only if set by debconf, when either of the two
|
|
conditions met (simplifying): either /etc/aliases does not exists,
|
|
or it is a new install (not upgrade). But root_address debconf
|
|
question is of "medium" priority, while default priority when
|
|
first run is "high", so this question is not seen by the user.
|
|
When re-configuring it, /etc/aliases exists and it is not a new
|
|
install anymore, so it is not added.
|
|
|
|
|
|
newaliases
|
|
~~~~~~~~~~
|
|
|
|
In debian postfix package up to 3.9.1, it was used to run newaliases
|
|
if alias database contains a map type being registered. This is kinda
|
|
pointless, -- yes, it helps in a situation when the user configured
|
|
a new map type for alias_database which is not installed on the target
|
|
system, -- now, alias database will be built automatically at map install
|
|
time. But this isn't a common situation, and the user can run newaliases
|
|
manually after observing errors in the logs. And it is still broken,
|
|
because alias database might contain other map types, in which case
|
|
newaliases will fail and the installation will stop too. A correct
|
|
solution would be to add a trigger to the main postfix package and try
|
|
to rebuild aliases. Or better yet, just remove whole thing and only
|
|
try to run newaliases once at new install, and just tell user to re-run
|
|
it manually if failed - since adding this automatic complexity is
|
|
difficult (to get right) with no visible gains.
|
|
|
|
There might be another case when we may want to run newaliases during
|
|
upgrade: when file format has changed for some database. But this
|
|
should be handled for all maps, not just aliases, and for all instances,
|
|
and it is dependent on other packages, not on postifx.
|
|
|
|
See https://bugs.debian.org/847242 https://bugs.debian.org/865005
|
|
https://bugs.debian.org/864609
|
|
|
|
Complex newaliases handling has been removed in 3.9.1-3, - we now
|
|
try to run newaliases only once when we know we modified /etc/aliases,
|
|
at the end of postfix.postinst script, and if that failed, just warn
|
|
user and continue. No need to try to be smart here.
|
|
|
|
|
|
chroot
|
|
~~~~~~
|
|
|
|
Debian postfix package always had chroot enabled by default. Enabling
|
|
it in the first place is questionable by itself already, but enabling it
|
|
by default is.. difficult, it poses a lot of unnecessary burden to the
|
|
users. High percentage of bug reports in the bts are due to chroot in
|
|
one way or another. We should get rid of this default at least. Offering
|
|
a debconf-level choice might be a good thing, but it is very difficult to
|
|
achieve, - maybe only for a new install. And we have to keep currently
|
|
used chroots working, and fix the remaining bugs if possible.
|
|
|
|
See https://bugs.debian.org/151692 https://bugs.debian.org/1084167 and
|
|
numerous bug reports marked with "[chroot]" in the title.
|
|
|
|
We copy nss stuff to chroot because this is what's used by postfix smtp
|
|
client as "native" way for host lookups (smtp_host_lookup). By default
|
|
it uses internal dns routines directly, which utilizes res_* functions.
|
|
Also, various networking maps might use nss host lookups, but these are
|
|
better to be handled with proxy: map type. Glibc does not need libresolv
|
|
anymore. And picks up changes to resolv.conf immediately on next lookup.
|
|
|
|
#572841 says /dev/random and /dev/urandom are needed in chroot jail
|
|
to run ldaps. Is this true still? Are these device files needed for
|
|
something else? In 3.9.1-5, I stopped creating /dev/random in chroot.
|
|
|
|
|
|
rmail
|
|
~~~~~
|
|
|
|
Do we need rmail binary (comes from sendmail package) and a working uucp
|
|
entry in master.cf in 2025? Not that it requires much though.
|