Networker

Re: [Networker] Client with an inflated ego

2010-08-24 12:41:50
Subject: Re: [Networker] Client with an inflated ego
From: Tim Mooney <Tim.Mooney AT NDSU DOT EDU>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 24 Aug 2010 11:40:51 -0500
In regard to: [Networker] Client with an inflated ego, STANLEY R. HORWITZ...:

I am trying to set up a new Red Hat Linux VM to be backed up to my Red
Hat Linux NetWorker server. Both the client and the server are running
NetWorker 7.5SP3. The problem is that this particular client tries to
connect to the server as if it the server and so I get an error that the
client's root user needs to be put on the server's remote access list.
If I make that change, then I do a backup, what gets backed up is the
server's data, not the client's. I have never seen anything like this
before and it has me baffled.

That is a weird one.

I assume that only the lgtoclnt package (and possibly lgtoman) is
installed on the client -- definitely remove the node and server packages
if you have them installed on the client.

I would verify the contents of the /nsr/res/servers file on the client.

On your backup server, I would save the clientid for the client, and then
completely delete the client and recreate it from scratch, making certain
to preserve the client id.

I checked all the usual stuff such as ping in both directions

In this particular situation, just testing that "ping servername.fqdn"
or "ping WW.XX.YY.ZZ" produces an echo response isn't sufficient, since
what we really need to know is if the response is coming from the system
we expect it to be.  If there's something fouled up with DNS or what
system has a particular IP address bound to it, you could be getting a
ping response, but not from where you think it should be coming from.
If you haven't, you should actually watch network traffic while this is
happening, to make certain that the two endpoints you expect to be
involved actually are.

and
reverse DNS on both the client and the server for both of them. It all
works fine. If anyone has any ideas on how to fix this, please let me
know.

If recreating the client doesn't fix it, I would fall back to debugging
tool of choice: strace.  You'll get a lot of data if you strace a probe of
the client, but somewhere in there will be a clue as to why one system is
impersonating another.

Tim
--
Tim Mooney                                             Tim.Mooney AT ndsu DOT 
edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

<Prev in Thread] Current Thread [Next in Thread>