Thanks Girish.
Thanks also for updating my post at Symantec Connect.
-----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: Wednesday, May 11, 2011 4:32 PM
To: Lightner, Jeff
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] bpclntcmd andothersignoringnsswitch.conf?-RESOLVED
(yes actually resolvedthis time)
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
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
|
