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
|