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]
