postfix service on specific port fails

[go8ose]

Describe the bug

I get a SaltRenderError when I try to use this forumla to make postfix listen on localhost:10025.

Setup

I'm using a github fork of this repository. It's on version 077a6a6494e546f8bb34a60752112f861c1a5040.

Steps to reproduce the bug

I have a pillar that reads (in part, snipped for brevity):

 16 postfix:
 17   manage_master_config: True
 18   master_config:
 19     enable_dovecot: True
 20     enable_submission: True
 21     services:
 22         # Make postfix listen on a port for emails to return from amavisd.
 23         localhost:10025:
 24           command: smtpd
 25           type: inet
 26           private: n
 27           args:
 28              - 'content_filter='
 29              - 'smtpd_delay_reject=no'

(Edit 2019-10-06, fixed example pillar to show "localhost:10025" instead of "localhost_10025", as the former actually causes the SaltRenderError, the later is what I had committed to my pillar to avoid the exception being thrown)

When I run salt, I see an error.

$ sudo salt 'mcconnell*' --state-output=changes state.apply postfix.config  saltenv=
dev pillarenv=dev test=True
mcconnell.lan:
  Name: postfix - Function: pkg.installed - Result: Clean Started: - 22:26:29.418995 Duration: 52.299 
ms
  Name: /etc/postfix/main.cf - Function: file.managed - Result: Clean Started: - 22:26:29.476628 Durat
ion: 95.722 ms
----------
          ID: /etc/postfix/master.cf
    Function: file.managed
      Result: False
     Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1933, in call
                  **cdata['kwargs'])
                File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1951, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/states/file.py", line 2769, in managed
                  **kwargs
                File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 4824, in check_mana
ged_changes
                  **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 4265, in get_manage
d
                  **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 169, in render_t
mpl
                  output = render_str(tmplstr, context, tmplpath)
                File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 406, in render_j
inja_tmpl
                  buf=tmplstr)
              SaltRenderError: Jinja variable 'unicode object' has no attribute 'get': "<Template memory:7f00b17cded0>", "0"
     Started: 22:26:29.572605
    Duration: 133.425 ms
     Changes:   
----------
…

Expected behaviour

I would expect salt to write out a /etc/postfix/master.cf file that includes an entry for "localhost:10025", which has the arguments listed above (such as content_filter, smtpd_delay_reject, etc). I would expect salt to restart postfix, and then postfix to be listening on port 10025.

Versions report

$ salt --versions-report
Salt Version:
           Salt: 2019.2.1

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: 2.1.1
          ioflo: Not Installed
         Jinja2: 2.9.4
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Sep 26 2018, 18:42:22)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.1
        timelib: Not Installed
        Tornado: 4.4.3
            ZMQ: 4.2.1

System Versions:
           dist: debian 9.11
         locale: UTF-8
        machine: x86_64
        release: 4.9.0-9-amd64
         system: Linux
        version: debian 9.11

Additional context

I've done some investigation. I suspect in postfix/files/master.cf, in the "Handle custom services" section at the end, the "pillar.get" on 'postfix:master_config:services:%s' is causing a lookup of 'postfix:master_config:services:localhost:10025', which is not a key that exists in my pillar.

I don't know how to define a pillar that will result in the formula writing out a postfix service entry for "localhost:10025", and will also satisfy that pillar.get lookup.

[aboe76]

@ixs can you comment on this?

[ixs]

@aboe76 thanks for the headsup. This looks familiar...

I might actually have that already fixed locally. Let me have a look.

[ixs]

@go8ose Have a look at https://github.com/bawuenet/postfix-formula/commit/9454406f8e60df48af33416cbd70b62c87bc8e5c and see if that would work for you.

It's a quite extensive rework of the services config but finally allows to configure really everything. :-)

[aboe76]

@ixs do I see a PR in the future? :)

[go8ose]

@go8ose Have a look at bawuenet@9454406 and see if that would work for you.

It's a quite extensive rework of the services config but finally allows to configure really everything. :-)

Thanks @ixs, I've tried out this branch. My testing shows it works, in that a salt test run doesn't error out, and does look like it would apply the diff to master.cf that I expect. I haven't actually put this into use on a test server to confirm that postfix starts up.

Furthemore, the diff I needed to apply to my pillar was pretty minor:

diff -r a6172aa4951b pillarroot/cromp/mailhost.sls
--- a/pillarroot/cromp/mailhost.sls     Sat Oct 05 10:33:07 2019 +1000
+++ b/pillarroot/cromp/mailhost.sls     Sat Oct 05 11:13:56 2019 +1000
@@ -20,9 +20,11 @@
     enable_submission: True
     services:
         # Make postfix listen on a port for emails to return from amavisd.
-        localhost_10025:
+        localhost:10025:
+          enable: True
           command: smtpd
           type: inet
+          servicetype: internal
           private: n
           args:
              - 'content_filter='

(Note I previously had "localhost_10025" to work around the salt exceptions being thrown, and yes, that was causing a broken master.cf file to be created).

So if this change makes it's way into a PR, that would definitely close this issue.

[ixs]

Thanks for the feedback. I'll see what needs to be cleaned up before we can merge that in...