Discussion:
generic main.cf files
(too old to reply)
Michael Fox
2016-07-23 18:00:42 UTC
Permalink
I've got several postfix systems which all have the same configuration
except for a few host-specific parameters like:
-- myhostname
-- mynetworks
-- mydestination
-- myorigin
-- inet_interfaces
-- proxy_interfaces
-- relay_domains
-- virtual_mailbox_domains

Typically, I copy the main.cf to another machine and edit the host-specific
values. What would be nice is to have a generic main.cf that can be copied
to any machine and which references all host-specific values in external
files.

In http://www.postfix.org/postconf.5.html, there is no general rule at the
top that says a filename can be used for any parameter. So it is evidently
available only for some parameters. And some of the above parameters are
indeed documented as allowing filenames (mynetworks, mydestination,
relay_domains, virtual_mailbox_domains).

But I ran into a few problems and have a few questions:

1) myorigin is not documented as allowing a filename. But the Ubuntu
Postfix package sets it to /etc/mailname, which seems to work. Perhaps
http://www.postfix.org/postconf.5.html should be updated?

2) proxy_interfaces is not documented as allowing a filename. But postfix
check and postfix reload accept it. Perhaps
http://www.postfix.org/postconf.5.html should be updated?

3) myhostname and inet_interfaces do not accept a filename. Is there a way
to set them from a source outside of main.cf (i.e., a file)?

4) When an external filename is used, postconf shows the filename, not the
value. That's good when sending postconf -n to this list. But I'd also
like to be able to see the actual values Postfix has configured. I can't
find a way to do that. Postconf -x only expands $variablename, not the
contents filenames. Is there a way to show the actual value assigned to a
parameter if it comes from a file?

5) Alternatively, I could place all of the host-specific parameters in a
file that is then included into main.cf, such as "!include
host-specific-main.cf". But I don't see an include mechanism listed. Does
it exist?

Thanks for any suggestions.
Michael
Wietse Venema
2016-07-23 19:57:46 UTC
Permalink
The documented behavior is supported, as in, bugs fixed and backwards
compatibility provided as Postfix evolves. Undocumented behavior is
unsupported.

There is no 'include' command for main.cf or master.cf files, because
a) it would complicate how commands like 'postconf -e' work, b)
it would complicate the 'postfix check' that Postfix parameters
don't come from a file or directory that is writable by non-root
users, c) other considerations that were hashed out many years ago.

I suggest that you have a script on each machine that customizes a
generic Postfix main.cf and master.cf file. As of a few releases
you can use 'postconf -F' to customize each master.cf field and
'postconf -P' to customize each '-o name=value' parameter setting
in master.cf.

In a distant past I might suggest using rdist to move and customize
files; nowadays people might use Puppet, Chef, and the like to a
similar effect.

Wietse
Peter
2016-07-23 22:54:30 UTC
Permalink
Post by Michael Fox
In http://www.postfix.org/postconf.5.html, there is no general rule at the
top that says a filename can be used for any parameter. So it is evidently
available only for some parameters. And some of the above parameters are
indeed documented as allowing filenames (mynetworks, mydestination,
relay_domains, virtual_mailbox_domains).
Specifically, they can be specified in database tables, which can be any
of the supported table types listed in postconf -m.
Post by Michael Fox
1) myorigin is not documented as allowing a filename. But the Ubuntu
Postfix package sets it to /etc/mailname, which seems to work. Perhaps
http://www.postfix.org/postconf.5.html should be updated?
This is a debian modification, it is not supported by Postfix.
Post by Michael Fox
5) Alternatively, I could place all of the host-specific parameters in a
file that is then included into main.cf, such as "!include
host-specific-main.cf". But I don't see an include mechanism listed. Does
it exist?
It would be nice, but no. People have scripted this in the past,
though, by using something like a makefile to build main.cf (and
possibly master.cf) from a collection of other files.


