Date: Wed, 3 Jul 1996 21:25:22 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: mikebo@tellabs.com Cc: bugs@freebsd.org Subject: Re: 2.1-960627-SNAP: YP problem Message-ID: <199607040125.VAA03325@skynet.ctr.columbia.edu> In-Reply-To: <199607032025.PAA13743@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 3, 96 03:25:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the world, mikebo@tellabs.com had to walk
into mine and say:
> Previously, I wrote:
> > I believe a bug has been introduced into the 2.1-960627-SNAP YP code.
> > Previously, I had been able to use NIS netgroups in the password file:
> > +@mygroup:::::::::
> >
> 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.
See if you can do 'id <some NIS user>' and have it recognise the
user in the NIS passwd map. If this works, then it is reading the
passwd map correctly.
> > The FreeBSD client is bound to a SunOS 4.1.x server. When I attempt to
> > login, FreeBSD attempts :
> > NIS: ----- Network Information Service -----
> > NIS: Proc = 4 (Return first key-value pair in map)
> > NIS: Domain = mydomain
> > NIS: Map = master.passwd.byname
> >
> > Of course, my Sun NIS domain has no such map "master.passwd.byname",
> > and that's the end of that.
Yes, I know. The FreeBSD client is checking for the presence of the
master.passwd.by{name,uid} maps. If it doesn't find them, it rolls
over to the passwd.by{name,uid} maps.
In other words, the behavior you are seeing is normal.
> > The FreeBSD client goes on to try and get
> > the passwd.byname entry for my login, which succeeds. Nevertheless,
> > the login is refused. Here is a high-level packet trace:
> >
> > 1 0.00000 toybox -> sunc NIS C FIRST
> > 2 0.01581 sunc -> toybox NIS R FIRST No such map
> > 3 0.00321 toybox -> sunc NIS C MATCH mikebo in passwd.byname
> > 4 0.01115 sunc -> toybox NIS R MATCH OK
> >
> > If I take the SunOS map entry from my account, and massage it to fit
> > the format of the FreeBSD vipw, I am able to login just fine. This means
> > that the password encryption and comparison is working. (Yes, DES is
> > installed and working).
> >
> Let me rephrase my closing comments. I really need NIS password file
> support to work.
So do I. I hate it I tear my hair out working on code and just when
I think I have it working exactly right, somebody finds a new set of
conditions that I never thought to test for which breaks the whole mess.
> Is anyone else seeing this problem? Is there anything
> I should check out that might be incorrectly configured? Is anyone else
> successfully using NIS password entries when bound to a SunOS server?
Yes, I am. The getpwent.c module in the 2.1 SNAP and 2.1-stable tree is
idendical to the one in -current, and I've been using -current without
any problems using both a SunOS NIS server and the FreeBSD NIS server.
What I would do is try to test the getpwent(3) routines by writing
a small C program that calls getpwnam(). Here's an example:
1) Copy the src/lib/libc/gen/getpwent.c source file from the SNAP
release you're using to a work directory.
2) Create a small C program (pwtest.c) like this:
#include <stdio.h>
#include <pwd.h>
main()
{
struct passwd *pw;
pw = getpwnam(argv[1]);
printf("Username is: [%s]\n", pw->pw_name);
printf("UID is: [%lu]\n", pw->pw_uid);
printf("Password is: [%s]\n", pw->pw_passwd);
exit(0);
}
3) Compile the program like this:
% cc -g -c pwtest.c
% cc -g -c -DYP getpwent.c
% cc -o pwtest pwtest.o getpwent.o
4) Run the program like this:
$ pwtest nisuser
where 'nisuser' is the username of a user that appears in the NIS
passwd maps.
(Try it with the +@myuser:::::::: entry too, just for kicks.)
Check the output from this program and see if it makes sense. Print out
all the fields if you want. Chances are that whatever the problem is will
make itself evident when you see the output. If you see bogus output
but you can't explain it, try stepping through the program with gdb.
Since you have compiled the program with debugging, you'll be able to
step through the getpwent(3) module and hopefully you'll be able to
spot the problem.
If you see bogus output but you still can't explain it even with the
debugger, show us the output. Try to keep it as close to the original
output as possible (some people don't want to e-mail their passwd
database info to open mailing lists, but often when people make up
replacement sample results they fail to preserve the glitch closely
enough to allow proper debugging).
If the output looks exactly correct, then expand the program to
include a call to crypt(3) and compare the results with the encrypted
password show in the pw_passwd field.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
License error: The license for this .sig file has expired. You must obtain
a new license key before any more witty phrases will appear in this space.
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607040125.VAA03325>