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
