On Thursday 17 July 2014 00:53:12 Alan Hodgson did opine
And Gene did reply:
> On Thursday, July 17, 2014 12:22:59 AM you wrote:
> > Thanks Alan, but this is what I get on the client:
> >
> > gene@lathe:/$ sudo amrecover -CDaily -scoyote.coyote.den
> > AMRECOVER Version 2.6.1p1. Contacting server on coyote.coyote.den ...
> > [request failed: timeout waiting for ACK]
> >
> > Cheers, Gene Heskett
>
> Well, you may be missing stuff from a normal install, then.
>
> On my server, I have an xinetd config for amanda that looks like:
>
> # cat /etc/xinetd.d/amandaserver
> # default: on
> #
> # description: Amanda services for Amanda server and client.
> #
>
> service amanda
> {
> disable = no
> socket_type = stream
> protocol = tcp
> wait = no
> user = amandabackup
> group = disk
> groups = yes
> server = /usr/libexec/amanda/amandad
> server_args = -auth=bsdtcp amdump amindexd amidxtaped
> }
>
> service amanda
> {
> disable = no
> socket_type = dgram
> protocol = udp
> wait = yes
> user = amandabackup
> server = /usr/libexec/amanda/amandad
> server_args = -auth=bsd amdump amindexd amidxtaped
> }
>
> You may need to add something similar (and appropriate to your
> install).
>
> Also, maybe check your firewall setup. I probably can't help much more
> than that remotely.
Here, that file has:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons & such it needs
service amanda
{
disable = no
only_from = coyote.coyote.den shop.coyote.den
lathe.coyote.den
flags = IPv4
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amanda/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amanda/amidxtaped
}
The 2nd and 3rd were commented out but I just re-enabled them and
restarted xinetd. No change, still a timeout. I'll go see if I can find a
logfile
/var/log/amanda/client/amrecover-debug says:
1405570766.256247: amrecover: pid 1662 ruid 0 euid 0 version 2.6.1p1:
start at Thu Jul 17 00:19:26 2014
which would correspond to (if the client clock is correct) the normal
amdump run this morning. But lemme see if the clock is correct, ntp may
not be running yet. Yes, time on the client is within a minute of correct.
Local network, no firewall s/b running. There is no iptables in the
clients /etc/init.d.
On the client machine, /var/log/amanda/client/Daily has sme
amrecover.##.debug files, the newest of which says:
1405585016.053050: amrecover: pid 1727 ruid 0 euid 0 version 2.6.1p1:
start at Thu Jul 17 04:16:56 2014
1405585016.053868: amrecover: pid 1727 ruid 0 euid 0 version 2.6.1p1:
rename at Thu Jul 17 04:16:56 2014
1405585016.053992: amrecover: security_getdriver(name=bsd) returns
0xc37c40
1405585016.054036: amrecover: security_handleinit(handle=0x8bff400,
driver=0xc37c40 (BSD))
1405585016.054904: amrecover: dgram_bind: setting up a socket with family
2
1405585016.056177: amrecover: bind_portrange2: Try port 841: Available -
Success
1405585016.056239: amrecover: dgram_bind: socket 3 bound to 0.0.0.0.841
1405585016.056794: amrecover: dgram_send_addr(addr=0x8bff420,
dgram=0xc3fa24)
1405585016.056822: amrecover: (sockaddr_in *)0x8bff420 = { 2, 10080,
192.168.71.3 }
1405585016.056843: amrecover: dgram_send_addr: 0xc3fa24->socket = 3
1405585026.067223: amrecover: dgram_send_addr(addr=0x8bff420,
dgram=0xc3fa24)
1405585026.067278: amrecover: (sockaddr_in *)0x8bff420 = { 2, 10080,
192.168.71.3 }
1405585026.067301: amrecover: dgram_send_addr: 0xc3fa24->socket = 3
1405585036.077535: amrecover: dgram_send_addr(addr=0x8bff420,
dgram=0xc3fa24)
1405585036.077591: amrecover: (sockaddr_in *)0x8bff420 = { 2, 10080,
192.168.71.3 }
1405585036.077613: amrecover: dgram_send_addr: 0xc3fa24->socket = 3
1405585046.087741: amrecover: security_seterror(handle=0x8bff400,
driver=0xc37c40 (BSD) error=timeout waiting for ACK)
1405585046.087824: amrecover: security_close(handle=0x8bff400,
driver=0xc37c40 (BSD))
AKA the timeout msg I see on the console. I am not sure I have the
.amandahosts file in the correct location on the client, its a eb install
of 2.6.1p1, this machine has a much newer 4.0, locally built.
So basically I am not finding the log file with the real showstopper.
I haven't a clue where 2.6.1p1 expects to find the .amandahosts file.
Here on the server, I apparently have 3 .amandahosts files
root@coyote:/var/backups# ls -lau `locate .amandahosts`
-rw------- 1 amanda disk 550 2014-07-17 01:20 /home/amanda/.amandahosts
-rw------- 1 amanda disk 417 2013-07-09 10:27 /home/amanda/.amandahosts~
-rw------- 1 backup backup 47 2014-07-17 04:14 /var/backups/.amandahosts
The last one I just made, looks like its removeable.
The contents of /home/amanda/.amandahosts:
coyote.coyote.den amanda amdump amindexd amidxtaped
coyote amanda amdump amindexd amidxtaped
coyote.coyote.den root amdump amindexd amidxtaped
shop.coyote.den root amdump amindexd amidxtaped
shop root amdump amindexd amidxtaped
shop.coyote.den amanda amdump amindexd amidxtaped
shop amanda amdump amindexd amidxtaped
lathe root amdump amindexd amidxtaped
lathe.coyote.den amanda amdump amindexd amidxtaped
lathe amanda amdump amindexd amidxtaped
That might need fixing, but the backup have been working. But tonights
backup run emailed report show that all entries for "lathe" are missing.
an su -c amanda "amcheck Daily" reports
WARNING: lathe: selfcheck request failed: Connection refused
So something isn't configured right on lathe.coyote.den yet.
Ideas welcome.
Thanks.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
