* Wietse Venema <[email protected]>:
> 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
