[BUG] openSUSE Leap overwrites salt config on first start

[fzipi]

Your setup

Formula commit hash / release tag

1.0.1

Versions reports (master & minion)

015895a1c19:~ # salt -V
Salt Version:
           Salt: 3000.3

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.11.2
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.6.10 (default, Jan 16 2020, 09:12:04) [GCC]
   python-gnupg: Not Installed
         PyYAML: 5.3.1
          PyZMQ: 19.0.1
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.2

System Versions:
           dist: SuSE NAME="openSUSE Leap"
         locale: UTF-8
        machine: x86_64
        release: 5.6.8-300.fc32.x86_64
         system: Linux
        version: SuSE NAME="openSUSE Leap"

Pillar / config used

test/salt/pillar/default.sls

---

Bug details

Describe the bug

Suse resets salt configuration if file /var/adm/postfix.configured in not present.

Before starting the service, systemd startup script will:

ExecStartPre=/etc/postfix/system/config_postfix
ExecStartPre=/etc/postfix/system/update_chroot
ExecStartPre=/etc/postfix/system/update_postmaps

And /etc/postfix/system/config_postfix will execute all defaults for OpenSuse, effectively rewriting salt written config.

Steps to reproduce the bug

Problem started when including OpenSuse as test platform.

Expected behaviour

Config properly written, and tests verify configuration.

Attempts to fix the bug

Additional context

This is happening while adding inspec tests in PR #108 .

[myii]

@fzipi Do you know what the contents of /var/adm/postfix.configured need to be to prevent this from happening?

[fzipi]

@myii The file just need to exist (it is a lock).

It is called by /etc/postfix/system/config_postfix:

#!/bin/bash

if [ ! -e /var/adm/postfix.configured ]; then
    echo "First configuration of postfix"
        /usr/sbin/config.postfix
        touch /var/adm/postfix.configured
fi

So we just need to have that file managed.

Another file that may have impact is /etc/sysconfig/mail:

## Path:        Network/Mail/General
## Description: Basic general MTA configuration
## Type:        yesno
## Default:     yes
## Config:      postfix,sendmail
#
# If you don't want to let SuSEconfig generate your
# configuration file, set this to no
#
MAIL_CREATE_CONFIG="yes"

Maybe we want to disable that one also...

[myii]

@myii The file just need to exist (it is a lock). ... So we just need to have that file managed.

---

Another file that may have impact is /etc/sysconfig/mail:

...
# If you don't want to let SuSEconfig generate your
# configuration file, set this to no
...

Maybe we want to disable that one also...

@fzipi Ah, OK. Hopefully this is straightforward, then.

[myii]

Fixed by #112, thanks @fzipi.