Tim,
Thanks for your thoughts on this matter.
I started to poke around on the client and I noticed that the
/nsr/logs/daemon.raw log on the client was displaying a hostname that was
different than what DNS said. As it turns out, even though this client's
/etc/hosts file was correct and so was the results of "/sin/ifconfig -a" it
turns out that there was an in the client's /etc/sysconfig/networks file. The
FQDN for this server was along the lines of xxx.yyy.temple.edu but in that
file, it had xxx.temple.edu which does not exist in DNS or in the client's
/etc/hosts file. Since this client is still in test mode, I changed its
/etc/sysconfig/network file to reflect reality, rebooted it, and I can now back
it up.
On 08 24, 2010, at 12:40 PM, Tim Mooney wrote:
> 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
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
|
