Viktor Dukhovni:
> On Tue, Dec 25, 2012 at 09:36:52AM -0500, Wietse Venema wrote:
>
> > Early on it I had to make a choice: release Postfix as a "complete"
> > MTA, or release it as a work-in-progress. You also have a choice:
> > wait until Postfix is "complete" or use what we have now.
>
> I recall you did not see much benefit from such a tool. I did create a
> "postmast" utility a few years back, but it did not get adopted. The main
> feature was the ability to replace, not just append entries. Another was
> "postmast -n" and "postmast -d" to report non-default/default settings (for
> a particular service or all of master.cf).
>
> At this point the read-only feature-set is available via "postconf -M", with
> the exception that "postconf -Mn" reports entries with non-default parameter
> overrides, rather than simply non-default master.cf entries. I am not sure
> that this is the most intuitive interface. Perhaps it should show all
> non-default entries, including those that don't override parameters?
Appleas and oranges are different things. Configuration parameters
exist event when main.cf is empty, but services don't exist unless
they are specified in master.cf.
There is no shared definition for what is "default". In fact, it's
worse: while main.cf has a dependable built-in baseline, master.cf
does not even have a dependable "external" baseline definition.
Instead I prefer to keep the "-n" semantics identical for master.cf
and main.cf: in both cases it now means "show explicit configuration
parameter settings".
If not with "-n", how else would one request "show explicit parameter
settings" for master.cf? Use a different option name? Now that would
be a confusing user interface.
I suggest using a different option name to request a "diff" of
master.cf (or any configuration file) against a reference copy.
Remmeber that Postfix has no built-in master.cf settings.
The "diff" semantics have a non-trivial complication: different
maintainers provide different master.cf files, so we (as providers
of support) don't even know the baseline for this "diff" output.
Remember that Debian turns on chroot in master.cf.
For all these reasons I expect that more problems will be solved
by asking the user for "postconf -Mf inet" etc., that is, by asking
for specific entries by type or type.name, instead of asking for
entries that somehow differ from some unkown baseline.
> As for editing, "postconf -Me name.type" could still be added, thereby
> obviating "postmast". It should be possible to add, remove or replace
> a service.
Yes, "postconf -Me" is an obvious path for the future. This may
also benefit from the built-in line-wrapping support. Instead of
requiring -fe or -Mfe, perhaps folding could be made the default.
> # postconf -Me name.type \
> <private> <unpriv> <chroot> <wakeup> <maxproc> <command> [<args> ...]
>
> Add or re-define a service, and perhaps just "postconf -Md name.type"
> to delete a service, though it is often better to disable services,
> since that can be more easily undone.
I think we should reuse reuse -X (remove) and -# (comment out)
which already serve similar purposes for main.cf.
> [ The "postmast" syntax supported replacing a service with a different
> service (atomic delete + add), but this is not compelling in retrospect,
> and required the edit command to provide the name and type fields twice. ]
Just like "postconf -e" will add or replace an entry in main.cf,
"postconf -Me" should add or replace an entry in master.cf. Requiring
the name twice seems inconsistent.
Wietse
