On Thu, 08 Jul 1999 03:59:43 GMT, shop@mfv.com wrote:
>Hi all,
>
>We have an SGI Octane running 6.5.4. As a client, I cannot seem to
>get it to resolve names on our Internet providers DNS server (ie.
>Netscape cannot do a DNS lookup). I can ping the DNS servers using
>their IP address, so I know I can get out onto the net through our
>gateway and pass packets using IP addresses, but no name services. I
>know the name servers are functioning properly. I use same servers
>successfully for other platforms. I have the name servers listed in
>the resolv.conf file, network is on, and a good static route to our
>gateway. Any other files involved in name resolution??
Yes, /etc/nsswitch.conf. Make the "hosts" entry say:
hosts: files dns
...unless you are using nis.
You also need to do "nsadmin restart" or reboot after making modifications
to nsswitch.conf or resolv.conf.
Michael/font>
"If I decoded this correctly, you want to say that you have gcc compiled on old version of IRIX. This is bad. Very bad. Gcc wants to have its own include files and some of them depend on the things you got with the OS. In general, when you use gcc compiled on a previous version of any OS, weird things can happen. Since everything's OK with wget produced with a native C compiler, I suppose weirdness you've discovered can be attributed to the improper gcc setup."
Newsgroups: comp.sys.sgi.apps Subject: Re: Ping #'s not names? Date: Thu, 6 May 1999 21:47:13 LOCAL In articleRalf Beyer writes: > From: Mark Snyder > Hi all, > > I have a problem with my name server. I can use nslookup to get the dns > #, but Navigator nor Ping nor traceroute will "resolve" "unknown host". > Any ideas on what might be causing this? Where can I look next to try > and get it to work properly. > Thanks, > Mark > >You don't say what OS you have. >For IRIX 6.5.2 and later: >man nsd >su >Check /etc/nsswitch.conf that it contains >the line > hosts: nis dns files > >chkconfig nsd on >reboot >Regards >Ralf.Beyer@dlr.de >German Aerospace Center (DLR) >Deutsches Zentrum fuer Luft- und Raumfahrt e.V.
206.31.39.208 - - [27/Mar/1999:21:06:41 +0000] "GET /ftp-mirror/alife/alifegame/pub/alife-game/program /sounds/ HTTP/1.1" 200 830 206.31.39.208 - - [27/Mar/1999:21:06:41 +0000] "GET /icons/blank.gif HTTP/1.1" 200 148 206.31.39.208 - - [27/Mar/1999:21:06:42 +0000] "GET /icons/back.gif HTTP/1.1" 200 216 206.31.39.208 - - [27/Mar/1999:21:06:42 +0000] "GET /icons/binary.gif HTTP/1.1" 200 246 sv1% nslookup 206.31.39.208 Server: nserv1.dl.ac.uk Address: 148.79.80.78 *** nserv1.dl.ac.uk can't find 206.31.39.208: Non-existent host/domain
>From: l.cranswick@dl.ac.uk [Lachlan Cranswick]
>Newsgroups: comp.sys.sgi.apps,comp.sys.sgi.admin
>Subject: Re: Ping# - Problem: IRIX 6.5.x, NSD and Apache Hostname lookup.
>Date: Sun, 9 May 1999 03:48:39 LOCAL
>Organization: Daresbury Laboratory, UK
Basically, Apache 1.3.x compiled under the latest
IRIX 6.5.3 has the occassional hung child servers
when doing DNS lookup on addresses passing through
Lame DNS servers. The webserver is on a
ccp14.ac.uk subnet, the dedicated name server is on
the dl.ac.uk network is do the lookups.
(For: SGI O2 running IRIX 6.5.3 (upgraded from IRIX 6.3(?)
where this problem was not visibly occuring) and apache 1.3.6
compiled with the native SGI cc compiler (gcc gives the
same problem))
I have reported the following to the Apache group
and their reply is that Apache uses the supplied
gethostbyname(). And that there is nothing apache
can do if the gethostbyname() library call does garbage.
I should note that no other program gives this problem
and "nslookup" seems to behave correctly in all tested
circumstances - and on IP addresses that were.
======
A possible way of reproducing things is with using the
/usr/local/apache/bin/logresolve program of the access_log
file.
"logresolve" also hangs on the access_log file in a
semi erratic manner. Doing "logresolve" on a Redhat 5.2
Linux PC Laptop with apache1.3.6 and the same access_log
file does not get stuck.
Following is the /etc/nsswitch.conf file and examples of
points (file sizes) at which "logresolve" hangs.
Any suggestions? If needed, I can put a portion of the
access_log file on the web - as well as corellating
the access_log input with where the program hangs on
the output.
Lachlan.
============================================
============================================
/usr/local/apache/bin/logresolve Output filesizes showing
at what point it was hanging due to lack of increased file
size
File size date-time
53248 May 8 22:00 doobry.text.txt
131072 May 8 22:21 doobry.text.txt
831488 May 8 23:02 doobry.text.txt
131072 May 8 23:14 doobry.text.txt
491520 May 8 23:20 doobry.text.txt
831488 May 8 23:24 doobry.text.txt
131072 May 8 23:30 doobry.text.txt
491520 May 8 23:41 doobry.text.txt
131072 May 8 23:59 doobry.text.txt
============================================
============================================
#
# This is the SGI default nsswitch.conf file. This file determines
# the maps that will be maintained by nsd, which methods will be
# used to lookup information for a map, and what order the methods
# are called in.
#
# For details on this file see the nsswitch.conf(4) manual page.
#
automount(dynamic): files nis(nis_enumerate_key)
#bootparams: files nis
capability: files nis
clearance: files nis
ethers: files nis
group: files nis
hosts: files nis dns
mac: files nis
mail(null_extend_key): ndbm(file=/etc/aliases) nis
netgroup: nis
#netid.byname: nis
networks: files nis
passwd: files(compat) [notfound=return] nis
protocols: nis [success=return] files
rpc: files nis
services: files nis
shadow(mode=0700): files
#ypservers: nis
======
Lachlan M. D. Cranswick
Collaborative Computational Project No 14 (CCP14)
for Single Crystal and Powder Diffraction
Daresbury Laboratory, Warrington, WA4 4AD U.K
Tel: +44-1925-603703 Fax: +44-1925-603124
E-mail: l.cranswick@dl.ac.uk Ext: 3703 Room C14
NEW CCP14 Web Domain (Under heavy construction):
http://www.ccp14.ac.uk
>Date: Sun, 9 May 1999 12:55:11 GMT >Path: daresbury!server5.netnews.ja.net!nntp.news.xara.net!xara.net!nntp.primenet.com!enews.sgi.com!dojo.mi.org!not-for-PROFS >Newsgroups: comp.sys.sgi.apps,comp.sys.sgi.admin >From: Mike O'Connor [mjo@dojo.mi.org] >Subject: Re: Ping# - Problem: IRIX 6.5.x, NSD and Apache Hostname lookup. >Reply-To: Mike O'Connor>Organization: No one falls into a simple set of labels In article , Lachlan Cranswick [l.cranswick@dl.ac.uk] wrote: :Basically, Apache 1.3.x compiled under the latest :IRIX 6.5.3 has the occassional hung child servers :when doing DNS lookup on addresses passing through :Lame DNS servers. The webserver is on a You may need patch 3667. -- Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: mjo@dojo.mi.org InterNIC WHOIS: MJO | (has my PGP & Geek Code info) | Phone: +1 248-848-4481
>From: art@flying.broomstick.com [Arthur Hagen] >Newsgroups: comp.sys.sgi.apps,comp.sys.sgi.admin >Subject: Re: Ping# - Problem: IRIX 6.5.x, NSD and Apache Hostname lookup. >Date: Sun, 9 May 1999 16:09:56 +0200 >Organization: Broomstick Net Services >References: [l.cranswick.269.0807475F@dl.ac.uk] [990509125511.AA5095@dojo.mi.org] >Reply-To: art@broomstick.com In article [990509125511.AA5095@dojo.mi.org], Mike O'Connor [mjo@dojo.mi.org] writes: > In article [l.cranswick.269.0807475F@dl.ac.uk], > Lachlan Cranswickwrote: > :Basically, Apache 1.3.x compiled under the latest > :IRIX 6.5.3 has the occassional hung child servers > :when doing DNS lookup on addresses passing through > :Lame DNS servers. The webserver is on a > > You may need patch 3667. Strange. As having reported this bug in the first place, I never have been adviced of that patch. See [URL:http://support.sgi.com/surfzone/content/bugs/html/incidents/ 669000/669928.html] for more details. Regards, -- *Art
From: "Brent L. Bates" [blbates@vigyan.com]
Subject: Re: Ping# - Problem: IRIX 6.5.x, NSD and Apache Hostname lookup.
Sender: news@arl.mil (The News System [news])
Date: Mon, 10 May 1999 12:01:37 GMT
Something to check. Do you have more than one name server listed in your
/etc/resolv.conf file? Are any of the name servers who's addresses are listed
not functioning? Under previous versions of IRIX, we had some old name servers
listed in the file at the bottom. We weren't using them any more as we had 3
others that we trusted more at the top of the file. The documentation says
that only the first 3 name servers are actually used, so I didn't think
anything of it. Everything worked, that is until we moved to IRIX 6.5 and
`nsd'.
We were having intermittent problems with name resolution and it only
clearly showed up with `sendmail'. `ping', `nslookup', etc., all showed quick
unfailing name and IP resolution. Only `sendmail' had easily definable
problems. With a little help from SGI support (turned on debugging in nsd), I
tracked down the problem to the other name servers listed in our
/etc/resolv.conf file. Apparently, `nsd' doesn't have a limit on the number of
name servers that can be listed and it was using ALL the name servers listed.
A number of the addresses listed didn't point to valid name servers any more.
After I deleted all the extra name servers and only had the 3 I knew were
valid, things improved.
This didn't fix all our problems. The name server is also our email
server. The documentation says to put `0.0.0.0' as the name server in the
/etc/resolv.conf file if that machine is the name server. This didn't work
real well, so SGI suggested (and has also been suggested in these SGI groups as
well) to change this to `127.0.0.1'. This helped some more. Didn't completely
fix things. Finally, I made sure there was only ONE name server listed,
`127.0.0.1' , the local name server, and that seems to have cleared up all our
problems. Since the machine is using its self as a name server, this didn't
bother me much as if the name server is down, then the email server would also
be down. No need for more than one name server in this case.
Hope this helps some.
--
Brent L. Bates (UNIX Sys. Admin.) Phone:(757) 864-2854
M.S. 912 Phone:(757) 865-1400, x204
NASA Langley Research Center FAX:(757) 865-8177
Hampton, Virginia 23681-0001
Email: B.L.BATES@larc.nasa.gov http://www.vigyan.com/~blbates/
nsd hangs forever on DNS reverse lookup failure
Bug Number : 669928
Product : Networking
IRIX Release : 6.5.2m
Category : software
Classification : bug
Priority : 2
Status : closed
Date Opened : 02/03/99
Date Updated : 04/06/99
Summary : nsd hangs forever on DNS reverse lookup failure
Description :
Bug description:
nsd hangs forever on DNS reverse lookup failure
Hardware: SGI O2, believed to be hardware independent Software: IRIX 6.5.2m running BIND 4.9.7
IRIX 6.5.2f running BIND 8.1.2
Almost certainly not BIND dependent.
Example of problem:
kether ~ % nslookup 207.56.48.149
Server: kether
Address: 0.0.0.0
*** kether can't find 207.56.48.149: Server failed
kether ~ % ping 207.56.48.149
[hangs forever]
Fix Information :
This problem has been fixed in IRIX 6.5.4m.
[IRIX 6.5.3f 6.5.3m ] Patch 3667 - infinite retries in name services
INDEX
Relations
Release Notes
Inst Subsystem Requirements
Inst Subsystem Checksums
Inst Subsystem File Listings
Download Patch
RELATIONS
This patch does not replace any other patches.
This patch has no known incompatiblities with other patches.
This patch fixes the following bugs:
682059 - Mail to nonexistent hosts in some domains hangs sendmail
689695 - LANL patch for
RELEASE NOTES
1. Patch SG0003667 Release Note
This release note describes patch SG0003667 to IRIX 6.5.3
and IRIX 6.5.4.
Patch SG0003667 replaces no patches(es)
1.1 Supported Hardware Platforms
This patch contains bug fixes for all hardware
configurations.
1.2 Supported Software Platforms
This patch contains bug fixes for IRIX 6.5.3 (version
1275309330) through IRIX 6.5.4 (version 1275505031). The
software cannot be installed on other configurations.
1.3 Bugs Fixed by Patch SG0003667
This patch contains fixes for the following bugs in IRIX
6.5.3 and IRIX 6.5.4. Bug numbers from Silicon Graphics bug
tracking system are included for reference.
Patch 1601:
Fixes:
Bug #682059-name service requests can loop on error
1.4 Subsystems Included in Patch SG0003667
This patch release includes these subsystems:
o patchSG0003667.eoe_sw.base
1.5 Installation Instructions
Because you want to install only the patches for problems
you have encountered, patch software is not installed by
default. After reading the descriptions of the bugs fixed
in this patch (see Section 1.3), determine the patches that
meet your specific needs.
If, after reading Sections 1.1 and 1.2 of these release
notes, you are unsure whether your hardware and software
meet the requirements for installing a particular patch, run
inst. The inst program does not allow you to install
patches that are incompatible with your hardware or
software.
Patch software is installed like any other Silicon Graphics
software product. Follow the instructions in your Software
Installation Administrator's Guide to bring up the miniroot
form of the software installation tools.
Follow these steps to select a patch for installation:
1. At the Inst> prompt, type
install patchSGxxxxxxx
where xxxxxxx is the patch number.
2. Initiate the installation sequence. Type
Inst> go
3. You may find that two patches have been marked as
incompatible. (The installation tools reject an
installation request if an incompatibility is
detected.) If this occurs, you must deselect one of
the patches.
Inst> keep patchSGxxxxxxx
where xxxxxxx is the patch number.
4. After completing the installation process, exit the
inst program by typing
Inst> quit
1.6 Patch Removal Instructions
To remove a patch, use the versions remove command as you
would for any other software subsystem. The removal process
reinstates the original version of software unless you have
specifically removed the patch history from your system.
versions remove patchSGxxxxxxx
where xxxxxxx is the patch number.
To keep a patch but increase your disk space, use the
versions removehist command to remove the patch history.
versions removehist patchSGxxxxxxx
where xxxxxxx is the patch number.
1.7 Known Problems
INST SUBSYSTEM REQUIREMENTS
No Requirements Information Available.
INST SUBSYSTEM CHECKSUMS
These checksums help to provide a 'signature' for the patch inst image which can
be used to authenticate other inst images. You can obtain this kind of output by
running sum -r on the image (from the command line):
00404 216 patchSG0003667.eoe_sw
52911 8 patch/README.patch.3667
53682 2 patchSG0003667
INST SUBSYSTEM FILE LISTINGS
The following lists the files which get installed from each subsystem in the patch:
patchSG0003667.eoe_sw.base
usr/etc/nsd
usr/relnotes/patchSG0003667/TC
usr/relnotes/patchSG0003667/ch1.z
DOWNLOAD PATCH
The size of the patch is 123Kb. Download the patch.
If you have support contract, you may log a call electronically
with Supportfolio Connect to get this patch shipped to you.
Maintained by supportlib@sgi.com
Instructions for extracting and installing a patch tar file:
(These instructions apply to inst or swmgr for Irix(TM) 5.2 or higher)
1.Change directories to a temporary empty directory. For example:
mkdir -p /usr/tmp/patches
cd /usr/tmp/patches
(Make sure you have sufficient disk space. Refer to the size indicated in
the download page. You will need about twice as much disk space as the size of the
patch to untar the patch tar file.)
2.Place the patch tar file to this temporary directory.
3.Extract the files from the tar image with the command:
tar xvf TARFILE
where TARFILE is the name of the file you copied to the empty directory in step 2 above.
4.Within this directory, start the software installation tool of your choice:
To use inst to install:
inst -f /usr/tmp/patches/
To use swmgr to install: (for ** IRIX 6.2 or above ** ONLY)
swmgr -f /usr/tmp/patches/
5.If you are using inst to install, type the following command to view the
list of subsystems available for installation:
inst> list
(For swmgr, click the "Customize Installation" button to do so).
Select the subsystems to install.
6.If you are using inst to install, type the following command to show any conflicts:
inst> conflicts
(For swmgr, click the Conflicts button if it is highlighted).
7.Resolve any conflicts.
8.If you are using inst to install, install the subsystems with the command:
inst> go
(For swmgr, click the Start button to perform the installation.)
9.If you are using inst to install, exit the software installation tool by typing the following:
inst> quit
(For swmgr, select the File Menu button followed by the Exit menu button.)