Date: Mon, 21 Apr 1997 23:33:42 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: yves@CC.McGill.CA Cc: hackers@freebsd.org, abelits@phobos.illtel.denver.co.us, vinay@agni.nuko.com Subject: Re: Need a common passwd file among machines Message-ID: <199704220333.XAA27745@skynet.ctr.columbia.edu> In-Reply-To: <199704211328.JAA07167@maelstrom.cc.mcgill.ca> from "Yves Lepage" at Apr 21, 97 09:28:51 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, Yves Lepage had to walk into mine and say: > > Hello, > > > P.S. Is there any existing thing or at least an idea of making one that > > does this thing nicer? NIS is based on rather dumb idea that to > > authenticate local user one will want to go to some server and ask him > > instead of IMHO more sane approach of distributing authentication > > information from that server to always perform authentication locally and > > never depend on some host being accessible at the time of user's login. > > Well, you're supposed to depend on a group of hosts rather than just one. But by sending all the authentication information to each host that needs it, you're defeating the purpose of NIS, which is to avoid having multiple copies of the same information all over the place. > In surface this is right. However, NIS does database lookups instead of sequential > file access (non-FreeBSD systems) and that's one of the better reasons of existence > of NIS. With a few thousands of users, sequential search becomes rather heavy. Unfortunately, some programs insist on doing using a getpwent() loop to enumerate the passwd database. In order to simulate the behavior of a local file lookup, getpwent() will make calls to yp_first() and yp_next(), with each call reading back one entry at a time. This translates to one NIS request at a time, which is actually very wasteful: a typical passwd record is maybe about 50 bytes or so, but now you have to construct an RPC query, stuff it into a UDP datagram, wait for the server to get it, decode it, validate the request arguments, check your access rights, do the lookup, encode the answer, send the reply in a UDP datagram, then the client decodes the response and hands it to the caller. If you have a passwd database with 30K entries, you'll find that it takes _much_ less time to do 'ypcat passwd' that it does to dump out the the maps with yp_first()/yp_next(). This is because ypcat uses yp_all(), which opens a single TCP pipe to the server and sucks the entire map over as a single RPC (note that this involves writing a custom XDR filter to unpack the records as they arrive, along with a similar custom filter in ypserv to to encode them; this requires the use of a callback in yp_all(), and is sufficiently complicated that some naive NIS implementations have a yp_all() that is really a wrapper around yp_first()/yp_next()). You might ask why yp_all() isn't used for getpwent() instead of yp_first() and yp_next(). There are a couple of reasons. For one, each instance of yp_all() uses a seperate socket descriptor both on the client and server. This socket remains open until the query ends, either because the end of the table was reached or because yp_all() was aborted. For another, since yp_all() is basically just one big RPC call, you have to play games inside the XDR filter to unpack each entry, and the XDR filter is called from inside the RPC library; this makes it very hard to use it as a one-off function that just reads one record and returns. I did it once for giggles, but I had to use setjmp()/longjmp() to do it. And if the caller reads a few records from getpwent() and then forgets about it, the socket to the server stays open until the client process exits, or the server decides the connection has been idle too long and times it out; adding code to delect the idle condition makes the server more complicated and slows it down. > IMO, NIS is fine, given you have reliable networks and reliable servers and at > least one slave. What I don't like about NIS is that in 1997, it still doesn't allow > for atomic modifications of the database (add one user, etc...). True, you can't do this with NIS, but you can do it with NIS+. Unfortunately, while NIS+ fixes many of the problems with NIS, it brings with it a new problem which is that it is far more complicated. It's taken me several months just to learn how to use and administer NIS+, nevermind code it. -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 ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704220333.XAA27745>