On Tue, Jul 11, 2017 at 12:49:16AM +0200, Heiko Schlittermann wrote: > > > Jose M Calhariz <[email protected]> (Mo 10 Jul 2017 > > > 19:51:31 CEST): > > > … > > > > I happily ship a systemd unit for amanda if someone writes one for the > > > > Debian package. > > > > > > Here are the unit files, I created just now. > > > The User= setting needs to be adapted probably. > > > > Fedora and CentOS (thus probably RHEL also) have some slight > > variations. Plus I added a couple of additions. May not be > > appropriate for Debian, I don't know. > > Thank you. Some notes though… > > > > > > > ,---------------------------------[the socket unit]----------- > > > | # amanda.socket > > > | [Unit] > > > | Description=Amanda Server socket > > > > It is refered to as "Amanda Activation socket". I suspect > > because it is used by both server and client. > > Yes, the description can follow some formalities, "Amanda Activation > socket" reads good. Maybe even better: "Amanda Agent Activation socket", > to avoid confusion with the "Amanda Server", the server, that controls > the backup machinery. > > > > > | Wants=network.target > > > | > > > | [Socket] > > > | Accept=true > > > | # need an IPv4 address, as current (3.3.9) amandad can't deal with ipv6 > > > here > > > | ListenStream=0.0.0.0:10080 > > > | > > > | [Install] > > > | WantedBy=sockets.target > > > `---------------------------------------------------------------- > > > > > > ,--------------------------[the service template unit]----------- > > > | # [email protected] > > > | [Unit] > > > | Description=Amanda Server service > > > > Again, an alternative description "Amanda Backup Service" > > Yes, but see above. "Amanda Backup Agent service" > > > > Added "After=local-fs.target". Debian may not even have > > the "local-fs.target", or they may have something similar. > > Do the "After=" dependencies matter for socket activated services?
I don't know. Why do you think they may not matter? I'm guessing the reason for the added "After=local-fs.target" is to avoid starting amanda on the client before the backup source is mounted or on the server before the holding disk and/or the vtapes are mounted. > > > > | > > > | [Service] > > > | User=backup <------------- change it to your needs > > > > "Group=disk" is added > > Tried this, but this seems to override the groups, "backup" belongs to, > leading to "permission denied" problems when executing the amcheck > triggered tests. > I haven't checked a running dump process. On my systems Amanda's primary group is "Disk", though an Amanda login process has several secondary groups. amcheck and other amanda programs run fine here. I wonder why we see different effects. > > > > > | StandardInput=socket > > > | StandardError=journal Does this prevent writing to amanda's normal log/debug files? > > > | ExecStart=/usr/lib/amanda/amandad -auth=bsdtcp amdump amindexd > > > amidxtaped > > > > Added valid commands "amdumpd" and "ambackupd" to allow server to > > respond to recently added client requests. One such requests is > > "ambackup" which allows the client to requests it own immediate > > backup to the holding disk for later autoflush during a regular > > amdump run. I use it for my sometimes on/sometimes off laptop. BTW while the "Added" comment earlier meant added by fedora/centos, here I mean "Added" by me, not the package developers. > > Maybe this could be done via an env file /etc/default/amanda having > SERVICES="amdump amindexd amindxtaped…" > > > and then extending the .service unit: > > EnvironmentFile=-/etc/default/amanda > ExecStart=/usr/lib/amanda/amandad -auth=bsdtcp $SERVICES I was not aware of this capability. I think I'd pick a more specific variable name, like AMANDAD_SERVICES. Jon -- Jon H. LaBadie [email protected] 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
