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

Re: RFC: postconf user interface

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.