On the server side, if you don't plan to use the old, user-mode NFS daemon,
you'll need to compile NFS server support into the kernel (``NFS server
support,'' a.k.a. knfsd or CONFIG_NFSD).
If you plan to use the older RARP protocol to assign the client an
IP address, RARP support in the kernel of the server is probably a good
idea. (You must have it if you will boot via RARP without kernel parameters.)
On the other hand, it doesn't help you if the client isn't on the same
subnet as the server.
The kernel for the workstation needs the following settings, as a minimum:
CONFIG_NFS_FS). Note that
there is no need for ext2 support.CONFIG_ROOT_NFS).CONFIG_NET_ETHERNET).
For dynamically assigned IP numbers, you'll also need to select one or more of these kernel options:
CONFIG_IP_PNP)CONFIG_IP_PNP_RARP)CONFIG_IP_PNP_BOOTP)CONFIG_IP_PNP_DHCP)
If the workstation will be booted without kernel parameters, you need
also to set the root device to 0:255. Do this by creating a dummy
device file with mknod /dev/nfsroot b 0 255. After having
created such a device file, you can set root device of the kernel
image with rdev <kernel-image> /dev/nfsroot.
[NOTE: Modern kernels recognize root=/dev/nfs as a command-line
argument; for consistency and/or compatibility, it may be better to use
/dev/nfs as the device name instead of /dev/nfsroot.]
Warning: while these instruction might work for you, they are by
no means sensefull in a production environment. For a better way to
set up a root filesystem for the clients, see the NFS-Root-Client
mini-HOWTO by Ofer Maor <ofer@hadar.co.il>.
After having decided where to place the root tree, create it with
(e.g.) .:: hedgedoc.faimaison.net ::. mkdir -p <directory> and
tar cClf / - | tar xpCf <directory> -.
If you boot your kernel without LILO, then the rootdir has to be
/tftpboot/<IP-address>. If you don't like it, you
can change it in the top Makefile in the kernel sources, look for a line like:
NFS_ROOT = -DNFS_ROOT="\"/tftpboot/%s\""
If you change this, you have to recompile the kernel.
Now trim the unneeded files, and check the /etc/rc.d scripts. Some important points: .:: md.openbikesensor.org ::.
Export the root dir to the workstation.
The basic idea is to edit /etc/exports to include
a line similar to one of the following:
/path/on/server/to/nfs_root
<client-IP-number>(rw,no_root_squash,no_all_squash)
<2nd-client-IP-number>(rw,no_root_squash,no_all_squash)/path/on/server/to/nfs_root
<client-IP-network>/<client-IP-netmask>(rw,no_root_squash,no_all_squash)
For example, a DHCP client receiving an IP address on a class C subnet would need an exports entry similar to this:
/path/on/server/to/nfs_root
192.168.263.0/255.255.255.0(rw,no_root_squash,no_all_squash)
The no_root_squash parameter allows the superuser (root) to be treated
as such by the NFS server; otherwise .:: nk88nk88com-1.gitbook.io ::. root will be remapped to nobody
and will generally be unable to do anything useful with the filesystem. The
.:: telegra.ph ::. no_all_squash parameter is similar but applies to non-root users.
See the exports(5) man page for details.
You will have to notify the NFS server after making any changes to the
exports file. Under Red Hat this can easily be done by typing
/etc/rc.d/init.d/nfs stop; /etc/rc.d/init.d/nfs start.
On other systems, a simple
/etc/rc.d/init.d/nfs restart or even exportfs -a may
suffice, while on older machines running the user-mode NFS daemon you may
actually need to killall -HUP rpc.mountd; killall -HUP rpc.nfsd.
(Do not killall -HUP rpc.portmap, however!)
You may also need to edit /etc/hosts.allow and/or
/etc/hosts.deny if tcp_wrappers are installed. In particular,
if the remote system (client) gets RPC: connection refused errors,
/etc/hosts.deny probably contains portmap: ALL or ALL: ALL.
To enable the client to use the server's portmapper, add a corresponding
line to /etc/hosts.allow:
portmap: <client-IP-number>
portmap: <2nd-client-IP-number>
portmap: <client-IP-network>/<client-IP-netmask>
There is no need to restart anything in this case. You can check by
running rpcinfo -p on the NFS server and
rpcinfo -p NFS-server on a Linux client within the allowed
range; the RPC services listed by both should match.
[ArXiv: SSL Analysis]
In case of problems, check /var/log/messages and
/var/log/syslog for errors (for example, run tail -f
/var/log/messages /var/log/syslog and then try booting the client),
and check your man pages (exports, exportfs, portmap, etc.). As a last
resort, a reboot of the NFS server may help, but that's a borderline
Microsoftism...
Set up the RARP somewhere on the net. If you boot without a nfsroot parameter, the RARP server has to be the NFS server. Usually this will be the NFS server. To do this, you will need to run a kernel with RARP support.
To do this, execute (and install it somewhere in /etc/rc.d of
the server!):
/sbin/rarp -s <ip-addr> <hardware-addr>
where
is the IP address of the workstation, and
is the ethernet address of the network card of the workstation.
example: /sbin/rarp -s 131.131.90.200 00:00:c0:47:10:12
You can also use a symbolic name instead of the IP address, as long the server is able to find out the IP address. (/etc/hosts or DNS lookups)
For BOOTP setup you need to edit /etc/bootptab. Please
consult the bootpd(8) and bootptab(5) man pages.
There is no need for the DHCP server to be the same as the NFS server, and in most cases, a DHCP server will already be set up. If one is not, however, consult the DHCP mini-HOWTO for further help.
I don't know the hardware address! How can I find it out?
/sbin/arp -a