It's not so simple on Solaris 10:
>From Solaris OS 10U4 onwards, the contents of the /etc/inet/ipnodes and
>/etc/hosts files have been merged together into just the/etc/hosts file.
>Applying kernel patch 120011-14 on any Solaris 10 system will also perform the
>merge, and subsequent removal of the/etc/inet/ipnodes file.
V.J.
-----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 10:02 PM
To: JeffLightner
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] bpclntcmd and others ignoringnsswitch.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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
