Open myfirstnameispaul opened 3 years ago
I don't think milter communications listening on lo will be a performance bottleneck.
root@m:~# iperf3 -s -B 127.0.0.1 -4 > /dev/null &
[1] 8894
root@m:~# iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[ 4] local 127.0.0.1 port 41210 connected to 127.0.0.1 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.70 GBytes 14.6 Gbits/sec 0 8.12 MBytes
[ 4] 1.00-2.00 sec 1.61 GBytes 13.8 Gbits/sec 0 8.12 MBytes
[ 4] 2.00-3.00 sec 1.62 GBytes 13.9 Gbits/sec 0 8.12 MBytes
[ 4] 3.00-4.00 sec 1.52 GBytes 13.1 Gbits/sec 0 8.12 MBytes
[ 4] 4.00-5.00 sec 1.48 GBytes 12.7 Gbits/sec 0 8.12 MBytes
[ 4] 5.00-6.00 sec 1.54 GBytes 13.2 Gbits/sec 0 8.12 MBytes
[ 4] 6.00-7.00 sec 1.45 GBytes 12.5 Gbits/sec 0 8.12 MBytes
[ 4] 7.00-8.00 sec 1.29 GBytes 11.1 Gbits/sec 0 8.12 MBytes
[ 4] 8.00-9.00 sec 1.53 GBytes 13.2 Gbits/sec 0 8.12 MBytes
[ 4] 9.00-10.00 sec 1.59 GBytes 13.6 Gbits/sec 0 8.12 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 15.3 GBytes 13.2 Gbits/sec 0 sender
[ 4] 0.00-10.00 sec 15.3 GBytes 13.2 Gbits/sec receiver
iperf Done.
root@m:~# fg
iperf3 -s -B 127.0.0.1 -4 > /dev/null
^C
Unix sockets would be nicer for at least the reason that they are named, so we don't have to guess what port is for what. So, yes, I'd accept a PR that makes that change (except for spampd if it doesn't work).
Okay, I'm finally on this starting with opendmarc
and it functions with the only issue being that Status Checks of course reports "OpenDMARC is not running (port 8893)."
I have opendmarc.sock
owned by opendmarc:opendmarc
in /var/spool/postfix/opendmarc/
(within the postfix
chroot
) and also owned by opendmarc:opendmarc
.
The changes made were:
opendmarc.conf
, comment out the inet
configuration and replace with Socket unix:/var/spool/postfix/opendmarc/opendmarc.sock
mkdir /var/spool/postfix/opendmarc/
, chown opendmarc:opendmarc
, and chmod 750
.adduser postfix opendmarc
.main.cf
, comment out smtpd_milters
configuration and replace with smtpd_milters=inet:127.0.0.1:8891 unix:opendmarc/opendmarc.sock
.The only thing I'm left with is how to make status_checks.py
evaluate a daemon running through a socket.
Any tips would be much appreciated, and I should be able to use such on postgrey
and later dkimpy
and spampd
when working on 22.04 (installed version of spampd
doesn't support sockets).
The only thing I'm left with is how to make status_checks.py evaluate a daemon running through a socket.
It would be fine to skip that for now, since we don't have it for the other services like that, as you mentioned.
using socket.AF_UNIX (as first arg to socket.socket() call in status_checks.py::check_service::try_connect) and the path to the socket (in socket.connect()) might work
It seems the various packages used with
postfix
(opendkim
,opendmarc
, andpostgrey
) are using TCP sockets, which is usually the default for most packages. As best I can tell, this server doesn't have any other reasons to run these as TCP sockets, but I may be missing something.If I put together a PR to change to Unix Domain Sockets, is there any interest? This is how I configured back tha' day when "cheap" VPS came with 512MB RAM and HDDs. I realize squeezing every last drop out of servers these days is not as necessary as it was back then, but I know how to do it, so I thought I would go ahead and do it, if there is at least some interest.
From a StackOverflow question I discovered ipc-bench, a tool for comparing TCP and domain sockets locally to compare performance difference. Unfortunately, the tool is poorly documented and I barely figured out the basic commands for using it, but simple tests suggested >200% increase in performance for both latency and throughput.
Without actually going through and configuring, I've discovered one obvious problem which is that
spampd
is using TCP sockets and cannot be reconfigured for domain sockets without upgrading to 2.53, the latest version ofspampd
.A previous issue with
spampd
was fixed with a workaround, though the maintainer did create a Launchapd bug report to update the Ubuntu repository to the latest version (which is already in 20.04 and Debian repositories), the bug report has sat motionless for over two years now.Unless something changes (lots of 'this bug affects me' added to the bug report?), it appears that Ubuntu won't be adding the latest build of the
spampd
package to 18.04. Other options include building from source at install (sounds like a PITA) or creating a PPA. I've successfully built backported PPAs for myself in the past, but like the other changes suggested here I don't want to spend the time if there isn't at least some interest in using the PPA.