From: Wietse Venema (no email)
Date: Fri Feb 01 2008 - 07:04:12 EST
Victor Duchovni:
> On Thu, Jan 31, 2008 at 07:33:45PM -0500, Wietse Venema wrote:
>
> > > The only way that "postfix start" can change main.cf (via create-missing)
> > > is for the environment passed by postfix(1) to postfix-script and hence
> > > to post-install to (miraculously) differ from the main.cf settings that
> > > post-install computes via "postconf -h". However, even in that case,
> > > empty values should not be possible, because the sanity check at the
> > > top of post-install should bail out early.
> > >
> > > I see no code path that matches the reported symptoms, the installation
> > > or run-time environment is likely damaged.
> >
> > Note this:
> >
> > for name in config_directory $MOST_PARAMETERS
> > do
> > eval test -n \${$name} || {
> > echo "$0: Error: do not invoke this command directly" 1>&2
> > echo Re-run this command as: postfix $0 ... 1>&2
> > exit 1
> > }
> > done
> >
> > This does not work reliably because the "test -n" argument needs to
> > be quoted.
> >
> > Correct is this:
> >
> > for name in config_directory $MOST_PARAMETERS
> > do
> > eval test -n \"\${$name}\" || {
> > echo "$0: Error: do not invoke this command directly" 1>&2
> > echo Re-run this command as: postfix $0 ... 1>&2
> > exit 1
> > }
> > done
>
> This is half of the puzzle, so an empty setting won't bail out, but how
> does the empty arise? The only thing that comes to mind is an obsolete
> postfix(1) on the user's path (different command_directory) that invokes
> the new postfix-script (same config_directory).
That would be the most likely explanation ("postfix start"
using an obsolete "postfix" executable).
> Finally, perhaps the code that saves installation parameters into
> main.cf should only run when upgrade-package, upgrade-source,
> first-install-reminder or set-permissions are specified. Just
> "create-missing" shoud perhaps not change main.cf even if the install
> parameters appear to be different. The specific test can be:
>
> test -n "${first_install_reminder}${set_perms}${upgrade_conf}${upgrade_perms}"
>
> or we can add a new flag that is set when setting one of these. Either
> way the code that runs "postconf -e" could be disabled with just the
> create-missing post-install action that is triggered from "postfix start".
This change would be inconsistent with the man page which says
name=value can be used with any command. This change would also
be inconsistent with the code which will implement name=value which
with any command.
Let's fix the real problem: post-install being run in the wrong
environment, instead of plugging all the holes that may result from
running in the wrong environment.
Wietse
|
|
|