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

Re: RFC: postconf user interface

Expand Messages
  • vince@vheuser.com
    how does one get off this list? My attempts have all been blocked by majordomo. ... From: Patrick Ben Koetter To:
    Message 1 of 23 , Jan 8, 2013
    • 0 Attachment
      how does one get off this list?
      My attempts have all been blocked by majordomo.
      Even Weitse's personal filter blocked my email.... /-:



      ----- Original Message -----
      From: "Patrick Ben Koetter" <p@...>
      To: <postfix-users@...>
      Sent: Tuesday, January 08, 2013 4:38 PM
      Subject: Re: RFC: postconf user interface


      >* Wietse Venema <postfix-users@...>:
      >> This note discusses some user-interface issues with upcoming
      >> postconf(1) features that will be used to manage the content of
      >> master.cf files.
      >>
      >> User-interface consistency is important, especially for people who
      >> work a lot with Postfix: fewer things to remember means fewer
      >> mistakes to make (it's also important for implementors, because it
      >> leads to similar code for similar operations and opportunities to
      >> use code that already exists, meaning fewer mistakes to make).
      >>
      >> In particular, it would be desirable that postconf(1) uses similar
      >> command syntax for similar operations on main.cf and master.cf.
      >>
      >> First I will review a few commands that already exist, and then
      >> I'll introduce some commands that are likely to be implemented.
      >>
      >> The first two examples are already implemented:
      >>
      >> postconf -M inet
      >> Show all TCP services in master.cf
      >>
      >> postconf -M inet.submission
      >> Show the submission-over-TCP service in master.cf
      >>
      >> Next, a few examples that are likely to be implemented:
      >>
      >> postconf -M# service-type ...
      >> postconf -M# service-type.service-name ...
      >>
      >> postconf -MX service-type ...
      >> postconf -MX service-type.service-name ...
      >>
      >> Delete (or comment) out the specified services.
      >
      > Would it make sense - differing from main.cf behaviour - to revert
      > comments in
      > master.cf?
      >
      >
      >> These commands are analogous to "postconf -# parameter(s)" (comment
      >> out main.cf parameter settings) and "postconf -X parameter(s)"
      >> (remove main.cf parameter settings). Therefore they should have
      >> similar syntax. I don't expect that these commands will be used
      >> much, but they will make the postconf command more consistent.
      >
      > We've done a few web interfaces to configure Postfix. Having postconf edit
      > master.cf would make such tasks easier.
      >
      >
      >> I am contemplating a new class of master.cf operations that operate
      >> column-wise. These currently have no main.cf equivalent.
      >>
      >> postconf -Mu chroot=n inet unix fifo pass
      >>
      >> Update the "chroot" column to "n" for all services.
      >
      > Would the new class also allow to edit a _single_ service e.g.:
      >
      > postconf -Mu chroot=n inet.submission
      >
      >
      >> postconf -Mu type=unix fifo
      >>
      >> Update all "fifo" services so that they use UNIX-domain
      >> sockets. This is more laptop-friendly as it avoids MTIME
      >> updates.
      >>
      >> Obviously, this command is powerful but it can also inflict a great
      >> deal of damage.
      >
      > Should postconf be able/offer to make backup copies before it acts a
      > request
      > out?
      >
      >
      >> And finally, a more complicated example:
      >>
      >> postconf -Me 'text of complete master.cf entry'
      >>
      >> Replace the specified master.cf service or add a new service.
      >> Each postconf(1) command-line argument contains the text
      >> of a complete master.cf entry. The new entry is line-wrapped
      >> as with "postconf -Mf".
      >>
      >> This command syntax is consistent with existing "postconf -e"
      >> commands, where each postconf(1) command-line argument contains the
      >> text of a complete main.cf entry.
      >
      > In postconf(1) you wrote "-e Edit the main.cf configuration file, and
      > update
      > parameter settings ..."
      >
      > I haven't thought this through - you probably have: Wouldn't it be more
      > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e'
      > as
      > proposed for master.cf?
      >
      > p@rick
      >
      > --
      > [*] 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
      ... In both cases, I don t understand how that would work. ... Of course. A pattern can match one entry or more. ... Should it with main.cf? Should we enourage
      Message 2 of 23 , Jan 8, 2013
      • 0 Attachment
        Patrick Ben Koetter:
        > > Next, a few examples that are likely to be implemented:
        > >
        > > postconf -M# service-type ...
        > > postconf -M# service-type.service-name ...
        > >
        > > postconf -MX service-type ...
        > > postconf -MX service-type.service-name ...
        > >
        > > Delete (or comment) out the specified services.
        >
        > Would it make sense - differing from main.cf behaviour - to revert
        > comments in master.cf?

        In both cases, I don't understand how that would work.

        > > I am contemplating a new class of master.cf operations that operate
        > > column-wise. These currently have no main.cf equivalent.
        > >
        > > postconf -Mu chroot=n inet unix fifo pass
        > >
        > > Update the "chroot" column to "n" for all services.
        >
        > Would the new class also allow to edit a _single_ service e.g.:
        >
        > postconf -Mu chroot=n inet.submission

        Of course. A pattern can match one entry or more.

        > Should postconf be able/offer to make backup copies before it acts a request
        > out?

        Should it with main.cf? Should we enourage the use of version control?

        > > And finally, a more complicated example:
        > >
        > > postconf -Me 'text of complete master.cf entry'
        > >
        > > Replace the specified master.cf service or add a new service.
        > > Each postconf(1) command-line argument contains the text
        > > of a complete master.cf entry. The new entry is line-wrapped
        > > as with "postconf -Mf".
        > >
        > > This command syntax is consistent with existing "postconf -e"
        > > commands, where each postconf(1) command-line argument contains the
        > > text of a complete main.cf entry.
        >
        > In postconf(1) you wrote "-e Edit the main.cf configuration file, and update
        > parameter settings ..."

        The text is too vague and needs to be updated. What happens in
        reality is "replace or add main.cf entry, using the complete entry
        given on the postconf command line".

        If there is a command to implement THAT FUNCTION for master.cf (add
        or replace entry, using the complete entry given on the postconf
        command line) then it should use the same -e option.

        > I haven't thought this through - you probably have: Wouldn't it be more
        > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as
        > proposed for master.cf?

        "u" replaces a field in master.cf. It has no main.cf equivalent
        (replace a word in the middle of a line?) therefore should not use
        an option letter that is used for main.cf.

        Wietse
      • mouss
        ... I like the mib syntax of main.cf. so I d prefer something like postconf -e service.submission.chroot=n (or false|no|whatever) and then, I would love to
        Message 3 of 23 , Jan 8, 2013
        • 0 Attachment
          Le 08/01/2013 22:00, Wietse Venema a écrit :
          > This note discusses some user-interface issues with upcoming
          > postconf(1) features that will be used to manage the content of
          > master.cf files.
          >
          > User-interface consistency is important, especially for people who
          > work a lot with Postfix: fewer things to remember means fewer
          > mistakes to make (it's also important for implementors, because it
          > leads to similar code for similar operations and opportunities to
          > use code that already exists, meaning fewer mistakes to make).
          >
          > In particular, it would be desirable that postconf(1) uses similar
          > command syntax for similar operations on main.cf and master.cf.
          >
          > First I will review a few commands that already exist, and then
          > I'll introduce some commands that are likely to be implemented.
          >
          > The first two examples are already implemented:
          >
          > postconf -M inet
          > Show all TCP services in master.cf
          >
          > postconf -M inet.submission
          > Show the submission-over-TCP service in master.cf
          >
          > Next, a few examples that are likely to be implemented:
          >
          > postconf -M# service-type ...
          > postconf -M# service-type.service-name ...
          >
          > postconf -MX service-type ...
          > postconf -MX service-type.service-name ...
          >
          > Delete (or comment) out the specified services.
          >
          > These commands are analogous to "postconf -# parameter(s)" (comment
          > out main.cf parameter settings) and "postconf -X parameter(s)"
          > (remove main.cf parameter settings). Therefore they should have
          > similar syntax. I don't expect that these commands will be used
          > much, but they will make the postconf command more consistent.
          >
          > I am contemplating a new class of master.cf operations that operate
          > column-wise. These currently have no main.cf equivalent.
          >
          > postconf -Mu chroot=n inet unix fifo pass


          I like the "mib" syntax of main.cf. so I'd prefer something like
          postconf -e service.submission.chroot=n (or false|no|whatever)
          and then, I would love to have that in main.cf.

          more precisely, it would be nice to control master.cf things from main.cf:

          service.submission.disable = (true|false)
          so I could disable a service without removing it (the old pattern:
          active vs undefined)
          service.submission.chroot = false
          and then a service.all.chroot = false would disable all chrooting,
          which would be helpful when we
          suspect that a problem is due to a chroot.
          service.submission.class = smtpd
          service.submission.address = 0.0.0.0
          service.submission.port = 587
          service.submission.name = submission
          with this, we would have submission_recipient_restrictions = mumble dee
          service.submission.logname = postmumble/submission
          service.submission.options = joe=jim foo=bar ...
          this would add -o joe=jim etc. for all but "well known options".

          if you go that road, then at one time, master.cf would become a "service
          definition" file.







          >
          > Update the "chroot" column to "n" for all services.
          >
          > postconf -Mu type=unix fifo
          >
          > Update all "fifo" services so that they use UNIX-domain
          > sockets. This is more laptop-friendly as it avoids MTIME
          > updates.
          >
          > Obviously, this command is powerful but it can also inflict a great
          > deal of damage.
          >
          > And finally, a more complicated example:
          >
          > postconf -Me 'text of complete master.cf entry'
          >
          > Replace the specified master.cf service or add a new service.
          > Each postconf(1) command-line argument contains the text
          > of a complete master.cf entry. The new entry is line-wrapped
          > as with "postconf -Mf".
          >
          > This command syntax is consistent with existing "postconf -e"
          > commands, where each postconf(1) command-line argument contains the
          > text of a complete main.cf entry.
          >
          > However, the syntax differs from "postconf -M" commands that can
          > target multiple services, such as "postconf -M inet" or "postconf
          > -Mu chroot=n inet". There, a service is better specified as
          > service-type or service-type.service-name.
          >
          > Considering the difference between specifying the complete content
          > of a master.cf entry versus a patterm that can select multiple
          > master.cf entries, it makes sense to have this difference in command
          > syntax.
          >
          > Wietse
        • mouss
          ... given that people use different version control systems, I wouldn t make that part of postfix. also, I am working on a web UI, where the whole conf would
          Message 4 of 23 , Jan 8, 2013
          • 0 Attachment
            Le 08/01/2013 23:06, Wietse Venema a écrit :
            > Patrick Ben Koetter:
            > [snip]
            >> Should postconf be able/offer to make backup copies before it acts a request
            >> out?
            > Should it with main.cf? Should we enourage the use of version control?

            given that people use different version control systems, I wouldn't make
            that part of postfix.

            also, I am working on a web UI, where the whole conf would be in a db
            (dumped to config files of course!). in which case, the version control
            part amounts to a few columns (who did what when...) and a rollback is
            not a lot more than an sql query.
            (I actually can do all that "for me", but I find it hard to support all
            the possible configurations that postfix supports).


            >>> And finally, a more complicated example:
            >>>
            >>> postconf -Me 'text of complete master.cf entry'
            >>>
            >>> Replace the specified master.cf service or add a new service.
            >>> Each postconf(1) command-line argument contains the text
            >>> of a complete master.cf entry. The new entry is line-wrapped
            >>> as with "postconf -Mf".
            >>>
            >>> This command syntax is consistent with existing "postconf -e"
            >>> commands, where each postconf(1) command-line argument contains the
            >>> text of a complete main.cf entry.
            >> In postconf(1) you wrote "-e Edit the main.cf configuration file, and update
            >> parameter settings ..."
            > The text is too vague and needs to be updated. What happens in
            > reality is "replace or add main.cf entry, using the complete entry
            > given on the postconf command line".
            >
            > If there is a command to implement THAT FUNCTION for master.cf (add
            > or replace entry, using the complete entry given on the postconf
            > command line) then it should use the same -e option.
            >
            >> I haven't thought this through - you probably have: Wouldn't it be more
            >> consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as
            >> proposed for master.cf?
            > "u" replaces a field in master.cf. It has no main.cf equivalent
            > (replace a word in the middle of a line?) therefore should not use
            > an option letter that is used for main.cf.
            >
            > Wietse
          • Wietse Venema
            ... A problem is that your syntax is ambiguous: a service name may contain . , the same character that you propose to use as the separator between service
            Message 5 of 23 , Jan 8, 2013
            • 0 Attachment
              mouss:
              > > I am contemplating a new class of master.cf operations that operate
              > > column-wise. These currently have no main.cf equivalent.
              > >
              > > postconf -Mu chroot=n inet unix fifo pass
              >
              > I like the "mib" syntax of main.cf. so I'd prefer something like
              > postconf -e service.submission.chroot=n (or false|no|whatever)
              > and then, I would love to have that in main.cf.

              A problem is that your syntax is ambiguous: a service name may
              contain ".", the same character that you propose to use as the
              separator between service name and column name (in fact any non-space
              character is permitted though '/' might be a problem).

              > service.submission.class = smtpd
              > service.submission.address = 0.0.0.0
              > service.submission.port = 587
              > service.submission.name = submission

              I want to complete the support for the existing configuration file
              formats, before I start to consider semantical changes.

              Wietse
            • Patrick Ben Koetter
              ... Neither do I. Here s the problem I d like to solve: The submission service is commented out by default. Nowadays I enable it very often when I install
              Message 6 of 23 , Jan 8, 2013
              • 0 Attachment
                * Wietse Venema <postfix-users@...>:
                > Patrick Ben Koetter:
                > > > Next, a few examples that are likely to be implemented:
                > > >
                > > > postconf -M# service-type ...
                > > > postconf -M# service-type.service-name ...
                > > >
                > > > postconf -MX service-type ...
                > > > postconf -MX service-type.service-name ...
                > > >
                > > > Delete (or comment) out the specified services.
                > >
                > > Would it make sense - differing from main.cf behaviour - to revert
                > > comments in master.cf?
                >
                > In both cases, I don't understand how that would work.

                Neither do I.

                Here's the problem I'd like to solve: The submission service is commented out
                by default. Nowadays I enable it very often when I install Postfix. Issuing a
                command that removes/reverts the comments from e.g. the submission service
                sounds just like a feature that would solve my problem. Thus the investigation
                if it made sense to revert comments in master.cf.

                On a sidenote: At the moment "postconf -M ..." doesn't seem to list service
                types that are commented out. Unless I haven't missed a way it would probably
                make sense to list them if comments were to be reverted.


                > > > I am contemplating a new class of master.cf operations that operate
                > > > column-wise. These currently have no main.cf equivalent.
                > > >
                > > > postconf -Mu chroot=n inet unix fifo pass
                > > >
                > > > Update the "chroot" column to "n" for all services.
                > >
                > > Would the new class also allow to edit a _single_ service e.g.:
                > >
                > > postconf -Mu chroot=n inet.submission
                >
                > Of course. A pattern can match one entry or more.
                >
                > > Should postconf be able/offer to make backup copies before it acts a request
                > > out?
                >
                > Should it with main.cf? Should we enourage the use of version control?

                Somehow I fear that we will see more users having ruined their master.cf than
                others having done the same to main.cf. Resurrecting a master.cf seems to be
                more hard because of its higher inner complexity (columns etc.).

                I think the documentation should encourage the use of version control. The
                rest may remain every admins personal responsibility.


                > > > And finally, a more complicated example:
                > > >
                > > > postconf -Me 'text of complete master.cf entry'
                > > >
                > > > Replace the specified master.cf service or add a new service.
                > > > Each postconf(1) command-line argument contains the text
                > > > of a complete master.cf entry. The new entry is line-wrapped
                > > > as with "postconf -Mf".
                > > >
                > > > This command syntax is consistent with existing "postconf -e"
                > > > commands, where each postconf(1) command-line argument contains the
                > > > text of a complete main.cf entry.
                > >
                > > In postconf(1) you wrote "-e Edit the main.cf configuration file, and update
                > > parameter settings ..."
                >
                > The text is too vague and needs to be updated. What happens in
                > reality is "replace or add main.cf entry, using the complete entry
                > given on the postconf command line".
                >
                > If there is a command to implement THAT FUNCTION for master.cf (add
                > or replace entry, using the complete entry given on the postconf
                > command line) then it should use the same -e option.
                >
                > > I haven't thought this through - you probably have: Wouldn't it be more
                > > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as
                > > proposed for master.cf?
                >
                > "u" replaces a field in master.cf. It has no main.cf equivalent
                > (replace a word in the middle of a line?) therefore should not use
                > an option letter that is used for main.cf.

                Got it.

                Thanks

                p@rick

                --
                [*] 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
              • Viktor Dukhovni
                ... I almost no issues with any of the proposed interfaces. The new -Me syntax is natural. The -Mu syntax also makes sense for all the standard columns. The
                Message 7 of 23 , Jan 8, 2013
                • 0 Attachment
                  On Tue, Jan 08, 2013 at 04:00:34PM -0500, Wietse Venema wrote:

                  >
                  > However, the syntax differs from "postconf -M" commands that can
                  > target multiple services, such as "postconf -M inet" or "postconf
                  > -Mu chroot=n inet". There, a service is better specified as
                  > service-type or service-type.service-name.
                  >
                  > Considering the difference between specifying the complete content
                  > of a master.cf entry versus a patterm that can select multiple
                  > master.cf entries, it makes sense to have this difference in command
                  > syntax.

                  I almost no issues with any of the proposed interfaces. The new
                  "-Me" syntax is natural. The -Mu syntax also makes sense for all
                  the standard columns.

                  The only part that is tricky is the "command + args" column, where
                  users arguably may want to add/delete "-o" flags, but in general
                  the various "-o" flags one may want to add are not necessarily
                  othogonal, and it is not always safe to add such a setting while
                  unware of its context. So perhaps when changing the command, one
                  should be forced to use "-Me", but this is not completely obvious.

                  Perhaps one should be add to insert or delete a "-o" setting, but
                  this would likely require yet another cinterface (-Mo?) and is likely
                  not worth the complexity.

                  --
                  Viktor.
                • Noel Jones
                  ... I don t think uncomment is particularly useful. Just ignore commented entries; add a new entry with the desired settings. That way you don t have to
                  Message 8 of 23 , Jan 8, 2013
                  • 0 Attachment
                    On 1/8/2013 5:26 PM, Patrick Ben Koetter wrote:
                    > * Wietse Venema <postfix-users@...>:
                    >> Patrick Ben Koetter:
                    >>>> Next, a few examples that are likely to be implemented:
                    >>>>
                    >>>> postconf -M# service-type ...
                    >>>> postconf -M# service-type.service-name ...
                    >>>>
                    >>>> postconf -MX service-type ...
                    >>>> postconf -MX service-type.service-name ...
                    >>>>
                    >>>> Delete (or comment) out the specified services.
                    >>>
                    >>> Would it make sense - differing from main.cf behaviour - to revert
                    >>> comments in master.cf?
                    >>
                    >> In both cases, I don't understand how that would work.
                    >
                    > Neither do I.
                    >
                    > Here's the problem I'd like to solve: The submission service is commented out
                    > by default. Nowadays I enable it very often when I install Postfix. Issuing a
                    > command that removes/reverts the comments from e.g. the submission service
                    > sounds just like a feature that would solve my problem. Thus the investigation
                    > if it made sense to revert comments in master.cf.

                    I don't think "uncomment" is particularly useful. Just ignore
                    commented entries; add a new entry with the desired settings. That
                    way you don't have to worry about multiple matching comments with
                    the same name.


                    >
                    > On a sidenote: At the moment "postconf -M ..." doesn't seem to list service
                    > types that are commented out. Unless I haven't missed a way it would probably
                    > make sense to list them if comments were to be reverted.

                    I think comments should be ignored by the automated tools.

                    And yes, the docs should strongly encourage the user to back up *.cf
                    before mucking around with them. I can imagine postconf saving the
                    unmodified file to eg. ./rescue/master.cf-{date+time}.


                    -- Noel Jones
                  • mouss
                    ... oops. for some reason mib lead me to sysctl syntax. of course, postfix (mai.cf) uses underscores so that should read service_smtp:127.0.0.1_enable = yes
                    Message 9 of 23 , Jan 9, 2013
                    • 0 Attachment
                      Le 09/01/2013 00:00, Wietse Venema a écrit :
                      > mouss:
                      >>> I am contemplating a new class of master.cf operations that operate
                      >>> column-wise. These currently have no main.cf equivalent.
                      >>>
                      >>> postconf -Mu chroot=n inet unix fifo pass
                      >> I like the "mib" syntax of main.cf. so I'd prefer something like
                      >> postconf -e service.submission.chroot=n (or false|no|whatever)
                      >> and then, I would love to have that in main.cf.
                      > A problem is that your syntax is ambiguous: a service name may
                      > contain ".", the same character that you propose to use as the
                      > separator between service name and column name (in fact any non-space
                      > character is permitted though '/' might be a problem).

                      oops. for some reason mib lead me to sysctl syntax. of course, postfix
                      (mai.cf) uses underscores so that should read

                      service_smtp:127.0.0.1_enable = yes
                      ...

                      of course, this is still not safe because people could have used
                      underscores in services names.


                      >> service.submission.class = smtpd
                      >> service.submission.address = 0.0.0.0
                      >> service.submission.port = 587
                      >> service.submission.name = submission
                      > I want to complete the support for the existing configuration file
                      > formats, before I start to consider semantical changes.
                      >
                      > Wietse
                    • Wietse Venema
                      ... Editing individual words in master.cf with a command-line tool is too much like editing a text document on a hard-copy terminal. I ll aim for a limited
                      Message 10 of 23 , Jan 11, 2013
                      • 0 Attachment
                        Viktor Dukhovni:
                        > The only part that is tricky is the "command + args" column, where
                        > users arguably may want to add/delete "-o" flags, but in general
                        > the various "-o" flags one may want to add are not necessarily
                        > othogonal, and it is not always safe to add such a setting while
                        > unware of its context. So perhaps when changing the command, one
                        > should be forced to use "-Me", but this is not completely obvious.

                        Editing individual words in master.cf with a command-line tool is
                        too much like editing a text document on a hard-copy terminal.

                        I'll aim for a limited interface:

                        postconf -Mu attribute=value... service-spec...

                        Or in mouss style, which makes -e redundant:

                        postconf -M type.service.attribute=value...

                        For each matching service, update the named attributes with the
                        specified values. It remains to be seen how robust the latter form
                        can be made, considering that '.' already appears in service names
                        as part of an IP address. Also, we would have to forbid the use
                        of '=' in a service name, which I hope is uncommon.

                        The attribute name is "service", "type", "private", "unprivileged",
                        "chroot", "wakeup", "process_limit" or "command". The command
                        attribute includes both the name and arguments; the attribute value
                        would typically be specified in the shell as a quoted string with
                        embedded whitespace.

                        If there is a command to set the value of a specific attribute,
                        that suggests there needs to be a corresponding command to query
                        its value. I'm sure that mouss would want to see something like
                        "type.service.attribute = value" here. Asking for an attribute's
                        value by its name is not necessarily useful for humans but it would
                        allow for a more robust "postfix upgrade-configuration" implementation.

                        If the concerns with '=' and '.' in service names can be overcome,
                        then the mouss syntax would simplify the user interface to query
                        or update a master.cf attribute.

                        Wietse
                      • Viktor Dukhovni
                        ... Neither is actually a problem provided we use strrchr to find the delimiter, since the attribute names never contain = or . . So it is fine if the
                        Message 11 of 23 , Jan 11, 2013
                        • 0 Attachment
                          On Fri, Jan 11, 2013 at 03:47:41PM -0500, Wietse Venema wrote:

                          > If the concerns with '=' and '.' in service names can be overcome,
                          > then the mouss syntax would simplify the user interface to query
                          > or update a master.cf attribute.

                          Neither is actually a problem provided we use "strrchr" to find
                          the delimiter, since the attribute names never contain "=" or ".".
                          So it is fine if the service names do, provided we use "-Mu" to
                          indicate an attribute update.

                          --
                          Viktor.
                        • Wietse Venema
                          ... This would be incorrect when a command attribute value contains = , for example with -o name=value or with pipe(8) daemon command lines. I think that
                          Message 12 of 23 , Jan 11, 2013
                          • 0 Attachment
                            Viktor Dukhovni:
                            > On Fri, Jan 11, 2013 at 03:47:41PM -0500, Wietse Venema wrote:
                            >
                            > > If the concerns with '=' and '.' in service names can be overcome,
                            > > then the mouss syntax would simplify the user interface to query
                            > > or update a master.cf attribute.
                            >
                            > Neither is actually a problem provided we use "strrchr" to find
                            > the delimiter, since the attribute names never contain "=" or ".".

                            This would be incorrect when a "command" attribute value contains
                            '=', for example with "-o name=value" or with pipe(8) daemon command
                            lines.

                            I think that it's useful for scripting if postconf supports queries
                            for the command attribute (i.e. command name and arguments) just
                            like it supports queries for other master.cf attributes. And of
                            course, queries and assignments should use similar syntax.

                            If we allow '=' in service names then we would need to help the
                            parser a little, for example by allowing that a service name is
                            enclosed with [] (similar to what happened with IPv6 to avoid
                            mis-parsing the ':').

                            Otherwise, '=' in a service name can be mis-parsed even if the
                            parser knows all the names in master.cf. For example with two known
                            type.service entries "inet.foo" and "inet.foo.command=x", the string
                            "inet.foo.command=xx.chroot=y" can be parsed in two ways.

                            There is no such problem with "inet.[foo.command=x].chroot=y".

                            Wietse
                          • Robert Moskowitz
                            ... My thoughts on this is which provides a better delete function? attribute= may NOT be a delte function, as the default may be something other than
                            Message 13 of 23 , Jan 13, 2013
                            • 0 Attachment
                              On 01/11/2013 03:47 PM, Wietse Venema wrote:
                              > Viktor Dukhovni:
                              >> The only part that is tricky is the "command + args" column, where
                              >> users arguably may want to add/delete "-o" flags, but in general
                              >> the various "-o" flags one may want to add are not necessarily
                              >> othogonal, and it is not always safe to add such a setting while
                              >> unware of its context. So perhaps when changing the command, one
                              >> should be forced to use "-Me", but this is not completely obvious.
                              > Editing individual words in master.cf with a command-line tool is
                              > too much like editing a text document on a hard-copy terminal.
                              >
                              > I'll aim for a limited interface:
                              >
                              > postconf -Mu attribute=value... service-spec...
                              >
                              > Or in mouss style, which makes -e redundant:
                              >
                              > postconf -M type.service.attribute=value...

                              My thoughts on this is which provides a better delete function?

                              "attribute= " may NOT be a delte function, as the default may be
                              something other than blank. So an actual delete this attribute from
                              master.cf would be valuable. Or at least my limited experience leans
                              that way. So I think the mouss style is better oriented to a delete
                              function.

                              > For each matching service, update the named attributes with the
                              > specified values. It remains to be seen how robust the latter form
                              > can be made, considering that '.' already appears in service names
                              > as part of an IP address. Also, we would have to forbid the use
                              > of '=' in a service name, which I hope is uncommon.
                              >
                              > The attribute name is "service", "type", "private", "unprivileged",
                              > "chroot", "wakeup", "process_limit" or "command". The command
                              > attribute includes both the name and arguments; the attribute value
                              > would typically be specified in the shell as a quoted string with
                              > embedded whitespace.
                              >
                              > If there is a command to set the value of a specific attribute,
                              > that suggests there needs to be a corresponding command to query
                              > its value. I'm sure that mouss would want to see something like
                              > "type.service.attribute = value" here. Asking for an attribute's
                              > value by its name is not necessarily useful for humans but it would
                              > allow for a more robust "postfix upgrade-configuration" implementation.
                              >
                              > If the concerns with '=' and '.' in service names can be overcome,
                              > then the mouss syntax would simplify the user interface to query
                              > or update a master.cf attribute.
                              >
                              > Wietse
                              >
                            • Wietse Venema
                              ... For main.cf, postconf already uses the following syntax: postconf mynetworks ... show main.cf entry(or entries) postconf -# mynetworks ... comment out
                              Message 14 of 23 , Jan 13, 2013
                              • 0 Attachment
                                Robert Moskowitz:
                                > My thoughts on this is which provides a better delete function?

                                For main.cf, postconf already uses the following syntax:

                                postconf mynetworks ... show main.cf entry(or entries)
                                postconf -# mynetworks ... comment out main.cf entry
                                postconf -X mynetworks ... delete main.cf entry

                                Using the same approach for master.cf:

                                postconf -M inet.smtp ... show master.cf entry(or entries)
                                postconf -M# inet.smtp ... comment out master.cf entry
                                postconf -MX inet.smtp ... delete master.cf entry

                                Less syntax to learn, fewer mistakes to make.

                                Wietse
                              • Robert Moskowitz
                                ... Oh, excellent and very clear. Thank you. Now these parts of the man page make more sense. It does raise a question if there is an uncomment option? For
                                Message 15 of 23 , Jan 13, 2013
                                • 0 Attachment
                                  On 01/13/2013 02:54 PM, Wietse Venema wrote:
                                  > Robert Moskowitz:
                                  >> My thoughts on this is which provides a better delete function?
                                  > For main.cf, postconf already uses the following syntax:
                                  >
                                  > postconf mynetworks ... show main.cf entry(or entries)
                                  > postconf -# mynetworks ... comment out main.cf entry
                                  > postconf -X mynetworks ... delete main.cf entry
                                  >
                                  > Using the same approach for master.cf:
                                  >
                                  > postconf -M inet.smtp ... show master.cf entry(or entries)
                                  > postconf -M# inet.smtp ... comment out master.cf entry
                                  > postconf -MX inet.smtp ... delete master.cf entry
                                  >
                                  > Less syntax to learn, fewer mistakes to make.

                                  Oh, excellent and very clear. Thank you. Now these parts of the man page
                                  make more sense.

                                  It does raise a question if there is an uncomment option? For example
                                  submission is commented in the master.cf and a very frequent uncomment
                                  target.

                                  I can see, though that this could be really hard as to how to recognize
                                  a comment line as a commented parameter line.
                                • Wietse Venema
                                  ... I don t understand how that would work. Wietse
                                  Message 16 of 23 , Jan 14, 2013
                                  • 0 Attachment
                                    Robert Moskowitz:
                                    > It does raise a question if there is an uncomment option? For example
                                    > submission is commented in the master.cf and a very frequent uncomment
                                    > target.

                                    I don't understand how that would work.

                                    Wietse
                                  • Robert Moskowitz
                                    ... Actually, I don t either! SInce both main.cf and master.cf are just text files that anyone can edit, how does postconf determine that a comment line is
                                    Message 17 of 23 , Jan 14, 2013
                                    • 0 Attachment
                                      On 01/14/2013 03:59 AM, Wietse Venema wrote:
                                      > Robert Moskowitz:
                                      >> It does raise a question if there is an uncomment option? For example
                                      >> submission is commented in the master.cf and a very frequent uncomment
                                      >> target.
                                      > I don't understand how that would work.
                                      Actually, I don't either!

                                      SInce both main.cf and master.cf are just text files that anyone can
                                      edit, how does postconf determine that a comment line is really a
                                      parameter that can be uncommented? Rather hard and wrong actions can
                                      happen all to frequently.

                                      When I looked at the comment open (-#) my immediate reaction was an
                                      uncomment option (--#). But then I spent a few brain cells on thinking
                                      about how it would work and realized that it would be open to bad
                                      behaviour. Still a nice idea.

                                      ================wayback machine time====================

                                      You see way back in the early 80s, I was a Database development manager
                                      at a company that used a CODYSL (probably got that acroymn wrong, think
                                      I am missing a letter) database system. I typically had 3-4 applications
                                      groups putting in database changes over a weekend and typically one
                                      would fail and have to back out their changes, so I had to develop a
                                      schema file management system to maintain this and since I had complete
                                      control over the schema file content, I COULD do things like uncomment.
                                      But those were simplier days and no one, but my database people, were
                                      allowed to touch the schema files. No hand editing allowed; use the
                                      management system we developed only. I think this is another reason why
                                      I am pre-disposed to perfering postconf to maintain the .cf files. Oh,
                                      back then we programed in 'B'; really!

                                      =================return to the present===================

                                      So just wishful thinking on a users part.

                                      Thank you for all you are doing.
                                    • Wietse Venema
                                      ... See http://www.postfix.org/postconf.5.html#master_service_disable for an approach that avoids these issues. This feature uses DNS-like notation to select
                                      Message 18 of 23 , Jan 14, 2013
                                      • 0 Attachment
                                        Robert Moskowitz:
                                        > On 01/14/2013 03:59 AM, Wietse Venema wrote:
                                        > > Robert Moskowitz:
                                        > >> It does raise a question if there is an uncomment option? For example
                                        > >> submission is commented in the master.cf and a very frequent uncomment
                                        > >> target.
                                        > > I don't understand how that would work.
                                        > Actually, I don't either!

                                        See http://www.postfix.org/postconf.5.html#master_service_disable
                                        for an approach that avoids these issues. This feature uses DNS-like
                                        notation to select a service, i.e. "service.type" or just "type":

                                        master_service_disable = inet (disable all inbound network servers)
                                        master_service_disable = inet pickup.fifo (disable inbound mail)

                                        Now, this uncovers one minor problem in my plans.

                                        I adopted the same DNS-like notation for "postconf -M", for example:

                                        # postconf -M inet (show all inbound network services)
                                        # postconf -M inet pickup.fifo (show inbound mail services)

                                        But the RFCs in this thread seem to favor the reverse, MIB-style,
                                        notation: type.service and type.service.attribute.

                                        Fortunately things can be changed, whether in design (easy) or in
                                        deployment (more work).

                                        First, where would postconf use pathname notation? It is a natural
                                        approach if we want to update or query individual service attribute
                                        values. This is especially useful for scripting. With the DNS-like
                                        notation, that would look like:

                                        # postconf -M chroot.smtp.inet=n process_limit.smtp.inet=25
                                        # postconf -M chroot.smtp.inet process_limit.smtp.inet
                                        chroot.smtp.inet = n
                                        process_limit.smtp.inet = 25
                                        # postconf -Mh chroot.smtp.inet
                                        n

                                        With the MIB-style notation proposed by mouss, the equivalent
                                        commands would look like:

                                        # postconf -M inet.smtp.chroot=n inet.smtp.process_limit=25
                                        # postconf -M inet.smtp.chroot inet.smtp.process_limit
                                        inet.smtp.chroot = n
                                        inet.smtp.process_limit = 25
                                        # postconf -Mh inet.smtp.chroot
                                        n

                                        Both notations are equally capable (and the MIB notation perhaps
                                        more natural). More important is that the MIB-style notation appears
                                        to be more common for attribute manipulation.

                                        How do we reconcile the differences? It's easy enough for designs
                                        that haven't been implemented and it's the cost of business for
                                        users of a development release, but it requires a planned migration
                                        when it affects users of a stable release.

                                        If we are to use "type.service" in "postconf -M" commands, then
                                        historical features that use "service.type" will have to be migrated
                                        to that form, too. The affected features are master_service_disable
                                        (introduced with Postfix 2.6), and with "postconf -M" (introduced
                                        with Postfix 2.9). These will have to support both forms for the
                                        near future (use the preferred syntax first, and fall back to its
                                        reverse if the prefferred syntax does not work).

                                        I did not expect that Postfix would end up with little-endian versus
                                        big-endian issues, but there we are.

                                        Wietse
                                      • Pau Amma
                                        ... JANET (dammit!) (Probably showing my age on several counts.)
                                        Message 19 of 23 , Jan 14, 2013
                                        • 0 Attachment
                                          On Mon, January 14, 2013 4:46 pm, Wietse Venema wrote:
                                          > I did not expect that Postfix would end up with little-endian versus
                                          > big-endian issues, but there we are.

                                          JANET (dammit!)

                                          (Probably showing my age on several counts.)
                                        • Wietse Venema
                                          ... The puzzled reader may want to look up http://www.ibiblio.org/pub/docs/mail-directories/janet.sites ... Bringing ancient history back to life! Wietse
                                          Message 20 of 23 , Jan 14, 2013
                                          • 0 Attachment
                                            Pau Amma:
                                            > On Mon, January 14, 2013 4:46 pm, Wietse Venema wrote:
                                            > > I did not expect that Postfix would end up with little-endian versus
                                            > > big-endian issues, but there we are.
                                            >
                                            > JANET (dammit!)

                                            The puzzled reader may want to look up
                                            http://www.ibiblio.org/pub/docs/mail-directories/janet.sites

                                            > (Probably showing my age on several counts.)

                                            Bringing ancient history back to life!

                                            Wietse
                                          • mouss
                                            ... note that the delimiter may be a dot as in sysctl or an underscore as in main.cf, BSD rc.conf, ... (underscore is more shell friendly). I like the MIB
                                            Message 21 of 23 , Jan 14, 2013
                                            • 0 Attachment
                                              Le 11/01/2013 21:47, Wietse Venema a écrit :
                                              > Viktor Dukhovni:
                                              >> The only part that is tricky is the "command + args" column, where
                                              >> users arguably may want to add/delete "-o" flags, but in general
                                              >> the various "-o" flags one may want to add are not necessarily
                                              >> othogonal, and it is not always safe to add such a setting while
                                              >> unware of its context. So perhaps when changing the command, one
                                              >> should be forced to use "-Me", but this is not completely obvious.
                                              > Editing individual words in master.cf with a command-line tool is
                                              > too much like editing a text document on a hard-copy terminal.
                                              >
                                              > I'll aim for a limited interface:
                                              >
                                              > postconf -Mu attribute=value... service-spec...
                                              >
                                              > Or in mouss style, which makes -e redundant:
                                              >
                                              > postconf -M type.service.attribute=value...


                                              note that the delimiter may be a dot as in sysctl or an underscore as in
                                              main.cf, BSD rc.conf, ... (underscore is more shell friendly).

                                              I like the MIB approach because it is generic enough. it can be easily
                                              implemented in a UI, in a DB, ... etc. I can use the same syntax for
                                              postfix as well as for other stuff. and given that postfix is often
                                              integrated with other stuff (network config, pop/imap, mailing-list,
                                              anti-spam, fetchmail/getmail/.., ...), having a generic syntax is a good
                                              thing IMHO.


                                              as for uncommenting out services, I personally prefer to distinguish:
                                              defining a service (specifying its attribtes) and enabling/disabling
                                              that service.


                                              >
                                              > For each matching service, update the named attributes with the
                                              > specified values. It remains to be seen how robust the latter form
                                              > can be made, considering that '.' already appears in service names
                                              > as part of an IP address. Also, we would have to forbid the use
                                              > of '=' in a service name, which I hope is uncommon.
                                              >
                                              > The attribute name is "service", "type", "private", "unprivileged",
                                              > "chroot", "wakeup", "process_limit" or "command". The command
                                              > attribute includes both the name and arguments; the attribute value
                                              > would typically be specified in the shell as a quoted string with
                                              > embedded whitespace.
                                              >
                                              > If there is a command to set the value of a specific attribute,
                                              > that suggests there needs to be a corresponding command to query
                                              > its value. I'm sure that mouss would want to see something like
                                              > "type.service.attribute = value" here. Asking for an attribute's
                                              > value by its name is not necessarily useful for humans but it would
                                              > allow for a more robust "postfix upgrade-configuration" implementation.
                                              >
                                              > If the concerns with '=' and '.' in service names can be overcome,
                                              > then the mouss syntax would simplify the user interface to query
                                              > or update a master.cf attribute.
                                              >
                                              > Wietse
                                            Your message has been successfully submitted and would be delivered to recipients shortly.