home *** CD-ROM | disk | FTP | other *** search
-
- NFS-Root-Client Mini-Howto
- [1]Ofer Maor, [2]oferm@hcs.co.il
- V4.1, 02 February 1999
-
- The purpose of this Mini-Howto is to explain how to create client root
- directories on a server that is using NFS Root mounted clients. You
- can find the latest version of this Howto (HTML or Text) at URL:
- [3]http://www.hcs.co.il/oferm/NFS-Root-Client/
-
- 1. Copyright
-
- (c) 1996 Ofer Maor (oferm@hcs.co.il)
-
- Unless otherwise stated, Linux HOWTO documents are copyrighted by
- their respective authors. Linux HOWTO documents may be reproduced and
- distributed in whole or in part, in any medium physical or electronic,
- as long as this copyright notice is retained on all copies. Commercial
- redistribution is allowed and encouraged; however, the author would
- like to be notified of any such distributions.
-
- All translations, derivative works, or aggregate works incorporating
- any Linux HOWTO documents must be covered under this copyright notice.
- That is, you may not produce a derivative work from a HOWTO and impose
- additional restrictions on its distribution. Exceptions to these rules
- may be granted under certain conditions; please contact the Linux
- HOWTO coordinator at the address given below.
-
- In short, we wish to promote dissemination of this information through
- as many channels as possible. However, we do wish to retain copyright
- on the HOWTO documents, and would like to be notified of any plans to
- redistribute the HOWTOs.
-
- If you have questions, please contact Ofer Maor ([4]oferm@hcs.co.il),
- the author of this mini-HOWTO, or Greg Hankins, the Linux HOWTO
- coordinator, at [5]gregh@sunsite.unc.edu via email, or at +1 404 853
- 9989.
-
- If you have anything to add to this Mini-Howto, Please mail the author
- (Ofer Maor, [6]oferm@hcs.co.il
- ), with the information. Any new relevant information would be
- appreciated.
-
- 1.1. Thanks
-
- I would like to express my thanks to the author of the NFS-Root Howto,
- Andreas Kostyrca ([7]andreas@medman.ag.or.at). His Mini-Howto helped
- me with the first steps in creating a NFS Root Mounted client. My
- Mini-Howto does not, in any way, try to replace his work, but to
- enhance it using my experiences in this process.
-
- I would also like to thank Mark Kushinsky ([8]mark026@ibm.net) for
- polishing the english and spelling of this Howto, thus making it much
- more readable.
-
- 2. Preface
-
- This Mini-Howto was written in order to help people who want to use
- NFS Root mounting to create their client's directories. Please note
- that there are many ways to accomplish this, depending on your needs
- and intent. If the clients are individual, and each client has its own
- users and administrator, it will be necessary to make significant
- parts of the client dirs not shared with other clients. On the other
- hand if the client is intended for multiple users, and are all
- administrated by the same person (for instance, a computer class),
- make as many files as possible shareable in order to make
- administration more manageable. This Howto will focus on the second
- issue.
-
- 2.1. General Overview
-
- When building a client's root directory, and trying to limit ourselves
- to the minimum client size, we mainly focus on which files can we
- share, or mount from the server. In this Howto I will recommend the
- configuration of a client based on my experience. But before we begin
- please note:
-
- * This Mini-Howto does not explain how to do the actual NFS Root
- mounting. Reffer to the NFS-Root Mini-Howto if you need more
- information about that issue.
- * I based most of my client's configuration on mounts and symbolic
- links. A lot of those symbolic links can be replaced by hardlinks.
- One should choose according to his personal preference. Putting a
- hardlink over a mount and a symbolic link has its advantages, but
- might cause confusion. A file will not be erased until all its
- hardlinks are removed. Thus, In order to prevent a case in which
- you upgrade a certain file, and the hardlinks still refer to the
- older version, you will have to be very careful and keep track of
- every link you put.
- * While mounting the information from the server, two concepts can
- be used. The first (most common) concept, is to mount the whole
- server root directory under a local directory, and then just
- change the path or link the relevant directories there. I
- personally dislike mounting root partitions of a server on
- clients. Thus, this Howto suggests a way to mount the relevant
- directories of the server to the relevant places on the system.
- * This Howto is based on my experience building client directories
- on a Slackware 3.1 based distribution. Things may be different
- (especially on the rc.* files), for other users, however the
- concepts should still remain the same.
-
- 3. Creating the client's root directory
-
- 3.1. Creating the directory tree
-
- First of all, you need to create the directory structure itself. I
- created all the clients under /clients/hostname and I will use it for
- my examples listed below. This, however, can be changed to anything
- else. The first stage, then, is to create the relevant directories in
- the root directory. You should create the following directories:
- bin, dev, etc, home, lib, mnt, proc, sbin, server, tmp, usr, var
-
- and any other directories you might want to have on your system.
-
- The local, proc, and dev directories will be used separately on each
- machine while the rest of the directories will be either party or
- completely shared with the rest of the clients.
-
- 3.2. Creating the minimal file system needed for boot
-
- 3.2.1. Creating the dev dir.
-
- Although the dev dir can be shared, it is better to create a separate
- one for each client. You can create your client's dev directory with
- the appropriate MAKEDEV scripts, however in most cases it is simpler
- just to copy it from the server:
- cp -a /dev /clients/hostname
-
- You should keep in mind that /dev/mouse, /dev/cdrom and /dev/modem are
- symbolic links to actually devices, and therefore you should be sure
- that they are linked correctly to fit the client's hardware.
-
- 3.2.2. Copying the necessary binaries.
-
- Although we mount everything from the server, there is a minimum that
- we need to copy to each client. First of all, we need "init", our
- system will not be able to run anything before init'ing (as the author
- found out in the hard way ;-). So first, you should copy /sbin/init to
- your client's sbin dir and then so that rc.S will run, you should copy
- /bin/sh to the client's bin directory. Also, in order to mount
- everything you need to copy /sbin/mount to the client's sbin
- directory. This is the minimum, assuming the first line in your rc.S
- is mount -av. However, I recommend copying a few more files: update,
- ls, rm, cp and umount, so that you will have the basic tools in case
- the client has problems mounting. If you choose to leave your swap on
- line before mount, you should also copy the swapon binary.
-
- Since most of these binaries are by default dynamically linked, you
- will also need to copy a fair part of /lib:
- cp -a /lib/ld* /lib/libc.* /lib/libcursses.* /client/hostname/lib
-
- Hardlinking the binaries themselves, instead of copying them, should
- be considered. Please read my comments on this in part 2.1 of this
- Howto.
-
- Please notice, all of the information above assumes that the kernel
- has been given the network parameters while booting up. If you plan to
- use rarp or bootp, you will probably need the relevant binaries for
- these as well.
-
- Generally, you will need the minimum of files that will enable you to
- configure the network and run rc.S up to the point where it mounts the
- rest of the file system. Make sure you looked into your /etc/init and
- rc.S files, making sure there are no "surprises" in any of them, which
- will require other files to be accessed, before the first mount will
- take place. If you do, however, find such files, you can either copy
- them as well, or remove the relevant parts from your init and your
- rc.S files.
-
- 3.2.3. The var directory
-
- The var directory, in most cases, should be separate for each client.
- However, a lot of the data can be shared. Create under the server
- directory a directory called var. We will mount the server's var
- directory there. To create the local var directory, simply type:
- cp -a /var /clients/hostname/
-
- Now, you have a choice as to what you want to separate, and what you
- want to share. Any directory/file that you want to share, simply
- remove it from the client's var dir, and symlink it to the
- /server/var/ directory. However please note that you should either
- symlink it to /server/var or to ../server/var but NOT to
- /clients/hostname/server/var as this will not work when the root
- changes.
-
- Generally, I would recommend separating /var/run, /var/lock,
- /var/spool, and /var/log.
-
- 3.2.4. The rest of the directories
-
- * etc is explained thoroughly in the next section.
- * mnt and proc are for local purposes.
- * usr and home are merely mount points.
- * tmp is up to you. You can create a different tmp directory for
- each client, or create some /clients/tmp directories, and mount it
- for each client under /tmp. I would recommend that you provide
- each client with a separate tmp directory.
-
- 3.3. Building the etc directory and configuring the clients
-
- Please Note - this section refers to building the etc directory which
- is mostly shared among the clients. If your diskless clients have
- separate system administrators, it's best to set up for each client a
- separate etc directory.
-
- 3.3.1. Building a clients wide etc directory
-
- Although we separate the etc directories of the clients, we still want
- to share a large portion of the files there. Generally, I think
- sharing the etc files with the server's /etc is a bad idea, and
- therefore I recommend creating a /clients/etc directory, which will
- hold the information needed for the clients. To start with, simply
- copy the contents of the server's etc to the /clients/etc directory.
-
- You should add to this directory all of the non-machine-specific
- configuration files, for instance motd, issue, etc. and not the client
- specific ones.(i.e. inittab or fstab)
-
- The most important changes will be in your rc.d directory. First, you
- should change rc.inet1 to be suitable for your local setup. I pass all
- my network parameters to the kernel through the LILO/Loadlin,
- therefore I remove almost everything from rc.inet1 file. The only
- thing I leave there is the ifconfig and route of the localhost. If you
- use rarp or bootp, you will have to build it accordingly.
-
- Secondly, you should edit your rc.S. First, remove all the parts that
- are responsible for the fsck check as fsck will occur when the server
- boots up. Then, you should find the line that mounts your fstab. This
- should look something like:
- mount -avt nonfs
-
- The -t nonfs is there since normal clients first run rc.S and only
- later on use rc.inet1 to configure the Ethernet. As this will cause no
- NFS partitions to be mounted this line should be deleted. Therefore,
- change it to mount -av. If you need to run rarp/bootp to configure
- your network, do it in rc.S (or call the appropriate script from
- rc.S), before the mount, and make sure your physical bin and sbin
- directories have the necessary files available.
-
- After the mount -av is performed, you will have a working file system.
- Build a general fstab, so that you can later copy it to each client.
- Your fstab should look something like this:
- server:/clients/hostname / nfs default 1 1
- server:/bin /bin nfs default 1 1
- server:/usr /usr nfs default 1 1
- server:/sbin /sbin nfs default 1 1
- server:/home /home nfs default 1 1
- server:/lib /lib nfs default 1 1
- server:/clients/etc /server/etc nfs default 1 1
- server:/clients/var /server/var nfs default 1 1
- none /proc proc default 1 1
-
- Please notice, that the keyword deafult might not work on all versions
- of mount. You might change it to rw or ro or remove all of the default
- 1 1 part.
-
- Also, make sure your server's /etc/exports looks like this:
- /clients/hostname hostname.domainname(rw,no_root_squash)
- /clients/etc hostname.domainname(ro,no_root_squash)
- /clients/var hostname.domainname(ro,no_root_squash)
- /usr hostname.domainname(ro,no_root_squash)
- /sbin hostname.domainname(ro,no_root_squash)
- /bin hostname.domainname(ro,no_root_squash)
- /lib hostname.domainname(ro,no_root_squash)
- /home hostname.domainname(rw,no_root_squash)
-
- Other than the first line, which should be separate for each host, the
- rest of the lines can be replaced with a hostmask to fit all your
- hosts (like pc*.domain - keep in mind though, that * will substitue
- only strings without a dot in them). I suggest that you make most of
- the directories read only, but this is up to you. The no_root_squash
- will make sure root users on the clients have actual root permissions
- on the nfsd as well. Check out man exports(5). If you want users to be
- able to run passwd from the clients also, make sure the /etc has rw
- and not ro permissions. However, this is not advisable.
-
- Please note another thing concerning the rc.S file. In Slackware, by
- default, it creates a new /etc/issue and /etc/motd every time it runs.
- This function MUST be disabled if these files are mounted ro from the
- server, and I would recommend that they should be disabled in any
- case.
-
- Lastly, if you want to have the same userbase on the server as on the
- clients, you should choose between 1), using NIS (Yellow Pages - check
- the yp-howto), and then each client will have a separate /etc/passwd
- and /etc/group as it receives it from the NIS server. 2) In most
- cases, a simple symbolic link will suffice. Therefore, you will need
- to either hardlink /clients/etc/passwd to /etc/passwd, or if you
- prefer a symlink, link /etc/passwd to /clients/etc/passwd (and not the
- other way around, since the clients do not mount the server's etc
- directory). Do the same for /etc/group.
-
- 3.3.2. Creating a client's etc directory
-
- Generally, most of the files in the client's etc should be symlinked
- to the /server/etc directory. However, some files are different for
- each machine, and some just have to be there when the kernel loads.
- The minimum you need from the etc dir is as follows:
- resolv.conf
- hosts
- inittab
- rc.d/rc.S
- fstab
-
- Since these 5 files can be identical on all clients, you can simply
- hardlink them or copy them again. However, with the rc.S and fstab
- file it is advised to keep a separate copy for each client. You will
- also need a separate etc/HOSTNAME for each client. I personally
- recommend having all of the rc.d files separate for each client, as
- configurationand hardware might vary from one to another.
-
- For each client, add to the fstab the proper swap line:
- /dev/swap_partition swap swap default 1 1
-
- The rest of the /etc files of the client, you can either hardlink to
- the /clients/etc/* files, or symlink them to the /server/etc (which is
- the mount point of /clients/etc/).
-
- Make sure your machine can resolve properly, either through a named or
- through etc/hosts. It is not a bad idea to keep the server's IP in the
- etc/hosts, instead of counting on resolving. If you will count only on
- named resolving, a problem in the named will prevent your clients from
- booting up.
-
- 3.4. Booting Up
-
- Now, all you have to do is to boot up your machine, cross your fingers
- and hope everything works as it should :-).
-
- 4. Creating more clients
-
- If you have followed my instructions so far this should be simple - cd
- to /clients/ and type:
- cp -a hostname1 hostname2
-
- and then make sure you check these points:
-
- rc.d/* files matches the hardware and wanted software configuration
- etc/HOSTNAME is correct, fstab's swap line is correct, the symbolic
- links of dev/mouse, dev/modem and dev/cdrom are right.
-
- Good Luck....
-
- References
-
- 1. http://www.hcs.co.il/oferm/
- 2. mailto:oferm@hcs.co.il
- 3. http://www.hcs.co.il/oferm/NFS-Root-Client/
- 4. mailto:oferm@hcs.co.il
- 5. mailto:gregh@sunsite.unc.edu
- 6. mailto:oferm@hcs.co.il
- 7. mailto:andreas@medman.ag.or.at
- 8. mailto:mark026@ibm.net
-