Remote amrestore
Installed basic amanda on RH7.2 using RH rpm's got basic system running and tried default /etc backup of localhost. amrestore allowed single file restore... interface seems simple enough to use. updated disklist with remote machine this time using comp-root for / on a machine with 15G in use. backup went just fine. tried to do amrestore got error message: # amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d /dev/nst0 AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ... amrecover: Unexpected server end of file. the /tmp/amanda/amrecover.2002.debug file contains. amrecover: debug 1 pid 29658 ruid 0 euid 0 start time Thur ... amrecover: stream_client: connected to 65.64.90.11.10082 amrecover: stream_client: our side is 0.0.0.0.540 I have entries for amanda, amandaidx, amidxtape in /etc/services for both the client and server. I have restarted network and xinetd on both servers RH 7.2 is using /etc/xinetd.d for inetd configuration. There are 3 files, one for amanda, amandaidx, & amidxtape. On both machines I have these set to disable=no tried to find archives to look through... latest I could find on ftp site ended in 1999. references in those messages seemed to point to problems in /etc/services and /etc/inetd.conf I have reviewed all that and added the 10082 & 10083 entries on both machines with the above noted restarted services. nothing seems to change the error (except putting the firewall up on the server... but that is down for these tests) Any pointers or ideas would be appreciated. thanks Kurt L Vanderwater President, Meridian Data Systems, Inc. Phone: (405) 755-6690 Fax: (405) 415-0676
Remote amrestore
Installed basic amanda on RH7.2 using RH rpm's got basic system running and tried default /etc backup of localhost. amrestore allowed single file restore... interface seems simple enough to use. updated disklist with remote machine this time using comp-root for / on a machine with 15G in use. backup went just fine. tried to do amrestore got error message: # amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d /dev/nst0 AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ... amrecover: Unexpected server end of file. the /tmp/amanda/amrecover.2002.debug file contains. amrecover: debug 1 pid 29658 ruid 0 euid 0 start time Thur ... amrecover: stream_client: connected to 65.64.90.11.10082 amrecover: stream_client: our side is 0.0.0.0.540 I have entries for amanda, amandaidx, amidxtape in /etc/services for both the client and server. I have restarted network and xinetd on both servers RH 7.2 is using /etc/xinetd.d for inetd configuration. There are 3 files, one for amanda, amandaidx, & amidxtape. On both machines I have these set to disable=no tried to find archives to look through... latest I could find on ftp site ended in 1999. references in those messages seemed to point to problems in /etc/services and /etc/inetd.conf I have reviewed all that and added the 10082 & 10083 entries on both machines with the above noted restarted services. nothing seems to change the error (except putting the firewall up on the server... but that is down for these tests) Any pointers or ideas would be appreciated. thanks Kurt L Vanderwater President, Meridian Data Systems, Inc. Phone: (405) 755-6690 Fax: (405) 415-0676
Re: Remote amrestore
># amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d /dev/nst0 >AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ... >amrecover: Unexpected server end of file. > >the /tmp/amanda/amrecover.2002.debug file contains. >... What's in /tmp/amanda/amindexd*debug on tserv.meridian-ds.com? >RH 7.2 is using /etc/xinetd.d for inetd configuration. What's the amindexd config file look like? In particular, make sure you do *not* have a "server args" (or whatever it's called) entry. >tried to find archives to look through... latest I could find on ftp site >ended in 1999. Look toward the bottom of the Amanda web page (www.amanda.org). It refers you to the searchable E*groups (Yahoo) mailing list archive. >Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Remote amrestore
>># amrestore -s tserv.meridian-ds.com -t tserv.meridian-ds.com -d
/dev/nst0
>>AMRECOVER Version 2.4.2p2. Contacting server on tserv.meridian-ds.com ...
>>amrecover: Unexpected server end of file.
>>
>>the /tmp/amanda/amrecover.2002.debug file contains.
>>...
>
>What's in /tmp/amanda/amindexd*debug on tserv.meridian-ds.com?
>
amindexd: debug 1 pid 28366 ruid 33 euid 33 start time Thu Jan 24 16:29:08
2002
amindexd: version 2.4.2p2
gethostbyaddr: Success
amindexd: pid 28366 finish time Thu Jan 24 16:29:08 2002
>>RH 7.2 is using /etc/xinetd.d for inetd configuration.
>
>What's the amindexd config file look like? In particular, make sure
>you do *not* have a "server args" (or whatever it's called) entry.
>
couldn't find amindexd... at least not in refernce to /etc/xinetd.d
so... assuming you meant one of the files in /etc/xinetd.d
in all cases, there server args thingie (very technical term) doesn't seem
to be there.
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amanda
group = disk
server = /usr/lib/amanda/amandad
}
# default: off
#
# description: Part of the Amanda server package
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amindexd
}
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
server = /usr/lib/amanda/amidxtaped
}
>>tried to find archives to look through... latest I could find on ftp site
>>ended in 1999.
>
>Look toward the bottom of the Amanda web page (www.amanda.org). It refers
>you to the searchable E*groups (Yahoo) mailing list archive.
>
I'll look there... thanks
>>Kurt L Vanderwater
>
>John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Remote amrestore
>amindexd: debug 1 pid 28366 ruid 33 euid 33 start time Thu Jan 24 16:29:08 2002 >amindexd: version 2.4.2p2 >gethostbyaddr: Success >amindexd: pid 28366 finish time Thu Jan 24 16:29:08 2002 That "gethostbyaddr: Success" line is a problem. I'm pretty sure what it's trying to say (and I'll get the message fixed so it's clearer) is that it cannot do a host name lookup on the IP address of the client coming in (e.g. the machine you're running amrecover on). So I'd start checking that kind of thing on your server (tserv.meridian-ds.com). I use the following two little programs, if it helps: ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyaddr.c ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyname.c They are "better" than groping around through /etc/hosts or using nslookup because they issue the same actual system library call Amanda does, so they go through whatever lookup mechanisms your system is set up to use (files, NIS, DNS, whatever). >couldn't find amindexd... at least not in refernce to /etc/xinetd.d >so... assuming you meant one of the files in /etc/xinetd.d ... Yeah, that's what I meant. Sorry for the confusion between service name and server/program name. >in all cases, there server args thingie (very technical term) doesn't seem >to be there. Agreed. And "server args thingie" is as technical as I could get :-). The only Linux machine I have access to doesn't have any man pages :-( so I couldn't look it up. There is a parameter in those files that allows you to pass command line arguments to the service when it is started. Some documentation or RPM's incorrectly converted the inetd.conf line to the xinetd format and included this entry with the name of the program. But passing that as an arg to Amanda services really confuses them. In any case, you don't have that problem, so this is all academic. >Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Remote amrestore
John we are now working! thanks so much. you were right about the host name lookup.. for some reason, the remote machine wasn't communicating with the server using it's own IP address... one of it's alias IP addresses instead. I ran ethereal to see what was happening for that. I tracked down the address it was using, and it was unused... so I removed the file from /etc/sysconfig/network-scripts and restarted network on the machine. This gave me a new error message... but enough of clue that indicated that the .amandahosts file on the host needed to be aware of root on the remote client. Once I updated .amandahosts with the machine name and "root" I got into the amrestore interface just fine. currently restoring a subdirectory as a test of the system. thanks again for all your help. Kurt L Vanderwater President, Meridian Data Systems, Inc. Phone: (405) 755-6690 Fax: (405) 415-0676 "John R. Jackson" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] due.edu> cc: [EMAIL PROTECTED] Sent by: Subject: Re: Remote amrestore owner-amanda-users@ amanda.org 01/24/02 07:36 PM Please respond to jrj >amindexd: debug 1 pid 28366 ruid 33 euid 33 start time Thu Jan 24 16:29:08 2002 >amindexd: version 2.4.2p2 >gethostbyaddr: Success >amindexd: pid 28366 finish time Thu Jan 24 16:29:08 2002 That "gethostbyaddr: Success" line is a problem. I'm pretty sure what it's trying to say (and I'll get the message fixed so it's clearer) is that it cannot do a host name lookup on the IP address of the client coming in (e.g. the machine you're running amrecover on). So I'd start checking that kind of thing on your server (tserv.meridian-ds.com). I use the following two little programs, if it helps: ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyaddr.c ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyname.c They are "better" than groping around through /etc/hosts or using nslookup because they issue the same actual system library call Amanda does, so they go through whatever lookup mechanisms your system is set up to use (files, NIS, DNS, whatever). >couldn't find amindexd... at least not in refernce to /etc/xinetd.d >so... assuming you meant one of the files in /etc/xinetd.d ... Yeah, that's what I meant. Sorry for the confusion between service name and server/program name. >in all cases, there server args thingie (very technical term) doesn't seem >to be there. Agreed. And "server args thingie" is as technical as I could get :-). The only Linux machine I have access to doesn't have any man pages :-( so I couldn't look it up. There is a parameter in those files that allows you to pass command line arguments to the service when it is started. Some documentation or RPM's incorrectly converted the inetd.conf line to the xinetd format and included this entry with the name of the program. But passing that as an arg to Amanda services really confuses them. In any case, you don't have that problem, so this is all academic. >Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Remote amrestore
>we are now working! Glad to hear it. FYI, I just applied a code change that will report a much more sane message from gethostbyaddr() and hopefully shorten the head scratching time for the next poor soul. Consider nudging me to do that your good deed for the week :-). >Kurt L Vanderwater John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
