Attachment 15869 Details for Bug 29311 – file.diff

[patch] file.diff

file.diff (text/plain), 35.64 KB, created by jmcoopr on 2001-07-30 01:40:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: jmcoopr

Created: 2001-07-30 01:40:01 UTC

Size: 35.64 KB

patch

obsolete

>diff -ruN Howto/files/patch-nfs Howto.new/files/patch-nfs
>--- Howto/files/patch-nfs	Sat Nov 20 14:52:50 1999
>+++ Howto.new/files/patch-nfs	Wed Dec 31 16:00:00 1969
>@@ -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 TCP/IP Network
>- Administration 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.
>- 
>--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.
>--
>--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">
>- 
>--If you need to set up a non-Linux box as server you will have to
>-+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.
>- 
>--If you're running please see <ref id="linuxtwotwo" name="the Linux
>--2.2 section"> before you continue reading this.
>--
>- Those of you still reading will need to set up a number of
>- programs.
>- 
>- <sect1>The portmapper<label id="portmapper">
>- 
>--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
>-+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.
>--
>--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.
>- 
>--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
>-+Now we're set to start mountd
>-+and then nfsd. They will both
>- read the exports file. 
>- 
>- 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>
>- 
>--Save it in, say, <tt>/usr/sbin/exportfs</tt>, and don't forget to
>-+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.
>- 
>- 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">
>- 
>- 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.
>- 
>- 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.
>- 
>- 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 @@
>- 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">
>- 
>- 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.
>- 
>--Newer Linux kernels (since 1.3 sometime) perform read-ahead for
>-+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>
>- 
>- or something similar. Please refer to the exports man page on the
>-@@ -413,7 +385,9 @@
>- distance connections. 
>- 
>- 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 :-)
>- 
>- 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.
>- 
>--root_squash is in fact the default with the Linux NFSd, to grant
>-+root_squash is in fact the default with the FreeBSD NFSd, to grant
>- root access to a filesystem use <tt/no_root_squash/.
>- 
>- 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 @@
>- 
>- 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.
>--
>--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 not
>--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>
>--
>--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 not be
>--necessary.
>--
>--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.
>--
>--<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...
>--
>--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">
>- 
>--If you use the hosts.allow/deny, root_squash, nosuid and privileged
>-+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/
>--
>--Is the portmapper running?
>--<bf/Fix:/ Start it.
>--Is mountd running? 
>--<bf/Fix:/ Start it.
>--Is nfsd running?
>--<bf/Fix:/ Start it.
>--Is the portmapper forbidden to answer by <tt>/etc/hosts.deny</tt>?
>--<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 @@
>- 
>- <bf/Fix:/ Get the date set right.
>- 
>--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.
>-+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
>--
>--This is the FAQ section. It is partly based on a old NFS FAQ by
>--Alan Cox.
>--
>--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.
>--
>-- 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>
>--
>-- 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?
>--
>-- 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
>--
>-- 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.
>--
>-- 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
>--
>-- 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
>--
>-- No, not at present.
>--
>-- <item>I get loads of strange errors trying to mount a machine from a
>-- Linux box.
>--
>-- 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.
>--
>-- 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
>--
>-- 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.
>--
>-- 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.
>--
>-- 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.
>--
>-- 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.
>--
>-- 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.
>--
>-- Adding 
>--
>--<code>
>--nfso -o nfs_use_reserved_ports=1
>--</code>
>--
>-- 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
>- 
>- 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">
>--
>--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.
>--
>--What the status of NFS in Linux 2.4 will be i unknown.
>--
>--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.
>--
>--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.
>--
>--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.
>--
>--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.
>--
>--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.
>--
>--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
>--
>--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.
>--
>--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.
>--
>--Actually, you can also avoid locking entierly (not that I recomend
>--this), by giving "<tt/nolock/" in the mount option list.
>--
>--As far as I know this is all that's needed to get the client
>--working.
>--
>--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.
>--
>--<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.
>--
>--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
>--
>--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
>--
>--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.
>--
>--
>--<sect1> Introduction
>--
>--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.
>--
>--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.
>--
>--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.
>--
>--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.
>--
>--
>--
>--<sect1>Expectations
>--
>--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.
>--
>--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.
>--
>--Your mileage may vary.
>--
>--
>--
>--<sect1>Requirements
>--
>--<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>
>--
>--
>--<sect1> Server Setup
>--
>--<sect2> Boot the temporary NFS server
>--
>--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.
>--
>--<sect2> Mount the floppy and cdrom
>--
>--Once the system is booted up, the boot/root floppies are not needed. The
>--system is fully contained in RAM.
>--
>--Replace the root floppy with the suplimentary disk. Mount the floppy:
>--
>--<tt>mount /dev/fd0 /floppy</tt>
>--
>--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.
>--
>--Mount the cdrom:
>--
>--<tt>mount -t iso9660 /dev/hdc /cdrom</tt>
>--
>--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.
>--
>--<sect2> Set up networking on the temporary server.
>--
>--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):
>--
>--IPADDR:172.16.5.100 #This is the address of the temporary server.
>--
>--NETMASK:255.255.255.0 #This is the netmask.
>--
>--BROADCAST:172.16.5.255 #The last number (255) is significant from IPADDR.
>--
>--ETHNETWORK:172.16.5.0 #Once again, slightly different from IPADDR.
>--
>--GATEWAY:172.16.5.251 #Only needed if you have a gateway. You will probably
>--know. Most home networks won't have a gateway.
>--
>--The commands to get on the network. Insert values from above:
>--
>--<tt>ifconfig eth0 inet IPADDR arp netmask NETMASK broadcast BROADCAST</tt>
>--
>--<tt>route add -net ETHNETWORK netmask NETMASK eth0</tt>
>--
>--Only use next command if you have a gateway and need to go through it:
>--
>--<tt>route add default gw GATEWAY netmask 0.0.0.0 eth0</tt>
>--
>--If all goes well, you are now on the network and should be able to ping other
>--nodes.
>--
>--<sect2> Set up the NFS share.
>--
>--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:
>--
>--<tt>echo "/cdrom/slakware" > /etc/exports</tt>
>--
>--<sect1> Run the NFS server
>--
>--Go to /floppy/usr/sbin and run:
>--
>--<tt>./rpc.portmap</tt>
>--
>--<tt>./rpc.mountd</tt>
>--
>--<tt>./rpc.nfsd</tt>
>--
>--<sect2> Complete, start the install.
>--
>--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. 
>--
>--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.
>--
>--The system will then NFS mount the server. Watch for any error messages.
>--All should be complete and you can continue the installation.
>--
>--
>--<sect1>Troubleshooting
>--
>--<sect2> Nothing Here Yet.
>--
>--I don't have any troubleshooting info yet. Perhaps as people use this
>--procedure, there will be more tips and hints available.
>--
>--
>--<sect1>To Do
>--
>--<sect2>DOS Disk.
>--
>--Check out a DOS disk for the suplimentary disk.
>--
>--<sect2> rpc commands.
>--
>--Check out specific order of running rpc.* commands and if all or just some
>--of the command needs to be run.
>--
>--
>--
>- 
>- <sect>PC-NFS
>- 
>diff -ruN Howto/pkg-plist Howto.new/pkg-plist
>--- Howto/pkg-plist	Tue Dec 29 20:42:36 1998
>+++ Howto.new/pkg-plist	Sun Jul 29 17:23:44 2001
>@@ -1,2 +1 @@
>-share/doc/Howto
> @unexec /bin/rm -rf %D/share/doc/Howto

Actions: View | Diff

Attachments on bug 29311: 15869