On Mon, 13 Jan 2003, Wietse Venema wrote:

> Victor.Duchovnimorganstanley.com:
> > - The smtp_mumble parameters are first looked up as <transport>_mumble,
> > and only then as smtp_mumble.
>
> And how would one audit a configuration with postconf? Not everything
> runs as a daemon (let alone as message delivery transport). The
> service name is ambiguous when used as parameter name prefix.
> Postfix has multiple name spaces because it supports multiple IPC
> mechanisms. For example, "smtp" is the name of the smtp/tcp port,
> but it is also the name of a Postfix internal AF_LOCAL socket.
>

I was thinking that "smtp" specifically, rather than all daemons in
general, would do this. Granted this is ad-hoc, so more generally any
delivery agent (and so necessarily a uniquely named fifo or unix domain
socket in $queue_directory/private/) would prefer its socket name over
argv[0] as a prefix for suitable parameters.

As for auditing with postconf, I have long held that "postconf" (w/o
-d) should print all main.cf settings, not just those that are obtained
from global/mail_param.h and the various initialization tables in the
various daemons.

The primary difficulty is finding default values for dynamic parameters
(e.g. ldapsource_server_port). This is not an issue for "postconf -n" or
when the parameter is explicitly set in main.cf.

I would suggest that the "<transport>_mumble" parameters should not exist
by default, so that instead of:

        relay_connect_timeout = $smtp_connect_timeout
        smtp_connect_timeout = 30s

we have:

        relay_connect_timeout = <undefined if not set in main.cf>
        smtp_connect_timeout = 30s

and the "relay" "smtp" explicitly checks for the composite parameter
"relay_connect_timeout" and then for a normal parameter
"smtp_connect_timeout".

With this everything is accessible via postconf, and it sometimes takes
two parameter lookups to determine the settings used by a daemon.

This generalizes to a design (perhaps a bad one, but worth considering I
think), where composite parameters in all cases have no defaults. Any
daemon that needs defaults for such parameters uses a second parameter
that holds the implicit default. For example with LDAP instead of:

   ldap_server_host = explicit (or otherwise localhost)
   ldap_server_port = explicit (or otherwise 389)

we would have:

   ldap_server_host = explicit (or otherwise $default_ldap_server_host)
   ldap_server_port = explicit (or otherwise $default_ldap_server_port)

Here all parameters are either known to postconf or don't exist.

> > I believe that all "-o" arguments in master.cf are workarounds for missing
> > features. It should IMHO be possible to configure all parameters in
> > main.cf.
>
> As long as there is a mechanism to give one main.cf parameter a
> context dependent value, people will use it.
>

Yes, I just think that master.cf is a not a very place to put
configuration parameters and that the practice should be discouraged and
made as much as possible unnecessary.

-- 
	Viktor.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]