The Amanda Backup suite is a mature (some say “legacy” ..) backup solution that is very flexible and reliable. Its client-server architecture allows the admin to set up large distributed configuration and distribute CPU-intensive tasks like compression and encryption between server and clients.
The communication between server and clients is an important part here. Over time Amanda has added 8 methods of communication between the Amanda server and the clients.
See this manpage for details: link
The default auth-method (since amanda-2.51) is called “bsdtcp”:
The client listens on a TCP socket and starts the amandad-binary for tasks like amdump etc.
The amanda documentation describes how to configure client and server with inetd or xinetd, for bsdtcp-authentication: link
Most linux distributions provide the relevant config-files.
The more modern and current auth-method is “ssh”: if you use this, you don’t have to read further, with ssh everything is run via the sshd.service.
But sometimes (performance?) it might be still useful to run with bstcp-auth.
In 2010 systemd was originally released. It was designed as a modern successor to init daemons like “SysV”, and radically changed the way to run linux services.
Among its countless features there is the so called “socket activation”:
like inetd or xinetd, systemd is able to listen on defined sockets and spawn respective services when connections come in.
This feature allows us to get rid of inetd/xinetd, if we don’t need them for other services. These other services might also be migrated to a systemd-unit, by the way.
For reference: the manpage of systemd.socket
For security reasons Amanda requires additional config-files and parameters, they are needed either with (x)inetd or systemd.
amanda-security.conf lists the executables amanda can execute as root, and ranges of privileged networks ports, both for tcp and udp:
# /etc/amanda-security.conf runtar:gnutar_path=/usr/bin/tar tcp_port_range=512,1024 udp_port_range=840,860
The “amandahosts” file lists the services that amanda is allowed to run on each configured client/server.
# Example of the .amandahosts file on an Amanda client amandaserver.example.com amandabackup amdump # Example of the .amandahosts file on an Amanda server amandaclient1.example.com root amindexd amidxtaped
inetd.conf in Debian
In Debian Buster 10.10 (the current stable release when I wrote this article) the amanda-socket is still provided via inetd. The amanda-package comes with this line in inetd.conf:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped
inetd itself is run as a systemd-service:
# systemctl status inetd.service ● inetd.service - Internet superserver Loaded: loaded (/lib/systemd/system/inetd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2021-06-22 21:29:14 CEST; 1 months 0 days ago Docs: man:inetd(8) Main PID: 599 (inetd) Tasks: 1 (limit: 4915) Memory: 6.5G CGroup: /system.slice/inetd.service └─599 /usr/sbin/inetd
To provide the same functionality with systemd, we need two files.
At first a service-file to define what to do when a connection comes in. In this case this means starting the amandad-binary in a specific user-context, with specific parameters:
# amanda@.service [Unit] Description=Amanda Backup System After=local-fs.target [Service] User=backup Group=backup ExecStart=/usr/lib/amanda/amandad -auth=bsdtcp amdump amindexd amidxtaped StandardInput=socket
And because we have to tell systemd that it should create a TCP-socket and listen on this, we need a socket-file as well:
# amanda.socket [Unit] Description=Amanda Activation Socket [Socket] ListenStream=10080 Accept=true [Install] WantedBy=sockets.target
These two files should go into
/etc/systemd/system, after storing them tell systemd to reload via “systemctl daemon-reload”.
The option “ListenStream” tells systemd to listen on “0.0.0.0” which means “listen on all configured IP-adresses”. In my tests I noticed things breaking when the host contains multiple network interface cards (= NICs).
You can specify the one IP you want to use with amanda like in:
As far as I know this is at least partially an issue within Amanda, not in systemd.
enable socket, disable inetd
We can now disable inetd and enable and start the new amanda.socket:
# systemctl stop inetd # systemctl disable inetd # systemctl start amanda.socket # systemctl enable amanda.socket
If you use inetd for other things, you have to comment or remove the amanda-related line from inetd.conf, and restart inetd. Otherwise the new socket and inetd conflict at trying to listen on the same port.
If you don’t use inetd anymore, you may even remove it from your system now.