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.

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.
> Again, you own all the problems that result from not using (or
> from changing) the Postfix installation/upgrade procedure.
> 
>       Wietse
> 

Reply via email to