S3 backups ignore AWS credentials in example.dup when using desturl=s3://hostname/bucket
This problem arises when performing backups to Amazon S3.
In particular some Amazon S3 regions (including Frankfurt and London) require authentication using the newer "signature version 4" method.
I managed to get this to work by configuring /etc/backup.d/example.dup with
desturl=s3://{hostname}/{bucket}
and by creating a /root/.boto file containing:
[s3]
use-sigv4 = True
[Credentials]
aws_access_key_id = {{ aws_s3_backup_user.access_key }}
aws_secret_access_key = {{ aws_s3_backup_user.secret_key }}
The use-sigv4 setting ensures that Boto uses "signature version 4" authentication. The s3://{hostname}/{bucket} URL seems to be needed to provide the host name for authentication purposes.
Configuring the awsaccesskeyid and awssecretaccesskey in /etc/backup.d/example.dup doesn't work because /usr/share/backupninja/dup ignores these values unless desturl is of the form s3+http://bucket.
Ignoring awsaccesskeyid and awssecretaccesskey for s3://{hostname}/{bucket} URLs seems like a bug in /usr/share/backupninja/dup. The fix would be to use awsaccesskeyid and awssecretaccesskey for "s3:" URLs. For back compatibility should not require awsaccesskeyid and awssecretaccesskey to be set in this case (but a warning might be helpful).
Ideally /etc/backup.d/example.dup would also be extended to support "signature version 4" authentication. I believe that is possible by setting environment variable S3_USE_SIGV4=True when invoking duplicity.