On Thu, 08 Jul 1999 03:59:43 GMT, firstname.lastname@example.org 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 article
Ralf 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.
126.96.36.199 - - [27/Mar/1999:21:06:41 +0000] "GET /ftp-mirror/alife/alifegame/pub/alife-game/program /sounds/ HTTP/1.1" 200 830 188.8.131.52 - - [27/Mar/1999:21:06:41 +0000] "GET /icons/blank.gif HTTP/1.1" 200 148 184.108.40.206 - - [27/Mar/1999:21:06:42 +0000] "GET /icons/back.gif HTTP/1.1" 200 216 220.127.116.11 - - [27/Mar/1999:21:06:42 +0000] "GET /icons/binary.gif HTTP/1.1" 200 246 sv1% nslookup 18.104.22.168 Server: nserv1.dl.ac.uk Address: 22.214.171.124 *** nserv1.dl.ac.uk can't find 126.96.36.199: Non-existent host/domain
>From: email@example.com [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: firstname.lastname@example.org 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 [email@example.com] >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 [firstname.lastname@example.org] 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: email@example.com InterNIC WHOIS: MJO | (has my PGP & Geek Code info) | Phone: +1 248-848-4481
>From: firstname.lastname@example.org [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: email@example.com In article [990509125511.AA5095@dojo.mi.org], Mike O'Connor [firstname.lastname@example.org] writes: > In article [l.cranswick.269.0807475F@dl.ac.uk], > Lachlan Cranswick
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. 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" [email@example.com] Subject: Re: Ping# - Problem: IRIX 6.5.x, NSD and Apache Hostname lookup. Sender: firstname.lastname@example.org (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 188.8.131.52 Server: kether Address: 0.0.0.0 *** kether can't find 184.108.40.206: Server failed kether ~ % ping 220.127.116.11 [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 email@example.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.)