From owner-freebsd-hackers Thu Jan 5 00:03:06 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA27966 for hackers-outgoing; Thu, 5 Jan 1995 00:03:06 -0800 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA27959 for ; Thu, 5 Jan 1995 00:03:00 -0800 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id DAA01184; Thu, 5 Jan 1995 03:00:20 -0500 From: Wankle Rotary Engine Message-Id: <199501050800.DAA01184@skynet.ctr.columbia.edu> Subject: Re: No RARP for FreeBSD yet?? To: sneits@hit.fi (Osku Sneits) Date: Thu, 5 Jan 1995 03:00:17 -0500 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199501042156.XAA18961@hit.fi> from "Osku Sneits" at Jan 4, 95 11:56:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 7700 Sender: hackers-owner@freebsd.org Precedence: bulk They say this Osku Sneits person was kidding when he wrote: > > I am just wondering if anyone of those skillful hackers out there > would be kind enough to do a working rarp or rarpd for FreeBSD? > I've got access to some sun3's and would love to boot them off > of a FreeBSD with xkernel or such which requires rarp. > > Would be a *shame* to install a netbsd just for that, wouldn't it? :) > > If you have information on this, please reply directly as > I'm not in the list. > > Thank you. > It seems to me that rarpd alone is not enough to boot a diskless SunOS client: you also need rpc.bootparamd. (I know that FreeBSD has bootpd, but I don't think it has bootparamd.) Oddly enough, even though I recently obtained a copy of InfoMagic's BSDisc (with FreeBSD 2.0 and NetBSD 1.0), it never occurred to me to look through the NetBSD sources to see if they had a bootparam daemon. If NetBSD has both of these, then I might take a stab at porting them once I'm through with the NIS server junk. (Hopefully the NetBSD people won't mind.) Speaking of NIS, it's time for another update. Stuff I've done: - Cleaned up a few more GDBM -> DB teething problems in ypserv -- maps that contain YP_MASTER_NAME and YP_LAST_MODIFIED as their last elements would confuse the read_database() function. (Noticed this while trying to read a dummy ypservers map, which had only one real entry. :) Fixed with some more rigorous sanity checks. - Finished/tested ypserv's ypxfr functionality: successfully yppushed maps from a SunOS server. Made sure that ypxfr requests originating from non-privileged ports are refused. - Tested yppush: tried to push maps to myself, which worked, but which also led to the following two points: - Rpcgen'ed new YP stub files for ypxfr and yppush because the existing ones were hopelessly mangled. (Would it be 'Linux impaired' or 'FreeBSD challenged?' :) - Stripped down the newly-generated yp_xdr.c to avoid conflicts with YP XDR funxtions already in libc. This problem didn't show up when linking ypxfr and yppush dynamically, but when I tried to make static binaries as a test, I got all sorts of 'multiply-defined symbol' errors. (Not to mention many inexplicable core dumps.) - Modified /usr/src/libc/gen/getpwent.c to use master.passwd.byname and master.passwd.byuid maps if they can be found. I could find no quick and easy way to dynamically verify the existence of the 'shadow' maps other than to try a yp_first() on one of them. If the current user is superuser (geteuid() != 0), we try to retrieve the first element from the master.passwd.byname map. If this fails, we assume the master maps are not available and default back to the standard passwd maps. I'm not all that thrilled with the results: for normal users, things are just as fast as they always were, but the superuser winds up having to do two YP lookups for each getpw*() request. For certain programs (like finger) that do stupid things such as: while(pw = getpwnam()) {}, this causes a noticeable slowdown. (This is with a passwd map containing about 300 entries being served from a SunOS machine). If anyone can think of a better, *faster*, way, I'm open to suggestions. The reason for the superuser status check is this: I've set up ypserv to refuse to serve the master.passwd maps to any client that does not issue a request on a privileged port. Since only the superuser is supposed to be able to issue such a request, there is no point in going through the whole yp_first() nonsense for non-root users. All this was done to permit optimum interoperability between FreeBSD and other NIS servers/clients. You should be able to run: o A FreeBSD server with generic YP clients o FreeBSD clients with a generic YP server o only FreeBSD clients with FreeBSD servers o a little of each There is one caveat: if you run a FreeBSD NIS server with both FreeBSD and generic clients, you have to maintain an insecure copy of the passwd maps (i.e. a version with actual encrypted passwords instead of dummy fields) even though the FreeBSD clients don't need them, since you probably won't be able to get the generic clients to understand FreeBSD's 'secure' master.passwd maps, unless you're lucky enough to have source. - Also added a _masterpw_breakout_yp() function to getpwent.c to properly decode the contents of the master.passwd maps. - Hacked the crap out of yppasswdd in the following ways: o An alternate set of password files can be specified on the command line as follows: # yppasswdd -m /alternate/master.passwd -o /alternate/passwd By default, yppasswdd will operate on the standard password databases in /etc. This may be desireable in some cases, or it may not. If you do tell it to operate on the files in /etc, yppasswdd will run pwd_mkdb to rebuild the databases. I currently have a seperate copy of passwd and master.passwd stored in /var/yp. You can put them anywhere you like so long as you tell yppasswdd where they are and edit /var/yp/Makefile accordingly. o Added a -u (unsecure) flag which, if you are using an alternate set of password files, will cause actual encrypted passwords to be stored in the alternate passwd file, and the passwd.byname and passwd.byuid maps. (The default behavior is to put an '*' in the password field of the passwd file and its maps.) This flag is provided in the event that you need to use your FreeBSD system to serve a SunOS or similarly brain-damaged NIS client, since such clients won't be able to use the 'shadow' maps. If you are not using alternate passwd files, -u does nothing. o Added -f and -s flags to disallow changing of the 'full name' and 'gecos' fields, respectively. (These were originally compile-time options.) - Edited /var/yp/Makefile to generate a ypservers map for use with yppush. - Edited /var/yp/Makefile to run /usr/libexec/yppush after rebuilding the maps. - Re-organized the heirarchy a little: /usr/bin/yppush <- should this go in /usr/sbin instead? /usr/sbin/ypserv /usr/sbin/yp_mkdb /usr/libexec/ypxfr /usr/libexec/yppasswdd /usr/lib/pwupdate (shell script) /usr/bin/yppasswd /usr/bin/ypchfn (link to yppasswd) /usr/bin/ypchsh (link to yppasswd) /var/yp/Makefile /var/yp/master.passwd Stuff I still have to do: - Integrate /usr/bin/yppasswd with /usr/bin/passwd, as per Garrett Wollman's suggestion. This is tricker than it sounds, because it also implies that I should integrate ypchfn and ypshsh (which are links to yppasswd) with chpass. I've decided I'm not going to do that though. I will make merge yppasswd with passwd, but ypchfn and ypchsh will have to remain as links (to passwd). Someone else can make a 'ypchpass' if they want: I've had more than enough fun already. :) Yes, that's right folks: just one more item left on the 'to do' list. With luck, it'll only be another day or so before I'm ready to hand over the code for inspection, assuming trivial things like my job don't intrude. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul System Manager wpaul@ctr.columbia.edu Center for Telecommunications Research (212) 854-6020 Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~