Peter
Michael Fox
2016-07-24 17:19:28 UTC
Permalink
Post by Wietse Venema
Ubuntu Postfix package sets myorigin to /etc/mailname, which seems to
work
Post by Wietse Venema
The documented behavior is supported, as in, bugs fixed and backwards
compatibility provided as Postfix evolves. Undocumented behavior is
unsupported.
This is a debian modification, it is not supported by Postfix.
Wow. OK. So, I guess I should remove the /etc/mailname setting. Strange.
It's been that way since at least Ubuntu 12.04 LTS., perhaps earlier.



What about viewing the value which is set by reading a file?
For example: mynetworks = ${config_directory}/filename

Postconf -x will resolve $config_directory. But I don't see a postconf
option that would show me what mynetworks is actually set to.
Post by Wietse Venema
There is no 'include' command for main.cf or master.cf files, because
a) it would complicate how commands like 'postconf -e' work, b)
it would complicate the 'postfix check' that Postfix parameters
don't come from a file or directory that is writable by non-root
users, c) other considerations that were hashed out many years ago.
OK. Thanks.
Post by Wietse Venema
I suggest that you have a script on each machine that customizes a
generic Postfix main.cf and master.cf file. As of a few releases
you can use 'postconf -F' to customize each master.cf field and
'postconf -P' to customize each '-o name=value' parameter setting
in master.cf.
In a distant past I might suggest using rdist to move and customize
files; nowadays people might use Puppet, Chef, and the like to a
similar effect.
OK. Thanks.

Michael
Scott Kitterman
2016-07-24 17:33:33 UTC
Permalink
Post by Michael Fox
Post by Wietse Venema
Ubuntu Postfix package sets myorigin to /etc/mailname, which seems
to
work
Post by Wietse Venema
The documented behavior is supported, as in, bugs fixed and backwards
compatibility provided as Postfix evolves. Undocumented behavior is
unsupported.
This is a debian modification, it is not supported by Postfix.
Wow. OK. So, I guess I should remove the /etc/mailname setting.
Strange.
It's been that way since at least Ubuntu 12.04 LTS., perhaps earlier.
It's been that way in Debian (and later Ubuntu) since at least 1999.

Not supported by Postfix upstream doesn't translate to remove it if you're using distro packages. It means consult distro specific support resources if you are having problems with it.

Scott K
Peter
2016-07-24 20:23:47 UTC
Permalink
Post by Michael Fox
What about viewing the value which is set by reading a file?
For example: mynetworks = ${config_directory}/filename
Look at postmap(1) to see how you can do map lookups from the command line.
Post by Michael Fox
Postconf -x will resolve $config_directory. But I don't see a postconf
option that would show me what mynetworks is actually set to.
postconf mynetworks


Peter
Michael Fox
2016-07-24 22:34:17 UTC
Permalink
Post by Peter
Post by Michael Fox
What about viewing the value which is set by reading a file?
For example: mynetworks = ${config_directory}/filename
Look at postmap(1) to see how you can do map lookups from the command
line.
To clarify, I'm not trying to do a map lookup. I'm trying to display the
configuration, where some values are set by reading from a file. But I did
try to use a cidr-type table such as:

network_table.cidr:
192.168.1.0/24 OK
192.168.2.0/24 OK
...

main.cf:
mynetworks = cidr:${config_directory}/network_table.cidr

No difference that I can tell.
Post by Peter
Post by Michael Fox
Postconf -x will resolve $config_directory. But I don't see a postconf
option that would show me what mynetworks is actually set to.
postconf mynetworks
That doesn't work. It shows:

mynetworks = ${config_directory}/text_filename
-or-
mynetworks = cidr:${config_directory}/network_table.cidr

And postconf -x mynetworks shows:

mynetworks = /etc/postfix/text_filename
-or-
mynetworks = hash:/etc/postfix/network_table.cidr

Again, I'd like to see the *value(s)* assigned to mynetworks, not the
filename or map name that the value came from. In other words, I'm looking
for the following postconf output:

