Op 23/08/2013 om 09:51:07 -0400, schreef Wietse Venema:
> Wietse Venema:
> > Leo Baltus:
> > > Op 19/08/2013 om 13:11:04 -0400, schreef Wietse Venema:
> > > > Leo Baltus:
> > > > > > > However, I did notice that postfix exec()'s new processes using
> > > > > > > the
> > > > > > > path to the binaries it got from
> > > > > > > 'PATH=symlink_to_postfix/sbin postfix start'
> > > > > > > instead of compile-time arguments DEF_COMMAND_DIR DEF_DAEMON_DIR
> > > > > > > etc.
> > > > > >
> > > > > > The Postfix master(8) daemon executes programs with pathnames
> > > > > > that are derived from the $daemon_directory value.
> > > > > >
> > > > >
> > > > > Where $daemon_directory defaults to DEF_DAEMON_DIR?
> > > >
> > > > The Postfix installation/upgrade procedure, as distributed by me,
> > > > always sets daemon_directory in main.cf. Therefore, that setting
> > > > takes precedence over DEF_DAEMON_DIR.
> > > >
> > >
> > > We do not set daemon_directory etc. in main.cf because we like it to be
> > > set
> > > to DEF_DAEMON_DIR. I hope this is a supported feature because it allows
> > > us to quickly rollback changes, like in this case.
> >
> > You break the warranty, therefore you own all the problems that
> > result from not using (or from changing) the Postfix installation
> > or upgrade procedure.
>
> Instead of modding the install/upgrade scripts, you could symlink
> daemon_directory, command_directory, sendmail_path, mailq_path,
> manpath, and so on and avoid braking the warranty.
>
Changing the symlinks while running postfix would immediatly affect
newly forked processes, which is what I am trying to avoid.
Also the symlink is used by several instances on the machine, so
changing it would affect all of them.
> However, you must run "postfix upgrade-configuration" when you
> switch from an older Postfix version to a newer one. Otherwise
> there is no guarantee that it will work properly.
>
> Switching from a newer release to an older one requires careful
> backing out of configuration changes. For example, files with long
> queue ID names will not be recognized by Postfix versions that
> pre-date long queue ID support. You have to revert to old queue IDs
> as documented in the RELEASE_NOTES file.
>
> Wietse
>
> > > After examining further I found in the environment of the master process
> > > that with postfix-2.9.6 daemon_directory is set to $PATH/libexec and
> > > command_directory is set to $PATH/sbin, however sendmail_path,
> >
> > Postfix as distributed by me does not prepend the PATH environment
> > to its program names, and no version of Postfix has done this.
I think I found what is going on.
We start postfix:
env -i PATH=/local/pf/sbin postfix -c /my/mx/main.cf start
Where /local/pf -> /software/postfix-x.y
Before this however we run
/local/pf/libexec/post-install queue_directory=... create-missing
so the neccesary directories are created. I must say that I find it
redundant, our management system should have created them in the
first place.
It seems that this command *changes* main.cf and adds daemon_directory
using the path it got from starting postfix:
eval test \"\$$name\" = \"`$POSTCONF -c $config_directory -h $name`\" || {
with daemon_directory it evaluates to
test "/local/pf/libexec" = "/software/postfix-x.y/libexec" || {
and so it decides to change main.cf
master now uses /local/pf/libexec as its daemon_directory.
Now, our management system regularly overwrites all configuration so I
wasn't aware of this change.
After a stop and start, without post-install because all directories are
there now, master uses the compiled-in daemon_directory.
So, I think I know what is going on and how to stop postfix from
changing main.cf.
I am aware that this is by no means a standard set-up so I apologize for
the confusion this may have caused.
--
Leo Baltus, internetbeheerder /\
NPO ICT Internet Services /NPO/\
Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/
serviced...@omroep.nl, 035-6773555 \/
