2 files changed, 1 insertions, 841 deletions

diff --git a/misc/Howto/distinfo b/misc/Howto/distinfo
index 01df16d6baf5..29dd7bf3c915 100644
--- a/misc/Howto/distinfo
+++ b/misc/Howto/distinfo
@@ -2,4 +2,4 @@ MD5 (Howto/Linux+FreeBSD.sgml.gz) = 6c24d994421b4c336f7f7621fd849858
 MD5 (Howto/DNS-HOWTO.sgml.gz) = 2a4377ecb427124f4526e22e4de5aeef
 MD5 (Howto/NFS-HOWTO.sgml.gz) = 1751237681f2ed74de520ff03f4556b4
 MD5 (Howto/NIS-HOWTO.sgml.gz) = 679a51559fc6f2b95a21b5fc25ac8ebb
-MD5 (Howto/Security-HOWTO.sgml.gz) = efb5b205dbf97a9d4005b2af818d0455
+MD5 (Howto/Security-HOWTO.sgml.gz) = 0530cc1d218790f21bf3bfe8640b51c4
diff --git a/misc/Howto/files/patch-nfs b/misc/Howto/files/patch-nfs
deleted file mode 100644
index 3c05f06ccd6a..000000000000
--- a/misc/Howto/files/patch-nfs
+++ /dev/null
@@ -1,840 +0,0 @@
---- NFS-HOWTO.sgml.orig	Thu Nov 18 06:51:14 1999
-+++ NFS-HOWTO.sgml	Thu Nov 18 06:52:16 1999
-@@ -79,7 +79,7 @@
- networking and the terms used.  If you don't recognize the terms you
- can either go back and check the networking HOWTO, wing it, or get a
- book about TCP/IP network administration to familiarize yourself with
--TCP/IP.  That's a good idea anyway if you're administrating UNIX/Linux
-+TCP/IP.  That's a good idea anyway if you're administrating UNIX
- machines.  A very good book on the subject is <em>TCP/IP Network
- Administration</em> by Craig Hunt, published by O'Reilly &amp;
- Associates, Inc.  And after you've read it and understood it you'll
-@@ -89,14 +89,6 @@
- <em/Mount Checklist/ and <em/FAQs/.  Please refer to them if something
- dosen't work as advertized.
- 
--<p>The home-site for the Linux 2.0 nfsd is <htmlurl
--name="ftp.mathematik.th-darmstadt.de:/pub/linux/okir"
--url="ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/">, in case
--you want/need to get it and compile it yourself.
--
--<p>For information about NFS under Linux 2.2 please see <ref
--id="linuxtwotwo" name="the Linux 2.2 section">.
--
- <sect>Setting up a NFS server<label id="nfs-server">
- 
- <sect1>Prerequisites
-@@ -116,7 +108,7 @@
- skip ahead to <ref id="nfs-client" name="the section on setting up a
- NFS client">
- 
--<p>If you need to set up a non-Linux box as server you will have to
-+<p>If you need to set up a non-FreeBSD box as server you will have to
- read the system manual(s) to discover how to enable NFS serving and
- export of file systems through NFS.  There is a separate section in
- this HOWTO on how to do it on many different systems.  After you have
-@@ -124,16 +116,13 @@
- HOWTO.  Or read more of this section since some of the things I will
- say are relevant no matter what kind of machine you use as server.
- 
--<p>If you're running please see <ref id="linuxtwotwo" name="the Linux
--2.2 section"> before you continue reading this.
--
- <p>Those of you still reading will need to set up a number of
- programs.
- 
- <sect1>The portmapper<label id="portmapper">
- 
--<p>The portmapper on Linux is called either <tt/portmap/ or
--<tt/rpc.portmap/.  The man page on my system says it is a "DARPA port
-+<p>The portmapper on FreeBSD is called <tt/portmap/.
-+The man page on my system says it is a "DARPA port
- to RPC program number mapper".  It is the first security hole you'll
- open reading this HOWTO.  Description of how to close one of the holes
- is in <ref id="nfs-security" name="the security section">.  Which I,
-@@ -149,14 +138,7 @@
- If there is a script called something like <tt/inet/ it's probably the
- right script to edit.  But, what to write or do is outside the scope
- of this HOWTO.  Start portmap, and check that it lives by running
--<tt/ps aux/ and then <tt/rpcinfo -p/.  It does?  Good.
--
--<p>Oh, one thing.  Remote access to your portmapper is regulated by
--the contents of your <tt>/etc/hosts.allow</tt> and
--<tt>/etc/hosts.deny</tt> files.  If <tt/rpcinfo -p/ fails, but your
--portmapper is running please examine these files.  See <ref
--id="nfs-security" name="the security section"> for details on these
--files.
-+<tt/ps aux/.  It does?  Good.
- 
- <sect1>Mountd and nfsd<label id="nfsd">
- 
-@@ -187,24 +169,23 @@
- use./ There is a separate section in this HOWTO about other Unixes
- <tt/exports/ files.
- 
--<p>Now we're set to start mountd (or maybe it's called <tt/rpc.mountd/
--and then nfsd (which could be called <tt/rpc.nfsd/).  They will both
-+<p>Now we're set to start mountd
-+and then nfsd.  They will both
- read the exports file.  
- 
- <p>If you edit <tt>/etc/exports</tt> you will have to make sure nfsd
- and mountd knows that the files have changed.  The traditonal way is
--to run <tt/exportfs/.  Many Linux distributions lack a exportfs
--program.  If you're exportfs-less you can install this script on your
-+to run <tt/exportfs/.  FreeBSD lacks a exportfs
-+program.  You can install this script on your
- machine:
- 
- <code>
- #!/bin/sh
--killall -HUP /usr/sbin/rpc.mountd
--killall -HUP /usr/sbin/rpc.nfsd
-+/bin/kill -HUP `/bin/cat /var/run/mountd.pid`
- echo re-exported file systems
- </code>
- 
--<p>Save it in, say, <tt>/usr/sbin/exportfs</tt>, and don't forget to
-+<p>Save it in, say, <tt>/usr/local/sbin/exportfs</tt>, and don't forget to
- <tt/chmod a+rx/ it.  Now, whenever you change your exports file, you
- run exportfs after, as root.
- 
-@@ -225,12 +206,8 @@
- mountd and nfsd.
- 
- <p>If you get <tt>rpcinfo: can't contact portmapper: RPC: Remote
--system error - Connection refused</tt>,
--<tt>RPC_PROG_NOT_REGISTERED</tt> or something similar instead then the
--portmapper isn't running.  OR you might have something in
--<tt>/etc/hosts.{allow,deny}</tt> that forbids the portmapper from
--answering, please see <ref id="nfs-security" name="the security
--section"> for details on these files.  If you get <tt>No remote
-+system error - Connection refused</tt> or something similar instead
-+then the portmapper isn't running.  Fix it.  If you get <tt>No remote
- programs registered.</tt> then either the portmapper doesn't want to
- talk to you, or something is broken.  Kill nfsd, mountd, and the
- portmapper and try the ignition sequence again.
-@@ -255,12 +232,8 @@
- <sect>Setting up a NFS client<label id="nfs-client">
- 
- <p>First you will need a kernel with the NFS file system either
--compiled in or available as a module.  This is configured before you
--compile the kernel.  If you have never compiled a kernel before you
--might need to check the kernel HOWTO and figure it out.  If you're
--using a very cool distribution (like Red Hat) and you've never fiddled
--with the kernel or modules on it (and thus ruined it ;-), nfs is
--likely automagicaly available to you.
-+compiled in or available as a module.  This is configured in the GENERIC
-+FreeBSD kernel for you.
- 
- <p>You can now, at a root prompt, enter a appropriate mount command
- and the file system will appear.  Continuing the example in the
-@@ -280,8 +253,7 @@
- by server: Permission denied</tt> then the exports file is wrong, or
- you forgot to run exportfs after editing the exports file.  If it says
- <tt>mount clntudp_create: RPC: Program not registered</tt> it means
--that nfsd or mountd is not running on the server.  Or you have the
--<tt/hosts.{allow,deny}/ problem mentioned earlier.
-+that nfsd or mountd is not running on the server.
- 
- <p>To get rid of the file system you can say
- 
-@@ -294,7 +266,7 @@
- as this is required:
- 
- <code>
--# device      mountpoint     fs-type     options	      dump fsckorder
-+# Device      Mountpoint     FStype      Options	      Dump Pass#    
- ...
- eris:/mn/eris/local  /mnt    nfs	rsize=1024,wsize=1024 0	   0
- ...
-@@ -332,7 +304,7 @@
- <p>Picking up the previous example, this is now your fstab entry:
- 
- <code>
--# device      mountpoint     fs-type    options                  dump fsckorder
-+# Device      Mountpoint     FStype      Options	      Dump Pass#    
- ...
- eris:/mn/eris/local  /mnt    nfs	rsize=1024,wsize=1024,hard,intr 0 0
- ...
-@@ -342,8 +314,8 @@
- <sect1>Optimizing NFS<label id="optimizing">
- 
- <p>Normally, if no rsize and wsize options are specified NFS will read
--and write in chunks of 4096 or 8192 bytes.  Some combinations of Linux
--kernels and network cards cannot handle that large blocks, and it
-+and write in chunks of 4096 or 8192 bytes.  Some 
-+network cards cannot handle that large blocks, and it
- might not be optimal, anyway.  So we'll want to experiment and find a
- rsize and wsize that works and is as fast as possible.  You can test
- the speed of your options with some simple commands.  Given the mount
-@@ -379,7 +351,7 @@
- have different optimal sizes.  SunOS and Solaris is reputedly a lot
- faster with 4096 byte blocks than with anything else.
- 
--<p>Newer Linux kernels (since 1.3 sometime) perform read-ahead for
-+<p>Newer FreeBSD kernels (since 3.0) perform read-ahead for
- rsizes larger or equal to the machine page size.  On Intel CPUs the
- page size is 4096 bytes.  Read ahead will <em/significantly/ increase
- the NFS read performance.  So on a Intel machine you will want 4096
-@@ -393,13 +365,13 @@
- requests shall not be considered finished before the data written is
- on a non-volatile medium (normally the disk).  This restricts the
- write performance somewhat, asynchronous writes will speed NFS writes
--up.  The Linux nfsd has never done synchronous writes since the Linux
-+up.  The FreeBSD nfsd has never done synchronous writes since the FreeBSD
- file system implementation does not lend itself to this, but on
--non-Linux servers you can increase the performance this way with this
-+non-FreeBSD servers you can increase the performance this way with this
- in your exports file:
- 
- <code>
--/dir	-async,access=linuxbox
-+/dir	-async,access=freebsdbox
- </code>
- 
- <p>or something similar.  Please refer to the exports man page on the
-@@ -413,7 +385,9 @@
- distance connections.  
- 
- <p>This section is based on knowledge about the used protocols but no
--actual experiments.  Please let me hear from you if try this ;-)
-+actual experiments.  My home computer has been down for 6 months (bad
-+HD, low on cash) and so I have had no modem connection to test this
-+with.  Please let me hear from you if try this :-)
- 
- <p>The first thing to remember is that NFS is a slow protocol.  It has
- high overhead.  Using NFS is almost like using kermit to transfer
-@@ -623,10 +597,10 @@
- servers root account.  In the NFSd man page there are several other
- squash options listed so that you can decide to mistrust whomever you
- (don't) like on the clients.  You also have options to squash any UID
--and GID range you want to.  This is described in the Linux NFSd man
-+and GID range you want to.  This is described in the FreeBSD NFSd man
- page.
- 
--<p>root_squash is in fact the default with the Linux NFSd, to grant
-+<p>root_squash is in fact the default with the FreeBSD NFSd, to grant
- root access to a filesystem use <tt/no_root_squash/.
- 
- <p>Another important thing is to ensure that nfsd checks that all it's
-@@ -634,7 +608,7 @@
- any old port on the client a user with no special privileges can run a
- program that's is easy to obtain over the Internet. It talks nfs
- protocol and will claim that the user is anyone the user wants to be.
--Spooky.  The Linux nfsd does this check by default, on other OSes you
-+Spooky.  The FreeBSD nfsd does this check by default, on other OSes you
- have to enable this check yourself.  This should be described in the
- nfsd man page for the OS.
- 
-@@ -645,98 +619,9 @@
- 
- <p>The basic portmapper, in combination with nfsd has a design problem
- that makes it possible to get to files on NFS servers without any
--privileges.  Fortunately the portmapper that most Linux distributions
--use is relatively secure against this attack, and can be made more
--secure by configuring up access lists in two files.
--
--<p>Not all Linux distributions were created equal.  Some seemingly
--up-to-date distributions does <em/not/ include a securable portmapper,
--even today, many years since the vulnerability became common
--knowledge.  At least one distribution even contains the manpage for a
--securable portmapper but the actual portmapper is <em>not</em>
--secureable.  The easy way to check if your portmapper is good
--or not is to run strings(1) and see if it reads the relevant files,
--<tt>/etc/hosts.deny</tt> and <tt>/etc/hosts.allow</tt>.  Assuming your
--portmapper is <tt>/usr/sbin/portmap</tt> you can check it with this
--command: <tt>strings /usr/sbin/portmap | grep hosts</tt>.  On my
--machine it comes up with this:
--
--<code>
--/etc/hosts.allow
--/etc/hosts.deny
--@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
--@(#) hosts_access.c 1.20 96/02/11 17:01:27
--</code>
--
--<p>First we edit <tt>/etc/hosts.deny</tt>.  It should contain the line
--
--<code>
--portmap: ALL
--</code>
--
--which will deny access to <em/everyone/.  While it is closed thus run
--<tt>rpcinfo -p</tt> just to check that your portmapper really reads
--and obeys this file.  rpcinfo should give no output, or possebly a
--errormessage.  Restarting the portmapper should <em>not</em> be
--necessary.
--
--<p>Closing the portmapper for everyone is a bit drastic, so we open it
--again by editing <tt>/etc/hosts.allow</tt>.  But first we need to
--figure out what to put in it.  It should basically list all machines
--that should have access to your portmapper.  On a run of the mill
--Linux system there are very few machines that need any access for any
--reason.  The portmapper administrates nfsd, mountd, ypbind/ypserv,
--pcnfsd, and 'r' services like ruptime and rusers.  Of these only nfsd,
--mountd, ypbind/ypserv and perhaps pcnfsd are of any consequence.  All
--machines that needs to access services on your machine should be
--allowed to do that.  Let's say that your machines address is
--129.240.223.254 and that it lives on the subnet 129.240.223.0 should
--have access to it (those are terms introduced by the networking HOWTO,
--go back and refresh your memory if you need to).  Then we write
--
--<code>
--portmap: 129.240.223.0/255.255.255.0
--</code>
--
--in <tt/hosts.allow/.  This is the same as the network address you give
--to route and the subnet mask you give to ifconfig.  For the device
--<tt/eth0/ on this machine <tt/ifconfig/ should show
--
--<code>
--...
--eth0      Link encap:10Mbps Ethernet  HWaddr 00:60:8C:96:D5:56
--          inet addr:129.240.223.254  Bcast:129.240.223.255  Mask:255.255.255.0
--          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
--          RX packets:360315 errors:0 dropped:0 overruns:0
--          TX packets:179274 errors:0 dropped:0 overruns:0
--          Interrupt:10 Base address:0x320 
--...
--</code>
-+privileges.  Fortunately the portmapper FreeBSD uses is relatively
-+secure against this attack.
- 
--and <tt/netstat -rn/ should show
--
--<code>
--Kernel routing table
--Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
--...
--129.240.223.0   0.0.0.0         255.255.255.0   U     0      0   174412 eth0
--...
--</code>
--
--(Network address in first column).
--
--The <tt/hosts.deny/ and <tt/hosts.allow/ files are described in the
--manual pages of the same names.
--
--<p><bf/IMPORTANT:/ Do <em/not/ put <em/anything/ but <em/IP NUMBERS/ in
--the portmap lines of these files.  Host name lookups can indirectly
--cause portmap activity which will trigger host name lookups which can
--indirectly cause portmap activity which will trigger...
--
--<p>The above things should make your server tighter.  The only
--remaining problem (Yeah, right!) is someone breaking root (or boot
--MS-DOS) on a trusted machine and using that privilege to send requests
--from a secure port as any user they want to be.
- 
- <sect1>NFS and firewalls<label id="security-firewalls">
- 
-@@ -752,13 +637,13 @@
- 
- <sect1>Summary<label id="security-summary">
- 
--<p>If you use the hosts.allow/deny, root_squash, nosuid and privileged
-+<p>If you use the nosuid and privileged
- port features in the portmapper/nfs software you avoid many of the
- presently known bugs in nfs and can almost feel secure about <em/that/
- at least.  But still, after all that: When an intruder has access to
- your network, s/he can make strange commands appear in your
- <tt/.forward/ or read your mail when <tt>/home</tt> or
--<tt>/var/spool/mail</tt> is NFS exported.  For the same reason,
-+<tt>/var/mail</tt> is NFS exported.  For the same reason,
- you should never access your PGP private key over nfs.  Or at least
- you should know the risk involved.  And now you know a bit of it.
- 
-@@ -766,10 +651,10 @@
- it's not totally unlikely that new bugs will be discovered, either in
- the basic design or the implementation we use.  There might even be
- holes known now, which someone is abusing.  But that's life.  To keep
--abreast of things like this you should at least read the newsgroups
--<htmlurl url="news:comp.os.linux.announce"
--name="comp.os.linux.announce"> and <htmlurl
--url="news:comp.security.announce" name="comp.security.announce"> at a
-+abreast of things like this you should at least read the mailing lists
-+<htmlurl url="mailto:freebsd-security@FreeBSD.org"
-+name="freebsd-security@FreeBSD.org">
-+at a
- absolute minimum.
- 
- <sect>Mount Checklist
-@@ -780,18 +665,7 @@
- refer to this list before posting your problem.  Each item describes a
- failure mode and the fix.
- 
--<enum>Mount keeps saying <tt/RPC:  Program not registered/
--
--<p>Is the portmapper running?
--<p><bf/Fix:/ Start it.
--<p>Is mountd running? 
--<p><bf/Fix:/ Start it.
--<p>Is nfsd running?
--<p><bf/Fix:/ Start it.
--<p>Is the portmapper forbidden to answer by <tt>/etc/hosts.deny</tt>?
--<p><bf/Fix:/ Either remove the rule in <tt/hosts.deny/ or add a rule
--  to <tt/hosts.allow/ such that the portmapper is allowed to talk to
--  you.
-+<enum>
- 
- <item>File system not exported, or not exported to the client in
- question.
-@@ -832,10 +706,7 @@
- 
- <p><bf/Fix:/ Get the date set right.
- 
--<p>The HOWTO author recommends using NTP to synchronize clocks.  Since
--there are export restrictions on NTP in the US you have to get NTP for
--Debian, Red Hat or Slackware from
--<tt>ftp://ftp.hacktic.nl/pub/replay/pub/linux</tt> or a mirror.
-+<p>The HOWTO author recommends using NTP to synchronize clocks.
- 
- <item>The server can not accept a mount from a user that is in more
- than 8 groups.
-@@ -845,153 +716,10 @@
- 
- </enum>
- 
--<sect>FAQs
--
--<p>This is the FAQ section.  It is partly based on a old NFS FAQ by
--Alan Cox.
--
--<p>If you have a problem mounting a filesystem please see if your
--problem is described in the ``Mount Checklist'' section.
--
--<enum>
--
--  <item>I get a lot of ``stale nfs handle'' errors when using Linux as
--  a nfs server.
--
--  <p>This is caused by a bug in some old nfsd versions.  It is fixed
--  in nfs-server2.2beta16 and later.
--
--  <item>When I try to mount a file system I get
--
--  <tscreen><verb>
--  can't register with portmap: system error on send
--  </verb></tscreen>
--
--  <p>You are probably using a Caldera system.  There is a bug in the
--  rc scripts.  Please contact Caldera to obtain a fix.
--
--  <item>Why can't I execute a file after copying it to the NFS server?
--
--  <p>The reason is that nfsd caches open file handles for performance
--  reasons (remember, it runs in user space).  While nfsd has a file
--  open (as is the case after writing to it), the kernel won't allow
--  you to execute it.  Nfsds newer than ~spring 95 release open files
--  after a few seconds, older ones would cling to them for days.
--
--  <item>My NFS files are all read only
--
--  <p>The Linux NFS server defaults to read only.  Please read the
--  section about ``Mountd and nfsd'' and ``Exporting filesystems'' in
--  this HOWTO, and refer to the ``exports'' and ``nfsd'' manual
--  pages. You will need to alter <tt>/etc/exports</tt>.
--
--  <item>I mount from a Linux NFS server and while <tt>ls</tt> works I
--  can't read or write files.
--
--  <p>On older versions of Linux you must mount a NFS servers with
--  <tt/rsize=1024,wsize=1024/.
--
--  <item>I mount from a Linux NFS server with a block size of between
--  3500-4000 and it crashes the Linux box regularly
--
--  <p>Basically don't do it then.  This does not happen with 2.0 and
--  2.2 kernels.  As far as I recall there is no problem with 1.2
--  either.
--
--  <item>Can Linux do NFS over TCP
--
--  <p>No, not at present.
--
--  <item>I get loads of strange errors trying to mount a machine from a
--  Linux box.
--
--  <p>Make sure your users are in 8 groups or less. Older servers
--  require this.
--
--  <item>When I reboot my machine it sometimes hangs when trying to
--  unmount a hung NFS server.
--
--  <p>Do <bf/not/ unmount NFS servers when rebooting or halting, just
--  ignore them, it will not hurt anything if you don't unmount them.
--  The command is <tt/umount -avt nonfs/.
--
--  <item>Linux NFS clients are very slow when writing to Sun and BSD
--  systems
--
--  <p>NFS writes are normally synchronous (you can disable this if you
--  don't mind risking losing data).  Worse still BSD derived kernels
--  tend to be unable to work in small blocks. Thus when you write 4K of
--  data from a Linux box in the 1K packets it uses BSD does this
--
--  <tscreen><verb>
--	read 4K page
--	alter 1K
--	write 4K back to physical disk
--	read 4K page
--	alter 1K
--	write 4K page back to physical disk
--	etc..
--  </verb></tscreen>
--
--  <item>When I connect many clients to a Linux NFS server the
--  performance suddenly drops.
--
--  <p>The NFS protocol uses fragmented UDP packets.  The kernel has a
--  limit of how many fragments of incomplete packets it can have before
--  it starts throwing away packets.  In 2.2 this is runtime tuneable
--  via the /proc filesystem:
--  <tt>/proc/sys/net/ipv4/ipfrag_high_thresh</tt> and
--  <tt>ipfrag_low_thresh</tt>.  In 2.0 these are compile-time constants
--  defined in <tt>.../linux/net/ipv4/ip_fragment.c</tt>,
--  <tt>IPFRAG_HIGH_THRESH</tt> and <tt>IPFRAG_LOW_THRESH</tt>.  The
--  meaning of these values is that once the memory consumption of
--  unassembled UDP fragments reaches the ``ipfrag_high_thresh'' in
--  bytes (256K by default in 2.2.3 and 2.0.36) it is cut down to
--  ``ipfrag_low_tresh'' at once.  This is done by throwing away
--  fragments.  This will look almost like packet loss, and if the
--  high threshold is reached your server performance drops a lot.
--
--  <p>256K is enough for up to 30 clients.  If you have 60, double it.
--  And double the low threshold also.
--
--  <item>I'm using Linux 2.2 (or later) with knfsd and I can't get my
--  AIX, IRIX, Solaris, DEC-Unix, ... machine to mount it.
--
--  <p>Knfsd announces that it implements NFS version 3.  It does not.
--  There is an option to stop it from announcing it.  Use it.  Or you
--  can put "<tt/vers=2/" in the mount option list on the clients.
--
--  <item>My AIX 4 machine cannot mount my Linux NFS server.  It says
--
--  <tscreen><verb>
--	mount: 1831-011 access denied for server:/dir
--	mount: 1831-008 giving up on:
--	server:/dir
--	The file access permissions do not allow the specified action.
--  </verb></tscreen>
--
--  or something like that instead.
--
--  <p>AIX 4.2 used reserved ports (<1024) for NFS.  AIX 4.2.1 and 4.3
--  are not constrained to reserved ports.  Also, AIX 4.2.1 and 4.3 try
--  to mount using NFS3, then NFS/TCP, then fiannly NFS/UDP.
--
--  <p>Adding 
--
--<code>
--nfso -o nfs_use_reserved_ports=1
--</code>
--
--  <p>to the end of <tt/rc.tcpip/ will force it to use reserved ports
--  again.  (This tip was supplied by Brian Gorka)
--	
--</enum>
--
--
- <sect>Exporting filesystems
- 
- <p>The way to export filesytems with NFS is not completely consistent
--across platforms of course.  In this case Linux and Solaris 2 are the
-+across platforms of course.  In this case FreeBSD and Solaris 2 are the
- deviants.  This section lists, superficially, the way to do it on most
- systems.  If the kind of system you have is not covered you must check
- your OS man-pages.  Keywords are: nfsd, system administration tool, rc
-@@ -1040,291 +768,6 @@
- </code>
- 
- After editing run the program <tt/shareall/ to export the filesystems.
--
--<sect>NFS under Linux 2.2
--<label id="linuxtwotwo">
--
--<p>As I write this Linux 2.2.12 is the current kernel version and to
--use NFS under it can be a bit of a chore.  Or not.
--
--<p>What the status of NFS in Linux 2.4 will be i unknown.
--
--<p>The new big thing in Linux 2.2 is support for a in-kernel nfs
--server demon, called knfsd in 2.2.  This way of implementing nfsd has
--some advantages, the main one is speed.  A Linux 2.2 machine with
--knfsd is a respectable nfs server.  You can still use the old nfsd
--with Linux 2.2 though, and there are some advantages to using this,
--mainly simplicity.
--
--<p>If you use a kernel source or binary package made by someone like
--RedHat (6.0 and later), SuSE (6.1 or later, I belive) or some other
--professional system integrator they have likely integrated full
--"knfsd" functionality in their kernel and you need not worry, it will
--work.  Mostly.  Until you want to compile a kernel yourself.  If you
--use a stock Linux 2.2 kernel (up to 2.2.12 at least) knfsd will break.
--
--<p>To get this on the air yourself you need to get H.J. Lus knfsd
--package.  This is a collection of patches, and the needed utilities
--for 2.2 that Lu is maintaining in his spare time.  You can get it from
--your local kernel mirror, the master site is <htmlurl
--url="ftp://ftp.kernel.org/pub/linux/devel/gcc/"
--name="ftp.kernel.org:/pub/linux/devel/gcc/">.  <bf/This is not meant
--for general consumption/.  If you find this package confusing please
--don't try to do this yourself.  Wait until a kernel package from your
--favourite system integrator (e.g., Red Hat, SuSE or ...) appears.
--
--<p>Also, please don't send me questions about this, I can't help you.
--I do not have any knfsd based servers running.  If you find errors or
--omissions in this documentation, please write to me and I'll revise
--this HOWTO and release it again.
--
--<p>Still reading?  Ok.  H.J.Lu posts about new versions of this
--package on the linux-kernel mailing list.  Other issues pertaining to
--NFS in 2.2 is also posted about there.  Read it.
--
--<p>There is one interesting thing to note about the knfsd package.  It
--announces that it supports NFS version 3.  However it does not support
--it.  There is an option you can give to stop it from announcing NFS3,
--or on the clients you can specify "<tt/vers=2/" in the mount option
--list.
--
--<sect1>The client
--
--<p>The client is almost simple.  To get propper locking you need to
--get <tt/statd/ (from the knfsd package) compiled, installed and
--started from your boot-scripts.  Do that.  Statd needs a directory
--called <tt>/var/lib/nfs</tt> to function otherwise it will just abort
--with no error message, so that directory needs to be created before it
--will run.
--
--<p>Once statd is running you can use the <tt/testlk/ program (in
--<tt>tools/locktest</tt> to test if locking of a file on a NFS mounted
--filesystem works.  It should.  If it prints <em/No locks available/
--statd is not working.
--
--<p>Actually, you can also avoid locking entierly (not that I recomend
--this), by giving "<tt/nolock/" in the mount option list.
--
--<p>As far as I know this is all that's needed to get the client
--working.
--
--<p>Oh, if you have a Sparc or Alpha NFS server you will find that the
--nfs client in Linux 2.2 absolutely sucks.  The transfer rates to and
--from the server is so bad that ... you can't imagine.  It's far worse
--than under Linux 2.0.  Far.  But there is a fix for this of course.
--The Alan Cox series of 2.2 kernels (which are a bit more experimental
--than the normal 2.2 kernels from Linus) include a patch to make Linux
--2.2 perform when used with Alpha and Sparc servers.  If you want to
--use the Alan Cox 2.2 kernels you should be reading the linux-kernel
--mailing list and if you do you know where the patch can be found.
--There home site of this patch is <url
--url="http://www.uio.no/~trondmy/src/">, in case you want to try to
--apply it to a stock 2.2 kernel.  This patch will probably not be in
--Linux 2.4 either, because it requires too many changes in the kernel
--to be accepted in the current development cycle.  Wait for Linux 2.5.
--
--<p><tt/trondmy/ also has patches to make Linux use NFS version 3, this
--will also enable you to use tcp as transport mechanism instead of UDP.
--NFSv3 is is very good for long-haul networks and other networks where
--the packet loss is non-zero or the latencies are high.
--
--<p>The reason you should read the linux-kernel mailing list to use
--these patches is that sometimes there are bad bugs discovered in them.
--Bugs that eat your files.  So please <bf/beware/.
--
--<sect1>The server
--
--<p>The nfs server demon under Linux 2.2 and later is called
--"<tt/knfsd/".  It is tricky to set it up.  You have to figure this out
--all by yourself, or stick to what SuSE, Red Hat and others are
--releasing in the way of 2.2 kernel packages. Sorry.  You can still use
--the old nfsd under Linux 2.2 though.  It's slow but easy to set up.
--
--<sect>NFS server on a floppy
--
--<p>This section was written by Ron Peters, <htmlurl
--url="mailto:rpeters@hevanet.com" name="rpeters@hevanet.com"> It
--explains how to set up an NFS server when booting up from floppy.  It
--was originally devised to be able to NFS share a cdrom from another
--non-Linux/UNIX machine to install Linux on a machine that does not
--have a cdrom.
--
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1> Introduction
--<p>
--This document is being created for those who will run into the same problem
--I had recently.  I was building a Linux server on a machine that didn't have
--a cdrom and has no facility for adding one except for possibly an external
--SCSI or the like.  Now that it is getting less and less likely that you will
--be installing on a machine like that, this document may not be that
--valuable.  However, I would have appreciated it when I was trying to build
--my machine.
--<p>
--Since my machine didn't have a cdrom drive, I thought I would go find an NFS
--server for Win95 and share the cdrom for long enough to install the box and
--get it on my network.  Of the two products I found, (I'm not mentioning names
--but one was freeware and the other was a 14 day limited license), one didn't
--work out of the box, and the other couldn't handle the Linux naming
--convention well enough to complete the install.
--<p>
--I then settled on trying to boot my Win95 machine with the boot/root set of
--disks and then use a suplimentary floppy to set up the NFS server.
--<p>
--This was remarkably simple, and the procedure is probably easier than reading
--this introduction but I believe that putting the whole procedure in one
--place will be value added.
--<p>
--
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1>Expectations
--<p>
--This document was derived using the boot/root disks from one of the current
--InfoMagic developer distributions of Slackware.  I used kernel version 
--2.0.34 for the boot/root disks, but the NFS server programs were taken from 
--a 2.0.30 server.  I have always used the Slakware installation method, not 
--because it is any easier or better or worse, just that I am comfortable with 
--it and I haven't taken the time to try another method.
--<p>
--I don't believe that there will be many problems using this document in
--relation to OS version.  I would recommend using something relatively
--current.  Since it is likely that this will be used for installation, a
--current boot/root set will likely be used.
--<p>
--Your mileage may vary.
--<p>
--
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1>Requirements
--<p>
--<itemize>
--<item>Network capable system and boot disk.  The system that is to be the 
--NFS server must have a network card and it must be recognized by the during 
--the boot process.  More information on this can be found in the Networking 
--HOWTO.
--<item>Secondary floppy that contains rpc.portmap, rpc.mountd and rpc.nfsd.
--These files should be easily found from an ftpsearch off the web.  
--<item>Slackware (or other) source media (assumed to be cd).
--</itemize>
--
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1> Server Setup
--<p>
--<sect2> Boot the temporary NFS server
--<p>
--Boot the NFS server system from boot floppy and make sure the network card 
--is recognized.  It is also necessary that the CDROM be recognized.  I will 
--use eth0 as the example network card.
--<p>
--<sect2> Mount the floppy and cdrom
--<p>
--Once the system is booted up, the boot/root floppies are not needed.  The
--system is fully contained in RAM.
--<p>
--Replace the root floppy with the suplimentary disk.  Mount the floppy:
--<p>
--<tt>mount /dev/fd0 /floppy</tt>
--<p>
--This assumes that the floppy is an ext2 file system type.  I imaging that
--the suplimentary disk could be a DOS floppy with the files on it, but I
--haven't tried that yet.  I imagine that this would be easier that a disk 
--image.  In this case, it would be a <tt>mount -t msdos ...etc</tt>.  This 
--should probably be put in the todo section.
--<p>
--Mount the cdrom:
--<p>
--<tt>mount -t iso9660 /dev/hdc /cdrom</tt>
--<p>
--The floppy and cdrom devices are the ones I used.  These may be different
--depending on application.  The mount points /floppy and /cdrom exist on the 
--root floppy disk image so they can be used.  If they don't, create them or 
--you could use any mount points you like.
--<p>
--<sect2> Set up networking on the temporary server.
--<p>
--This is where the temporary NFS server is set up to talk on the network.  
--There are only a few commands to run.  There are a few items of information
--that you will need before running the commands (values are examples):
--<p>
--IPADDR:172.16.5.100  #This is the address of the temporary server.
--<p>
--NETMASK:255.255.255.0  #This is the netmask.
--<p>
--BROADCAST:172.16.5.255 #The last number (255) is significant from IPADDR.
--<p>
--ETHNETWORK:172.16.5.0 #Once again, slightly different from IPADDR.
--<p>
--GATEWAY:172.16.5.251 #Only needed if you have a gateway.  You will probably
--know.  Most home networks won't have a gateway.
--<p>
--The commands to get on the network.  Insert values from above:
--<p>
--<tt>ifconfig eth0 inet IPADDR arp netmask NETMASK broadcast BROADCAST</tt>
--<p>
--<tt>route add -net ETHNETWORK netmask NETMASK eth0</tt>
--<p>
--Only use next command if you have a gateway and need to go through it:
--<p>
--<tt>route add default gw GATEWAY netmask 0.0.0.0 eth0</tt>
--<p>
--If all goes well, you are now on the network and should be able to ping other
--nodes.
--<p>
--<sect2> Set up the NFS share.
--<p>
--Determine the directory that you want to NFS share.  In the case of the my
--example, I used the /cdrom/slakware directory.  Put this directory in the
--/etc/exports file:
--<p>
--<tt>echo "/cdrom/slakware" > /etc/exports</tt>
--<p>
--<sect1> Run the NFS server
--<p>
--Go to /floppy/usr/sbin and run:
--<p>
--<tt>./rpc.portmap</tt>
--<p>
--<tt>./rpc.mountd</tt>
--<p>
--<tt>./rpc.nfsd</tt>
--<p>
--<sect2> Complete, start the install.
--<p>
--This should share the "/cdrom/slakware" directory in the /etc/exports file.
--Once this is done, you can now boot up the machine to be installed from
--boot/root floppies (I used same ones that I booted NFS server with) and start
--the installation.  
--<p>
--Once you are ready to choose the media source location, choose the NFS 
--server option.  It will ask about the ip address of the server.  Give it the 
--IP address that you used as IPADDR for the server.  It will also ask for the 
--directory to be mounted.  This is the directory you put in the /etc/exports 
--on the NFS server.
--<p>
--The system will then NFS mount the server.  Watch for any error messages.
--All should be complete and you can continue the installation.
--<p>
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1>Troubleshooting
--<p>
--<sect2> Nothing Here Yet.
--<p>
--I don't have any troubleshooting info yet.  Perhaps as people use this
--procedure, there will be more tips and hints available.
--<p>
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
--<sect1>To Do
--<p>
--<sect2>DOS Disk.
--<p>
--Check out a DOS disk for the suplimentary disk.
--<p>
--<sect2> rpc commands.
--<p>
--Check out specific order of running rpc.* commands and if all or just some
--of the command needs to be run.
--<p>
--
--<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
- 
- <sect>PC-NFS
-