08.12.2024 18:12, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
One example is `newaliases' run at the end of the startup procedure in debian,
- it
has numerous rather complex workarounds, and yet there are open bug reports
still,
for many years. The simple thing is: newaliases, or postalias, or postmap, or a
few other aux utilities, require valid myhostname, or network_interfaces, to be
set, to a sane values. But a package might be installed from another system for
example (bootstrapping) where host name is not required to be set, or during
regular system setup when host name part hasn't been done yet, or in numerous
other contexts, where the environment isn't set up (yet).
What about this: don't run any Postfix commands until the machine
is ready. I prefer to start any Postfix activity only after DNS,
networking, etc. are configured/running. That has always workded
well for me.
This is exactly why debian install scripts for postfix jumps
through numerous hoops just to init the initial /etc/aliases.db.
This complexity and unreliability is astonishing, ditto for amount
of bug reports and various failure scenarios. newaliases does not
do a lot of variable expansion (ok, you can use alias_database=
hash:/etc/${myhostname}/aliases, but this is sort of extreme).
Utilities like postmap and postalias does not perform any variable
expansions, I think.
In this case the newaliases I probably can delay it to the daemon
startup time by touching a flag file somewhere and running newaliases
if that flag exist, - this might be easier than all the insanity which
has been there before.
I was just trying to reduce this complexity to some more manageable
level.
Postfix would not work well if it wakes up with a queue full of
messages and networking or DNS still needs to be figured out.
And this is very interesting. It deserves a separate thread for sure.
I has always been under impression that postfix will handle missing
DNS just fine. If DNS doesn't work yet, postfix will receive
TEMPFAIL errors (or just timeouts) trying to perform DNS queries,
and things will be just deferred until later time.
Think of a laptop. It is not connected to the net all the time, so
DNS is supposed to be non-functioning during runtime too, not just
at startup. And postfix hopefully handles this fine. When the
connectivity is back, it'll send queued mails. But while there's
no network, it still can accept smtp at localhost just fine, with
no issues whatsoever.
Currently in debian, postfix startup depends on network being online,
and postfix itself is a dependency on regular system runlevel.
Basically, no user logons before postfix awaits for the network to
be up, which might require connecting to a WIFI hotspot.. which
entirely defeats the purpose of local logins :) (It's a bit more
complex than this, but you've got the idea). And the same prob
applies as above: the network does not necessary stays up once it
is up at boot, - it can go up and down at random, because it is
a network.
So it's kind of strange to require working network for an email
system to be operational.
(sure thing, if you told postfix to listen on particular interface,
this one should be available before starting postfix, but it is
something else than being fully online).
At the same time, there's postconf which does not require valid config to be
present, -- at least this one can be used to perform some configuration.
That really depends on how postconf is invoked ('show settings'
requires that parameters have a sane value, versus 'write/delete
settings' which cares less).
Can't at least some tools be made to not require complete valid configuration?
That will be difficult, given that many settings have dependencies
on parameters whose values are determined dynamically. We'd d have
to stop using $name expansion.
Or to determine values dynamically at first reference, which does not
work in a chroot.
Or maybe, mark given value as broken at init time, and delay the
error until it is actually referenced. This will keep things like
`newaliases` with alias_database=/${myhostname}/foo broken still.
Or have a "don't care" flag for variable init, which gets set by some
programs (under some conditions).
How does postmulti -l care about network_interfaces or postalias about
myhostname? Neither does.
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
