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
