christiansaga.de

After the upgrade of Wheezy to Jessie, Spamassassin is not added to the startup services. Hence if you were using it before in your mail setup, you will run into the following error in /var/log/syslog

spamc: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
spamc: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused

Debian has a similar bug filed (#764438), even after a fresh reinstall.

So what is the solution

Simply activate Spamassassin via systemctl enable spamassassin

If you have a firewall, you probably have 99% of the entires in your syslog filled with iptables denied info. So there are two options to get rid of that. Turn of the logging of iptables or move it out of the syslog.

As I want to have the logging, I need to move it. You will find a lot of explanations on RSyslog in the official documentation, however I found that the simple case I was looking for was not described.

I am using the following to create the syslog entries:

iptables -I INPUT 5 -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

So what is the solution

You might have more logging or similar ones in your configuration. The important part here is the --log-prefix as we will sort via this.

To create a filter, create /etc/rsyslog.d/iptables.conf and add the following

# Proper file permissions
$FileCreateMode 0600
# Ruleset for sorting
if $msg contains 'iptables denied: ' then {
    # new destination
    /var/log/iptables.log
    # stop processing message, otherwise it will carbon to syslog
    stop
}

After restarting rsyslogd, this will now divert the iptables entries to the new logging location identified by the prefix.

The stop is particularly important, as the rule above diverts the logging, but without the stop it would still end up in syslog. If you google setups like this you will often find a ~ instead of the stop. Which is deprecated and cause a warning in the log, however works as well.

Sidenote: Remember to put the stop in brackets for the if/then clause, otherwise you stop all logging to syslog.

As a last step you should create a logrotation for the new log. I did it very simple by creating the file /etc/logrotate.d/iptables and added

/var/log/iptables.log {
  rotate 5
  monthly
  compress
  missingok
  notifempty
}

Logrotate is started via cron and will read the new config in the next run. Alternatively you can run the config directly via logrotate -f /etc/logrotate.d/iptables

I am using duplicity with duply to do PGP encrypted backups to Amazon S3. As there are enough guides around for the basic setup (i used Backup unter Linux mit duply), I won’t go into details of that.

However if you are planning to use the new EU (Frankfurt) location called eu-central-1 you will run into problems as this location only supports the V4 authentication. You might encounter the following error when using duply (even if the config worked on other locations before)

The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256

So what is the solution

This is a bit tricky, as the Debian packages are not up to date and you need to mix backports and unstable versions. To solve this you will need to upgrade your duplicity and boto framework packages as following:

• duplicity needs version 0.7.02-1 This version is available within the backport branch of Debian. I used package pinning to get this package. You can easily find articles for this via Google, I found APT Pinning helpful. Be careful to understand pinning, as you might confuse APT with a wrong configuration. You should always use sudo apt-cache policy [packagename] and the -s parameter on upgrades first to check what will happen. Currently I am using duplicity 0.7.06-1~bpo8+1.

• python-boto needs version 2.36.0 Previously this was only available via PyPi, however a newer version is now available in the unstable branch. Hence again you can install this via pinning. Currently I am using python-boto 2.40.0-1

• duply did not need additional changes, I am using version 1.9.1-1 out of the regular stable branch.

SQLGrey itself will not be updated during the upgrade towards Jessie, however the change to Systemd will result in a stub automatically created by Systemd around the original init. The problem I encountered was, that SQLGrey would start before my database (MySQL). Hence you receive something like the following in /var/log/syslog

sqlgrey: dbaccess: can't connect to DB: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock’

The problem here is, that the generated stub is not obeying the init scripts dependencies and not having any Systemd ones, hence the services are starting in a “wild” order.

So what is the solution

We need to create at least the SQLGrey unit file and add the dependency into it. Create /etc/systemd/system/sqlgrey.service and add:

[Unit]
Description=SQLgrey Postfix Grey-listing Policy service
After=syslog.target network.target mysql.service
[Service]
Type=forking
PIDFile=/var/run/sqlgrey.pid
ExecStart=/usr/sbin/sqlgrey -d
[Install]
WantedBy=multi-user.target

Note the mysql.service in the After line. This is the needed dependency.

As you might have noticed, there is no mysql.service unit file existing, as the package maintainers have deprioritized to create one (there are two bugs #765425 and #742900.

However you can reference the stubs as well. If you need to adapt this for other services: To find the name of the stub you can use systemd-analyze blame. It gives you a list of the services started. Details you can get with systemctl, e.g. systemctl status mysql.service. The details will tell you in the Loaded line if it is a real unit file or just a init script stub.

The automatic upgrade is pretty straight forward and you probably need only to check the configs for changes and merge them. For me dovecot came up after the restart and was doing its work. However I received the following errors in /var/log/mail.err

dovecot: master: Error: systemd listens on port 143, but it's not configured in Dovecot. Closing.
dovecot: master: Error: systemd listens on port 993, but it's not configured in Dovecot. Closing.
dovecot: master: Error: systemd listens on port 993, but it's not configured in Dovecot. Closing.

Looking for this in the net, I could only find a maintainer discussion about socket vs. service configuration and what happens if both is set? What config should have precedence (the config actually).

That pointed me to the socket configuration within Systemd. Indeed within the update the socket unit file was activated (in /etc/systemd/system/sockets.target.wants).

So what is the solution

To get rid of the error, just deactivate the dovecot.socket via systemctl disable dovecot.socket.