home *** CD-ROM | disk | FTP | other *** search
/ PC World 1999 August / PCWorld_1999-08_cd.bin / doc / HOWTO / mini / NFS-Root-Client < prev    next >
Text File  |  1999-02-08  |  17KB  |  354 lines

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