On Fri, Nov 29, 2013 at 05:41:35PM -0500, Wietse Venema wrote:
> There is no '/' in master.cf service names because master.cf services
> must have sockets or FIFOs under the postfix-owned "private" or
> "public" directory. It's unsafe for the Postfix master daemon to
> open sockets or FIFOs in directories that aren't under control by
> Postfix.
I was thinking of master.cf type "unix" entries, where the system
administrator could be using spawn(8) to create sockets outside
the Postfix queue directory. Perhaps such configurations are both
unwise and unsupported.
> Second, the idea is to uniformly represent all configuration features
> as "name = value" pairs, and to have the same uniform representation
> in query results and in update requests.
This does however mean that updates to multiple fields of the same
service entry are rather verbose:
postconf ... \
"service/type/name1 = value1" \
"service/type/name2 = value2"
where it might arguably be more "economical" for the user to use:
postconf ... \
-<SERVICE_NAME_FLAG> "service/type" \
"name1 = value1" \
"name2 = value2"
However, if the interface is intended primarily for scripts, not
interactive users, that is not a major issue.
> If all feature of Postfix can be represented as a list of name=value
> pairs, for example:
>
> feature context | name = value
> ====================|=====================
> main.cf | parameter = value
> master.cf field | service/type/field = value
> master.cf -o override | service/type/parameter = value
The down-side here is that software parsing the output may need to
implement a list of "reserved names" that distinguish parameter
names from "private", "unpriv", "chroot", "wakeup" and "maxproc".
One can even imagine perverse cases in which "chroot" or "maxproc"
are user-defined variables in main.cf parameters, with potential
master.cf overrides.
smtp unix ... smtp
-o maxproc=mumble
(maxproc is then used indirectly in some actual parameter processed by
smtp(8)).
I am not arguing against a uniform naming scheme, just suggesting
caution to disambiguate names of different types. It could, for
an off the cuff example, be as subtle as:
service/type.chroot (master.cf field)
vs.
service/type/chroot (-o override)
--
Viktor.
