This seems to be a HP-UX bug (getaddrinfo API). Here is link describing it:
https://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1304369816045+28353475&threadId=614359
> PHCO_30030 fixed the problem
Let me know if the patch resolves the issue.
Thanks,
/Girish
--- On Mon, 5/2/11, Lightner, Jeff <jlightner AT water DOT com> wrote:
> From: Lightner, Jeff <jlightner AT water DOT com>
> Subject: Re: [Veritas-bu] bpclntcmd and others ignoring nsswitch.conf? -SPOKE
> TO SOON
> To: "Patrick" <netbackup AT whelan-consulting.co DOT uk>
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Date: Monday, May 2, 2011, 9:25 PM
> 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
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
