Getting SunOS 4.1 to use DNS -and- /etc/hosts (long)
Rob Riepel
rob at wdl50.wdl.loral.com
Mon Mar 11 11:44:34 AEST 1991
rg at msel.unh.edu (Roger Gonzalez) writes:
>Sun, for some strange reason, ships their host resolver routines linked
>to routines that -only- use /etc/hosts. I wrestled with this for a
>while, until a helpful soul at Boeing sent me a recipe that walked me
>through unarchiving some shared object libraries, and rebuilding them
>with a different version of a particular routine that uses -only- DNS
>instead of /etc/hosts. This works fine, except that someone in charge
>of the name server has removed 'localhost', so that I keep getting
>"localhost != 127.0.0.1" messages in the error logs. Not horrible, but
>certainly irritating. Also, there are a few host addresses that the
>nameserver doesn't know that I used to have in /etc/hosts.
>I just thought of an idea that I'd like to bounce off the more experienced.
>Keep in mind that I have no source, just the .so files:
>- slurp the DNS lookup routine and the /etc/hosts routine out of the .so files
>- hack the object files so that the two versions have unique names
>- write my own routine that first calls the DNS version, and then /etc/hosts
>- make my routine's name and interface look the same as the originals
>- rearchive them into their .so's
>If this would work, I suspect that there would be a lot of happy SunOS 4.1
>sysadmins out there. In fact, I'm surprised that it hasn't been done
>already!
>Am I overlooking something?
>-Roger
Well Roger (et. al.) here's some answers to this problem!
Recently, there have been a lot of requests for information on how to get the
network programs (telnet, ftp, etc.) on SunOS to use DNS. In the past there
have been posts on exactly how to do this. I've worked with several of these
previously posted methods on SunOS 4.1 in various configurations, and this is
a summary of what I've found.
First of all, if you're using NIS (yellow pages), you're in luck! See page 449
in the "System and Networking Administration" manual. All you have to do is
change one line in /var/yp/Makefile on the master NIS server and you're in
business.
Now if you're not using NIS (yellow pages), you'll have to do a little work to
use DNS. The amount of work you'll have to do depends on whether you want DNS
lookups to "do the right thing." Now an aside to define "the right thing"
Everything you need to use DNS is supplied with SunOS 4.1.x.
It's simply a matter of rebuilding one shared library. However,
the version of DNS supplied uses the name server exclusively,
i.e., it completely ignores the /etc/hosts file once it is
started. Consequently, it goes out on the network to resolve
names like "localhost" and "loghost", names that are used
extensively by a lot of software, including window systems. This
means that if the network or name server is down, stuff like Open
Windows won't work.
I think that applications that don't require a network should not
be crippled by dependencies on a resolver that does. The
resolver should "do the right thing" - use the /etc/hosts file as
a backup! That is, first try to resolve the name using the name
server, and if that fails, check for the entry in /etc/hosts.
(It could be argued that the check on /etc/hosts should be made
first, either way is fine with me). Following are 2 (basically
the same) methods for enabling the DNS resolver on SunOS. The
second includes hacks for "doing the right thing".
To use DNS under SunOS, you need to rebuild the libc shared library. Here is a
post from some time ago that shows exactly how to do that. I have used it, and
it does work on SunOS 4.1. However, it generates a resolver that doesn't "do
the right thing."
=============== Begin included post =========================================
>From: adrian at accucx.cc.ruu.nl (Adrian P. van Bloois)
>Newsgroups: comp.unix.admin
>Subject: named and SUNOS 4.1
>Keywords: Using named without NIS on SUNOS 4.1
>Date: 19 Dec 90 15:46:46 GMT
This is a procedure you can use to substitute or add
a module in your shared libc C library.
Note! If you are interested in a System V libc, please substitute
libc_pic.a for libcs5_pic.a in step 3,
libc.so.x.y.z for libcs5.so.x.y.z in step 8.
-------------------------------------------------------------------------
0. From the directory /usr/lib/shlib.etc
1. Become super user
% su
2. Make a temporary directory
# mkdir tmp
3. Change to the "tmp" directory just made, extract the pic .o from
libc_pic.a and rm the file __.SYMDEF. The reason you need to do
the 2 (or 3) "mv" commands is because "ar" truncated filenames over
16 characters.
# cd tmp
# ar x ../libc_pic.a
# rm __.SYMDEF
# mv rpc_dtablesize. rpc_dtablesize.o
# mv rpc_commondata. rpc_commondata.o
If on a Sun-4, perform this additional `mv' command:
# mv xccs.multibyte. xccs.multibyte.o
Here are some extra instructions for building a shared libc.so that uses the
resolver for hostname/addr resolution:
3a. Extract the contents of libc_pic.a and /usr/lib/libresolv.a into the
tmp directory:
# ar x /usr/lib/libresolv.a
The libresolv.a contains object modules that are position independant, so
they can be added to the libc_pic modules.
*Note* If you have your own copy of the resolver library sources,
(perhaps from a post-4.8 BIND distribution) you can compile each of these
modules yourself using `cc -pic' and the resulting object modules *should*
be usable in this schema as well. To test that the custom resolver
modules will be usable, cd to the directory containing the custom resolver
sources and object modules and perform this test:
# ld -assert pure-text *.o
If `ld' issues no complaints, then you can assume that the object modules
are safe to use.
3b. Remove the old routine to do the hostname/addr resolution:
# rm gethostent.o
3c. Remove the libresolv module that contains `strncasecmp' (which is now
in the main C library, so it is redundant):
# rm strcasecmp.o
3d. As mentioned in step 5 below, edit the file `lorder-sparc' in the ..
directory. Remove the reference to `gethostent.o' and add the
references to the resolver library routines by applying this patch:
*** lorder-sparc.orig Thu Feb 8 05:27:46 1990
--- lorder-sparc Mon Apr 9 12:58:59 1990
***************
*** 150,154 ****
getwd.o
getnetgrent.o
! gethostent.o
ypxdr.o
ttyname.o
--- 150,161 ----
getwd.o
getnetgrent.o
! gethostnamadr.o
! sethostent.o
! res_query.o
! res_mkquery.o
! res_send.o
! res_debug.o
! res_comp.o
! res_init.o
ypxdr.o
ttyname.o
3e. Continue on, from steps 6 to 9 (i.e., skip steps 4 and 5 immediately below).
------------------------------------------------------------------------------
4. Replace or add the .o that you wanted by doing a copy. Please
note here that you are advised to create your object with
the following compiler option, i.e "cc -c -pic yourprogram.c" to make
it shareable.
# cp your.o .
5. If you add a new module then you need to do this step.
You need to edit the file "lorder-sparc" and add the name of the file
you have copied from step 4 at the end of this file.
# vi ../lorder-sparc
6. # cd ..
7. # make libc.so
8. Now you should have some libc.so.x.y.z built in the current directory.
It is recommended that you tested out this library at this point
before installing it. You can do so by setting the environment
LD_LIBRARY_PATH to the current directory for example:
# setenv LD_LIBRARY_PATH `pwd`
# your_favorite_test_cmd
Once you are satisfied that the new library worked, you can proceed
to install it with the following commands:
# cp libc.so.x.y.z /usr/lib
# ldconfig
# unsetenv LD_LIBRARY_PATH
9. You are now running with the new library. You can verify this by
doing a trace command of let's say "date".
# trace date
The output should informed you that the new library is being used.
=============== End of included post ========================================
Of course, following the above directions yields a resolver that ignores the
/etc/hosts file. A more recent post references a procedure available via FTP.
=============== Begin included post =========================================
>From: andys at ulysses.att.com (Andy Sherman)
>Newsgroups: comp.sys.sun
>Subject: Re: SunOS 4.1 Name Resolution Libraries
>Date: 25 Jan 91 15:09:27 GMT
>Approved: Sun-Spots at rice.edu
>X-Refs: Original: v10n15
>X-Sun-Spots-Digest: Volume 10, Issue 26, message 10
>X-Note: Submissions: sun-spots at rice.edu, Admin: sun-spots-request at rice.edu
In article <1236 at brchh104.bnr.ca> lofaso at titan.tsd.arlut.utexas.edu
(Bernie Lofaso) writes:
>It appears as though the name resolution libraries on uunet do not work
>under SunOS 4.1, although we have used them successfully under 4.0.3. Can
>anyone confirm this? Are resolver libraries available for 4.1?
They're not needed for 4.1, since the release contains the tools to
customize the shared C library. Greg Earle, Sun's on-site support person
at JPL has posted instructions for how to do the resolver to the
sun-managers list, and possibly to this list. Perhaps the moderator will
add an archive reference to this. If not, send me mail and I'll see if I
can find it to repost it.
[[Ed's Note: I think I have the right reference although it doesn't appear
to be from Greg Earle (might have inherited someone's name that reposted
it) -bdg]]
FTP: Hostname : titan.rice.edu
Directory: sun-source
Filename : bindon41.shar
Archive Server Address: archive-server at rice.edu
Archive Server Command: send sun-source bindon41.shar
Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ
AUDIBLE: (201) 582-5928
READABLE: andys at ulysses.att.com or att!ulysses!andys
=============== End of included post ========================================
I retrieved bindon41.shar, hoping it would eventually produce a smarter
resolver. It includes instructions for FTPing the BIND source from
ucbarpa.berkeley.edu and applying a few (included) patches. When I followed
the instructions, I got a working version of DNS, but it still ignored the
/etc/hosts file! However, I had the source, so all was not lost.
The routine used by the network programs (telnet, ftp, etc.) to translate from
a host name to a host address is gethostbyname(). I found this entry in the
BIND source file gethostnamadr.c. At then end of gethostbyname(), it does
check the /etc/hosts file if connection to the name server was refused. I
broadened this behavior to check /etc/host if the name wasn't resolved for any
reason. Here's the diff output for my modification.
diff gethostnamadr.c gethostnamadr.c.patched.orig
264,265c264,267
< /* couldn't get it from name server, try hosts file */
< return (_gethtbyname(name));
---
> if (errno == ECONNREFUSED)
> return (_gethtbyname(name));
> else
> return ((struct hostent *) NULL);
294,295c296,298
< /* couldn't get it from name server, try hosts file */
< return (_gethtbyaddr(addr, len, type));
---
> if (errno == ECONNREFUSED)
> return (_gethtbyaddr(addr, len, type));
> return ((struct hostent *) NULL);
The resulting resolver works just fine. It uses the name server first, and if
that fails it checks it's /etc/hosts file. I am using it on several systems
now, and haven't experienced any problems.
One last point, (from bindon41.shar), to use DNS as described above,
You will require SunOS 4.1, and you must have the "Shlib_Custom"
option installed. If you didn't select the "Shlib_Custom" option
when you installed your system, use the SunOS add_services(8)
command to load it from the distribution tapes.
That's it. I hope this post helps you as much as the originals have helped me
(thanks all!). I welcome any questions and will answer as time permits (I get
REALLY busy sometimes (don't we all)).
Finally, <minor flame on>
Attention SUN!!!
I hope you will work on your implementation of the resolver to make these kind
of calestenics unnecessary!
<flame off>
..rob (rob at ssvax1.dnet.loral.com>
More information about the Comp.unix.admin
mailing list