Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!classic.iinet.com.au!news.uoregon.edu!news.dacom.co.kr!news.kreonet.re.kr!usenet.kornet.nm.kr!ames!lll-winken.llnl.gov!sol.ctr.columbia.edu!universe.ctr.columbia.edu!wpaul From: wpaul@ctr.columbia.edu (Bill Paul) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: npasswd Date: 13 Sep 1995 04:34:47 GMT Organization: Columbia University Center for Telecommunications Research Lines: 166 Message-ID: <435n17$gk5@sol.ctr.columbia.edu> References: <42d72u$ktg@ussenterprise.ufp.org> <42f6td$7r7@sol.ctr.columbia.edu> <42jpk7$djo@buffnet2.buffnet.net> <42loj9$cv7@sol.ctr.columbia.edu> <434scs$3rt@buffnet2.buffnet.net> NNTP-Posting-Host: universe.ctr.columbia.edu X-Newsreader: TIN [version 1.2 PL2] Daring to challenge the will of the almighty Leviam00se, steve hovey (shovey@buffnet.net) had the courage to say: : Bill Paul (wpaul@ctr.columbia.edu) wrote: : : Daring to challenge the will of the almighty Leviam00se, : : Superuser (root@buffnet.net) had the courage to say: : : : [deletia] : [deletia] [deletia] :) : : No, you can't use passwd on the master to do it. Yet. The default NIS : : configuration assumes that you will have a seperate master.passwd file : : as the source for your NIS passwd maps, which means I'd have to hack : : passwd to know to use the alternate file and run /usr/libexec/yppwupdate : : when it was finished. Unfortunately, I may not have time to implement : Im still not 100% on this. So you're saying one has more than the : regular master.passwd on the server? I thought it used the primary's : regular passwd and master.passwd - in which case you would think you : would update it there, and the rest would see it. : Im confused out. While you can very easily set up the NIS master to use the /etc/master.passwd file as the template for the NIS master.passwd and passwd maps, it's not set up this way by default because that's not always such a good idea. You may want the NIS master to be a secure machine, which is to say that only admins would have access it. You also might not want it to be an NIS client. In that event, you probably wouldn't want to use /etc/master.passwd as the template for the NIS maps since that would force you to put user all your user records in the main password database for the master, which would give all NIS users automatic login access to the master server. The default template for the NIS password maps is /var/yp/master.passwd. This file in in exactly the same format as /etc/master.passwd; it's just stored in a seperate location. You can move it somewhere else if you want: all you need to do is tell yppasswdd where it is and set the paths correctly in /var/yp/Makefile. [more deletia] : The question is due to being gun shy - under SCO if you maintain a shadow : file, and you have more than 30 or so users, and a user changes their : password, no one can log in anyplace for up to 10 minutes while the boxes : sync themselves - any more than 50 users and you end up with chewed and : corrupted /etc/passwd and /etc/shadow. The worse grinding is on the master. Hmmm... It doesn't generally take very long for FreeBSD to do a proper map update. The worst case is if you're using a homogenous FreeBSD network (all FreeBSD clients and servers) and you're using the master.passwd maps for shadowing: /var/yp/master.passwd is processed by an awk script to create /var/yp/passwd (which, like /etc/passwd, has no real password data in it), and both these files are then pumped into yp_mkdb to make the actual map databases. Lastly, the netid.byname map is created. This is actually a little less work than a standard local password database update because the local databases (/etc/spwd.db and /etc/pwd.db) contain _three_ copies of the original master.passwd data: one set is keyed by username, the second by uid and the third is keyed by the record's original line number in the master.passwd file. With large user databases, that can add up to a lot of work. However, bear in mind that the amount of time needed to fully propagate the password change shouldn't have hardly any effect on whether or not people can log in. The new maps aren't copied into place until they're completely ready, which means that ypserv will still answer queries while the updates are taking place. There is a very brief moment when the master.passwd and passwd maps will be unavailable to the server which occurs when the old files are removed and the new ones are renamed to take their place, but this shouldn't last more than a second or two at best. (Unlike the SunOS ypserv, the FreeBSD ypserv doesn't hold the databases open for long periods of time, which means that it starts using the new maps as soon as they're available rather than waiting for a YPPROC_CLEAR call to come along and prod it into closing all its old file descriptors and re-opening the maps.) Anyway, with a reasonably fast machine (Pentium with 8 megs of RAM, 16 megs if it's busy doing other things) it would probably take 2 or maybe 3 minutes to fully regenerate the maps and then yppush them to the slaves. This number may increase depending on the number of slaves (more than 6 or 7 may slow things down a bit). The auto-generation of the stock passwd maps from master.passwd template is really quite straightforward. The netid map is also generated with an awk script. : Can you tell I really love SCO? Well I dont! But I dont want to port : everything only to find a worse mess... I've never had the displeasure of using SCO... I like to think FreeBSD's NIS support is reasonably solid, but then I'm the only guy currently working on the NIS stuff so my view could easily be biased (or even downright wrong :). There are lots of things I'd still like to do, but lack of free time makes it tough. (There are other problems too, most notably copyright restirctions and code export restrictions: one of the things I'd _love_ to do is implement yp_update() and ypupdated, but a) the ypupdate protocol definition isn't part of the freely available RPC distribution from Sun (you can find ypupdate.x on any SunOS machine, but I'm not sure you're allowed to just copy it from there and distribute it), and b) ypupdate requires Secure RPC, which FreeBSD doesn't have. I've actually gotten secure RPC to work in FreeBSD, but it requires libdes, which isn't exporatable, plus the keyserv program needs libmp, which wasn't included in 4.4BSD-Lite due to the possibility that it might be tainted by AT&T code. I made it work using the GNU mp library, but I don't want to import yet another piece of GPL'ed software into the tree if I can avoid it. Foo.) (Secure RPC would also be nice for improving the security of the NIS shadow password system.) : Im really confused on the master.passwd issue - because then how does one : make a new account? the same old adduser? or do you have to manually add : something to this mystery file.. One could continue to use the adduser script/program/whatever with just two differences: 1) Use /usr/var/yp/master.passwd as the template instead of /etc/master.passwd 2) Do "cd /var/yp; make" instead of pwd_mkdb to update the maps. Everything else is done automatically for you. Of course, Real Men (tm) always edit the password map template by hand. :) The question raised here though is what happens when the administrator wants to forcibly change the password for an existing user (perhaps because the user has forgotten his password and needs to have it reset). The way things are now, the only way to do it, _if_ you're using a seperate /var/yp/master.passwd file, is to edit the master.passwd file manually and then rebuild the maps. You could just remove the password entirely and then, once the maps are rebuilt, use the passwd command to set a new password (just hit ENTER at the Old Password: prompt). If you choose to use /etc/master.passwd as your template, then things are slightly easier: the administrator can just use the passwd program on the NIS master to directly set a new password, and then do "cd /var/yp; make" to update the NIS maps. (Note that if you do use /etc/master.passwd as your map template, yppasswdd will be smart enough to do a pwd_mkdb for you on the master server so that both the master's local password database _and_ the NIS maps will be updated simultaneously.) I _will_ fix things so that the administrator can force a user's NIS password from the master (I'll also make chpass work the same way). I'm just not sure when. : I feel dumb today... I know that feeling well. Hopefully this will alleviate some of the confusion. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~ "Welcome to All Things BSDish! If it's not BSDish, it's crap!" ~~~~~~~