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.
Yet another post that doesn’t need a reply (Yes, I enjoy talking to myself). The good news is that it looks like amanda is now available from a standard repository as a binary rpm. The bad news is that any modifications to the systemd socket and service definition files get overwritten by the rpm (no rpmnew rpmold files after updating to the “production” rpm). I found this out after installing the update rpm and getting the same StartLimit error as in my previous post. Cheers!
You can actually avoid this by creating overrides in /etc/systemd/system for your services. Files placed in /usr are typically not configuration files and will be overwritten on updates.
I’m used to text files like these being “respected” like config files under /etc. Also, didn’t want to change the system wide defaults; just allow the amanda processes to spawn all of their normal sub-tasks. I’ll keep this in mind going forward. As I mentioned earlier, I’m an rc.d curmudgeon. First foray into mucking about with systemd and how to get it to do something other than the installation defaults.
man systemctl writes:
edit UNIT…
Edit a drop-in snippet or a whole replacement file if –full is specified, to extend or override the specified unit.
That is one way to “conveniently” get the snippet into the “appropriate” place (under /etc/systemd/).
The man systemd.unit does show the Unit Search Path – /etc overrides /run, and /run overrides /usr/lib.