Loading ...
Sorry, an error occurred while loading the content.

Re: $daemon_directory [Re: upgrade to 2.10.1: pass_accept_attr: cannot receive connection attributes: Numerical result out of range'

Expand Messages
  • Wietse Venema
    ... You break the warranty, therefore you own all the problems that result from not using (or from changing) the Postfix installation or upgrade procedure. ...
    Message 1 of 11 , Aug 23, 2013
    • 0 Attachment
      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.

      > 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
    • Wietse Venema
      ... Instead of modding the install/upgrade scripts, you could symlink daemon_directory, command_directory, sendmail_path, mailq_path, manpath, and so on and
      Message 2 of 11 , Aug 23, 2013
      • 0 Attachment
        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
        >
      • Leo Baltus
        ... 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
        Message 3 of 11 , Aug 27, 2013
        • 0 Attachment
          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 \ /\/
          servicedesk@..., 035-6773555 \/
        • Wietse Venema
          ... First, post-install is an internal interface (no manpage is installed), so calling post-install directly is not supported. However, if you peek under the
          Message 4 of 11 , Aug 27, 2013
          • 0 Attachment
            Leo Baltus:
            > 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.

            First, post-install is an internal interface (no manpage is installed),
            so calling post-install directly is not supported.

            However, if you peek under the covers (again, not supported) then
            you will see that post-install won't update main.cf as long as you
            specify the appropriate name=value settings on the post-install
            command line.

            Wietse
          Your message has been successfully submitted and would be delivered to recipients shortly.