PDA

View Full Version : amrecover from Client machine



taruone
September 28th, 2006, 05:48 PM
Hello all,

I compiled and installed the latest 2.5.1p1 bundle for a client and a server.
--with-tcpportrange=48004,48555
--with-udpportrange=850,854
--with-low-tcpportrange=1001,1009


I have a Server and Client. Respective ports are open for both these machines, includ.
The xinetd entries are set like following

For the Client (with ip 192.168.2.15)
service amanda
{
only_from = <ServerFQDN> 192.168.2.15
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amandabackup
group = disk
groups = yes
server = /opt/amanda-2.5.1/libexec/amandad
server_args = -auth=bsd amdump
}

For the tape/index Server
service amanda
{
only_from = <ServerFQDN> 192.168.2.15
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amandabackup
group = disk
groups = yes
server = /opt/amanda-2.5.1/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}

Amcheck checks out ok. Amdump backs up the Client and the Server just fine.
Amrecover is another story. It works when I restore on the server, for both machines. So when I

Server# amrecover

I can get both the Server's and the Client's backups

But when I try

Client# amrecover
AMRECOVER Version 2.5.1p1. Contacting server on zeus.iit.demokritos.gr ...
[request failed: timeout waiting for ACK]

It doesn't seem to be a firewall problem. I took down both firewalls to no avail. I sniffed the packets to see if there is any ports misconfiguration.
amrecover from Client gets through to the Server where process amandad starts. But that's where it ends, amidxtaped never starts (where as when I amrecover from Server amandad and then amidxtaped start).

It seems that that amandad is responsible for that. I thought that xinetd spawns amidxtaped but when I examined the process tree I saw that amandad spawns it.

Any ideas about it? It's not that important as I can always recover my clients backups on the server and then transfer them to the client. Just wandering though

paddy
September 29th, 2006, 09:12 AM
What are the contents of .amandahosts on the server? Please check you have made
changes to .amandahosts to use secure API for recovery. (http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication#.amandahosts_configuration_f ile_changes)

Thanks,
Paddy

taruone
September 30th, 2006, 02:29 AM
the .amandahosts contains:
192.168.2.15 amandabackup amindexd amidxtaped

the ip belongs to the Client. The only thing that doesn't match with the .amandahosts spec is that instead of FQDN there is IP there. Could it be it?

And yes it seems it's a security problem cause the amrecover logs show that a security_* function calls returns with an error (can't tell right now which specific function, cause Im at home atm and the access to our site is temporarily down so I cannnot examine the logs)

paddy
September 30th, 2006, 11:16 AM
.amandahosts appears to be ok.

Can you post the logs from amrecover when you can?

Paddy

paddy
September 30th, 2006, 11:22 AM
I made a mistake in my earlier post. .amandahosts on Amanda server should be

192.168.2.15 root amindexd amidxtaped

to allow amrecover running as root on machine with IP address 192.168.2.15 to
connect to Amanda server.

I have corrected the Amanda wiki.

Thanks,
Paddy

taruone
October 1st, 2006, 04:56 AM
the .amandahosts file is ok ,since I have both a root and an amandabackup line for that client with amindexd and amidxtaped.

