A tech note on this topic has been published: http://www.symantec.com/docs/TECH159765
--- On Wed, 5/4/11, Lightner, Jeff <jlight...@water.com> wrote: > From: Lightner, Jeff <jlight...@water.com> > Subject: RE: [Veritas-bu] bpclntcmd and othersignoringnsswitch.conf?-RESOLVED > (yes actually resolved this time) > To: "Girish Jorapurkar" <giris...@yahoo.com> > Cc: veritas-bu@mailman.eng.auburn.edu > Date: Wednesday, May 4, 2011, 2:00 AM > I'd seen most of that but it is all > related to Solaris which we don't use > here. The file mentioned for Solaris > ipnodes doesn't appear to exist for HP-UX or RHEL. > (The nsswitch.conf file exists on all 3 though and as noted > the HP-UX version does allow for an ipnodes line.) > > My MS Admin tells me that Windows always uses hosts first, > WINS second and DNS last so there apparently isn't any > equivalent to nsswitch.conf on Windows. > > -----Original Message----- > From: veritas-bu-boun...@mailman.eng.auburn.edu > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > On Behalf Of Girish Jorapurkar > Sent: Tuesday, May 03, 2011 4:02 PM > To: Lightner, Jeff > Cc: veritas-bu@mailman.eng.auburn.edu > Subject: Re: [Veritas-bu] bpclntcmd and > othersignoringnsswitch.conf?-RESOLVED (yes actually resolved > this time) > > http://www.brandonhutchinson.com/Solaris_10_ipnodes_caveat.html > http://blogs.sun.com/superpat/entry/solaris_10_etc_hosts_gotcha > http://download.oracle.com/docs/cd/E19455-01/806-0916/6ja8539c5/index.html > > Hmm... who knew (I did not) there is so much already known > about this?! :) > > --- On Wed, 5/4/11, Lightner, Jeff <jlight...@water.com> > wrote: > > > From: Lightner, Jeff <jlight...@water.com> > > Subject: RE: [Veritas-bu] bpclntcmd and others > ignoringnsswitch.conf?-RESOLVED (yes actually resolved this > time) > > To: "Girish Jorapurkar" <giris...@yahoo.com> > > Cc: veritas-bu@mailman.eng.auburn.edu > > Date: Wednesday, May 4, 2011, 12:04 AM > > I just checked my RHEL6 master and > > the RHEL5 media server I'd tested before and neither > of them > > have ipnodes in > /etc/nsswitch.conf. In fact > > the man page for nsswitch.conf on both does NOT > mention > > ipnodes. (The man page on HP-UX does > and > > I've found online references to same for Solaris man > > pages.) > > > > Does MS-Windows have an equivalent to > > nsswitch.conf? If so what is it? > > > > -----Original Message----- > > From: veritas-bu-boun...@mailman.eng.auburn.edu > > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] > > On Behalf Of Girish Jorapurkar > > Sent: Tuesday, May 03, 2011 2:13 PM > > To: Lightner, Jeff > > Cc: Girish Jorapurkar; veritas-bu@mailman.eng.auburn.edu > > Subject: Re: [Veritas-bu] bpclntcmd and others > > ignoringnsswitch.conf?-RESOLVED (yes actually resolved > this > > time) > > > > 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 > > > > 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 > > 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