1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
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.
postfix@ vs postfix vs postmulti service
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See https://bugs.debian.org/1088862 - we should revisit how services
are started. With systemd, there's no good way to run multiple
postfix instances within a single service, since systemd wants single
main process and is confused by multiple such processes.
I think it would be good to have regular postfix.service to start
just a single default instance. With all other instances managed as
their own postfix@foo.service, where foo is a path component after
/etc/postfix- prefix stripped - path-based because we need to manage
unnamed instances too, but this restricts directory naming.
When starting as `postfix start' (monolith multiple instances) or
`postmulti -i foo -p start', these utilities might just execute
the systemd service transparently instead of trying to run master(8).
This way, full functionality of postmulti(1) is available to the
user too, in a sane way, and we can also arrange to enable/disable
the instances automatically behind the scenes.
It is somewhat difficult to revert back from current multi-instance
postfix.service to plain postfix.service in postinst. And since users
of multi-instance postfix.service, who actually need multiple instances
managed by systemd, got used to the name `postfix' to refer to multi-
instance postfix service, it'd be nice to keep this single naming for
users and for maintscripts too. Also, users might have other dirs
besides /etc/postfix-* configured, especially like /etc/postfix/foo
(within main postfix dir) - these wont be usable.
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.
|
