Duplicity backup to Amazon S3 on Debian

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 as following:

Package 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 this one 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.

Package 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

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

Advertisements

Upgrading SQLGrey Debian Wheezy to Jessie

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 the following errors in /var/log/syslog

sqlgrey: dbaccess: can’t connect to DB: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/$
sqlgrey: dbaccess: error: couldn’t get now() from DB: Can’t connect to local MySQL server through socket ‘/v$
sqlgrey: dbaccess: can’t connect to DB: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/$
sqlgrey: dbaccess: error: couldn’t access config table: Can’t connect to local MySQL server through socket ‘$

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.

Upgrading Dovecot Debian Wheezy to Jessie

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