Postfix upgrade to 2.9.3-2~12.04.1 changes configuration files

I can't replicate this with postfix and apt, so I suspect the puppet involvement being where the issue is.

BTW, while I agree that configurations shouldn't be mucked with, there's no security issue here as postfix is not an open relay by default. It takes some work to get it to behave that way.

Thanks for having a look, Scott. I'm unsubscribing ubuntu-security and marking this as a regular, non-security bug.

It should be easy to reproduce this. Simply installing postfix on a fresh server installation in the background (so without any use interaction) and then chenging the configuration file should do it. Puppet does nothing special with the package. Also, it uses aptitude to install it, if that makes any difference. I can try again on monday when I'm back at work if you have trouble with this.

Oops missed a previous comment. I don't think this is a problem with puppet though. Puppet ensures the state of that file, it won't change values unless the manifest was changed by the user.

I've never seen anything like this with postfix before. If someone can give me a way to reproduce it when puppet is not involved, then I could trouble shoot that, but I don't think this is a postfix issue.

If this is any help, here is the installation log (/var/log/apt/history.log) from the package upgrade that changed the config file:

Start-Date: 2012-07-20 06:39:28
Commandline: apt-get -qq -y upgrade
Upgrade: postfix:amd64 (2.9.1-5, 2.9.3-2~12.04.1)
End-Date: 2012-07-20 06:39:31

This is not an issue with puppet, as puppet was not involved in the package upgrade at all. The upgrade was done by a nightly cron job that uses only apt-get.

Setting back to New. Somebody needs to try the suggested test case of installing postfix, changing the config file, and then upgrading, to see if the file is changed. Of course, the config file belongs to postfix, so if "force-confnew" is in use, that would make sense too, so it would be good to get the full apt configuration as well.

I installed postfix, set inet_interfaces to loopback_only, restarted postfix, then reinstalled with dpkg -i /var/cache/apt/archives/postf*. The inet_interfaces line did not get re-written.

Marking Incomplete, since others have tried failed to reproduce, and it seems likely that this is a local configuration issue rather than a bug in Postfix.

If you can provide exact steps to reproduce without using puppet, then please do so and re-open.

Even though I have the suspicion it is caused by not doing debconf (as puppet does not ask questions, but just installs with default values), I too can't reproduce it on a test-VM with the exact same debconf values as one of our servers.
I have no idea what puppet does to cause this behavior and I'm also sure the problem is there, as I've seen it happen again later, but I know that something that can't be reproduced can't be fixed.
You can close this ticket if you want. If I find a way to reproduce it in the future, I will reopen it.

Re debconf, thats not really a factor. Not answering the questions just uses defaults, but debconf and the maintainer scripts that use it do not change their behavior. Indeed, I think this issue doesn't seem to have much helpful information. I'm going to close it as Invalid.

Today I had to install postfix again, but manually (entering apt-get install on commandline) and saw in the console output the following lines:
setting inet_interfaces: loopback-only

This reminded me of this issue and gave me a clue where the problem is. I think the problem is not directly with debconf but with the postinst script in the package. It contains the following lines:

db_get postfix/main_mailer_type && mailer="$RET"
if [ "$mailer" != "No configuration" ]; then
  db_fget postfix/main_mailer_type changed
  if [ "$RET" = "true" ]; then
    echo "setting inet_interfaces: $val"
    set_postconf "inet_interfaces=$val"

I checked on our production server and as expected, postfix/main_mailer_type has no value:
$ debconf-get-selections | grep postfix/main_mailer_type
postfix postfix/main_mailer_type select
$

I think this script should be patched to support empty values and treat them as "dont change any configuration at all", since no value means the user did not even choose any option, so doesn't want the package to configure the mail server.

I think that's not a supported configuration. I'm not sure how you got it installed that way to begin with.

As you can read in the first posting, I simply installed it with puppet. Doesn't seem like such a rare scenario to me. I think any company with a substantial amount of servers should be using some form of configuration management. I think any completely non-interactive installation method will end up in that configuration.

And how can it not be a supported configuration? Puppet only calls aptitude, so the system gets itself in that configuration. Assuming some value, file, etc is present is bad practice in any situation. Is deleting main.cf also "unsupported"?

This has nothing to do with supported or not, but with a script that is not robust enough.

I suspect that the issue here is that the config file was modified (values set) during install, and then the file changed outside of debconf later, and then installed again, resulting in postfix honoring the debconf values it had been told to enforce.

There are several values that postfix expects you will only set using debconf or only not-using debconf. mixing that makes for bad times.

Since the non-debconf piece here appears to be puppet, one would expect puppet to quickly re-enforce the config state and make this a non-issue...

I'm not setting any values in debconf, I'm only installing the package (non-interactive) and doing configuration in puppet also.

You are right that puppet will re-enforce our configuration, however, we are not using the puppet agent, so resetting the value might take up to a few weeks, depending on the amount of changes we perform on our servers around that time.
In this particular case it left postfix open to the internet for about a week, possibly turning our servers into spam proxies. I didn't notice this change until the next run.

Thank you for your further investigations. I appreciate that this could be a bug. But since I still can't see how we might reproduce your issue, I don't think that we yet have clarity on the set of circumstances that might cause your problem. Without this clarity, I don't think that we can evaluate the implications that changing the postinst in the way you suggest might have.

So I think it's reasonable to leave this bug as Invalid for the moment. If you can give us precise and unambiguous steps to reproduce, in terms of exact commands that don't involve puppet, where you think the steps perform reasonable actions that the package and interaction with puppet should support, please can you post this and change the bug status back to New?