A tech note on this topic has been published:
http://www.symantec.com/docs/TECH159765
--- On Wed, 5/4/11, Lightner, Jeff <JLightner AT water DOT com> wrote:
> From: Lightner, Jeff <JLightner AT water DOT com>
> Subject: RE: [Veritas-bu] bpclntcmd and othersignoringnsswitch.conf?-RESOLVED
> (yes actually resolved this time)
> To: "Girish Jorapurkar" <girishsj AT yahoo DOT com>
> Cc: veritas-bu AT mailman.eng.auburn DOT 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-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
> On Behalf Of Girish Jorapurkar
> Sent: Tuesday, May 03, 2011 4:02 PM
> To: Lightner, Jeff
> Cc: veritas-bu AT mailman.eng.auburn DOT 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 <JLightner AT water DOT com>
> wrote:
>
> > From: Lightner, Jeff <JLightner AT water DOT com>
> > Subject: RE: [Veritas-bu] bpclntcmd and others
> ignoringnsswitch.conf?-RESOLVED (yes actually resolved this
> time)
> > To: "Girish Jorapurkar" <girishsj AT yahoo DOT com>
> > Cc: veritas-bu AT mailman.eng.auburn DOT 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-bounces AT mailman.eng.auburn DOT edu
> > [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
> > On Behalf Of Girish Jorapurkar
> > Sent: Tuesday, May 03, 2011 2:13 PM
> > To: Lightner, Jeff
> > Cc: Girish Jorapurkar; veritas-bu AT mailman.eng.auburn DOT 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 <JLightner AT water DOT com>
> > wrote:
> >
> > > From: Lightner, Jeff <JLightner AT water DOT com>
> > > Subject: RE: [Veritas-bu] bpclntcmd and others
> > ignoring nsswitch.conf?-RESOLVED (yes actually
> resolved this
> > time)
> > > To: "Girish Jorapurkar" <girishsj AT yahoo DOT com>
> > > Cc: veritas-bu AT mailman.eng.auburn DOT 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-bounces AT mailman.eng.auburn DOT edu
> > > [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu]
> > > On Behalf Of Girish Jorapurkar
> > > Sent: Monday, May 02, 2011 5:02 PM
> > > To: Patrick; Lightner, Jeff
> > > Cc: veritas-bu AT mailman.eng.auburn DOT 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 <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
> > >
> > > 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
> >
> > 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
>
> 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
|
