home *** CD-ROM | disk | FTP | other *** search
/ Freelog Special Edition 1: Linux / CD1.iso / doc / HOWTO / mini / NFS-Root-Client < prev    next >
Text File  |  1998-10-14  |  17KB  |  370 lines

  1.  
  2.    NFS-Root-Client Mini-Howto
  3.    Ofer Maor, ofer@hadar.co.il
  4.    V4, July 1st, 1997
  5.    
  6.    
  7.    The purpose of this Mini-Howto is to explain how to create client root
  8.    directories on a server that is using NFS Root mounted clients. You
  9.    can find the latest version of this Howto (HTML or Text) at URL:
  10.    http://www.hadar.co.il/ofer/nfs-root-client/
  11.    
  12.    1. Copyright
  13.    
  14.    (c) 1996 Ofer Maor (ofer@hadar.co.il)
  15.    
  16.    Unless otherwise stated, Linux HOWTO documents are copyrighted by
  17.    their respective authors. Linux HOWTO documents may be reproduced and
  18.    distributed in whole or in part, in any medium physical or electronic,
  19.    as long as this copyright notice is retained on all copies. Commercial
  20.    redistribution is allowed and encouraged; however, the author would
  21.    like to be notified of any such distributions.
  22.    
  23.    All translations, derivative works, or aggregate works incorporating
  24.    any Linux HOWTO documents must be covered under this copyright notice.
  25.    That is, you may not produce a derivative work from a HOWTO and impose
  26.    additional restrictions on its distribution. Exceptions to these rules
  27.    may be granted under certain conditions; please contact the Linux
  28.    HOWTO coordinator at the address given below.
  29.    
  30.    In short, we wish to promote dissemination of this information through
  31.    as many channels as possible. However, we do wish to retain copyright
  32.    on the HOWTO documents, and would like to be notified of any plans to
  33.    redistribute the HOWTOs.
  34.    
  35.    If you have questions, please contact Ofer Maor (ofer@hadar.co.il),
  36.    the author of this mini-HOWTO, or Greg Hankins, the Linux HOWTO
  37.    coordinator, at gregh@sunsite.unc.edu via email, or at +1 404 853
  38.    9989.
  39.    
  40.    If you have anything to add to this Mini-Howto, Please mail the author
  41.    (Ofer Maor, ofer@hadar.co.il), with the information. Any new relevant
  42.    information would be appreciated.
  43.    
  44.    1.1. Thanks
  45.    
  46.    I would like to express my thanks to the author of the NFS-Root Howto,
  47.    Andreas Kostyrca (andreas@medman.ag.or.at). His Mini-Howto helped me
  48.    with the first steps in creating a NFS Root Mounted client. My
  49.    Mini-Howto does not, in any way, try to replace his work, but to
  50.    enhance it using my experiences in this process.
  51.    
  52.    I would also like to thank Mark Kushinsky (mark026@ibm.net) for
  53.    polishing the english and spelling of this Howto, thus making it much
  54.    more readable.
  55.    
  56.    
  57.    
  58.    2. Preface
  59.    
  60.    This Mini-Howto was written in order to help people who want to use
  61.    NFS Root mounting to create their client's directories. Please note
  62.    that there are many ways to accomplish this, depending on your needs
  63.    and intent. If the clients are individual, and each client has its own
  64.    users and administrator, it will be necessary to make significant
  65.    parts of the client dirs not shared with other clients. On the other
  66.    hand if the client is intended for multiple users, and are all
  67.    administrated by the same person (for instance, a computer class),
  68.    make as many files as possible shareable in order to make
  69.    administration more manageable. This Howto will focus on the second
  70.    issue.
  71.    
  72.    2.1. General Overview
  73.    
  74.    When building a client's root directory, and trying to limit ourselves
  75.    to the minimum client size, we mainly focus on which files can we
  76.    share, or mount from the server. In this Howto I will recommend the
  77.    configuration of a client based on my experience. But before we begin
  78.    please note:
  79.    
  80.      * This Mini-Howto does not explain how to do the actual NFS Root
  81.        mounting. Reffer to the NFS-Root Mini-Howto if you need more
  82.        information about that issue.
  83.        
  84.      * I based most of my client's configuration on mounts and symbolic
  85.        links. A lot of those symbolic links can be replaced by hardlinks.
  86.        One should choose according to his personal preference. Putting a
  87.        hardlink over a mount and a symbolic link has its advantages, but
  88.        might cause confusion. A file will not be erased until all its
  89.        hardlinks are removed. Thus, In order to prevent a case in which
  90.        you upgrade a certain file, and the hardlinks still refer to the
  91.        older version, you will have to be very careful and keep track of
  92.        every link you put.
  93.        
  94.      * While mounting the information from the server, two concepts can
  95.        be used. The first (most common) concept, is to mount the whole
  96.        server root directory under a local directory, and then just
  97.        change the path or link the relevant directories there. I
  98.        personally dislike mounting root partitions of a server on
  99.        clients. Thus, this Howto suggests a way to mount the relevant
  100.        directories of the server to the relevant places on the system.
  101.        
  102.      * This Howto is based on my experience building client directories
  103.        on a Slackware 3.1 based distribution. Things may be different
  104.        (especially on the rc.* files), for other users, however the
  105.        concepts should still remain the same.
  106.        
  107.    
  108.    
  109.    3. Creating the client's root directory
  110.    
  111.    3.1. Creating the directory tree
  112.    
  113.    First of all, you need to create the directory structure itself. I
  114.    created all the clients under /clients/hostname and I will use it for
  115.    my examples listed below. This, however, can be changed to anything
  116.    else. The first stage, then, is to create the relevant directories in
  117.    the root directory. You should create the following directories:
  118.  
  119.     bin, dev, etc, home, lib, mnt, proc, sbin, server, tmp, usr, var
  120.  
  121.    and any other directories you might want to have on your system.
  122.    
  123.    The local, proc, and dev directories will be used separately on each
  124.    machine while the rest of the directories will be either party or
  125.    completely shared with the rest of the clients.
  126.    
  127.    3.2. Creating the minimal file system needed for boot
  128.    
  129.    3.2.1. Creating the dev dir.
  130.    
  131.    Although the dev dir can be shared, it is better to create a separate
  132.    one for each client. You can create your client's dev directory with
  133.    the appropriate MAKEDEV scripts, however in most cases it is simpler
  134.    just to copy it from the server:
  135.  
  136.     cp -a /dev /clients/hostname
  137.  
  138.    You should keep in mind that /dev/mouse, /dev/cdrom and /dev/modem are
  139.    symbolic links to actually devices, and therefore you should be sure
  140.    that they are linked correctly to fit the client's hardware.
  141.    
  142.    3.2.2. Copying the necessary binaries.
  143.    
  144.    Although we mount everything from the server, there is a minimum that
  145.    we need to copy to each client. First of all, we need "init", our
  146.    system will not be able to run anything before init'ing (as the author
  147.    found out in the hard way ;-). So first, you should copy /sbin/init to
  148.    your client's sbin dir and then so that rc.S will run, you should copy
  149.    /bin/sh to the client's bin directory. Also, in order to mount
  150.    everything you need to copy /sbin/mount to the client's sbin
  151.    directory. This is the minimum, assuming the first line in your rc.S
  152.    is mount -av. However, I recommend copying a few more files: update,
  153.    ls, rm, cp and umount, so that you will have the basic tools in case
  154.    the client has problems mounting. If you choose to leave your swap on
  155.    line before mount, you should also copy the swapon binary.
  156.    
  157.    Since most of these binaries are by default dynamically linked, you
  158.    will also need to copy a fair part of /lib:
  159.  
  160.     cp -a /lib/ld* /lib/libc.* /lib/libcursses.* /client/hostname/lib
  161.  
  162.    Hardlinking the binaries themselves, instead of copying them, should
  163.    be considered. Please read my comments on this in part 2.1 of this
  164.    Howto.
  165.    
  166.    Please notice, all of the information above assumes that the kernel
  167.    has been given the network parameters while booting up. If you plan to
  168.    use rarp or bootp, you will probably need the relevant binaries for
  169.    these as well.
  170.    
  171.    Generally, you will need the minimum of files that will enable you to
  172.    configure the network and run rc.S up to the point where it mounts the
  173.    rest of the file system. Make sure you looked into your /etc/init and
  174.    rc.S files, making sure there are no "surprises" in any of them, which
  175.    will require other files to be accessed, before the first mount will
  176.    take place. If you do, however, find such files, you can either copy
  177.    them as well, or remove the relevant parts from your init and your
  178.    rc.S files.
  179.    
  180.    3.2.3. The var directory
  181.    
  182.    The var directory, in most cases, should be separate for each client.
  183.    However, a lot of the data can be shared. Create under the server
  184.    directory a directory called var. We will mount the server's var
  185.    directory there. To create the local var directory, simply type:
  186.  
  187.     cp -a /var /clients/hostname/
  188.  
  189.    Now, you have a choice as to what you want to separate, and what you
  190.    want to share. Any directory/file that you want to share, simply
  191.    remove it from the client's var dir, and symlink it to the
  192.    /server/var/ directory. However please note that you should either
  193.    symlink it to /server/var or to ../server/var but NOT to
  194.    /clients/hostname/server/var as this will not work when the root
  195.    changes.
  196.    
  197.    Generally, I would recommend separating /var/run, /var/lock,
  198.    /var/spool, and /var/log.
  199.    
  200.    3.2.4. The rest of the directories
  201.    
  202.      * etc is explained thoroughly in the next section.
  203.      * mnt and proc are for local purposes.
  204.      * usr and home are merely mount points.
  205.      * tmp is up to you. You can create a different tmp directory for
  206.        each client, or create some /clients/tmp directories, and mount it
  207.        for each client under /tmp. I would recommend that you provide
  208.        each client with a separate tmp directory.
  209.        
  210.    
  211.    
  212.    3.3. Building the etc directory and configuring the clients
  213.    
  214.    Please Note - this section refers to building the etc directory which
  215.    is mostly shared among the clients. If your diskless clients have
  216.    separate system administrators, it's best to set up for each client a
  217.    separate etc directory.
  218.    
  219.    3.3.1. Building a clients wide etc directory
  220.    
  221.    Although we separate the etc directories of the clients, we still want
  222.    to share a large portion of the files there. Generally, I think
  223.    sharing the etc files with the server's /etc is a bad idea, and
  224.    therefore I recommend creating a /clients/etc directory, which will
  225.    hold the information needed for the clients. To start with, simply
  226.    copy the contents of the server's etc to the /clients/etc directory.
  227.    
  228.    You should add to this directory all of the non-machine-specific
  229.    configuration files, for instance motd, issue, etc. and not the client
  230.    specific ones.(i.e. inittab or fstab)
  231.    
  232.    The most important changes will be in your rc.d directory. First, you
  233.    should change rc.inet1 to be suitable for your local setup. I pass all
  234.    my network parameters to the kernel through the LILO/Loadlin,
  235.    therefore I remove almost everything from rc.inet1 file. The only
  236.    thing I leave there is the ifconfig and route of the localhost. If you
  237.    use rarp or bootp, you will have to build it accordingly.
  238.    
  239.    Secondly, you should edit your rc.S. First, remove all the parts that
  240.    are responsible for the fsck check as fsck will occur when the server
  241.    boots up. Then, you should find the line that mounts your fstab. This
  242.    should look something like:
  243.  
  244.     mount -avt nonfs
  245.  
  246.    The -t nonfs is there since normal clients first run rc.S and only
  247.    later on use rc.inet1 to configure the Ethernet. As this will cause no
  248.    NFS partitions to be mounted this line should be deleted. Therefore,
  249.    change it to mount -av. If you need to run rarp/bootp to configure
  250.    your network, do it in rc.S (or call the appropriate script from
  251.    rc.S), before the mount, and make sure your physical bin and sbin
  252.    directories have the necessary files available.
  253.    
  254.    After the mount -av is performed, you will have a working file system.
  255.    Build a general fstab, so that you can later copy it to each client.
  256.    Your fstab should look something like this:
  257.  
  258.     server:/clients/hostname    /               nfs     default  1 1
  259.     server:/bin                 /bin            nfs     default  1 1
  260.     server:/usr                 /usr            nfs     default  1 1
  261.     server:/sbin                /sbin           nfs     default  1 1
  262.     server:/home                /home           nfs     default  1 1
  263.     server:/lib                 /lib            nfs     default  1 1
  264.     server:/clients/etc         /server/etc     nfs     default  1 1
  265.     server:/clients/var         /server/var     nfs     default  1 1
  266.     none                        /proc           proc    default  1 1
  267.  
  268.    Please notice, that the keyword _deafult_ might not work on all
  269.    versions of mount. You might change it to _rw_ or _ro_ or remove all
  270.    of the _default 1 1_ part.
  271.    
  272.    Also, make sure your server's /etc/exports looks like this:
  273.  
  274.     /clients/hostname   hostname.domainname(rw,no_root_squash)
  275.     /clients/etc        hostname.domainname(ro,no_root_squash)
  276.     /clients/var        hostname.domainname(ro,no_root_squash)
  277.     /usr                hostname.domainname(ro,no_root_squash)
  278.     /sbin               hostname.domainname(ro,no_root_squash)
  279.     /bin                hostname.domainname(ro,no_root_squash)
  280.     /lib                hostname.domainname(ro,no_root_squash)
  281.     /home               hostname.domainname(rw,no_root_squash)
  282.  
  283.    Other than the first line, which should be separate for each host, the
  284.    rest of the lines can be replaced with a hostmask to fit all your
  285.    hosts (like pc*.domain - keep in mind though, that * will substitue
  286.    only strings without a dot in them). I suggest that you make most of
  287.    the directories read only, but this is up to you. The no_root_squash
  288.    will make sure root users on the clients have actual root permissions
  289.    on the nfsd as well. Check out man exports(5). If you want users to be
  290.    able to run passwd from the clients also, make sure the /etc has rw
  291.    and not ro permissions. However, this is not advisable.
  292.    
  293.    Please note another thing concerning the rc.S file. In Slackware, by
  294.    default, it creates a new /etc/issue and /etc/motd every time it runs.
  295.    This function MUST be disabled if these files are mounted ro from the
  296.    server, and I would recommend that they should be disabled in any
  297.    case.
  298.    
  299.    Lastly, if you want to have the same userbase on the server as on the
  300.    clients, you should choose between 1), using NIS (Yellow Pages - check
  301.    the yp-howto), and then each client will have a separate /etc/passwd
  302.    and /etc/group as it receives it from the NIS server. 2) In most
  303.    cases, a simple symbolic link will suffice. Therefore, you will need
  304.    to either hardlink /clients/etc/passwd to /etc/passwd, or if you
  305.    prefer a symlink, link /etc/passwd to /clients/etc/passwd (and not the
  306.    other way around, since the clients do not mount the server's etc
  307.    directory). Do the same for /etc/group.
  308.    
  309.    3.3.2. Creating a client's etc directory
  310.    
  311.    Generally, most of the files in the client's etc should be symlinked
  312.    to the /server/etc directory. However, some files are different for
  313.    each machine, and some just have to be there when the kernel loads.
  314.    The minimum you need from the etc dir is as follows:
  315.  
  316.     resolv.conf
  317.     hosts
  318.     inittab
  319.     rc.d/rc.S
  320.     fstab
  321.  
  322.    Since these 5 files can be identical on all clients, you can simply
  323.    hardlink them or copy them again. However, with the rc.S and fstab
  324.    file it is advised to keep a separate copy for each client. You will
  325.    also need a separate etc/HOSTNAME for each client. I personally
  326.    recommend having all of the rc.d files separate for each client, as
  327.    configurationand hardware might vary from one to another.
  328.    
  329.    For each client, add to the fstab the proper swap line:
  330.  
  331.     /dev/swap_partition                 swap    swap    default  1 1
  332.  
  333.    The rest of the /etc files of the client, you can either hardlink to
  334.    the /clients/etc/* files, or symlink them to the /server/etc (which is
  335.    the mount point of /clients/etc/).
  336.    
  337.    Make sure your machine can resolve properly, either through a named or
  338.    through etc/hosts. It is not a bad idea to keep the server's IP in the
  339.    etc/hosts, instead of counting on resolving. If you will count only on
  340.    named resolving, a problem in the named will prevent your clients from
  341.    booting up.
  342.    
  343.    3.4. Booting Up
  344.    
  345.    Now, all you have to do is to boot up your machine, cross your fingers
  346.    and hope everything works as it should :-).
  347.    
  348.    
  349.    
  350.    4. Creating more clients
  351.    
  352.    If you have followed my instructions so far this should be simple - cd
  353.    to /clients/ and type:
  354.  
  355.     cp -a hostname1 hostname2
  356.  
  357.    and then make sure you check these points:
  358.    
  359.    rc.d/* files matches the hardware and wanted software configuration
  360.    etc/HOSTNAME is correct, fstab's swap line is correct, the symbolic
  361.    links of dev/mouse, dev/modem and dev/cdrom are right.
  362.    
  363.    
  364.    
  365.    
  366.    
  367.    
  368.    
  369.    Good Luck....
  370.