
	KNFSD

	This is an alpha snapshot of my kernel nfsd implementation.
	It lets you run several servers in parallel, has better
	protection against file handle guessing, a request reply cache,
	and will soon have other nifty features such as more
	authentication types like kerberos or des, etc. pp.

	Note that this software is not complete yet. Not all of the
	features you know from the user space daemon work already,
	although some have been partly implemented already.


	DOCUMENTATION

	There is none; this is a hacker release. I'll write the manpages
	later.


	TESTING

	Disclaimer: I do not guarantee that your hard disk or any other
	data survive these experiments. They usually do for me, but
	I don't want you to sue me because a kernel crash wiped out your
	PhD thesis. BACK UP YOUR DATA FIRST!

	To test knfsd, you first have to apply the kernel patch in the
	toplevel directory. It's fairly straightforward, so you
	shouldn't have any problems integrating it into a later release.
	You then have to compile the package, and do the following:

	mkdir -p /var/lib/nfs
	touch /var/lib/nfs/xtab
	touch /etc/nfskeys
	insmod kernel/nfsd.o
	mountd/mountd
	nfsd/nfsd 8

	You should then be able to mount directories off the Linux box
	as specified in your exports file. If you remove and re-insert the
	nfsd module, you have to re-install the previously exported
	directories. You do this by calling

	exportfs/exportfs -a

	If you want to test the new file handle signature scheme, you
	have to create keys for the client hosts first using the
	nfsgenkey utility. For instance, to create an MD5 key, you would
	invoke it like this:

	nfsgenkey -vah foo.bar.com -t md5

	This utility is quite slow when you don't have /dev/random installed.
	You should therefore create the random devices using these commands:

	mknod /dev/random  c 1 8
	mknod /dev/urandom c 1 9


	KNOWN BUGS

	Many, for sure. Create calls do not work properly from certain
	clients; I still have to find out why. The new nfssock code may
	still be flakey at times; I haven't scrutinized it yet, but I
	believe it will occasionally ignore packets that are in its
	receive queue. This is not really a problem, because the next
	packet arriving will kick the receiver again.


	BUG REPORTS

	If you find a bug with nfsd, please mail me at okir@monad.swb.de.
	Unless this is one of the hard-to-find bugs that appear only once
	in a while, you should include a packet trace of the NFS calls that
	go wrong, if possible with the last 40 or 50 operations that
	preceded the one failing. Different OSs use different methods
	when talking to an NFS server, so while some may work, others may
	not. I need to know exactly what NFS calls failed; the plain fact
	that your tar command dumps core does not help much :-)

	For instance, to watch all NFS traffic to your linux box, you can
	use something like this:

	tcpdump -vvpttNli eth0 host linuxbox and port 2049

	[yes, the manpage says the p flag turns off promisc mode. All linux
	ports of tcpdump I've seen do it exactly the other way round, however.]


	COPYRIGHT

	knfsd is copyright by Olaf Kirch, okir@monad.swb.de, except for
	the NFS reply cache code (adapted from 44BSD). All parts written
	by me are covered by the GNU General Public License (version 2
	or later, as you wish). The other parts are covered by their
	respective copying licenses.

	Olaf Kirch, Feb 14, 1996
