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

upgrade behavior when smtpd_relay_restrictions is explicitly empty in main.cf

Expand Messages
  • Sahil Tandon
    In Postfix 2.10 Snapshot 20121022, conf/post-install tests whether smtpd_relay_restrictions is already set with: test -n `$POSTCONF -c $config_directory -nh
    Message 1 of 10 , Oct 30, 2012
    View Source
    • 0 Attachment
      In Postfix 2.10 Snapshot 20121022, conf/post-install tests whether
      smtpd_relay_restrictions is already set with:

      test -n "`$POSTCONF -c $config_directory -nh smtpd_relay_restrictions`"

      This evaluates to false when smtpd_relay_restrictions is explicitly set
      to the empty value in main.cf, resulting in the parameter being
      overriden as described in RELEASE_NOTES. This seems inconsistent with
      my (perhaps faulty) interpretation of intended behavior. Would it make
      more sense to revise the above test to:

      test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`"

      With this, the forward compatibility shim would only trigger if
      smtpd_relay_restrictions does not appear in an existing main.cf, while
      explicitly empty settings of the parameter would be preserved during an
      upgrade.

      Sorry if I have misunderstood something; I just want to be clear on how
      this works before updating the FreeBSD port.

      --
      Sahil Tandon
    • Ralf Hildebrandt
      ... I think your proposal is good. I encountered the same behaviour (I first set smtpd_relay_restrictions to an empty value and THEN upgraded) -- [*] sys4 AG
      Message 2 of 10 , Oct 31, 2012
      View Source
      • 0 Attachment
        * Sahil Tandon <postfix-users@...>:
        > In Postfix 2.10 Snapshot 20121022, conf/post-install tests whether
        > smtpd_relay_restrictions is already set with:
        >
        > test -n "`$POSTCONF -c $config_directory -nh smtpd_relay_restrictions`"
        >
        > This evaluates to false when smtpd_relay_restrictions is explicitly set
        > to the empty value in main.cf, resulting in the parameter being
        > overriden as described in RELEASE_NOTES. This seems inconsistent with
        > my (perhaps faulty) interpretation of intended behavior. Would it make
        > more sense to revise the above test to:
        >
        > test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`"
        >
        > With this, the forward compatibility shim would only trigger if
        > smtpd_relay_restrictions does not appear in an existing main.cf, while
        > explicitly empty settings of the parameter would be preserved during an
        > upgrade.

        I think your proposal is good. I encountered the same behaviour (I
        first set smtpd_relay_restrictions to an empty value and THEN upgraded)

        --
        [*] sys4 AG

        http://sys4.de, +49 (89) 30 90 46 64
        Franziskanerstraße 15, 81669 München

        Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
        Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
        Aufsichtsratsvorsitzender: Joerg Heidrich
      • Wietse Venema
        ... OK, I have changed this. BTW I duplicated that test from the inet_protocols compatibility shim. That parameter is usually not set to the empty value but
        Message 3 of 10 , Oct 31, 2012
        View Source
        • 0 Attachment
          Ralf Hildebrandt:
          > * Sahil Tandon <postfix-users@...>:
          > > In Postfix 2.10 Snapshot 20121022, conf/post-install tests whether
          > > smtpd_relay_restrictions is already set with:
          > >
          > > test -n "`$POSTCONF -c $config_directory -nh smtpd_relay_restrictions`"
          > >
          > > This evaluates to false when smtpd_relay_restrictions is explicitly set
          > > to the empty value in main.cf, resulting in the parameter being
          > > overriden as described in RELEASE_NOTES. This seems inconsistent with
          > > my (perhaps faulty) interpretation of intended behavior. Would it make
          > > more sense to revise the above test to:
          > >
          > > test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`"
          > >
          > > With this, the forward compatibility shim would only trigger if
          > > smtpd_relay_restrictions does not appear in an existing main.cf, while
          > > explicitly empty settings of the parameter would be preserved during an
          > > upgrade.
          >
          > I think your proposal is good. I encountered the same behaviour (I
          > first set smtpd_relay_restrictions to an empty value and THEN upgraded)

          OK, I have changed this.

          BTW I duplicated that test from the inet_protocols compatibility
          shim. That parameter is usually not set to the empty value but the
          shim has the same problem.

          Wietse
        • Sahil Tandon
          ... Great, thank you! ... Aye. I have a separate question that is tangentially related, so I hope that it is OK to broach without spawning a separate thread.
          Message 4 of 10 , Nov 1, 2012
          View Source
          • 0 Attachment
            On Wed, 2012-10-31 at 09:01:23 -0400, Wietse Venema wrote:

            > Ralf Hildebrandt:
            > > * Sahil Tandon <postfix-users@...>:
            > ...
            > > > test -n "`$POSTCONF -c $config_directory -n smtpd_relay_restrictions`"
            > > >
            > > > With this, the forward compatibility shim would only trigger if
            > > > smtpd_relay_restrictions does not appear in an existing main.cf, while
            > > > explicitly empty settings of the parameter would be preserved during an
            > > > upgrade.
            > >
            > > I think your proposal is good. I encountered the same behaviour (I
            > > first set smtpd_relay_restrictions to an empty value and THEN upgraded)
            >
            > OK, I have changed this.

            Great, thank you!

            > BTW I duplicated that test from the inet_protocols compatibility shim.
            > That parameter is usually not set to the empty value but the shim has
            > the same problem.

            Aye. I have a separate question that is tangentially related, so I hope
            that it is OK to broach without spawning a separate thread.

            Some background: upon deinstall, unaltered files installed by a FreeBSD
            package are supposed to be deleted. In the context of Postfix
            configuration files, this is done by comparing, for example, the stock
            main.cf in $daemon_directory with its analogue in $config_directory, and
            only deleting the latter if the two match. These two files are
            identical after a fresh install of a pre-built Postfix package, so
            uninstalling Postfix via the package management framework results in the
            expected deletion of all main.cf files.

            The issue I have with the smtpd_relay_restrictions compatibility shim is
            that it is triggered even on fresh install of a pre-built Postfix
            package. This is because the main.cf placed in $config_directory does
            not include a smtpd_relay_restrictions definition, which is therefore
            added by the package management system that has historically called the
            post-install script with the 'upgrade-package' argument. So, as of the
            latest 2.10 snapshot, the two main.cf's no longer match after a fresh
            package install.

            I understand this is not a Postfix issue, but I would appreciate if
            other package maintainers (or anyone else who is willing to opine!)
            could share how they handle this. I initially thought to append a
            default smtpd_relay_restrictions definition to the stock version so that
            the two main.cf files would match following a fresh install, but then I
            wondered if that could cause unwelcome consequences. Is there a more
            canonical approach to all this?

            BTW, there is no similar issue with the inet_protocols shim because that
            parameter is explicitly defined in the stock main.cf.

            --
            Sahil Tandon
          • Wietse Venema
            ... Come on, sites that don t edit main.cf are so rare that this is not something that I would worry about. Don t ask me to pre-patch the stock main/master.cf
            Message 5 of 10 , Nov 2, 2012
            View Source
            • 0 Attachment
              Sahil Tandon:
              > Some background: upon deinstall, unaltered files installed by a FreeBSD
              > package are supposed to be deleted. In the context of Postfix

              Come on, sites that don't edit main.cf are so rare
              that this is not something that I would worry about.
              Don't ask me to pre-patch the stock main/master.cf
              files. That is too hard to maintain (how do I know
              that it is still correct? I never use those files).

              Wietse
            • Viktor Dukhovni
              ... I think this response is a bit hasty. Yes, certainly sites that actually use Postfix typically change main.cf. On the other hand one often finds oneself
              Message 6 of 10 , Nov 2, 2012
              View Source
              • 0 Attachment
                On Fri, Nov 02, 2012 at 08:18:09AM -0400, Wietse Venema wrote:

                > Sahil Tandon:
                > > Some background: upon deinstall, unaltered files installed by a FreeBSD
                > > package are supposed to be deleted. In the context of Postfix
                >
                > Come on, sites that don't edit main.cf are so rare
                > that this is not something that I would worry about.
                > Don't ask me to pre-patch the stock main/master.cf
                > files. That is too hard to maintain (how do I know
                > that it is still correct? I never use those files).

                I think this response is a bit hasty. Yes, certainly sites that
                actually use Postfix typically change main.cf. On the other hand
                one often finds oneself with installed software that one never
                intends to use that is either pre-installed by default, or gets
                installed as part of some over-zealous package dependency management
                (can you say Debian? It has its pluses of course, ...)

                Thus it is not unreasonable to expect that de-installation of a
                never used package should leave no detritus. A Postfix package
                should run "postfix-upgrade configuration" as part of the package
                install, and this should ideally be a NOP for a first install.

                So while the issue is not a high priority, I think that it makes
                sense to ship a default master.cf that requires no tweaks, and a
                main.cf that likewise requires no tweaks.

                I don't recall to what extent this is up to the package installer.
                Should the installer first check whether this is a "first install"
                of Postfix, and then run only "postfix set-permissions" without
                "postfix upgrade-configuration"?

                We may not want to revert to legacy behaviour by default
                in brand new installs.

                In any case, I think that the conf/main.cf and conf/master.cf should
                be current (as they've been in most releases IIRC) and should not
                require install-time tweaks.

                --
                Viktor.
              • Wietse Venema
                ... I don t want post-install to run over both the installed main.cf and the source main.cf file because it would never remove shims that are no longer
                Message 7 of 10 , Nov 2, 2012
                View Source
                • 0 Attachment
                  Viktor Dukhovni:
                  > In any case, I think that the conf/main.cf and conf/master.cf should
                  > be current (as they've been in most releases IIRC) and should not
                  > require install-time tweaks.

                  I don't want post-install to run over both the installed main.cf
                  and the "source" main.cf file because it would never remove shims
                  that are no longer needed. Th ewhole point of the shims is that
                  they are temporary.

                  Wietse
                • Stan Hoeppner
                  ... I ve been using Postfix on Debian for about 7 years now and never had such an apt/aptitude dependency issue WRT Postfix, that I can recall. Though I have
                  Message 8 of 10 , Nov 2, 2012
                  View Source
                  • 0 Attachment
                    On 11/2/2012 2:13 PM, Viktor Dukhovni wrote:

                    > ... or gets
                    > installed as part of some over-zealous package dependency management
                    > (can you say Debian? It has its pluses of course, ...)

                    I've been using Postfix on Debian for about 7 years now and never had
                    such an apt/aptitude dependency issue WRT Postfix, that I can recall.
                    Though I have run into the issue you describe with other packages.

                    --
                    Stan
                  • Eray Aslan
                    ... FWIW, that would make my life easier as well. I also agree that it is not a high priority issue. -- Eray Aslan
                    Message 9 of 10 , Nov 2, 2012
                    View Source
                    • 0 Attachment
                      On 11/2/12 9:13 PM, Viktor Dukhovni wrote:
                      > So while the issue is not a high priority, I think that it makes
                      > sense to ship a default master.cf that requires no tweaks, and a
                      > main.cf that likewise requires no tweaks.

                      FWIW, that would make my life easier as well. I also agree that it is
                      not a high priority issue.

                      --
                      Eray Aslan <eras@...>
                    • Sahil Tandon
                      ... That s fair and understood, Wietse. I did not mean to imply that you should implement an upstream workaround to address this ports issue; sorry if it came
                      Message 10 of 10 , Nov 3, 2012
                      View Source
                      • 0 Attachment
                        On Fri, 2012-11-02 at 19:13:04 +0000, Viktor Dukhovni wrote:

                        > On Fri, Nov 02, 2012 at 08:18:09AM -0400, Wietse Venema wrote:
                        >
                        > > Sahil Tandon:
                        > > > Some background: upon deinstall, unaltered files installed by a FreeBSD
                        > > > package are supposed to be deleted. In the context of Postfix
                        > >
                        > > Come on, sites that don't edit main.cf are so rare
                        > > that this is not something that I would worry about.
                        > > Don't ask me to pre-patch the stock main/master.cf
                        > > files. That is too hard to maintain (how do I know
                        > > that it is still correct? I never use those files).

                        That's fair and understood, Wietse. I did not mean to imply that you
                        should implement an upstream workaround to address this ports issue;
                        sorry if it came across that way. I was just seeking advice from those
                        who may be addressing similar (admittedly "edge case") constraints.

                        > ...
                        > So while the issue is not a high priority, I think that it makes
                        > sense to ship a default master.cf that requires no tweaks, and a
                        > main.cf that likewise requires no tweaks.
                        >
                        > I don't recall to what extent this is up to the package installer.
                        > Should the installer first check whether this is a "first install"
                        > of Postfix, and then run only "postfix set-permissions" without
                        > "postfix upgrade-configuration"?
                        > ...

                        That seems reasonable. Although, if we take this approach, until the
                        smtpd_relay_restrictions tweak is phased out, it would mean first-time
                        users who perform a fresh install would notice no mention of this
                        parameter in their main.cf and become accustomed to default behavior.
                        Then, when upgrading on a later date, the shim (if it's still active)
                        would insert the safety net into the configuration. Perhaps this is not
                        a big deal, and it should not surprise users who dutifully read
                        RELEASE_NOTES before using/upgrading software, but not everyone does
                        that.

                        Anyway, I think I have enough to proceed; sorry for going off-topic and
                        thanks for the feedback.

                        --
                        Sahil Tandon
                      Your message has been successfully submitted and would be delivered to recipients shortly.