Xref: utzoo comp.unix.admin:1154 comp.unix.questions:29304
Path: utzoo!news-server.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!uunet!unhd.unh.edu!msel.unh.edu!rg
From: rg@msel.unh.edu (Roger Gonzalez)
Newsgroups: comp.unix.admin,comp.unix.questions
Subject: Getting SunOS 4.1 to use DNS -and- /etc/hosts (long)
Message-ID: <1991Mar9.171331.22378@unhd.unh.edu>
Date: 9 Mar 91 17:13:31 GMT
Sender: usenet@unhd.unh.edu (USENET News System)
Organization: UNH Marine Systems Engineering Laboratory
Lines: 118
Nntp-Posting-Host: msel.unh.edu


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



I've enclosed the recipe here for your viewing pleasure:


	Building the SunOS 4.1 resolver library to access DNS

1. Ensure that the resolver library is built "PIC" by doing the
   following:

		% su root
		% cd /usr/lib/shlib.etc
	        % mkdir tmp
		% cd tmp
		% ar xv /usr/lib/shlib.etc/libresolv.a
		% ls -assert pure-text *.o

	The last command will tell you if there are non-PIC constructs.
	Evidently, there shouldn't be or the resolver can't be made to
	work.

2. Extract contents of libc_pic.a  and /usr/lib/libresolv.a 

	% cd  tmp
	% ar x /usr/lib/shlib.etc/libc_pic.a
	% ar x /usr/lib/libresolv.a

3. Remove the __.SYMDEF file and restore filenames truncated by "ar"

	% rm __.SYMDEF         (note: name begins with 2 underscore char's)
	% mv rpc_dtablesize. rpc_dtablesize.o
	% mv rpc_commondata. rpc_commondata.o
	% mv xccs.multibyte. xccs.multibyte.o

4. Remove the old routine to do the hostname/addr resolution

	% rm gethostent.o

5. Move the libresolv module that contains the redundant 'strncasecmp'

	% rm strncasecmp.o

6. Edit the 'lorder-sparc'

	% cd ..      (assuming you are still in the tmp)
	% cp lorder-sparc lorder-sparc.orig
	% vi lorder-sparc
           ....
	   gethostent.o	      		<< delete this line >>
           ....
           getnetgrent.o
           gethostnamadr.o		<< add this line >>
	   sethostent.o			<<         "   "       >>
           res_query.o			<<         "   "       >>
	   res_mkquero.o		<<         "   "       >>
	   res_send.o			<<         "   "       >>
	   res_debug.o			<<         "   "       >>
	   res_comp.o			<<         "   "       >>
	   res_init.o			<<         "   "       >>

7. Create the new library.

	% make libc.so

8. Test the library before final installation.

	% setenv LD_LIBRARY_PATH `pwd`
   	% your_favorite_test_cmd  (e.g.  telnet, ftp)
	
	If everything appears normal, do the installation.

	% cp libc.so.x.y.z.  /usr/lib      # ensure that libc.so.x.y.z will be
					   # the highest version and does not
					   #  overwrite any existing version
	% /usr/etc/ldconfig
	% unsetenv LD_LIBRARY_PATH

9. Verify that you running with the new library.

	% trace date

 	the first line of output should read:
   			
	open ("usr/lib/ld.so",  ........
 
-- 
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsgar W. Dijkstra 
rg@[msel|unhd].unh.edu        |  UNH Marine Systems Engineering Laboratory
r_gonzalez@unhh.bitnet        |  Durham, NH  03824-3525