Re: Backing up remote server
> "RW" == Robert Wolfe writes: RW> This would be my assumption as well, but I am having issues on RW> finding a working xinetd file for that (running under RHEL 7.x and RW> 8.x). Just keep in mind that RHEL7 and 8 use systemd and don't run any inetd by default. I believe you can still install it and enable it if you like, but the versions of Amanda included with those operating systems use systemd socket activation. Those unit files should still work for you, with the possible caveat that you may have to change the path in the ExecStart line if your amandad doesn't install into /usr/sbin. Those unit files are identical to the ones from Fedora, which you can see here: https://src.fedoraproject.org/rpms/amanda/blob/master/f/amanda.socket https://src.fedoraproject.org/rpms/amanda/blob/master/f/amanda%40.service Of course, it may be prudent to ask why you aren't just using the amanda packages which come with the operating system. All I ever need to do to get it working is install amanda-client, make sure /var/lib/amanda/.amandahosts is correct, and run: systemctl enable amanda systemctl start amanda Then I can add disklist entries on my server and everything works. But if course if you just want to self-compile then that's up to you. - J<
Re: Backing up remote server
Or, more examples below his (since they’re lengthy.
Deb Baddorf
Fermilab
> On Oct 21, 2020, at 12:40 PM, Bernhard Erdmann wrote:
>
> Am 21.10.20 um 18:24 schrieb Robert Wolfe:
>> This would be my assumption as well, but I am having issues on finding a
>> working xinetd file for that (running under RHEL 7.x and 8.x).
>
> From my second CentOS 6.10 amanda server using amanda-3.5.1:
>
> $ head -n20 /etc/xinetd.d/am*
> ==> /etc/xinetd.d/amanda <==
> service amanda
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= amanda
> group = disk
> groups = yes
> server = /opt/amanda/libexec/amanda/amandad
> server_args = -auth=bsdtcp amdump amindexd amidxtaped
> }
>
> ==> /etc/xinetd.d/amandaidx <==
> service amandaidx
> {
> disable = yes
> socket_type = stream
> protocol= tcp
> wait= no
> user= amanda
> group = disk
> groups = yes
> server = /opt/amanda/libexec/amanda/amindexd
> }
>
> ==> /etc/xinetd.d/amidxtape <==
> service amidxtape
> {
> disable = yes
> socket_type = stream
> protocol= tcp
> wait= no
> user= amanda
> group = disk
> groups = yes
> server = /opt/amanda/libexec/amanda/amidxtaped
> }
>
> From a general CentOS 7.8.2003 server using amanda-3.4.5 (getting backup
> only):
>
> $ cat /etc/xinetd.d/amanda
> service amanda
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= amanda
> group = disk
> groups = yes
> server = /opt/amanda/libexec/amanda/amandad
> server_args = -auth=bsdtcp amdump
> }
OR:
==<< auth "bsd" >>
amanda-client.conf config containsauth "bsd" for nodes with this setup:
> /etc/xinetd.d/amanda :
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
disable = no
groups = yes
}
==<< auth "bsdtcp" >>
If node is new enough (amanda 3.xx), put auth "bsdtcp" in the
amanda-client.conf config file
> /etc/xinetd.d/amanda :
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
groups = yes
}
==<< auth "krb5" >>
If node is new enough (amanda 3.xx) AND wants to try Kerberos:
put auth "krb5" in the amanda-client.conf config file
Add a file to /etc/xinetd.d named amanda with these contents:
note that 3 lines have changed. The USER must change to root,
(it will lower itself as needed),
the service name on first line is now "k5amanda",
and "server_args" has changed auth=krb5.
till tested, I'm unsure about the rest of the args on this line.
> /etc/xinetd.d/amanda :
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service k5amanda
{
socket_type = stream
protocol= tcp
wait= no
user= root
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=krb5 amdump amindexd amidxtaped
disable = no
groups = yes
}
for krb5: also edit hosts.allow
addk5amanda to the amanda-services which are on the allow line
=
Re: Backing up remote server
Am 21.10.20 um 18:24 schrieb Robert Wolfe:
> This would be my assumption as well, but I am having issues on finding a
> working xinetd file for that (running under RHEL 7.x and 8.x).
>From my second CentOS 6.10 amanda server using amanda-3.5.1:
$ head -n20 /etc/xinetd.d/am*
==> /etc/xinetd.d/amanda <==
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /opt/amanda/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}
==> /etc/xinetd.d/amandaidx <==
service amandaidx
{
disable = yes
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /opt/amanda/libexec/amanda/amindexd
}
==> /etc/xinetd.d/amidxtape <==
service amidxtape
{
disable = yes
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /opt/amanda/libexec/amanda/amidxtaped
}
>From a general CentOS 7.8.2003 server using amanda-3.4.5 (getting backup
only):
$ cat /etc/xinetd.d/amanda
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= amanda
group = disk
groups = yes
server = /opt/amanda/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump
}
Re: Backing up remote server
This would be my assumption as well, but I am having issues on finding a working xinetd file for that (running under RHEL 7.x and 8.x). On 10/20/2020 6:47 PM, Nathan Stratton Treadway wrote: On Tue, Oct 20, 2020 at 16:36:52 -0500, Robert Wolfe wrote: Amanda Backup Client Hosts Check WARNING: wolfe2.wolfe.local: selfcheck request failed: error sending REQ: write error to: Connection refused Client check: 2 hosts checked in 0.069 seconds. 1 problem found. (brought to you by Amanda 3.3.3) Not sure what I need to do to get this to work. I have the firewall on the remote server is disabled, but not sure what else I need to do. The details depend on the authentication you have specified for that host on the Amanda server and on the distribution/release of Linux running on your Amanda client... but off hand it sounds like you are missing the definition for the amandad service in /etc/inetd.conf or /etc/xinietd.d/* on the client system. Nathan Nathan Stratton Treadway - [email protected] - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: Backing up remote server
Am 21.10.20 um 01:47 schrieb Nathan Stratton Treadway: On Tue, Oct 20, 2020 at 16:36:52 -0500, Robert Wolfe wrote: Amanda Backup Client Hosts Check WARNING: wolfe2.wolfe.local: selfcheck request failed: error sending REQ: write error to: Connection refused Client check: 2 hosts checked in 0.069 seconds. 1 problem found. (brought to you by Amanda 3.3.3) Not sure what I need to do to get this to work. I have the firewall on the remote server is disabled, but not sure what else I need to do. The details depend on the authentication you have specified for that host on the Amanda server and on the distribution/release of Linux running on your Amanda client... but off hand it sounds like you are missing the definition for the amandad service in /etc/inetd.conf or /etc/xinietd.d/* on the client system. "/etc/xinetd.d" ;-) Right. Check here: https://wiki.zmanda.com/index.php/Selfcheck_request_failed and https://wiki.zmanda.com/index.php/How_To:Configure_bsdtcp_authentication - And maybe let us know what OS the machines run on ... Amanda-3.3.3 is *old*, so it's very likely that it's not yet a machine with systemd.
Re: Backing up remote server
On Tue, Oct 20, 2020 at 16:36:52 -0500, Robert Wolfe wrote: > Amanda Backup Client Hosts Check > > WARNING: wolfe2.wolfe.local: selfcheck request failed: error sending > REQ: write error to: Connection refused > Client check: 2 hosts checked in 0.069 seconds. 1 problem found. > > (brought to you by Amanda 3.3.3) > > Not sure what I need to do to get this to work. I have the firewall on > the remote server is disabled, but not sure what else I need to do. The details depend on the authentication you have specified for that host on the Amanda server and on the distribution/release of Linux running on your Amanda client... but off hand it sounds like you are missing the definition for the amandad service in /etc/inetd.conf or /etc/xinietd.d/* on the client system. Nathan Nathan Stratton Treadway - [email protected] - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Backing up remote server
When attempting to back up a remote Linux server, I run the amcheck utility and get the following error: -bash-4.2$ amcheck MyConfig Amanda Tape Server Host Check - Holding disk /amanda/holding: 1073049600 kB disk space available, using 51200 kB as requested Searching for label 'MyData02':found in slot 2: volume 'MyData02' Will write to volume 'MyData02' in slot 2. NOTE: skipping tape-writable test NOTE: host info dir /amanda/state/curinfo/wolfe2.wolfe.local does not exist NOTE: it will be created on the next run. NOTE: index dir /amanda/state/index/wolfe2.wolfe.local does not exist NOTE: it will be created on the next run. Server check took 0.135 seconds Amanda Backup Client Hosts Check WARNING: wolfe2.wolfe.local: selfcheck request failed: error sending REQ: write error to: Connection refused Client check: 2 hosts checked in 0.069 seconds. 1 problem found. (brought to you by Amanda 3.3.3) Not sure what I need to do to get this to work. I have the firewall on the remote server is disabled, but not sure what else I need to do.
