On Sun, Dec 08, 2024 at 07:09:26PM +0300, Michael Tokarev via Postfix-users
wrote:
> 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,
I just see it as self-inflicted pain, by running things at the wrong
time. The complexity is in the strategy used, not in the Postfix tools,
which work reliably on correctly configured platforms. Move the logic
to not run prematurely.
> 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).
Only extreme for those who weren't "clever enough" to want to do that
for some reason. :-)
> Utilities like postmap and postalias does not perform any variable
> expansions, I think.
They do, because they need to load table driver shared libraries.
> 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.
Yes, run-once hooks are presumably a feature of systemd. But can be
simulated if not.
> I was just trying to reduce this complexity to some more manageable
> level.
Don't do premature processing that depends on the target system
environment.
> 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.
We're talking about latency and total cost, not robustness.
> 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 :)
Don't do that. If user logons would otherwise make sense before the
network comes up, user logons should not wait for Postfix to be started.
Nothing the user does needs Postfix to be running right away, it can
come up later.
> So it's kind of strange to require working network for an email
> system to be operational.
Postfix works fine with no neworking. The system just needs to be in
the fully up and running state that main.cf is tuned for.
It also works "fine" if the network comes down for a time, though of
course there may be delays in mail delivery, ...
> (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).
That's all that's needed, the interface needs to be "configured",
connectivity is optional, unless master.cf has non-local DNS names for
"inet" service entry point names.
> 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.
Lazy evaluation is in this context.
> How does postmulti -l care about network_interfaces or postalias about
> myhostname? Neither does.
You simply don't know that about "postalias".
As for "postmulti", yes with a bit of care we could change "-l"
processing to happen before main.cf parameter processing. Would
that help a lot? Or, again what's wrong with "just-in-time"
run-once hooks?
--
Viktor.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
