cpet/freebsd-ports
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7570754b96
freebsd-ports/misc/Howto/files/patch-nfs
Chris Piazza 7d63b5b8d6 Update MASTER_SITES and sync the NFS HOWTO 
PR:		14898
Submitted by:	KATO Tsuguru <tkato@prontomail.ne.jp>
1999-11-20 22:52:14 +00:00

841 lines
34 KiB
Plaintext
Raw Blame History

--- 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
Reference in New Issue View Git Blame Copy Permalink