diff options
Diffstat (limited to 'misc/Howto/files/patch-nfs')
| -rw-r--r-- | misc/Howto/files/patch-nfs | 840 |
1 files changed, 0 insertions, 840 deletions
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 & - 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 - |