Greetings All,
To date, I have received 3 responses (and one 'Me Too') to my
DNS/Resolver question.
In summary, my problem appears to be improper procedure installing the shared
resolver libraries. (That's what happens when a hardware guy starts screwing
around with this sort of thing.) I am currently re-doing the whole procedure -
I think correctly this time.
*Many thanks* to those who have responded - I investigated the
suggested courses of action in reverse-order of effort. I'm at
answer #3 (below) now.
The original question:
>
> I am trying to set up a sparc-2 running SunOS 4.1.3_U1 with DNS only (no yp).
> (I DID read the FAQ Subject 3.2 on DNS w/o NIS, but need more info.)
>
> I have built resolv+ on the machine, as well as sendmail8.6.9 *and thats all*.
> (I did this before knowing anything about changing BIND on the machine).
>
> It appears now that the resolver is not working properly. It does not appear
> to see all nameserver entries in resolv.conf, just the first. Also, the
> new sendmail appears to have a problem with hostname resolution. I have a
> properly configured hosts.conf.
>
> Do I need to do anything else to make all the DNS/resolver software work
> correctly? I did not touch BIND. Is that the problem?
>
> I got bindon41.shar (FAQ 3.2). If I go ahead with installing BIND4.8.3, do I
> need to redo the resolv+ build afterward? And sendmail? Are these things
> statically linked?
>
> Also, the bindon41 README says to apply patches to BIND4.8.3. If there is a
> later version, should I be suspicious about applying these patches?
>
> Any suggestions or instructions will be greatly appreciated.
>
The responses were:
_______________________________________________________________________________
*** 1. Richard Crane <crane@cadlab.ECE.Drexel.EDU>
I think what you have is a configuration problem. How many
DNS servers are in your resolv.conf file? If it is more than
three, then you needed to modify the source configuration files
in resolv+.
_______________________________________________________________________________
_______________________________________________________________________________
*** 2. Darryl Wagoner-MIS Manager <darryl@ptltd.COM>
It sounds like you didn't install the shared libraries for resolv+.
They are located in the shlib directory of the resolv+. You may also
need to add /etc/host.conf see resolv++.8 for details.
_______________________________________________________________________________
..This was one serious answer!! I have included it in its entirety as it
seemed appropriate to do so in this instance. (Some interesting notes
augmenting the vanilla /usr/lib/shlib.etc README file.)
You spent a lot of time doing this, Pat - thanks much.
("If all {else} fails...")
_______________________________________________________________________________
*** 3. (Pat Myrto) rwing!pat@ole.cdac.COM
"In the previous message, joe merola said..."
>
> Hi,
>
> I am trying to set up a sparc-2 running SunOS 4.1.3_U1 with DNS only (no yp).
> (I DID read the FAQ Subject 3.2 on DNS w/o NIS, but need more info.)
>
> I have built resolv+ on the machine, as well as sendmail8.6.9 *and thats all*.
> (I did this before knowing anything about changing BIND on the machine).
Did you rebuild the shared libs? Specifically, libc.so.x.x?
You need to do this, as well. The resolver calls in libc expect NIS to
be running before you can have the resolver work. The procedure involves
replacing/adding the resolver stuff to the libc shared library, so the
assorted networking applications will be using gethostby???? calls that
reference DNS directly, not NIS (which in turn references DNS). The
resolver lib functions are compiled with -pic, and extracted into a
subdir that the libc_pic.a modules are extracted into (see the README
in shlib.etc). The instructions are appended to this msg. Note you
must have installed the shared lib kit to do this operation (if
/usr/lib/shlib.etc is missing, you must install this option from the
CDROM before you start).
Note you will need to reboot to get all the daemons running on the new
shared library. Though the instructions below don't specify this, I
feel better going to single user to do the actual install of the new
library after testing it as instructed below in the appended info. Then
halt and reboot. Whatever you do, do NOT copy the new shared lib over
the old one - that will crash the machine, and do it HARD, leaving you
with an unusable shared lib. Do it like it says to do it.
Note the patch for libresolv.a mentioned in the info appended is irrelevant
if you replace the libresolv.a with libresolv.a built from the replacement
BIND package, or with libresolv+.a. I think the resolv in the latest
BIND 4.9, etc incorporates much of libresolv+, I am not sure if the new
BIND requires a later libresolv than libresolv+ or not (check the docs
with BIND).
> It appears now that the resolver is not working properly. It does not appear
> to see all nameserver entries in resolv.conf, just the first. Also, the
> new sendmail appears to have a problem with hostname resolution. I have a
> properly configured hosts.conf.
>
> Do I need to do anything else to make all the DNS/resolver software work
> correctly? I did not touch BIND. Is that the problem?
Yup, the replacement of libc.so. as mentioned above, see info appended.
> I got bindon41.shar (FAQ 3.2). If I go ahead with installing BIND4.8.3, do I
> need to redo the resolv+ build afterward? And sendmail? Are these things
> statically linked?
Sendmail is dynamically linked, but needs to be restarted, as do other
daemons, hence my suggestion to reboot.
> Also, the bindon41 README says to apply patches to BIND4.8.3. If there is a
> later version, should I be suspicious about applying these patches?
There is a later version - BIND 4.9.2 (or .1, I forget). You should
probably use the libresolv included. Note - change the Makefile
for building libresolv.a and comment out the ar -r and mv a.out
modulename.o lines, so each module is built without involving
ar. Use only the ar command that actually creates libresolv.a.
You also need to add -pic to the compiler flags, or the resolver modules
will not work in a shared library. It will take a few false starts
before you get it to build like you want, and makefiles creating cc cmd
lines that will find all the needed files. Don't forget to do the 'make
links' stage as described in the instructions with BIND before trying
the build.
> Any suggestions or instructions will be greatly appreciated.
Good luck. Instructions for doing libc shared libs below.
=========== Info on modifying libc.so with new resolver functions ============
Note! if you are interested in a System V libc, please substitute
libcs5_pic.a for libc_pic.a in step 3,
libcs5.so.x.y.z for libc.so.x.y.z in step 14.
-------------------------------------------------------------------------
1. Become super user
% su
2. Make a temporary directory
% mkdir tmp resolv
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 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
% mv xccs.multibyte. xccs.multibyte.o
Note: this last mv command is not present in the original version of the
README file that comes in /usr/lib/shlib.etc/README. If this step is
omitted, you will produce a shared libc.so that does not contain the
xccs_multibyte.o module. This module contains versions of the library
functions "mbtowc", "wctomb", "mbstowcs" and "wcstombs" (see mblen(3) for
more info on these multi-byte character functions), which operate on the
Xerox XCCS codeset standard. Specifically, the missing functions will be
_mbtowc_xccs(pwc, s, n)
_wctomb_xccs(s, pwc)
_mbstowcs_xccs(pwc, s, n)
_wcstombs_xccs(s, pwc, n)
These are called by the corresponding "mbtowc", "wctomb", "mbstowcs" and
"wcstombs" functions if the codeset is XCCS (other codesets include EUC,
ISO 2022, and a default). In short, if you use any Internationalization
features and need to handle multi-byte character sets, do not forget this
step.
4. Extract the contents of /usr/lib/libresolv.a into the resolv directory:
(this is the Sun libresolv, or one you have built using the -pic compiler
option)
% cd ../resolv
% ar x /usr/lib/libresolv.a
% rm __.SYMDEF
The Sun libresolv.a contains object modules that are position
independant, so they can be added to the libc_pic modules without fear.
Following patch is unnecessary if you are replacing the libresolv.a
module, either from the BIND package or with libresolv+.a.
NOTE: You may wish to install Sun patch 100465-01 *first* before taking
this step, as it provides a newer patched version of /usr/lib/libresolv.a.
This fixes a serious bug that causes DNS nameserver lookups to fail if the
first name server query yields ECONNREFUSED (Connection refused), even if
the other nameservers specified in /etc/resolv.conf are both up & working:
Patch i.d. Bug i.d's SunOS Description
---------- --------- ----- -----------
100465-01 1076977
4.1 4.1 4.1.2 DNS res_send() fails if first nameserver
in /etc/resolv.conf returns ECONNREFUSED
5. Remove the old routine to do the hostname/addr resolution, which
is the gethostent.o in the tmp subdir. Since we are in resolv:
% rm ../tmp/gethostent.o
6. Remove the libresolv module that contains `strncasecmp' (which is now
in the main C library, so it is redundant): (but didn't it overwrite
the main C library version of the module? I think this should be
removed from libresolv's modules BEFORE putting them into /tmp.
NOTE: I agree (pat@rwing). Also remove any mktemp.o modules from
the resolv subdir before the copy operation - you MUST use the
Sun version provided in the tmp subdir.
% rm strcasecmp.o
7. Remove the reference to `gethostent.o' and add the
references to the resolver library routines by applying this patch:
% cd ..
% diff -rc2 lorder-sparc.orig lorder-sparc
*** 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
8. If you are running under SunOS 4.1.2, you will want to add the entry
"mblib.o" to the very end of the "lorder-sparc" file. If you aren't running
SunOS 4.1.2, you may now skip down to step 9.
Also, you will need to patch the Makefile, as follows (a known bug):
*** Makefile.orig Wed Oct 23 10:13:00 1991
--- Makefile Mon Feb 24 18:38:08 1992
***************
*** 9,13 ****
libc.so:
! ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
/bin/ls /usr/lib/libc.so.* > TMP_FILE
mv a.out libc.so.`cat TMP_FILE | awk -f ${AWKFILE}`
--- 9,13 ----
libc.so:
! ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
/bin/ls /usr/lib/libc.so.* > TMP_FILE
mv a.out libc.so.`cat TMP_FILE | awk -f ${AWKFILE}`
***************
*** 15,19 ****
libcs5.so:
! ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
/bin/ls /usr/5lib/libc.so.* > TMP_FILE
mv a.out libc.so.`cat TMP_FILE | awk -f ${AWKFILE}`
--- 15,19 ----
libcs5.so:
! ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
/bin/ls /usr/5lib/libc.so.* > TMP_FILE
mv a.out libc.so.`cat TMP_FILE | awk -f ${AWKFILE}`
9. 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. For the resolv, do:
% cp respolv/*.o tmp
10. % make libc.so
11. 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 (many use date, ls, etc)
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
12. You are now running with the new library. You can verify this by
doing a trace command of, let's say, "date".
% trace date
or:
% ldd /bin/date
The output should informed you that the new library is being used.
_____________________________________________________________________________
Joe Merola merola@caesv1.norden.utc.com
Norden Systems Inc.
Norwalk, CT
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:13 CDT