Jeff, Great! Yes, NB 7.1 (starting with 7.0.1) has started using getaddrinfo (IPv6 friendly API) on all platforms (not just HP-UX). So, it is somewhat surprising that you observed this only on HP-UX. Perhaps, you had ipnodes setting in nsswitch.conf on other platforms.
Anyways, I'll get your findings documented in NB tech note; so that other NB users can benefit from it - Thanks to you! Regards, /Girish --- On Tue, 5/3/11, Lightner, Jeff <jlight...@water.com> wrote: > From: Lightner, Jeff <jlight...@water.com> > Subject: RE: [Veritas-bu] bpclntcmd and others ignoring > nsswitch.conf?-RESOLVED (yes actually resolved this time) > To: "Girish Jorapurkar" <giris...@yahoo.com> > Cc: veritas-bu@mailman.eng.auburn.edu > Date: Tuesday, May 3, 2011, 10:58 PM > The patch (PHCO_30030) has been > superseded more than once and we have one of the superseding > patches PHCO_37369 so would already have the "bug fix" the > poster at the link mentioned. > > However, I'd like to thank you as your pointer helped me > resolve the issue: > 1) By downloading and compiling his source code I was > able to see that I did have the same issue with his binary > as that poster did. (That is to say this > binary like the NetBackup binaries did not resolve from > /etc/hosts first but rather from DNS.) > 2) On reviewing the > /var/adm/sw/products/PHCO_37369/pfiles/README file that came > with the later patch I saw the following (which is from > another patch this one supersedes so is incorporated): > PHCO_29287: > ( QX:QXCR1000523428 > SR:8606308071 CR:JAGae71107 ) > If IPv6 is enabled on a system, > the Internet Services > commands use the APIs > getipnodeXX() or get*info() to > resolve the name instead of the > APIs gethostbyXX(). > The APIs getipnodeXX() and > get*info() look into the > ipnodes directive of the > /etc/nsswitch.conf to resolve > the name/address. As the > NIS/NIS+ backends do not > respond to the ipnodes > directive, the resolution of > IPv4 addresses fails for NIS > and NIS+ sources. > > While we aren't doing anything with NIS/NIS+ the other info > about IPv6 was informative. Turns out that in addition > to the standard "hosts:" line in /etc/nsswitch.conf HP-UX is > expecting an "ipnodes:" line for binaries that use the above > APIs. > > After modifying /etc/nsswtich.conf so it now has both the > following lines: > hosts: files [notfound=CONTINUE] dns > ipnodes: files [notfound=CONTINUE] dns > > The new binary resolved correctly from /etc/hosts and on > testing so did bpclntcmd. Based on that I > restarted the backup that had been going across the primary > LAN previously and it is currently running on the expected > backup LAN. > > Presumably this means the 7.1 NetBackup binaries are using > the above referenced APIs on HP-UX where the 6.5.4 binaries > didn't. > > We never saw this issue on HP-UX up through version 6.5.4 > and in testing yesterday I'd copied the 6.5.4 binary and its > associated libraries to another directory on my HP-UX host > and it resolved from /etc/hosts. > > I added the ipnodes entry to /etc/nsswitch.conf on the > other HP-UX 11.11 media server and the HP-UX 11.23 client > I'd recreated the error on previously. On > adding the line both hosts correctly resolved the backup LAN > IP from /etc/hosts instead of going to DNS. > > FYI: ITRC is going away so I'm not sure if the link > will still be accessible in the > future. Accordingly I'm including the > source code that poster had made so it is available from > this forum. > > His source code file was called: 114249.c and I > compiled it by running: > "cc -o testresolver 114249.c". Usage is > simply "testresolver <hostname>". The > source code is as follows: > > /* Test program to test IP resolution for domain names > */ > > > #include <stdio.h> > #include <sys/types.h> > #include <sys/socket.h> > #include <arpa/inet.h> > #include <netdb.h> > #include <string.h> > > > /* Function to get IP address for hostname > ** hostname - (i/p) - Hostname to find IP address > ** buffer - (o/p) - Buffer filled with IP > address > ** buffer_len - (i/p) - Length of buffer > ** Return APR_SUCCESS on success > **/ > int get_ip_from_hostname(char *hostname) > { > int status = 0; > struct addrinfo hints, *ai, *ai_list; > char host_ip[INET_ADDRSTRLEN]; > const char *ret = NULL; > > memset(&hints, 0, sizeof(hints)); > hints.ai_family = AF_INET; > hints.ai_socktype = SOCK_STREAM; > status = getaddrinfo(hostname, NULL, > &hints, &ai_list); > if (status) > { > printf("Failed to resolve IP > address for %s \n ", hostname); > printf("Error: %s \n", > gai_strerror(status)); > return status; > } > > ai = ai_list; > if(ai) > { > struct sockaddr_in *in = > (struct sockaddr_in *)ai->ai_addr; > host_ip[0] = '\0'; > ret = inet_ntop(AF_INET, > &in->sin_addr, host_ip, sizeof(host_ip)); > } > freeaddrinfo(ai_list); > > if(host_ip) > { > printf("Hostname \"%s\" > resolves to IP \"%s\" \n", hostname, host_ip); > status = 0; > } > else > { > printf("Failed to resolve IP > address for %s \n", hostname); > status = -1; > } > > return status; > } > > void usage() > { > > printf("resolve_hostname <hostname> > \n"); > > return; > } > > int main(int argc, char *argv[]) > { > > char hostname[1024]; > > if(argc<2) > { > usage(); > return 0; > } > > strcpy(hostname, argv[1]); > get_ip_from_hostname(hostname); > > > return 0; > } > > > -----Original Message----- > From: veritas-bu-boun...@mailman.eng.auburn.edu > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > On Behalf Of Girish Jorapurkar > Sent: Monday, May 02, 2011 5:02 PM > To: Patrick; Lightner, Jeff > Cc: veritas-bu@mailman.eng.auburn.edu > Subject: Re: [Veritas-bu] bpclntcmd and others ignoring > nsswitch.conf?-SPOKE TO SOON > > 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 <jlight...@water.com> > wrote: > > > From: Lightner, Jeff <jlight...@water.com> > > Subject: Re: [Veritas-bu] bpclntcmd and others > ignoring nsswitch.conf? -SPOKE TO SOON > > To: "Patrick" <netbac...@whelan-consulting.co.uk> > > Cc: veritas-bu@mailman.eng.auburn.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:netbac...@whelan-consulting.co.uk] > > > > Sent: Friday, April 29, 2011 10:00 AM > > To: Lightner, Jeff > > Cc: veritas-bu@mailman.eng.auburn.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. > > > > netbac...@whelan-consulting.co.uk > > > > > > -----Original Message----- > > From: veritas-bu-boun...@mailman.eng.auburn.edu > > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > > On Behalf Of Lightner, > > Jeff > > Sent: 29 April 2011 13:41 > > To: Rosie Cleary > > Cc: veritas-bu@mailman.eng.auburn.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.cle...@nuim.ie] > > Sent: Friday, April 29, 2011 5:06 AM > > To: Lightner, Jeff > > Cc: veritas-bu@mailman.eng.auburn.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-boun...@mailman.eng.auburn.edu > > > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > > *On Behalf Of > > > *Lightner, Jeff > > > *Sent:* Thursday, April 28, 2011 3:11 PM > > > *To:* veritas-bu@mailman.eng.auburn.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:jlight...@water.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_o...@symantec.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:jlight...@water.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_o...@symantec.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-boun...@mailman.eng.auburn.edu > > > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > > *On Behalf Of > > > *Lightner, Jeff > > > *Sent:* Thursday, April 28, 2011 2:22 PM > > > *To:* veritas-bu@mailman.eng.auburn.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 > | > > *:jlight...@water.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@mailman.eng.auburn.edu > > > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > _______________________________________________ > > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > > _______________________________________________ > > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > > _______________________________________________ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > > 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@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu