Looking at Zmanda’s website, Amanda Server is available on RHEL 8,7 (and thus on RL8?), but not on RHEL9 (and thus not on RL9). Is this just a timing thing and it’s coming? It looks like it’s available on CentOS Stream as amanda-3.5.1-30.el9.src.rpm. Would it be fair to assume that there will eventually be a build for RL9? Or should I be attempting to build the CentOS Stream version on RL9?
If Red Hat decides to add it into 9, then it’ll come to us in the future. Otherwise, a request to EPEL could be sufficient. Perhaps someone may be willing to branch it in.
You should be able to rebuild it in the meantime if you need it. You will need to build the dependencies first though (ncompress and rsh) since we don’t have them published in devel currently. You could probably use mock to do a chain and see if it’ll work. Something like…
mock -r rocky-9-x86_64 ncompress-4.2.4.4-21.el9.src.rpm rsh-0.17-98.el9.src.rpm amanda-3.5.1-30.el9.src.rpm --chain
Thanks so much for this. I’m sure you saved me a LOT of time by listing the dependencies. Your solution worked great.
I’m guessing that amanda will eventually come to RHEL9, given that it’s in CentOS Stream 9… but as I’m leaping from CentOS 6 to RL9, I’m grateful not to have to take the RL8 detour to keep my backups running.
1 Like
Following in your footsteps so to speak. I got amanda to build using mock as described earlier in this thread. Have you been able to get it working with systemd instead of xinetd? Any advice or working examples would be greatly appreciated. Thanks!
The systemd components are included in the RPM:
/usr/lib/systemd/system/amanda-udp.service
/usr/lib/systemd/system/amanda-udp.socket
/usr/lib/systemd/system/amanda.socket
/usr/lib/systemd/system/amanda@.service
/usr/lib/systemd/system/kamanda.socket
/usr/lib/systemd/system/kamanda@.service
To set the amanda server to listen at boot time:
systemctl enable amanda.socket
To set the amanda server to listen now:
systemctl start amanda.socket
(Or amanda-udp.socket if you use UDP rather than TCP)
Does that answer your question?
Sort of. Found them there after my post. You included the one thing in your reply that I hadn’t tried: systemctl enable amanda.socket. I tried enabling amanda@, amanda-udp, etc. Still not getting a response when I do an amservice to a client but closer.
Cheers
systemctl start amanda-udp.socket
if you are using UDP instead of TCP.
amservice rocky9 bsd noop < /dev/null
OPTIONS features=ffffffff9efefbfffffffffffffff3fffbf71f;
Thanks said the rc.d curmudgeon.
This is just a quick follow-up that doesn’t need a response. So, I have amanda working with mhVTL on one of my VMs plus another VM as the amanda client. The oddity I ran into is that 3 file systems on each VM were being successfully backed up and a different file system on each would fail. The same file systems would back up just fine if I ran amdump from the command line. systemctl status gave me:
[root@rocky9 DailySet1]# systemctl status -l amanda-udp.socket
× amanda-udp.socket - Amanda Activation Socket
Loaded: loaded (/usr/lib/systemd/system/amanda-udp.socket; disabled; vendor preset: disabled)
Active: failed (Result: service-start-limit-hit) since Tue 2023-03-21 00:45:09 MDT; 11h ago
Duration: 6h 14min 21.136s
Triggers: ? amanda-udp.service
Listen: [::]:10080 (Datagram)
CPU: 760us
Mar 20 18:30:48 rocky9.local.davenjudy.org systemd[1]: Listening on Amanda Activation Socket.
Mar 21 00:45:09 rocky9.local.davenjudy.org systemd[1]: amanda-udp.socket: Failed with result ‘service-start-limit-hit’.
Not sure why but it appears that systemd doesn’t like the way the amanda daemon kicks off a bunch of processes and no idea why on the specific file systems that fail. I ended up adding:
StartLimitBurst=20
to the amanda-udp.service file in the unit section to override the default of 5.