Amrecover log follows
amrecover: debug 1 pid 8584 ruid 0 euid 0: start at Thu Sep 28 15:26:23 2006
Reading conf file "/opt/amanda-2.5.1/etc/amanda/amanda-client.conf".
Could not open conf file "/opt/amanda-2.5.1/etc/amanda/daily/amanda-client.conf": No such file or directory
amrecover: debug 1 pid 8584 ruid 0 euid 0: rename at Thu Sep 28 15:26:23 2006
security_getdriver(name=bsd) returns 0x555c6020
security_handleinit(handle=0x805c0a0, driver=0x555c6020 (BSD))
amrecover: bind_portrange2: Skip port 759: Owned by con.
amrecover: bind_portrange2: Skip port 760: Owned by ns.
amrecover: bind_portrange2: Skip port 761: Owned by rxe.
amrecover: bind_portrange2: Skip port 762: Owned by quotad.
amrecover: bind_portrange2: Skip port 763: Owned by cycleserv.
amrecover: bind_portrange2: Skip port 764: Owned by omserv.
amrecover: bind_portrange2: Skip port 765: Owned by webster.
amrecover: bind_portrange2: Try port 766: Available - Success
amrecover: dgram_bind: socket bound to 0.0.0.0.766
amrecover: dgram_send_addr(addr=0xffffb9a0, dgram=0x555c7064)
amrecover: (sockaddr_in *)0xffffb9a0 = { 2, 24615, <SERVER_IP> }
amrecover: dgram_send_addr: 0x555c7064->socket = 3
amrecover: dgram_send_addr(addr=0xffffb770, dgram=0x555c7064)
amrecover: (sockaddr_in *)0xffffb770 = { 2, 24615, <SERVER_IP> }
amrecover: dgram_send_addr: 0x555c7064->socket = 3
amrecover: dgram_send_addr(addr=0xffffb770, dgram=0x555c7064)
amrecover: (sockaddr_in *)0xffffb770 = { 2, 24615, <SERVER_IP> }
amrecover: dgram_send_addr: 0x555c7064->socket = 3
security_seterror(handle=0x805c0a0, driver=0x555c6020 (BSD) error=timeout waiting for ACK)
security_close(handle=0x805c0a0, driver=0x555c6020 (BSD))

the amindexd or amidxtaped respective logs on the server are not available since they don't start, when I amrecover on the client :(


Here on the logs port 10080 is used to contact the server. As soon as I amrecover on the client I switch to a server terminal, where I see xinetd starting amandad. Then amandad waits for 30secs (xinetd configuratiion) and then dies.

paddy
October 1st, 2006, 06:22 AM
Please remove only_from field from server xinetd entry or set it
appropriately. Currently, it is set to allow connections only from server.

For the tape/index Server
service amanda
{
only_from = <ServerFQDN> 192.168.2.15
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amandabackup
group = disk
groups = yes
server = /opt/amanda-2.5.1/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}

taruone
October 1st, 2006, 09:08 AM
?? The only_from field atm specifies both the Server's FQDN and the client(192.168.2.15)....
I'll remove it though to see if that fixes the problem.

taruone
October 2nd, 2006, 09:17 AM
no luck either...
Anyway thx for the help, I'll move on and revisit this sometime later

paddy
October 2nd, 2006, 11:03 AM
Hi Taruone,

Take a look at xinetd logs at the server. For some reason, amindexd and amidxtaped
are not being started when amrecover sends a request to the server.

What distribution are you using?

I hope you do not have "<ServerFQDN>" in the only_from field value.

Paddy

taruone
October 2nd, 2006, 01:06 PM
ofc not :D

only_from = zeus.iit.restoofdomainname 192.168.2.15
zeus being the backup server and declared in the dns server too. 192.168 is the client.

I've examined the xinetd logs first thing but they are not informative at all
even when I specify (in the xinetd.conf) the full range of availabe options. One thing though. When I examine the whole process flow (when I amrecover on the server ) I see that xinetd spawns amandad which in turn spawns amindexd (parent id of amindexd is amandad).....It's a bit confusing. xinetd spawns all the am* server processes or is there a different sequence of events?

I wish I could see more info on the xinetd logs. I tried the syslog xinetd log option in xinetd.conf but the amount of available debug info was exactly the same (I didn't persist though so that's something I have to try again).

thx for taking the time with me.

ps. btw Im on a SuSE 9.2 with 2.5.1p1 which I compiled.

bethany
October 19th, 2006, 08:03 AM
I'm having the exact same problem. I changed my auth type to bsdtcp in hopes that it would resolve other issues I was having with unpredictable client timeouts, which so far it did, but now I can't recover! Relevant files:

.amandahosts on the server(middenheap):

daddy.xxx.edu root amindexd amidxtaped

.amandahosts on the client (daddy):

