08.12.2024 19:10, Viktor Dukhovni via Postfix-users пишет:
On Sun, Dec 08, 2024 at 05:43:38PM +0300, Michael Tokarev via Postfix-users
wrote:
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).
DO NOT attempt to build database tables, except just-in-time, shortly
before Postfix is ready to be started. Otherwise, you cannot know the
desired value of various supporting parameters, that may depend on the
system environment:
- default_database_type
- alias_database
- ...
How this can depend on the system environment? Maybe only if it is
something like (sorry I don't remember the correct syntax) --
alias_database = $(if $myhostname = 'foo', hash, cdb)
?
In other words, run "newaliases" in the start script, not at package
build time. If you're upgrading a "live" system, you may be able to in
some cases just rebuild the alias table (perhaps atomically) and leave
Postfix running, if the file format is somehow known stable, but a
restart is generally required, because that's hard to know for some
unknown database type, and whether packages you've installed affect
its on disk layout.
Over the years, debian tried to run newaliases in the startup script,
with a lot of complexity and bug reports. This is just a given fact,
a situation we're in which I'm trying to fix. And yes, this is my
solution too, exactly, - to do it right before starting postfix if
needed. It just looked like unnecessary complexity too which can
be avoided if postalias didn't complain about network_interfaces.
Another example is postmulti -- for example, in order to just list all
configured instances - like for a simple call to `postmulti -l`,
network_interfaces parameter should already be valid:
# postmulti -l
postmulti: fatal: config variable inet_interfaces: host not found: eth0
Again you should not attempt to query this information until the system
is in a runnable state. Leave behind one-time hooks to run once the
system is ready, or if live enough do a Postfix restart that will run
the hooks.
https://bugs.debian.org/882141 -- this is what we have in debian, and
the current solution:
ln -s "$SERVICEFILE" "$WANTDIR/[email protected]"
for DIR in $(postconf -h multi_instance_directories); do
ln -s "$SERVICEFILE" "$WANTDIR/postfix@$(postconf -o inet_interfaces= -hc "$DIR"
multi_instance_name).service"
done
There's no way other way to do this at the very early setup.
This is another area which needs to be revisited/fixed (whole
postmulti setup I mean - it can just use built-in postfix
abilities), but this is something I have to support anyway
since I want to avoid breaking existing setups. If the
above snipped can be rewritten using just `postmulti -l'
(also checking "enabled" flag while at it), that would
be great. But it "sort of" works now anyway in this strange
form.
Can't at least some tools be made to not require complete valid configuration?
Not reliably.
Yeah, this is what I got :)
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
