Thanks for feedback. Background information: the advanced query/update methods are primarily for programmatic use by system management tools. This means the "user" interface needs to be highly consistent.
Ideally, postconf enumerates Postfix main.cf and master.cf details as a list of "name=value" pairs, with names organized into structured name spaces. This allows other programs to reason about how Postfix works, and to make precise updates without having to worry about the exact layout of master.cf files. The current implementation still lacks support to for managing daemon options (-v, -D) and for daemon non-option command-line arguments. That can be added later. Patrick Ben Koetter: > * Wietse Venema <[email protected]>: > > I recently picked up work on the postconf command that I suspended > > in January this year. It's probably best to just give a few examples. > > > > First, a word about notation. I wanted to describe master.cf > > properties with a kind of pathname notation. The original idea was > > to have things like servicename.servicetype.whatever but that turned > > out to be problematic. Services can have '.' in their name, and > > therefore, the '.' can also appear in service-defined parameters. > > > > So I switched to servicename/servicetype/whatever. The result will > > be released as a non-production snapshot because the code still > > needs to be burned in (looking for feedback on the user interface). > > Expected release is Wedneday. > > Out of curiosity: Will you aim for the ability to create services too? Yes, that was implemented last January. Adding a master.cf entry is similar to adding a main.cf one. > This would create a service 'delay' with 'reasonable defaults' (and get around > the tricky part to specify all options in one command). Unfortunately services such as qmgr, bounce, local have mandatory master.cf settings that differ from built-in defaults. I think it is not reasonable to build (i.e. duplicate) all that logic into the postconf command. [Just like master is a stupid daemon that knows nothing about Postfix services, postconf knows almost nothing. The main exception is that postconf knows about a few parameter names that depend on master.cf service names, and that was done only because it allows postconf to report mistakes that are otherwise dificult to find. Mistakes in mandatory master.cf settings are already reported by daemons themselves.] Instead of adding a service from scratch, perhaps a more reasonable approach is to clone an existing service (take a service that works, and then duplicate its settings under a different service name). Currently, to clone the smtp/unix service settings you could do this: $ postconf -M smtp/unix smtp unix - - n - - smtp Then copy those fields (except the first field) to the existing or new delay/unix service: $ postconf -M delay/unix="delay unix - - n - - smtp" This notation is similar to how "postconf parameter=value" replaces or adds a main.cf entry. To combine the above, and clone smtp/unix -> delay/unix in one command: $ postconf -M delay/unix="`postconf -M smtp/unix|sed 's/smtp/delay/'`" This is perhaps not super-convenient for manual cloning, but it should be sufficient for programmatic configuration management. > $ postconf -M delay/unix/command=smtp This notation is already used to change a single service field, so I think it is not suitable to manipulate (create or update) multiple service fields. > > Again, this form makes it very easy to modify one parameter > > setting, for example to change the smtpd_tls_security_level setting for > > the submission/inet service: > > > > $ postconf -P 'submission/inet/smtpd_tls_security_level=may' > > That would use the option "-P" to read and to write (edit) service parameters > in master.cf. For main.cf you have dedicated command line options for reading > (-d, -n) and for editing (-e). FYI, The "-e" option has been optional since 20100715. "postconf parametername" reads, and "postconf parametername=value" updates. I'm using the same to read or update master.cf. When all operations are similar there are fewer things to remember. main.cf entry: $ postconf smtpd_tls_security_level $ postconf smtpd_tls_security_level=may $ postconf -e smtpd_tls_security_level=may master.cf entry: $ postconf -M smtp/inet $ postconf -M smtp/inet="smtp inet .... smtpd" $ postconf -Me smtp/inet="smtp inet .... smtpd" master.cf field: $ postconf -F smtp/inet/chroot $ postconf -F smtp/inet/chroot=n $ postconf -Fe smtp/inet/chroot=n master.cf service parameter: $ postconf -P submission/inet/smtpd_tls_security_level $ postconf -P submission/inet/smtpd_tls_security_level=may $ postconf -Pe submission/inet/smtpd_tls_security_level=may I also use the same options for the same operations on main.cf entries, master.cf entries (-M), or on fields (-F) or parameters (-P) in master.cf entries: -x Expand $name in main.cf entry, or master.cf entry (-M) or parameter (-P). -X Delete main.cf entry, or master.cf entry (-M) or parameter (-P). -# Comment out main.cf entry, or master.cf entry (-M). If I did not use the same option for the same operation on different things, then I would run out of option letters, and you would not be able to remember them. Wietse