localhost.localdomain amandabackup amdump
middenheap-dev.xxx.edu amandabackup amdump
middenheap.xxx.edu amandabackup amdump

(btw, Middenheap-dev and Middenheap point at the same IP address)

/etc/xinetd.d/amandaserver on server:
service amanda
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amandabackup
group = disk
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}



/etc/xinetd.d/amanda on client:
service amanda
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amandabackup
group = disk
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump
}

Recovery command, run as root on client:
amrecover ISDaily2.5 -s middenheap.xxx.edu -t middenheap.xxx.edu -d changer
AMRECOVER Version 2.5.1. Contacting server on middenheap.iXXX ...
[request failed: timeout waiting for ACK]

amrecover.*.debug:

[root@daddy ~]# cat /tmp/amanda/client/ISDaily2.5/amrecover.20061019111119.debug
amrecover: debug 1 pid 17915 ruid 0 euid 0: start at Thu Oct 19 11:11:19 2006
Could not open conf file "/etc/amanda/amanda-client.conf": No such file or directory
Could not open conf file "/etc/amanda/ISDaily2.5/amanda-client.conf": No such file or directory
amrecover: debug 1 pid 17915 ruid 0 euid 0: rename at Thu Oct 19 11:11:19 2006
security_getdriver(name=bsd) returns 0x1380e0
security_handleinit(handle=0x9166b48, driver=0x1380e0 (BSD))
amrecover: bind_portrange2: Try port 914: Available - Success
amrecover: dgram_bind: socket bound to 0.0.0.0.914
amrecover: dgram_send_addr(addr=0xbfef3f90, dgram=0x139084)
amrecover: (sockaddr_in *)0xbfef3f90 = { 2, 24615, 130.207.169.188 }
amrecover: dgram_send_addr: 0x139084->socket = 3
amrecover: dgram_send_addr(addr=0xbfef3d30, dgram=0x139084)
amrecover: (sockaddr_in *)0xbfef3d30 = { 2, 24615, 130.207.169.188 }
amrecover: dgram_send_addr: 0x139084->socket = 3
amrecover: dgram_send_addr(addr=0xbfef3d30, dgram=0x139084)
amrecover: (sockaddr_in *)0xbfef3d30 = { 2, 24615, 130.207.169.188 }
amrecover: dgram_send_addr: 0x139084->socket = 3
security_seterror(handle=0x9166b48, driver=0x1380e0 (BSD) error=timeout waiting for ACK)
security_close(handle=0x9166b48, driver=0x1380e0 (BSD))

I tried setting this in xinetd.conf and restarting xinetd, but I'm not getting any more info in /var/log/messages than I usually do:
log_type = SYSLOG authpriv info

Even though I already have a rule allowing all traffic between client and server, I also tried stopping iptables on both client and server, this changed nothing.

help! My backups are no good without recovery... :)
Client on Daddy is amanda-backup_client-2.5.1-1.fc3 installed via RPM.
Server is amanda-backup_server-2.5.1b2-1.rhel4 via RPM

I'll try recovering from a RHEL4 client this afternoon...

paddy
October 19th, 2006, 08:48 AM
Hi Bethany,

Are you able to recover from backup when you run amrecover on Amanda server?

Thanks,
Paddy

martineau
October 19th, 2006, 09:26 AM
amrecover is still using bsd auth

add
auth "bsdtcp"
in /opt/amanda-2.5.1/etc/amanda/amanda-client.conf

bethany
October 19th, 2006, 12:42 PM
Paddy,
I can't recover from backup running amrecover on the Amanda server:


amrecover ISDaily2.5 -s middenheap.xxx.edu -t middenheap.xxx.edu -d changer
AMRECOVER Version 2.5.1b2. Contacting server on middenheap.xxx.edu ...
[request failed: timeout waiting for ACK]

Martineau, do you mean on the client on server? Guess I'll try both...

bethany
October 19th, 2006, 01:07 PM
OK, Martineau had the solution: I needed a /etc/amanda/amanda-client.conf with auth "bsdtcp" on each backup client. thanks so much!