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
|
