Date: Thu, 21 Nov 1996 11:08:54 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: lennyt@arlut.utexas.edu (Lenny Tropiano) Cc: freebsd-bugs@FreeBSD.org, jkh@FreeBSD.org Subject: Re: Problem getting NIS/yp to allow logins/su to users Message-ID: <199611211608.LAA19976@skynet.ctr.columbia.edu> In-Reply-To: <199611211411.IAA28753@neelix.arlut.utexas.edu> from "Lenny Tropiano" at Nov 21, 96 08:11:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Lenny Tropiano had to walk into mine and say: > I've been banging my head against the wall on this one, and can't figure > out what the deal is. This is the first time I've had to use the NIS/yp > support. This is FreeBSD 2.1.6-RELEASE. > > I can successfully bind, ypcat, ypwhich, ypmatch. But if I su or login > it always comes back with unknown login. I know yp is working, since I > can see users and groups just fine in the "ls -l" listing... > > Script started on Thu Nov 21 08:07:58 1996 > eeyore# ypwhich > ns1.arlut.utexas.edu > eeyore# ypcat -x > Use "passwd" for "passwd.byname" > Use "group" for "group.byname" > Use "networks" for "networks.byaddr" > Use "hosts" for "hosts.byaddr" > Use "protocols" for "protocols.bynumber" > Use "services" for "services.byname" > Use "aliases" for "mail.aliases" > Use "ethers" for "ethers.byname" > eeyore# ypmatch lennyt passwd > lennyt:6cUB2ILRr7hNE:16555:16813:Lenny Tropiano,S252 TSD,3663,2516272:/home/lennyt:/bin/csh > eeyore# ypmatch lennyt passwd.byname > lennyt:6cUB2ILRr7hNE:16555:16813:Lenny Tropiano,S252 TSD,3663,2516272:/home/lennyt:/bin/csh > eeyore# ypmatch 16555 passwd.byuid > lennyt:6cUB2ILRr7hNE:16555:16813:Lenny Tropiano,S252 TSD,3663,2516272:/home/lennyt:/bin/csh > eeyore# su lennyt > su: unknown login: lennyt > eeyore# ls -l /host/n1/itg/stow/ps > total 77 > -rw-r--r-- 1 lennyt itlstw 31708 Sep 22 11:47 ps > ^^^ > eeyore# > Script done on Thu Nov 21 08:09:01 1996 Guh... you know, you're the second person I've encountered who's mentioned something like this. (The other was on IRC... hopefully you're not him. :) I'm starting to wonder about this. /bin/ls is statically linked, which means there's no question that it's using the correct NIS lookup routines. But /usr/bin/su is dynamically linked, which means it may be looking at the wrong libc. Unfortunately, I don't have a 2.1.6-RELEASE installation handy (my test box is running 2.2-ALPHA just at the moment) so I can't do a couple of the things I'd like to do, such as checking timestamps and sizes on /usr/lib/libc.so*. What I'd like you to do is describe to me exactly what parts of the system you installed when you set up the machine. I'm not so much interested in ports/packages (like fvwm, emacs or the other stuff that you can install with pkg_add) as I am in base system components, like bin, proflib, man, src, compat, etc. I'm mainly interested to know if you installed any of the compatibility distributions (as in, compatibility with older versions of FreeBSD). These distributions include different copies of libc.so, and this might be the cause of the problem: I changed the way the pwd_mkdb(8) encodes the special '+' and '-' YP entries from /etc/master.passwd into the /etc/pwd.db and /etc/spwd.db hash databases. I also changed the code in getpwent(3) in libc to match. The trouble is that if you rebuild your user database with pwd_mkdb(8) from 2.1.5 or 2.1.6, then programs that use the getpwent(3) code from 2.1.0 or earlier will _not_ be able to see the special + entries and will therefore assume that NIS is turned off. 2.1.5 and 2.1.6 can read databases from 2.1.0 correctly, but not the other way around. I'm worried that somehow you managed to install one of the older 'compat' versions of libc.so on your system instead of the correct one (or maybe that somehow somebody packed the wrong libc in the distribution). One way this might have happened is if the version numbers are the same: the new one may have been overwritten by the old one. The easiest way to confirm this is to check the copy of /usr/lib/libc.so.* on the 'live filesystem' CD-ROM for the release you have, but I don't think the CD-ROMs have been shipped yet. The other way to do is is to grab the bin.?? files for 2.1.6-RELEASE and extract a copy of libc from them. (cat bin.* | gzip -d | tar -xvf - usr/lib/libc.* should work; the bin.?? files are really just one large tar.gz archive broken up into pieces.) Once you have this copy of libc.so, compare it to the one installed on your system. If they aren't the same size or have different checksums, then somehow you got the wrong one installed. Another thing to try is to ls -l /usr/lib/libc.* and see if all the date/time stamps are roughly the same. If the timestamp for libc.so is way different from libc.a, then your libc.so is probablt bogus. (Alternatively, some kind soul with a fresh 2.1.6 install can show us an ls -l /usr/lib/libc.* and provide checksums for comparison.) I will attempt to load 2.1.6 on my test machine at some point to verify that NIS does work with the latest libc. Note that when I install, I always do a custom setup, and I never use the compat dists. If this does turn out to be tbe problem, the way to fix it is to extract usr/lib/libc.* from the bin distribution (as I mentioned above) and install those libraries on your system in place of the ones you have now. Replacing libc.so is tricky; it's best to do it from single user mode if possible, and them reboot immediately. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611211608.LAA19976>