Topic: Thanks and some suggestions
I've been using iRedMail open source version for a few years, and I've recently migrated from my home Xen box to an EC2 instance. I run on FreeBSD (11.2-RELEASE at the moment). I have a few suggestions for how iRedMail builds a mail server. Let me start by saying the work is awesome. I probably could do this myself, but thanks to you I don't have to!
Some universal suggestions:
SOGo uses memcached. Memcached, by default, listens on a TCP port and speaks TCP. I recommend switching it to use a unix socket instead of TCP. There's a blog post that suggests you get much better performance. It doesn't have to do the whole TCP handshake. Plus, memcached doesn't even open the TCP socket, so you don't have any worry of security issues. This requires a few easy changes:
In sogo.conf change the SOGoMemcachedHost line to this:
SOGoMemcachedHost = "/var/run/memcached/memcached.sock";
Launch memcached with the right command line. In my case I put the following in my /etc/rc.conf file:
memcached_flags="-s /var/run/memcached/memcached.sock -a 0666"
It would be good to make sure that location in the filesystem exists (/var/run/memcached) and has appropriate permissions. In my case memcached runs as user nobody, but sogod runs as user sogo. So I have it set to permissions 0666.
Consider adding pflogsumm? It's in the FreeBSD packages/ports tree. It sends an email (usually weekly) with statistics, and interesting error messages from /var/log/maillog.
On FreeBSD it is as simple as 'pkg install pflogsumm'
For pflogsumm, I have the following script installed as /usr/local/etc/periodic/weekly/600-pflogsumm:
#!/bin/sh (/bin/cat /var/log/maillog ; /usr/bin/bzcat /var/log/maillog.*bz2) | /usr/local/bin/pflogsumm --detail 8 | /usr/bin/mailx -s "PostFix Stats `date +'%Y-%m-%d %H:%M'`" postmaster@EXAMPLE.COM
Some FreeBSD-specific suggestions:
Use pkg more. Currently the iRedMail.sh script builds basically everything from source. There are a lot of things that I think are good to build from source (dovecot, postfix, amavis, etc.) There are a bunch of things that can be installed from binary (gmake, autoconf, libiconv, etc). I think at least 50% of the packages can be installed from binary packages instead of source. It's a bit of effort, but I can definitely provide a good list of the ones I installed using binary packages. At a high level, I install from packages a lot of the python packages (pynetifaces, pybeautifulsoup, pybcrypt, pyJinja2, pylxml), basic web things (nginx, uwsgi, php71), most of the php71 modules (not imap or mysql, but all the others), many low-level graphics packages (png, jpeg, tiff), most of the archiving packages (zip, cabextract, etc)
Use /usr/sbin/sysrc for updating rc.conf or rc.conf.local. It's idempotent. You can run "sysrc foo_enable=YES" over and over and it doesn't change the file. If the value is already present, it does nothing. It also works well with sudo, "sudo sysrc foo_enable=YES" works, whereas "sudo echo foo >> /etc/rc.conf.local" doesn't work (you have to do "echo foo | sudo tee /etc/rc.conf").
Use /usr/local/etc/periodic on FreeBSD. There are directories for hourly, daily, weekly, monthly. The benefit for using this mechanism is that the output of those maintenance scripts will go to the same place that all the periodic scripts go. There are two reasonable design choices:
Create many files that have just one line each. Include the same command lines as the crontab. There might be 5 or 6 different files. One file each for cleanup_db.py, delete_mailboxes.py, etc.
Create a single script that is basically the hourly cron commands and call it iredmail-hourly.sh or similar.
This might be a reasonable choice generally: have scripts for hourly/daily/weekly/monthly and just run those scripts from cron. When you upgrade or make a change, you don't have to update the crontab itself, you just update the script.