fitz@frc2.frc.ri.cmu.edu (Kerien Fitzpatrick) (01/31/90)
I am looking into using the resolver libraries available on uunet to allow our Sun network to make use of the nameservers running at my site. I must be missing something because things are not working as I would expect. The steps that I made are as follows: 1. copied the libc_resolver* to the correct name and ran ldconfig. 2. created a valid resolv.conf file in /etc. 3. changed /etc/hosts to contain only local hosts. 4. changed the makefile in /var/yp so it uses the -b flag when making the hosts YP database. 5. changed all YP servers and slaves to run ypserv -i. Symptoms that I see are as follows: If I ftp to uunet.uu.net (not listed in YP hosts) its IP address is queried and the connection is opened. If I rlogin to one of the Suns on our network using its short name the response is that it is an unknown host. If I qualify the name to the point that it is a known domain of the nameservers that are being queried the IP address is found and the connection is opened. It seems to me that the YP databases are not being queried prior to the nameserver as I would have expected and in fact don't seem to be queried at all. Can someone shed some light on what I am missing? Kerien Fitzpatrick fitz@frc2.frc.ri.cmu.edu
randy@tacky.cs.olemiss.edu (ptm@cs.olemiss.edu) (02/06/90)
In a previous posting Kerien Fitzpatrick asked... > ... Can someone shed some light on what I am missing? Yes I believe I can, would you believe I've just had to deal with this problem ? You are correct in saying that YP isn't being queried about machines on the local network. The patched resolver libraries bypass Yellow Pages completely and ALWAYS go to a remote nameserver to resolve names (unless you set up your own nameserver). The only problem I can think of is that the resolv routines don't set the correct domain name. Make sure that resolv.conf (and possibly rc.local) set your sub domain name to be what the remote nameserver thinks it should be. If this isn't correct, then the remote nameserver can't find the address for you. One confusing thing is that YP and ordinary internet both use the term domain-name even though they have different meanings. I find it easier to keep track of things if YP and internet agree on what the domain name should be. When you use short names, the (new) resolver routines are supposed to add the inet domain name to the end of your inet symbolic address. Yellow Pages (if it's working) appends the YP domain name (not the inet domain name) when it queries the resolv routines. This can cause problems if you switch from YP to non-YP operations (like we tried to do). We had problems here because the nameserver on the campus VM system didn't know about all of our machines. After we informed them, we found out that their response time was so slow that the resolver timed out. The -b option in the Makefile doesn't do much for you since the bug you're dealing with is in the gethostbyXXX() routines that you can't get at unless you have a source license. _Possible_ solutions: (1) Try editing your /etc/hosts file to use the full domain name as the primary name and add shorter names as aliases (saves the fingers some work) i.e. 130.74.32.13 sun4.ncpa.olemiss.edu sun4.ncpa sun4 130.74.32.10 sun3.ncpa.olemiss.edu sun3.ncpa sun3 This way, the software _should_ use the full domain name and you only have to type the short one. If you're using NFS, you may need to change the bootparams file to reflect the full domain name of your nfs servers This is the simplest solution I can think of that might mork. You can use the nslookup command to check and see what the remote nameserver is doing. This is a useful debugging aide. (2) Try setting up your own nameserver database in named.db (You also have to have an /etc/named.boot file to do this). Sun documentation does an okay job of describing how this is done, and sri-nic.arpa (10.0.0.51) has rfc (request for comments) documents that describe in (gorey) detail what all the fields in named.db are for. Specifically, you should have rfc974.lpr, and rfc1033.lpr. Both are reasonable small and are available via anonymous ftp at sri-nic.arpa and can also be found at various ftp sites that archive the bsd BIND source code (usually hidden in a .tar.Z file somewhere). If you have trouble finding them, I can make them available here. I can also leave example named.xxx files if you need them. You can arrange it so that the nameserver (on your host) takes care of all short names in your sub-domain "sub.domain.name" and asks the remote nameserver for names in the domain "domain.name" or above. I _think_ that you aren't supposed to have an /etc/resolv.conf file when you run your own nameserver. (3) Go for a real upgrade. Since we had other software problems, we've opted for the SunOS 4.0.3 upgrade since they _say_ (I have no objective proof) that this fixes the problem. Won't have proof for another fortnight since that's how long it's going to take to get it here. They also _say_ that SunOS 4.1 (available this spring) doesn't have this problem. As you've probably guessed, I won't believe it 'til I see it. When Sun releases the SunOS 4.1 upgrade you will need to make sure that the YP domain name (and database files) are consistent with the remote nameserver. Otherwise there could be conflicts with YP and the remote machine as to what the correct symbolic inet names are supposed to be. I can't stress strongly enough that these are suggestions and not guaranteed solutions. I won't guarantee any of these to work, since I'm not root on this system and didn't have an opportunity to test them all. Besides, we had to trash the resolver library and can't test these ideas now either. If you do decide to use the patched library, I would suggest recompiling any applications that _suddenly_ develop abnormal behavior. Other programs use that shared library besides the resolver, and you could have some interference. We only had this problem with one obscure application, but it happened to be a crucial one for us. Also, since sendmail uses YP to resolve names you may need to download patched versions of sendmail to get e-mail to function properly in your new environment. Personally, I'd rather go for the 4.0.3 upgrade. But the patched library should certainly keep things going in the interim. Good Luck !! Randy Zagar, lowly physics grad /-----------------------------------------\ Internet: randy.NCPA.OleMiss.Edu | Nat'l Center for Physical Acoustics | or randy.CS.OleMiss.Edu | The University of Mississippi at Oxford | | P.O. Box 847 | | University, MS 38677 | \-----------------------------------------/