Date: Mon, 8 Jul 1996 21:54:00 -0500 (CDT) From: mikebo@tellabs.com To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: mikebo (Mike Borowiec), bugs@freebsd.org Subject: Re: 2.1-960627-SNAP: YP problem Message-ID: <199607090254.VAA21062@sunc210.tellabs.com> In-Reply-To: <199607082310.TAA17851@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 8, 96 07:10:45 pm
index | next in thread | previous in thread | raw e-mail
Bill -
You wrote:
> > > Of all the gin joints in all the world, mikebo@tellabs.com had to walk
> > > into mine and say:
> > > > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code.
> > > > As it turns out, netgroups have nothing to do with this problem. It is
> > > > a problem with any YP password entries from my Sun server... I've added
> > > > +::::::::: when editing the password file (with vipw), but NONE of the
> > > > users in the NIS password map can login.
> > >
> Note that I installed the SNAP completely from scratch - I did _not_
> do an upgrade. (This may have something to do with it - read on.)
>
I did an install from scratch.
toybox> uname -sr
FreeBSD 2.1-960627-SNAP
toybox> ypwhich
sunc.lisle.tellabs.com
toybox> id mikebo
id: mikebo: No such user
toybox> id
uid=1874 euid=0(root) gid=10(staff) groups=10(staff), 0(wheel), 14(train), 381(netis), 2(kmem), 4(tty), 237(ecfreq), 111(slip), 380(isstaff), 23(tools), 3(sys), 22(tellab5)
toybox> ypmatch mikebo passwd.byname
mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh
toybox> ypmatch 1874 passwd.byuid
mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh
> Check that you exist correctly in both the passwd.byname and passwd.byuid
> maps. Check also that both of these maps has valid data in them. (By valid
> I mean with the correct number of fields and such.)
>
Looks good to me...
> For reference, my /etc/master.passwd looks like this (I don't mind
> showing you the encrypted passwords -- they'll be changed shortly :) :
>
> marple# cat /etc/master.passwd
> root:KBO1w243/.2XA:0:0::0:0:Charlie &:/root:/bin/csh
> toor:*:0:0::0:0:Bourne-again Superuser:/root:
> daemon:*:1:31::0:0:Owner of many system processes:/root:
> operator:jNfGj.GU4RB6g:2:20::0:0:System &:/usr/guest/operator:/bin/csh
> bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent
> games:*:7:13::0:0:Games pseudo-user:/usr/games:
> news:*:8:8::0:0:News Subsystem:/:/nonexistent
> man:*:9:9::0:0:Mister Man Pages:/usr/share/man:
> uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
> xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent
> nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent
> +@marple-users:::::::::
> +@super-people:::::::::
> +@SUG-people::32767:32767::::::/usr/local/etc/auth
> +@Snet-people::32767:32767::::::/usr/local/etc/auth
> +@acorn-people::32767:32767::::::/usr/local/etc/auth
> +@ctrnet-people::32767:32767::::::/usr/local/etc/auth
> +@image-people::32767:32767::::::/usr/local/etc/auth
> +@tnl-people::32767:32767::::::/usr/local/etc/auth
> +@sgi-people::32767:32767::::::/usr/local/etc/auth
> +@deleted1-people::32767:32767::::::/usr/local/etc/disabled
> +@deleted2-people::32767:32767::::::/usr/local/etc/disabled
>
toybox> cat /etc/master.passwd
root:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/csh
kroot:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/ksh
toor:*:0:0::0:0:Bourne-again Superuser:/root:
daemon:*:1:31::0:0:Owner of many system processes:/root:
operator:*:2:20::0:0:System &:/usr/guest/operator:/bin/csh
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent
games:*:7:13::0:0:Games pseudo-user:/usr/games:
news:*:8:8::0:0:News Subsystem:/:/nonexistent
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent
+:::::::::
> Okay, things to check:
>
> 1) Are you running kerberos? (probably not, but it's worth a shot. :)
NO. (Yuck ;v)
> 2) Did you upgrade to the SNAP by installing it fresh, or did you 'upgrade'
> by installing over a previous version?
Fresh. New filesystems and all...
> 2a) If you 'upgraded,' did you make sure you have only one version of
> libc.so.whatever in /usr/lib?
N/A.
> 3) Are you _SURE_ that you don't have an entry in your /etc/master.passwd
> file that says +::0:0::::::? Maybe one you missed?
No... see above.
> 4) Are you _SURE_ they you ran pwd_mkdb after you edited
> /etc/master.passwd?
I never edited /etc/master.passwd. I only used vipw which is supposed to do
this for me. For grins, I tried it. No difference...
> 5) Did you re-run ldconfig after you installed the DES package? (Rebooting
> accomplishes the same thing -- if you've rebooted the machine since the
> DES package went in, the answer is 'yes.')
I've reboot several times.
> 6) If you do 'ldd /usr/bin/login' does it show it to be linking against
> the correct version of libc.so.whatever?
>
> For reference, this is what it says for me:
>
> marple# ldd /usr/bin/login
> /usr/bin/login:
> -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000)
> -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000)
> -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000)
> -lc.2 => /usr/lib/libc.so.2.2 (0x8047000)
>
toybox> ldd /usr/bin/login
/usr/bin/login:
-lutil.2 => /usr/lib/libutil.so.2.1 (0x801e000)
-lskey.2 => /usr/lib/libskey.so.2.0 (0x802d000)
-lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8033000)
-lc.2 => /usr/lib/libc.so.2.2 (0x8048000)
This doesn't look right... but the program I built earlier looks OK.
See below... why wouldn't the numbers match?
> 6a) Also do an 'ldd test_program_you_built_earlier' and compare the
> output with 'ldd /usr/bin/login'.
toybox> ldd /home/sunc210/mikebo/tmp/pwtest
/home/sunc210/mikebo/tmp/pwtest:
-lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000)
-lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000)
-lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000)
-ldes.2 => /usr/lib/libdes.so.2.1 (0x8047000)
-lc.2 => /usr/lib/libc.so.2.2 (0x8053000)
> 7) Did you check /var/log/messages for suspicious messages resulting
> from the failed login attempts?
Yes, there were no suspicious messages.
> 8) If you log in as root, can you do 'su mikebo?'
su: no such login: mikebo
> 8a) If so, if you then type 'whoami' does it say 'mikebo?'
N/A.
>
> > Looks like NIS is working fine, and some programs/libraries are simply
> > ignoring the fact that there are valid YP tokens in the passwd files.
>
> Well, all the references are either within libc, or inside a small number
> of statically linked programs (e.g. those in /bin). I'm beginning to
> suspect a libc mismatch of some kind. These are the C libraries I have
> on my system:
>
> marple# ls -l /usr/lib/libc.*
> -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a
> -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2
>
toybox> ls -l /usr/lib/libc.*
-r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a
-r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1
-r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0
-r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2
Now how did this happen? I installed via FTP from the default
server listed in the install dialogue.
toybox> cksum /usr/lib/libc.so.2.2
3292964480 435248 /usr/lib/libc.so.2.2
> (Note that I don't have the profiled libraries installed. This shouldn't
> make any difference.)
>
> My libcrypt setup looks like this (sorry for the long lines):
>
> marple# ls -l /usr/lib/*crypt*
> lrwxr-xr-x 1 bin bin 13 Jul 5 14:07 /usr/lib/libcrypt.a -> libdescrypt.a
> lrwxr-xr-x 1 bin bin 18 Jul 5 14:07 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0
> lrwxr-xr-x 1 bin bin 15 Jul 5 14:07 /usr/lib/libcrypt_p.a -> libdescrypt_p.a
> -r--r--r-- 1 bin bin 10690 Jun 28 04:47 /usr/lib/libdescrypt.a
> -r--r--r-- 1 bin bin 18145 Jun 28 04:47 /usr/lib/libdescrypt.so.2.0
> -r--r--r-- 1 bin bin 12362 Jun 28 04:47 /usr/lib/libdescrypt_p.a
> -r--r--r-- 1 bin bin 4576 Jun 28 04:47 /usr/lib/libscrypt.a
> -r--r--r-- 1 bin bin 12755 Jun 28 04:47 /usr/lib/libscrypt.so.2.0
>
toybox> ls -l /usr/lib/*crypt*
lrwxr-xr-x 1 bin bin 13 Jul 3 12:51 /usr/lib/libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 bin bin 18 Jul 3 12:51 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 bin bin 15 Jul 3 12:51 /usr/lib/libcrypt_p.a -> libdescrypt_p.a
-r--r--r-- 1 bin bin 10690 Jun 28 03:47 /usr/lib/libdescrypt.a
-r--r--r-- 1 bin bin 18145 Jun 28 03:47 /usr/lib/libdescrypt.so.2.0
-r--r--r-- 1 bin bin 12362 Jun 28 03:47 /usr/lib/libdescrypt_p.a
-r--r--r-- 1 bin bin 4576 Jun 28 03:47 /usr/lib/libscrypt.a
-r--r--r-- 1 bin bin 12755 Jun 28 03:47 /usr/lib/libscrypt.so.2.0
-r--r--r-- 1 bin bin 5080 Jun 28 03:47 /usr/lib/libscrypt_p.a
> > The DES package was installed at the same time as the install, and all
> > appeared to complete flawlessly. The login program:
> > toybox> ls -l /usr/bin/login
> > -r-sr-xr-x 1 root bin 20480 Jun 28 03:59 /usr/bin/login
> > toybox> cksum /usr/bin/login
> > 957853657 20480 /usr/bin/login
> >
> > I appreciate all the help. What next?
>
> This depends on whether you did a complete reinstall or an upgrade.
I did a complete install, including newfs of both / and /usr.
> The reason I'm curious is this: I did change the getpwent(3) code in
> libc rather substantially between the June 27th SNAP and the previous
> one. Actually, what I did was sync the 2.1-STABLE version with the
> 2.2-current version, which had survived for several weeks in the
> -current tree without any trouble (no angry mobs came calling for my
> head), so I moved it over. The newer version is a bit less messy than
> the previous one and fixes some bugs. Also, /usr/include/pwd.h and
> /usr/sbin/pwd_mkdb changed a little since they and getpwent(3)
> are intimately related.
>
toybox> ls -l /usr/include/pwd.h /usr/sbin/pwd_mkdb
-r--r--r-- 1 bin bin 4118 Jun 28 03:44 /usr/include/pwd.h
-r-xr-xr-x 1 bin bin 12288 Jun 28 04:04 /usr/sbin/pwd_mkdb
> The result is that if you somehow managed to keep an older version of
> libc.so around (like from the previous SNAP) you might have conflicts since
> the older getpwent(3) NIS code is not strictly forward compatible (the
> new version is backward compatible though). Basically, if you use the
> new pwd_mkdb to create a hash user database with NIS entries, the old
> getpwent(3) will not be able to grok it properly. This sounds a lot like
> what's happening here.
>
Indeed... again, I installed from scratch via FTP using the default
server in the install dialogue. I can't remember the hostname, but I
assume it's ftp.freebsd.org. Note that I do appear to have an older
libc.so.2.2. Perhaps the install program screwed me up - but how?
Thanks again for spending so much time.
Regards,
- Mike
--
--------------------------------------------------------------------------
Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc.
Senior Member of Technical Staff 4951 Indiana Avenue, MS 63
708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA
--------------------------------------------------------------------------
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607090254.VAA21062>