Sorry folks - NOT resolved.
I thought this was resolved because the backup
started but on checking I see it is using the primary LAN rather than the
backup LAN. The addition of the FQDN on the client did get us past the 59
error but didn’t fix the issue I was asking about initially.
The bpclntcmd is still showing the 10.x
primary IP instead of the 172.x backup IP that I have in host file of the media
server. We really need this backup to go across the backup LAN.
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Lightner, Jeff
Sent: Thursday, April 28, 2011
3:11 PM
To:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu]
bpclntcmd and others ignoring nsswitch.conf? -RESOLVED
Dan Otto had responded and based on what
he wrote I resolved the issue. The below shows the thread between
us and is reposted here with his permission.
From: Lightner, Jeff
[mailto:jlightner AT water DOT com]
Sent: Thursday, April 28, 2011
2:02 PM
To: Daniel Otto
Subject: RE: bpclntcmd and others
ignoring nsswitch.conf?
That was it.
After checking bpcd log on the client we
saw that it was complaining that the FQDN name wasn’t a media
server. Our entry for the server was the short name for the media
server. Adding the FQDN to the line that had the backup LAN IP and
short name resolved the issue.
It just didn’t occur to me to look
at the client because I thought bpclntcmd was simply trying to resolve from the
media server.
I had actually tried adding FQDN of the
client to the media server earlier because we have seen various issues
regarding short name vs FQDN since implementing 7.1.
Thanks for your help.
From: Daniel Otto
[mailto:dan_otto AT symantec DOT com]
Sent: Thursday, April 28, 2011
2:57 PM
To: Lightner, Jeff
Subject: RE: bpclntcmd and others
ignoring nsswitch.conf?
The 59 is thrown because whatever server
hostname the client is resolving doesn’t exist in the client’s
server list hence server access denied status 59 and should show up as a status
46 error in bpcd as a invalid server. If the media server couldn’t
resolve the client at all or getting the wrong IP address you would be getting
58/25 or even 54’s type of errors.
From: Lightner, Jeff
[mailto:jlightner AT water DOT com]
Sent: Thursday, April 28, 2011
1:43 PM
To: Daniel Otto
Subject: RE: bpclntcmd and others
ignoring nsswitch.conf?
I did actually try removing dns from
nsswitch.conf but it didn’t help.
I haven’t looked at the
client’s bpcd log – I did verify the media server is in the
server list for the client. The only other one in the list is the
master.
From: Daniel Otto
[mailto:dan_otto AT symantec DOT com]
Sent: Thursday, April 28, 2011
2:35 PM
To: Lightner, Jeff
Subject: RE: bpclntcmd and others
ignoring nsswitch.conf?
Easy fix would be to use the bpcd log on
the client and whatever hostname is getting resolved simply add it to the
SERVER = on the client and the 59 should go away. As to why it is not using the
host file…that’s interesting.
Perhaps for a quick test remove the DNS
entry altogether from switch.conf to see if it then goes to the host file.
Though I have only seen Solaris server do funkly things such as this.
Hope this helps,
Dan O
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
On Behalf Of Lightner, Jeff
Sent: Thursday, April 28, 2011
2:22 PM
To:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] bpclntcmd
and others ignoring nsswitch.conf?
On a UNIX (HP-UX) media server when I run bpclntcmd –hn
<client> (and other bp commands) it appears they’re ignoring the IP
specified for the client in /etc/hosts.
The server also exists in DNS but my nsswitch.conf clearly
says to use files (i.e. /etc/hosts) then dns. If I run
command line tests using other tools (e.g. nslookup and ping) the IP seen for
the client is the one in /etc/hosts. However, bpclntcmd is giving
me the one from DNS. The IPs are different because we have use a
separate subnet for backup LAN.
I’ve done a fair amount of searching and have read
this technote:
http://www.symantec.com/business/support/index?page=content&id=TECH141117&key=15143&actp=LIST
I had actually rebooted the server for another reason about
an hour and a half after I changed /etc/hosts yesterday.
According to all the notes I found the cache should clear itself about an hour
after making a change but that didn’t happen.
This morning I still saw the issue. I tried
reissuing the bpclntcmd –clear_host_cache (new in 7.x) and bouncing
NetBackup on the media server to no avail.
Based on the above technote I have tried moving the cache
directory out and bouncing NetBackup again to no avail.
I also tried just for the hell of it stopping the
pbx_exchange daemon and restarting then bouncing NetBackup but that
didn’t help either.
Interestingly bpclntcmd –hn <client> on the
RHEL6 Linux master returns the correct IP from /etc/hosts file
there. Running bpclntcmd on the client itself with various flags
(e.g. –pn, -self) find the correct master etc…
My backup is failing with a status 59 – can’t
connect to client and I’m assuming it is because the media server is getting
the wrong IP for the client. (The client has an entry in its hosts
file specifying the backup LAN IP of the media server – this is the same
as it was in 6.5.4 except we were using a Windows media server then.)
P.S. On HP-UX nslookup DOES look at /etc/hosts unlike
nslookup on other *nix flavors so please don’t respond that using
nslookup for /etc/hosts isn’t valid. As noted ping also works
so such an observation wouldn’t be helpful even if it weren’t
incorrect. The issue isn’t host name resolution in UNIX but
rather hostname resolution done by NetBackup commands.
__________________________________________________________________________________________
Jeff Lightner | UNIX/Linux Administrator | DS Waters of America, Inc | 5660 New Northside Drive, Ste 250
| Atlanta,
GA 30328
(: (Direct
Dial) 678-486-3516 |(: (Cell) 678-772-0018
| *:jlightner AT water DOT com
Proud partner. Susan G. Komen for the Cure.
Please consider our
environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
