mirror of https://github.com/tLDP/LDP
Brieuc updated this Howto to include lots of ffedback and links to several new projects.
This commit is contained in:
nico
parent
e24e8a0830
commit
3f75ad566c
|
|
@ -6,7 +6,7 @@
|
|||
<!entity logilaburl "http://www.logilab.org">
|
||||
|
||||
<!entity etb "etherboot">
|
||||
<!entity etburl "http://etherboot.sourceforge.net/">
|
||||
<!entity etburl "http://etherboot.sourceforge.net">
|
||||
|
||||
<!entity ltsp "linux terminal server project">
|
||||
<!entity ltspurl "http://www.ltsp.org">
|
||||
|
|
@ -14,15 +14,17 @@
|
|||
<!entity vmware "VMWare">
|
||||
<!entity vmwareurl "http://www.vmware.com">
|
||||
|
||||
<!entity freemware "FreeMWare">
|
||||
<!entity freemwareurl "http://www.freemware.org">
|
||||
<!entity plex86 "plex86">
|
||||
<!entity plex86url "http://www.plex86.org">
|
||||
|
||||
<!entity imggenurl "ftp://www.ltsp.org/pub/download/lts/contrib">
|
||||
<!entity imggenurl "http://www.ltsp.org/contrib/">
|
||||
|
||||
<!entity disklesshowtourl "http://www.linuxdoc.org/HOWTO/Diskless-HOWTO.html">
|
||||
|
||||
<!entity disklessrootnfshowtourl "http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html">
|
||||
|
||||
<!entity bootdiskhowtourl "http://www.tldp.org/HOWTO/Bootdisk-HOWTO/index.html">
|
||||
|
||||
<!entity powerup2bashurl "http://www.linuxdoc.org/HOWTO/From-PowerUp-to-bash-prompt-HOWTO.html">
|
||||
|
||||
<!entity thinclienturl "http://www.linuxdoc.org/HOWTO/Thin-Client-HOWTO.html">
|
||||
|
|
@ -30,10 +32,19 @@
|
|||
<!entity cdwritingurl "http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html">
|
||||
|
||||
<!entity ntb "netboot">
|
||||
<!entity ntburl "http://www.han.de/~gero/netboot/">
|
||||
<!entity ntburl "http://netboot.sourceforge.net">
|
||||
|
||||
<!entity clusternfs "clusternfs">
|
||||
<!entity clusternfsurl "http://clusternfs.sourceforge.net">
|
||||
|
||||
<!entity grub "GRUB">
|
||||
<!entity gruburl "http://www.gnu.org/software/grub/">
|
||||
|
||||
<!entity clientsrootbuilding "Clients setup, creation of the root filesystem">
|
||||
|
||||
<!entity plume "plume">
|
||||
<!entity plumeurl "http://plume.sourceforge.net">
|
||||
|
||||
]>
|
||||
|
||||
<article>
|
||||
|
|
@ -46,30 +57,30 @@
|
|||
<author>
|
||||
<firstname>Brieuc</firstname>
|
||||
<surname>Jeunhomme</surname>
|
||||
<affiliation>
|
||||
<orgname>frtest</orgname>
|
||||
<address>
|
||||
<email>bbp@via.ecp.fr</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<corpauthor>Logilab S.A.</corpauthor>
|
||||
</authorgroup>
|
||||
|
||||
<abstract>
|
||||
|
||||
<para>This document explains how to quickly setup a linux server to provide
|
||||
what diskless linux clients require to get up and running, using an IP
|
||||
network. It includes data and partly rewritten text from the Diskless-HOWTO,
|
||||
the Diskless-root-NFS-HOWTO, the linux kernel documentation, the &etb;
|
||||
project's documentation, the <sp;'s homepage, and the author's personal
|
||||
experience, acquired when working for &logilab;. Eventually this document
|
||||
may end up deprecating the Diskless-HOWTO and
|
||||
Diskless-root-NFS-HOWTO. Please note that you'll also find useful
|
||||
information in the From-PowerUp-to-bash-prompt-HOWTO and the
|
||||
Thin-Client-HOWTO, and the Claus-Justus Heine's page about NFS
|
||||
swapping.</para>
|
||||
<para>This document explains how to quickly setup a linux server to provide what diskless linux clients require to get up and running, using an IP network. It includes data and partly rewritten text from the Diskless-HOWTO, the Diskless-root-NFS-HOWTO, the linux kernel documentation, the &etb; project's documentation, the <sp;'s homepage, and the author's personal experience, acquired when working for &logilab;. Eventually this document may end up deprecating the Diskless-HOWTO and Diskless-root-NFS-HOWTO. Please note that you'll also find useful information in the From-PowerUp-to-bash-prompt-HOWTO and the Thin-Client-HOWTO, and the Claus-Justus Heine's page about NFS swapping.</para>
|
||||
|
||||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<!-- To-Do list -->
|
||||
<!-- include documentation about netboot ; -->
|
||||
<!-- a word about grub ; devfs; DHCP daemon setup -->
|
||||
|
||||
<revision>
|
||||
<revnumber>0.3</revnumber>
|
||||
<date>2002-04-28</date>
|
||||
<authorinitials>bej</authorinitials>
|
||||
<revremark>Many feedback inclusions, added links to several projects</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>0.2.2</revnumber>
|
||||
|
|
@ -125,10 +136,12 @@
|
|||
|
||||
<title>Thanks</title>
|
||||
|
||||
<para>&logilab; sponsored this HOWTO. Check their <ulink url="&logilaburl;">website</ulink> for new versions of this document. I also thank the &etb; and <sp; developers and webmasters, who made it really possible to boot a Linux worstation over a network.</para>
|
||||
<para>&logilab; sponsored this HOWTO. Check their <ulink url="&logilaburl;">website</ulink> for new versions of this document. I also thank the &etb;, &ntb;, &plume; and <sp; developers and webmasters, who made it really possible to boot a Linux worstation over a network.</para>
|
||||
|
||||
<para>Very special thanks go to Ken Yap, member of the &etb; project, whose comments greatly helped to improve the quality of this document.</para>
|
||||
|
||||
<para>I also thank Jerome Warnier, main developer of the &plume; project, Pierre Mondié, Kyle Bateman, Peter T. Breuer, Charles Howes, and Thomas Marteau for their comments and contributions.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -273,7 +286,7 @@
|
|||
This document is copyrighted (c) 2001 and
|
||||
is distributed under the terms of the GNU Free Documentation License.
|
||||
You should have received a copy along with it. If not, it is available from
|
||||
<a href="http://www.fsf.org/licenses/fdl.html">http://www.fsf.org/licenses/fdl.html</a>.
|
||||
<ulink url="http://www.fsf.org/licenses/fdl.html">http://www.fsf.org/licenses/fdl.html</ulink>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -342,7 +355,7 @@
|
|||
|
||||
<title>Building the kernel</title>
|
||||
|
||||
<para>Firs of all, build a kernel for the clients. I suggest you build it on the server, this will be useful later for modules installation. Use a zImage to reduce its size. Include everything you need, but try to use as many modules as possible, because many BOOTP client implementations are unable to load very large kernels (at least on intel x86 architectures). Also include iramdisk support, NFS protocol support, root filesystem on NFS support, support for your NIC, kernel level IP autoconfiguration via BOOTP; <emphasis>do not use modules for these!</emphasis> Then, if you plan to use the same remote root filesystem for several clients, add support for ext2fs or some other filesystem and ramdisks (16 Megabytes ramdisks will do fine on most systems). You can then modify the kernel arguments as usual (see the BootPrompt-HOWTO for information on this topic), but you will have another opportunity to modify kernel arguments later.</para>
|
||||
<para>First of all, build a kernel for the clients. I suggest you build it on the server, this will be useful later for modules installation. Use a zImage to reduce its size. Include everything you need, but try to use as many modules as possible, because many BOOTP client implementations are unable to load very large kernels (at least on intel x86 architectures). Also include iramdisk support, NFS protocol support, root filesystem on NFS support, support for your NIC, kernel level IP autoconfiguration via BOOTP; <emphasis>do not use modules for these!</emphasis> Then, if you plan to use the same remote root filesystem for several clients, add support for ext2fs or some other filesystem and ramdisks (16 Megabytes ramdisks will do fine on most systems). You can then modify the kernel arguments as usual (see the BootPrompt-HOWTO for information on this topic), but you will have another opportunity to modify kernel arguments later.</para>
|
||||
|
||||
<para>Then, if you plan to use BOOTP, copy the kernel zImage on the server. We will assume it resides in <filename class="directory">/tftpboot</filename>, its name is zImage, the name of the image you want to create from this zImage for BOOTP operation is kernel, and the nfs root filesystem will reside in <filename class="directory">/nfsroot</filename>.</para>
|
||||
|
||||
|
|
@ -547,7 +560,7 @@
|
|||
|
||||
Don't forget to chmod 555 the <filename class="directory">/tftpboot</filename> directory, as most TFTP servers won't send the files if they are not world readable.</para>
|
||||
|
||||
<para>You should be aware of the limitations implied by running the TFTP daemon from the inetd. Most inetd's will hsutdown a service if it is spawned to frequently. So if you have many clients, you should look for another inetd like xinetd, or run a standalone TFTP daemon.</para>
|
||||
<para>You should be aware of the limitations implied by running the TFTP daemon from the inetd. Most inetd's will shutdown a service if it is spawned to frequently. So if you have many clients, you should look for another inetd like xinetd, or run a standalone TFTP daemon.</para>
|
||||
|
||||
<para>Now you have properly setup all daemons, you can restart the inetd and take a coffee. Don't forget to tell everyone the server setup is over, so you think you're a hero before you start building the root filesystem for the clients.</para>
|
||||
|
||||
|
|
@ -567,7 +580,7 @@
|
|||
|
||||
<title>Creating the first files and directories</title>
|
||||
|
||||
<para>First, <command>cd</command> to your future station's root directory. You can safely create the future <filename class="directory">/home</filename> directory with the <command>mkdir</command>, or by copying it from anywhere you want (you can use <command>cp -a</command> to do a recursive copy preserving owners, groups, symlinks, and permissions). Same thing for the future <filename class="directory">/mnt</filename>, <filename class="directory">/root</filename>, <filename class="directory">/tmp</filename> (don't forget to <command>chmod 0</command> it, this is only a mount point for the actual <filename class="directory">/tmp</filename> we will use, because each workstation needs to have its own <filename class="directory">/tmp</filename>). Then, copy some existing <filename class="directory">/bin</filename>, <filename class="directory">/sbin</filename>, <filename class="directory">/boot</filename>, and <filename class="directory">/usr</filename> into this future root directory (use <command>cp -a</command>). You can create the <filename class="directory">/proc</filename> directory with mkdir, and <command>chmod 0</command> it. Note some applications need write access to their user's home directory.</para>
|
||||
<para>First, <command>cd</command> to your future station's root directory. You can safely create the future <filename class="directory">/home</filename> directory with the <command>mkdir</command> command, or by copying it from anywhere you want (you can use <command>cp -a</command> to do a recursive copy preserving owners, groups, symlinks, and permissions). Same thing for the future <filename class="directory">/mnt</filename>, <filename class="directory">/root</filename>, <filename class="directory">/tmp</filename> (don't forget to <command>chmod 0</command> it, this is only a mount point for the actual <filename class="directory">/tmp</filename> we will use, because each workstation needs to have its own <filename class="directory">/tmp</filename>). Then, copy some existing <filename class="directory">/bin</filename>, <filename class="directory">/sbin</filename>, <filename class="directory">/boot</filename>, and <filename class="directory">/usr</filename> into this future root directory (use <command>cp -a</command>). You can create the <filename class="directory">/proc</filename> directory with mkdir, and <command>chmod 0</command> it. Note some applications need write access to their user's home directory.</para>
|
||||
|
||||
<para>The <filename class="directory">/lib</filename> directory can be safely copied from somewhere else, but you will have to put the proper modules in it. To do so, use the following commands (assuming you have compiled the kernel for your clients on the server in <filename class="directory">/usr/src/linux</filename>, and the root filesystem will reside in <filename class="directory">/nfsroot</filename>):
|
||||
|
||||
|
|
@ -721,7 +734,7 @@
|
|||
|
||||
<sect1>
|
||||
|
||||
<title>Several ways of obtaining the bootloader's code</title>
|
||||
<title>Several ways of obtaining the kernel</title>
|
||||
|
||||
<para>We have spoken so far about the client and server's configuration for operation after the BOOTP request has been issued by the client, but the first problem is that most computers are not able to behave as BOOTP clients by default. We will see in this section how to fix this.</para>
|
||||
|
||||
|
|
@ -735,7 +748,7 @@
|
|||
|
||||
<sect2>
|
||||
|
||||
<title>Local floppy or hard drive</title>
|
||||
<title>Kernel on a local floppy or hard drive</title>
|
||||
|
||||
<para>These cases are also quite simple: the kernel is loaded from a local drive, and all the kernel has to do is to obtain its network parameters from BOOTP, and mount its root filesystem over NFS; this should not cause any problem. By the way, a local hard drive is a good place to leave a <filename class="directory">/var</filename>, <filename class="directory">/tmp</filename>, and a <filename class="directory">/dev</filename>...</para>
|
||||
|
||||
|
|
@ -747,6 +760,30 @@
|
|||
|
||||
</para>
|
||||
|
||||
<para>However, Alan Cox told in a linux-kernel thread that this feature of the linux kernel will be removed sooner or later, you thus will have to use a bootloader even on floppies some day. I know this still works with 2.4.11 kernels, but support seems to have been removed in the 2.4.13 version. See the sixth chapter of the <ulink url="&bootdiskhowtourl;">boot-disk-HOWTO</ulink> for this topic.
|
||||
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
||||
<title>Bootloader without kernel on a local floppy or hard drive</title>
|
||||
|
||||
<para>Certain bootloaders are network aware, you may thus use them to download the kernel image from the network. Some of them are listed below:</para>
|
||||
|
||||
<itemizedlist mark="opencircle">
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="&ntburl;">&ntb;</ulink>, a bootloader dedicated to network boot.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="&gruburl;">&grub;</ulink>, the GNU project's GRand Unified Bootloader, which is a very general purpose bootloader.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -1101,7 +1138,7 @@
|
|||
|
||||
<title>How to create diskless MS-Windows stations?</title>
|
||||
|
||||
<para>Since MS-Windows does not support diskless booting, a simple workaround is presented here: the solution is to use software like <ulink url="&vmwareurl;">&vmware;</ulink> or its free alternative, <ulink url="&freemwareurl;">&freemware;</ulink>. These enable MS-Windows to be executed transparently on the linux box.</para>
|
||||
<para>Since MS-Windows does not support diskless booting, a simple workaround is presented here: the solution is to use software like <ulink url="&vmwareurl;">&vmware;</ulink> or its free alternative, <ulink url="&plex86url;">&plex86;</ulink>. Although the &plex86; seems to have been abandonned, one can still boot certain versions of MS-Windows using this software. These enable MS-Windows to be executed transparently on the linux box.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
|
@ -1111,9 +1148,13 @@
|
|||
|
||||
<sect2>
|
||||
|
||||
<title>The &ntb; distribution</title>
|
||||
<title>Transparently handling workstations'specific files</title>
|
||||
|
||||
<para>This <ulink url="&ntburl;">distribution</ulink> contains a bootloader enabling one to boot diskless stations with either Linux or DOS. This is an alternative to the usage of etherboot.</para>
|
||||
<para>
|
||||
|
||||
The previous sections discussed a simple way to handle workstations'specific files and directories like <filename class="directory">/var</filename>. Most of them are simply build on the fly and put on ramdisks, you may however prefer to deal with this problem on the NFS server. The &clusternfs; project provides a network filesystem server that can serve different files based on several criteria including the client's IP address or host name. The basic idea is that if the client whose IP address is 10.2.12.42 requests a file named, for instance, <filename>myfile</filename>, the server will look for a file named <filename>myfile$$IP=10.2.12.42$$</filename> and serve this file instead of <filename>myfile</filename> if it is available.
|
||||
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
|
@ -1139,7 +1180,7 @@
|
|||
|
||||
<title>Swapping over NFS</title>
|
||||
|
||||
<para>If your stations do not have enough memory and do not have local drives, you may want to swap over NFS. You have to be warned the cod eto do so is still under developpement and this method is generally quite slow. The full documentation for this can be found at <ulink url="http://www.instmath.rwth-aachen.de/~heine/nfs-swap/">http://www.instmath.rwth-aachen.de/~heine/nfs-swap/</ulink>.</para>
|
||||
<para>If your stations do not have enough memory and do not have local drives, you may want to swap over NFS. You have to be warned the cod eto do so is still under development and this method is generally quite slow. The full documentation for this can be found at <ulink url="http://www.instmath.rwth-aachen.de/~heine/nfs-swap/">http://www.instmath.rwth-aachen.de/~heine/nfs-swap/</ulink>.</para>
|
||||
|
||||
<para>The first thing to do if you want to apply this solution is to patch your kernel (you need a kernel version 2.2 or above). First download the patch at the above url, and cd to <filename class="directory">/usr/src/linux</filename>. I assume the patch is in <filename>/usr/src/patch</filename>. Then issue the following command:
|
||||
|
||||
|
|
@ -1171,7 +1212,7 @@
|
|||
|
||||
<title>Swapping over network block devices</title>
|
||||
|
||||
<para>I have to warn you I never tryed this, and I would particularly appreciate feedback about this section.</para>
|
||||
<para>Although I have never tried it personally, I got report that the trick described below works, at least with recent kernels.</para>
|
||||
|
||||
<para>The general principle for swapping over network block devices is the same than to swap over NFS. The good point is you won't have to patch the kernel. But most of the same drawbacks also apply to the NBD method.</para>
|
||||
|
||||
|
|
@ -1292,7 +1333,14 @@
|
|||
|
||||
<para>The speed of the EPROM needed depends on how it is connected to the computer bus. If the EPROM is directly connected to the computer bus, as in the case of many cheap NE2000 clones, then you will probably have to get an EPROM that is at least as fast as the ROMs used for the main BIOS. This is typically 120-150 ns. Some network cards mediate access to the EPROM via circuitry and this may insert wait states so that slower EPROMs can be used. Incidentally the slowness of the EPROM doesn't affect Etherboot execution speed much because Etherboot copies itself to RAM before executing. I'm told Netboot does the same thing.</para>
|
||||
|
||||
<para>If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities at <ulink url="http://www.canb.auug.org.au/~millerp/srecord.html">http://www.canb.auug.org.au/~millerp/srecord.html</ulink>. The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site at <ulink url="http://etherboot.sourceforge.net/bin2intelhex.c">http://etherboot.sourceforge.net/bin2intelhex.c</ulink>.</para>
|
||||
<para>If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities at <ulink url="http://www.canb.auug.org.au/~millerp/srecord.html">http://www.canb.auug.org.au/~millerp/srecord.html</ulink>. The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site at <ulink url="http://etherboot.sourceforge.net/bin2intelhex.c">http://etherboot.sourceforge.net/bin2intelhex.c</ulink>. You may alternatively use the objcopy utility, included in the binutils package:
|
||||
|
||||
<programlisting>
|
||||
<prompt># </prompt>objcopy --input-target binary --output-target ihex binary.file intelhex.file
|
||||
<prompt># </prompt>objcopy --input-target ihex --output-target binary intelhex.file binary.file
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Etherboot is believed to make PnP compliant ROMs for PCI NICs. A long-standing bug in the headers has been tracked down. However some faulty old BIOSes are out there so I have written a Perl script swapdevids.pl to switch the header around if necessary. You'll have to experiment with it both ways to find out which works. Or you could dump a ROM image that works (e.g. RPL, PXE ROM) using the Perl script disrom.pl. The fields to look at are Device (base, sub, interface) Type. It should be 02 00 00, but some BIOSes want 00 00 02 due to ambiguity in the original specification.</para>
|
||||
|
||||
|
|
@ -1335,11 +1383,27 @@
|
|||
<address>&disklessrootnfshowtourl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="Bootdisk-HOWTO">
|
||||
<title>Boot-disk-HOWTO</title>
|
||||
<address>&bootdiskhowtourl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="ltsp">
|
||||
<title>Linux Terminal Server Project</title>
|
||||
<title><sp;</title>
|
||||
<abstract>
|
||||
<simpara>A set of utilities and documentation for diskless stations, based on the red hat distribution.</simpara>
|
||||
</abstract>
|
||||
<address><spurl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="&plume;">
|
||||
<title>&plume;</title>
|
||||
<abstract>
|
||||
<simpara>A beginning project whose goal is to provide a set of utilities for diskless stations and associated servers, based on the debian distribution.</simpara>
|
||||
</abstract>
|
||||
<address>&plumeurl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="logilab">
|
||||
<title>Logilab.org web site</title>
|
||||
<address>&logilaburl;</address>
|
||||
|
|
@ -1361,18 +1425,24 @@
|
|||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="etb">
|
||||
<title>etherboot project</title>
|
||||
<title>&etb; project</title>
|
||||
<address>&etburl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="vmware">
|
||||
<title>VMWare</title>
|
||||
<biblioentry xreflabel="&vmware;">
|
||||
<title>&vmware;</title>
|
||||
<abstract>
|
||||
<simpara>A non free virtual machine software.</simpara>
|
||||
</abstract>
|
||||
<address>&vmwareurl;</address>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="freemware">
|
||||
<title>FreeMWare</title>
|
||||
<address>&freemwareurl;</address>
|
||||
<biblioentry xreflabel="&plex86;">
|
||||
<title>&plex86;</title>
|
||||
<abstract>
|
||||
<simpara>A free virtual machine software.</simpara>
|
||||
</abstract>
|
||||
<address>&plex86url;</address>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
|
|
|||
Loading…
Reference in New Issue