mynetworks = 192.168.1.0/24, 192.168.2.0/24, ...

Is that possible?


Michael
Wietse Venema
2016-07-24 23:08:18 UTC
Permalink
Michael Fox:
[file name or lookup table expansions in mynetworks]
Post by Michael Fox
Again, I'd like to see the *value(s)* assigned to mynetworks, not the
filename or map name that the value came from. In other words, I'm looking
mynetworks = 192.168.1.0/24, 192.168.2.0/24, ...
Is that possible?
It is not documented, therefore it is not supported.

The postconf command DOES NOT dump the content of files or lookup
tables that are mentioned in main.cf or master.cf parameter settings,
whether those files ir tables are referenced by mynetworks, by
virtual_alias_maps, by smtpd_recipient_restrictions, or by any other
Postfix parameter.

Wietse
Michael Fox
2016-07-25 00:17:06 UTC
Permalink
Post by Wietse Venema
It is not documented, therefore it is not supported.
Thanks and understood. And BTW, the documentation is excellent -- the best
I've seen anywhere.

Not to quibble, but the reason I double checked was that there DO appear to
be supported features that are either not documented or else I haven't been
able to find where they are documented after extensive searching. For
example, I have never been able to find where the documentations says we can
make up our own parameter names in main.cf (like mua_*_restrictions), yet
that's something that is recommended on this list. In fact, the statement
"The remainder of this document is a description of all Postfix
configuration parameters" near the top of
http://www.postfix.org/postconf.5.html implies that no others can exist.

I know it would have been helpful to me if the "Postfix main.cf file format"
section of http://www.postfix.org/postconf.5.html mentioned the ability to
create custom parameters.

Michael
Wietse Venema
2016-07-25 00:54:09 UTC
Permalink
Post by Michael Fox
Post by Wietse Venema
It is not documented, therefore it is not supported.
Thanks and understood. And BTW, the documentation is excellent -- the best
I've seen anywhere.
Not to quibble, but the reason I double checked was that there DO appear to
be supported features that are either not documented or else I haven't been
Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.

Wietse
Michael Fox
2016-07-25 02:27:37 UTC
Permalink
Post by Wietse Venema
Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.
...
You skipped over the apparent discrepancy that I pointed out. I'll try to
word it differently:

You and Viktor and several others suggest creating custom parameter names to
solve certain problems. In fact, you did so earlier today, with
$mua_*_restrictions.

I presume you wouldn't suggest solutions that are unsupported. Correct?
If so, then by the above rule, the ability to create and use custom
parameter names must be documented. But I have looked and looked and I just
can't find it. In fact, the quote I provided in my last email seems to
imply the opposite. I want to add a reference to my configuration notes.
So, will you please point me to where that capability is documented?

Thanks,
Michael
Viktor Dukhovni
2016-07-25 02:50:22 UTC
Permalink
Post by Michael Fox
Post by Wietse Venema
Only the documented behavior is supported. That means that bugs are
fixed, backwards compatibility is maintained as Postfix evolves.
...
You skipped over the apparent discrepancy that I pointed out. I'll try to
Entrapment via sophistry is rather poor taste, ineffective and
annoying. While the text could/should be more clear, it reads:

The general format of the main.cf file is as follows:

Each logical line is in the form "parameter = value". Whitespace
around the "=" is ignored, as is whitespace at the end of a
logical line.

This does not restrict "parameter" to just the predefined ones.
While it is possible that a small minority of features are
under-documented, the general principle stands. If it is not
documented, it is not supported.

While there may be a documentation bug in a few corner cases, major
design elements (such as potential support for "include" files
would be) are never undocumented.
--
Viktor.
Peter
2016-07-25 03:24:11 UTC
Permalink
Post by Viktor Dukhovni
Each logical line is in the form "parameter = value". Whitespace
around the "=" is ignored, as is whitespace at the end of a
logical line.
This is in postconf(5) at the beginning, in the DESCRIPTION section,
since the GP asked where this was documented.


Peter

Loading...