Study of yp, ipfilter, and nfsd in a transitional state from 2.0to 2.1

[Josh Moyer <jmoyer@genesis.tiac.net>]

I apologize in advance for this quite lengthy narrative -- this has become
such a headache that I needed to vent my frustrations through story
telling. ;-)  There is also a brief summary at the very end for those who
aren't interested in my ... stories. ;-)

Our "story" begins about two months ago when I got a '040 NeXT cube.  It
would be my second functional UN*X machine, the first being a Mac IIci
that, at the time, was running OpenBSD 2.0.  I was giddy with the prospects
-- I had full administrative control over two UN*X hosts (my last employer,
a local ISP, and I had differing ideas on the "correct" way to administer
systems.)  Well, my first task was to get NFS working.  After many hours of
head banging I discovered the -n flag for rpc.mountd, and NFS was working
with the cube as the server.  Woo!  At that point I decided that I wanted
the IIci to be an NFS server also, but that required getting kernel sources
and recompiling.  At the time I was very short on disk space, so this
wasn't an option.

<in the next paragraph metally insert details about moving into a new
apartment somewhere between beginning the yp work and the conclusion that
ipfilter was needed, as well as a job search that was interrupted due to
some nasty RSI flare-ups> ;-)

The next task was to get yp running with the cube as the master and the
IIci as the client.  Well, I got the passwd map to sort of work.  The IIci
would get the entry from the cube and do one of two things: login would
core or su would give me a root shell.  Neither of these were acceptable
behaviours, of course.  Assuming this was related to differences in the way
that Mach and OpenBSD handled passwd entries, I decided to move on to
simpler maps, specifically the hosts maps.  Not much luck here, either.
From what the lights on my hub indicate, the rpc call was being made, and
perhaps even being returned.  Experimentation with ypcat and ypmatch
revealed that both yp client and server were working fine, however.  Things
were further complicated by the fact that the cube's ypbind refuses to work
if the IIci is running a slave ypserv.  More research into the effects of
running ypserv on the IIci is still needed.

As I was -- and I am still -- unable to get the cube to acknowledge the
existence of ypserv.log (which would likely just contain the number 42 in a
higly succesful attempt to frustrate me further), I decided to attempt to
capture and analyze the rpc calls as they were being made.  This brought my
attention to ipfilter, which in turn made me aware of ipnat (wow, NAT --
think of the possibilities).  Unable to get ipmon to work (more on this and
other ipfilter woes in a bit), I admitted partial defeat and started to
scour the web and the OpenBSD and NetBSD mailing list archives for clues.
Well, OpenBSD pr #232 looked promising: it told of an old ULTRIX server
that was having problems that sounded similar.

Hmm, it was beginning to look like time to upgrade the IIci to OpenBSD 2.1.
Nah, it would be Too Much Trouble (I had recently been dropped from two
T1's back to 28.8, as I had quit my job with the ISP, and just couldn't
bear the thought of downloading the 2.1 release -- I'm still recovering).

Becoming more and more disheveled by each yp lookup, I decided to focus my
attention on getting ipfilter working.  Unaware of the presence of
/usr/lkm/ipl.o, and knowing that the GENERIC config file for OpenBSD/mac68k
didn't have ipfilter defined (nor LKM, I think), I  decided to compile my
own kernel, which would have the added benfit of turning the IIci into an
nfs server.  I had obtained more storage space in the form of the overly
cool, albeit flakey, NeXT optical disks, so things looked like they might
be getting better Real Soon Now.  Not so. :-(  Encountering compiliation
problems in the 2.0 kernel sources too horrid to detail in such a family
oriented list as this, I decided to upgrade to the OS and the kernel
sources to 2.1.  Imagine my delight when I saw that one of the changes in
2.1 was the addition of the -insecure flag to ypbind!  Maybe things were
going to get better after all -- the 2.1 GENERIC kernel even had ipfilter
compiled in by default.  Cool.

The OS upgrade went okay.  While digging through the IIci's filesystem to
back up all the important stuff -- just in case -- I noticed
/usr/lkm/ipl.o.  Doh!  A few bumps while untarring the tarballs -- in the
form of tar/pax coring due to invalid system calls (if I remember
correctly) while trying to set the permissions on
./{dev/scan0,etc/termios,usr/include/{varargs.h,errno.h}} -- to name a few.
But I got around it by re-untaring the files after booting into 2.1
(besides, I met my newest command line friend, pax, because of it).  I've
yet to upgrade to etc21, however, as I'm assuming that it's not critical
(please let me know if that's not the case.)  The OS upgrade took place a
few days ago.

After the upgrade was completed, the first thing I tried was using the new
-insecure flag with ypbind.  Unfortunately, ypbind (and the man pages) are
unaware of the existence of this new flag.  Hmph.  Turning my attention to
ipfilter, I discovered that it wouldn't work either.  Just to be sure that
the 2.1 kernel's ipfilter support wasn't broken, I compiled my own kernels
with support for ipfilter as an LKM and as part of the kernel.  In either
case ipnat, upon being told to add some rules to the rule list responds with

	ioctl(SIOCADNAT): invalid argument

ipfstat resonds similarly:

	ioctl(SIOCGETFS): invalid argument

Bah.  To top all that off, nfsd also refuses to work, dumping its core and
complaining of an illegal instruction.  Oh well, at least I've now learned
of tcpdump.

In sum:

<SUMMARY>

I cannot get my NEXTSTEP 2.0 yp server and my OpenBSD 2.1 yp client to talk
to each other.  The bindings are in place, ypcat and ypmatch both work, and
there is network activity during the times when yp calls should be made.
passwd lookups sort of work, but that's complicated to explain.  I suspect
some sort of incompatibility that the yp library routines silently ignore.
I have had this problem since 2.0.

ipfilter doesn't work as either an LKM or as part of the kernel.  All calls
made to ipfilter by its userland utilities seem to fail on an invalid
argument to ioctl().  This problem also occurred with 2.0.

nfsd doesn't work.  Compiled a new kernel with it enabled; however, it
refuses to work, dumping its core and complaining of an illegal
instruction.  Although this problem did not arise until after the 2.1
upgrade, I suspect it would have occured with 2.0 as well. ;-)

</SUMMARY>

Please help.  I'm all burnt out on UN*X because of this; I put in less than
an hour on my UN*X machines over the course of the last three days.
Normally I put in at least 4 a day.  And I still have to write all those
PRs! <smacks hand on forehead>  Oh well.  Thanks in advance for any help
you all may be able to provide -- I'll really appreciate it!

--------------------------------------------------------------------------------
       mailto:jmoyer@cortland.com      |   Show your dogcow that you love it;
    http://genesis.tiac.net/jmoyer/    |     give it a can of Mountain Dew.
--------------------------------------------------------------------------------
       Geek Code Version: 3.1
       Last updated: a long time ago
       GU d--()>+ s>+: !a C++++(++)$ UB++$>++++ P>+++ !L- !E---> W++$
       N(++) o? K-? w(--)$>--- !O>++ M++(+)$ !V-- PS+(++)@ PE(--) Y+>++
       !PGP>++ t+@ !5+(-) X+ R>+* tv-(+) b+>+++ DI(++)>+++ !D--- G>++++
       e->++@* h--?>++! r@ y+(++)
--------------------------------------------------------------------------------