Date: Thu, 5 Jan 1995 03:00:17 -0500 (EST) From: Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu> To: sneits@hit.fi (Osku Sneits) Cc: freebsd-hackers@freebsd.org Subject: Re: No RARP for FreeBSD yet?? Message-ID: <199501050800.DAA01184@skynet.ctr.columbia.edu> In-Reply-To: <199501042156.XAA18961@hit.fi> from "Osku Sneits" at Jan 4, 95 11:56:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501050800.DAA01184>