Re: tool to edit master.cf
- Viktor Dukhovni:
> On Tue, Dec 25, 2012 at 09:36:52AM -0500, Wietse Venema wrote:Appleas and oranges are different things. Configuration parameters
> > 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?
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
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, therebyYes, "postconf -Me" is an obvious path for the future. This may
> obviating "postmast". It should be possible to add, remove or replace
> a service.
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 \I think we should reuse reuse -X (remove) and -# (comment out)
> <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.
which already serve similar purposes for main.cf.
> [ The "postmast" syntax supported replacing a service with a differentJust like "postconf -e" will add or replace an entry in main.cf,
> service (atomic delete + add), but this is not compelling in retrospect,
> and required the edit command to provide the name and type fields twice. ]
"postconf -Me" should add or replace an entry in master.cf. Requiring
the name twice seems inconsistent.