Re: generic main.cf files

[Peter]

On 25/07/16 14:50, Viktor Dukhovni wrote:
> 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 is in postconf(5) at the beginning, in the DESCRIPTION section,
since the GP asked where this was documented.


Peter

Re: generic main.cf files

[Viktor Dukhovni]

On Sun, Jul 24, 2016 at 07:27:37PM -0700, Michael Fox wrote:

> > 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:

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.

RE: generic main.cf files

[Michael Fox]

> 
> 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

Re: generic main.cf files

[Wietse Venema]

Michael Fox:
> > 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

RE: generic main.cf files

[Michael Fox]

> 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

Re: generic main.cf files

[Wietse Venema]

Michael Fox:
[file name or lookup table expansions in mynetworks]
> 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?

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

RE: generic main.cf files

[Michael Fox]

> On 25/07/16 05:19, Michael Fox wrote:
> > 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.

 
> > 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

Re: generic main.cf files

[Peter]

On 25/07/16 05:19, Michael Fox wrote:
> 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.

> 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

RE: generic main.cf files

[Scott Kitterman]

On July 24, 2016 1:19:28 PM EDT, Michael Fox  wrote:
>Michael:
>> > Ubuntu Postfix package sets myorigin to /etc/mailname, which seems
>to
>work
>
>Weitse:
>> The documented behavior is supported, as in, bugs fixed and backwards
>> compatibility provided as Postfix evolves. Undocumented behavior is
>> unsupported.
>
>Peter:
>> 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

RE: generic main.cf files

[Michael Fox]

Michael:
> > Ubuntu Postfix package sets myorigin to /etc/mailname, which seems to
work

Weitse:
> The documented behavior is supported, as in, bugs fixed and backwards
> compatibility provided as Postfix evolves. Undocumented behavior is
> unsupported.

Peter:
> 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.


 
> 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.

 
> 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

Re: generic main.cf files

[Peter]

On 24/07/16 06:00, Michael Fox wrote:
> 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.

> 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.

> 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

Re: generic main.cf files

[Wietse Venema]

Michael Fox:
> But I ran into a few problems and have a few questions:

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

generic main.cf files

[Michael Fox]

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