]> git.decadent.org.uk Git - nfs-utils.git/blob - README
sm-notify command: include <config.h>
[nfs-utils.git] / README
1 This is version 1.1.0 of nfs-utils, the Linux NFS utility package.
2
3
4 0. PROJECT RESOURCES
5
6 Home page:  http://sourceforge.net/projects/nfs/
7
8 To use the 'gss' support you must have kerberos-5 development 
9 libraries installed.
10 Otherwise use  "--disable-gss"
11
12 To use nfsv4 support you need libevent and libnfsidmap development
13 libraries.  They are available from 
14    http://www.monkey.org/~provos/libevent/
15    http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/
16 Otherwise use --disable-nfsv4
17
18
19 1. COMPILING
20
21 Unpack the sources and run these commands:
22
23     # ./configure
24     # make
25
26 To install binaries and documenation, run this command:
27
28     # make install
29
30
31 2. COMPILING FROM GIT
32
33 Getting nfs-utils for the first time:
34
35         git clone git://linux-nfs.org/nfs-utils
36
37 Updating to the latest head after you've already got it.
38
39         git pull
40
41 Building requires that autotools be installed.  To invoke them
42 simply
43
44         sh autogen.sh
45
46 Finally, build as usual as above.
47
48 3. DAEMON STARTUP ORDER
49
50 This nfs-utils packages does not provide any scripts for starting
51 various daemons as most distributions replace them with their own, so
52 any scripts we package would not get much testing.
53 Instead, we explain the dependencies involved in startup so that
54 scripts can be written to work correctly.
55
56 3.0   PREREQUISITES 
57
58    Name service (host name lookup) should be working before any
59    NFS services are started.
60
61    "portmap" must be running before any NFS services (server or
62    client) are started.
63    
64    Normally network interfaces should be configured first as well,
65    though this isn't critical for the NFS server (providing name
66    service is handled locally).
67    
68 3.1.  SERVER STARTUP
69
70
71    A/  mount -t nfsd /proc/fs/nfsd
72       This filesystem needs to be mount before most daemons,
73       particularly exportfs, mountd, svcgssd, idmapd.
74       It could be mounted once, or the script that starts each daemon
75       could test if it is mounted and mount it if not.
76
77    B/ svcgssd ; idmapd
78        These supply services to nfsd and so should be started before
79        rpc.nfsd.  Where they come between mounting the nfsd filesystem
80        and starting the nfsd server is not important.
81        idmapd is only needed for NFSv4 support.
82        svcgssd is only needed if exportfs NFS filesystem with crypto-
83        security (Kerberos or SPKM3).
84
85    C/ exportfs -av ; rpc.mountd
86        It is important that exportfs be run before mountd so that
87        mountd is working from current information (in
88        /var/lib/nfs/etab).
89        It is also important that both of these are run before
90        rpc.nfsd.
91        If not, any NFS requests that arrive before mountd is started
92        will get replied to with a 'Stale NFS File handle' error.
93
94    D/ rpc.statd --no-notify
95        It is best if statd is started before nfsd though this isn't
96        critical.  Certainly it should be at most a few seconds after
97        nfsd.
98        When nfsd starts it will start lockd. If lockd then receives a
99        lock request it will communicate with statd.  If statd is not
100        running lockd will retry, but it won't wait forever for a
101        reply.
102        Note that if statd is started before nfsd, the --no-notify
103        option must be used.  If notify requests are sent out before
104        nfsd start, clients may try to reclaim locks and, on finding
105        that lockd isn't running, they will give up and never reclaim
106        the lock.
107        rpc.statd is only needed for NFSv2 and NFSv3 support.
108
109    E/ rpc.nfsd
110        Starting nfsd will automatically start lockd.  The nfs server
111        will now be fully active and respond to any requests from
112        clients.
113        
114    F/ sm-notify
115        This will notify any client which might have locks from before
116        a reboot to try to reclaim their locks.  This should start
117        immediately after rpc.nfsd is started so that clients have a
118        chance to reclaim locks within the 90 second grace period.
119        sm-notify is only needed for NFSv2 and NFSv3 support.
120
121
122 3.2.  CLIENT STARTUP
123
124    A/ sm-notify
125       This should be run shortly after boot and before any NFS
126       filesystems are mounted with remote-locking support -
127       filesystems can be mounted with "-o nolock" before sm-notify.
128       This is appropriate for '/', '/usr', and '/var'.
129
130    B/ gssd ; idmapd
131       idmapd should be started before mounting any NFSv4 filesystems.
132       gssd should be started before mounting any NFS filesystems
133       securely (with Kerberos of SPKM3).
134
135    C/ statd should be run before any NFSv2 or NFSv3 filesystem is
136       mounted with remote locking (i.e. without -o nolock).
137       'mount' will try to use "/usr/sbin/start-statd" to start statd
138       if it is not already running, so there is no need to explicitly
139       start statd in boot-time scripts.
140
141 3.3.  SERVER/CLIENT INTERACTIONS
142
143    A/ sm-notify
144       Both the server and the client need sm-notify to be run.
145       It should be run after the NFS server is started, but before
146       and NFS filesystems are mounted with remote locking.
147
148    B/ rpc.statd
149       Both the server and the client need rpc.statd to be running.
150       Each should try to start when they need it.
151
152    C/ idmapd
153
154       Both the server and client need idmapd to be running.  If idmapd
155       is started (for the client) before starting nfsd the 'nfsd'
156       filesystem is mounted, then idmapd should be sent a HUP signal
157       afterwards to signal that the server channels should be opened.
158
159    
160       
161
162 Share And Enjoy!
163
164     --  the nfs-utils developers
165         <linux-nfs@vger.kernel.org>