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