The answer is both commands "work" in that they both run. However, both
commands are using the IP from DNS to make the connection rather than the one
from /etc/hosts. Therefore the only IP I ever see in the output is the main
LAN IP rather than the one for the backup LAN that is in /etc/hosts.
Some testing was done after adding an entry to /etc/hosts that doesn't exist in
DNS and I found the command resolved the correct (backup LAN) IP. Also
afterwards the new entry was commented out of /etc/hosts and bpclntcmd
-clear_host_cache and it did NOT find anything in cache. This to me suggests
that the issue is that the NetBackup utilities are looking at /etc/hosts but
only after they can't find it in DNS but this is the opposite of the way
nsswitch.conf is configured.
I do not see an issue resolving the backup LAN IPs from /etc/hosts from either
the RHEL6 master or the Windows 2003 client.
Other tests show me that I can repeat this bad behavior on another HP-UX 11.11
media server and an HP-UX 11.23 client. Since host level utilities (nslookup
and ping) return the correct address from /etc/hosts I know that nsswitch.conf
is working on HP-UX.
To me it appears the issue is the NetBackup binaries all have the same flaw on
HP-UX. This suggests to me there is a bug in a common object or library that
is used for the host name resolution used by all these NetBackup binaries but
that it is only on the HP-UX version of NBU 7.1.
-----Original Message-----
From: Patrick [mailto:netbackup AT whelan-consulting.co DOT uk]
Sent: Friday, April 29, 2011 10:00 AM
To: Lightner, Jeff
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf? -SPOKE
TO SOON
Have you tried running bptestbpcd -client <client name> -verbose -debug from
the media server? What are the results? Does bpgetconfig -M <client name>
work?
Regards,
Patrick Whelan
VERITAS Certified NetBackup Support Engineer for UNIX.
VERITAS Certified NetBackup Support Engineer for Windows.
netbackup AT whelan-consulting.co DOT uk
-----Original Message-----
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: 29 April 2011 13:41
To: Rosie Cleary
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf?
-SPOKE TO SOON
We actually do that for most clients but this is a MS Exchange cluster name
and we didn't need to use a separate name for this cluster in 6.5.4. To me
this seems like a bug in the NetBackup tools since I can demonstrate OS
level tools resolve the expected IP and it is only the
NetBackup tools that are getting the wrong name. Also as I noted
before this is only happening on my HP-UX media server - my master server is
getting the correct IP in bpclntcmd for the client.
-----Original Message-----
From: Rosie Cleary [mailto:Rosie.Cleary AT nuim DOT ie]
Sent: Friday, April 29, 2011 5:06 AM
To: Lightner, Jeff
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf?
-SPOKE TO SOON
Hi Jeff,
I've just started using dnsmasq on Red Hat Linux which acts as a dns
forwarder but allows me to override certain IP addresses. It's easy to
configure and will get around this problem.
Other than that is it out of the question to use a slightly different name
for client interface that is in the backup network? (e.g.
servername-b) You would then put servername-b rather than servername in the
policy and the traffic would automatically route over the backup network.
I've used this for all clients in my backup network from day one and it's
been fine. The disadvantages that I can think of for you are
- The name of the client in reports and for searches is different from
the normal client name, and if it only applies to one or two servers then it
will be confusing.
- Backups taken before the change will be considered by the server to be
of a different client so there are a few extra steps to restore from these.
Best regards,
Rosie.
Rosie Cleary
Computer Centre
National University of Ireland, Maynooth
Lightner, Jeff wrote [28/04/2011 20:53]:
> 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=TECH14111
7&key=15143&actp=LIST
>
<http://www.symantec.com/business/support/index?page=content&id=TECH1411
17&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.
> ----------------------------------
>
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
