Description

Main motivation for this was avoiding the sleep approach in the wrapper script if we don't actually need to rely on it.

I've additionally removed the /var/log/auth.log references in the project (excluding a test case in tests.bats that's probably not that useful and will be removed later), and added two optional packages for Fail2Ban.

Commit messages do provide context, but more verbose details have been provided below.

Changes

Supervisord starts fail2ban-server directly now

Fail2Ban docs for the CLI (only lists for v0.8) or Github master branch. This removes the need to manually manage removal of the socket at startup (-x) and run in foreground (-f), letting us drop some scripts.

I have compared to the fail2ban-client start command that runs the fail2ban-server process with slightly different options (such as --async), but according to the docs that is for internal usage only and not advised to run the server with directly, so I've avoided matching those additional args.

/var/log/auth.log

• April 2016: In the start-up scripts for Fail2Ban (direct commit to master, no associated PR, does reference v2 discussion, but there is no mention about the change there).
• Dec 2016: Added into the Dockerfile to avoid logging an error (references an issue regarding CRON + PAM unix error log for the root user) "Unable to open env file: /etc/default/locale".
• On Fail2Ban Github, I did notice a Dec 2022 discussion mentioning the file being monitored. Presently I've only seen the file created and populated with content from SASLAUTHD (PAM) initializing. I'm not too familiar with what else would write to this auth.log file or when in DMS, but assume they would create the file if it doesn't exist?
• I am aware that it's typically associated to rsyslogd / syslog to manage it, and I've most commonly seen it referenced for SSHD. But also that the rsyslog package has some differences on Debian from the Ubuntu one that we had installed (at least with default user/group, possibly configs?).

Added Fail2Ban optional dependencies

pyinotify and dnspython are listed on the F2B Github README, both are minimal overhead to image weight.

While we presently have the gamin package installed, and Fail2Ban offers it as one of the notification methods, it can only do so with a Python 2 package no longer available on Debian as Python 2 is EOL now. Besides Fail2Ban devs have noted it's performance was very bad.

I'm not entirely sure about the pyinotify package. It may be more beneficial than constant polling of log files, but the project has not been maintained since June 2015. I have looked at the python3-pyinotify debian package where the Gitlab source appears to maintain a fork of the upstream project.

The dnspython package may also be of some value? (It is actively maintained) I do recall there was a PR a while back to disable DNS lookups due to NFTables/IPTables (possibly with F2B?) not resolving DNS requests properly? Having this package may have resolved that 🤷‍♂️

If neither seem worthwhile, let me know and I can drop them. I only looked into this when viewing Fail2Ban logs warning about failure to initialize gamin and pyinotify backends, so it falls back to polling strategy. The default config is backend=auto AFAIK, hence no change beyond installing python3-pyinotify is required. I have noticed the logs for that backend is not as nice as the polling ones. We could drop it since there has been no complaints with the polling backend currently used?

Background history for the wrapper script

A PR from July 2017 introduced supervisord to manage processes. It added wrapper scripts for Postfix and Fail2Ban citing that they could not be run in foreground mode, and these wrapper scripts were necessary to support these services due to their usage of multiple processes.

That doesn't seem to align to the current state of the image though? It'd seem we'd want more wrapper scripts then:

/usr/bin/dumb-init -- supervisord -c /etc/supervisor/supervisord.conf
/usr/bin/python3 /usr/bin/supervisord -c /etc/supervisor/supervisord.conf
 \_ /bin/bash /usr/local/bin/start-mailserver.sh
 |   \_ tail -Fn 0 /var/log/mail/mail.log
 \_ /usr/sbin/cron -f
 \_ /usr/sbin/rsyslogd -n
 \_ /usr/sbin/dovecot -F -c /etc/dovecot/dovecot.conf
 |   \_ dovecot/anvil
 |   \_ dovecot/log
 |   \_ dovecot/config
 \_ /usr/sbin/opendkim -f
 |   \_ /usr/sbin/opendkim -f
 \_ /usr/sbin/opendmarc -f -p inet:8893@localhost -P /var/run/opendmarc/opendmarc.pid
 \_ postgrey --inet=127.0.0.1:10023 --syslog-facility=mail --delay=300 --max-age=35 --auto-whitelist-clients=5 --greylist-text=Delayed by Postgrey
 \_ /usr/sbin/saslauthd -d -a pam -O
 |   \_ /usr/sbin/saslauthd -d -a pam -O
 |   \_ /usr/sbin/saslauthd -d -a pam -O
 |   \_ /usr/sbin/saslauthd -d -a pam -O
 |   \_ /usr/sbin/saslauthd -d -a pam -O
 \_ /usr/bin/python3 /usr/bin/fail2ban-server -xf start
 \_ /usr/bin/fetchmail -f /etc/fetchmailrc.d/fetchmail-1.rc -v --nodetach --daemon 300 -i /var/lib/fetchmail/.fetchmail-UIDL-cache --pidfile /var/run/fetchmail/fetchmail-1.pid
 \_ /usr/bin/fetchmail -f /etc/fetchmailrc.d/fetchmail-2.rc -v --nodetach --daemon 300 -i /var/lib/fetchmail/.fetchmail-UIDL-cache --pidfile /var/run/fetchmail/fetchmail-2.pid
 \_ /usr/sbin/clamd -c /etc/clamav/clamd.conf
 \_ /bin/bash /usr/local/bin/check-for-changes.sh
 |   \_ sleep 2
 \_ /usr/sbin/amavisd-new (master)
 |   \_ /usr/sbin/amavisd-new (virgin child)
 |   \_ /usr/sbin/amavisd-new (virgin child)
 \_ /bin/bash /usr/local/bin/postfix-wrapper.sh
     \_ sleep 5
/usr/sbin/postsrsd -f 10001 -r 10002 -d example.test -s /etc/postsrsd.secret -a = -n 4 -N 4 -u postsrsd -p /var/run/postsrsd.pid -c /var/lib/postsrsd -l 127.0.0.1 -D -X
/usr/lib/postfix/sbin/master
 \_ pickup -l -t fifo -u -c -o content_filter= -o receive_override_options=no_header_body_checks
 \_ qmgr -l -t unix -u

I don't think the wrapper script is providing any actual value? If it is, could we get a proper test for that, and confirmation that none of the other processes above are at risk? (the list is output from this PRs changes applied)

The referenced PR did originally run fail2ban in foreground mode, but in a later commit of that PR changed it to the wrapper script approach instead, with the context of:

You cannot start fail2ban in some foreground mode, and it's more or less important that docker doesn't kill fail2ban and its children if you stop the container.

Clearly you could start it in foreground mode? We also had a stop grace period added many years later after that PR. So I'm not sure that concern is valid anymore. It seems safe to remove the wrapper script?

UPDATE: I've since realized that PR was originally based off this PR (which the merged PR referenced as an "issue" it resolved, rather than the actual issue / FR) which had the fail2ban-server -f usage without the wrapper script. The associated issue from Dec 2016 references a serverfault thread which is where the wrapper script appears to have been adapted from in the July 2017 PR that was merged.

Type of change

• Improvement (non-breaking change that does improve existing functionality)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• New and existing unit tests pass locally with my changes