个人工具

“UbuntuHelp:DisklessUbuntuHowto”的版本间的差异

来自Ubuntu中文

跳转至: 导航, 搜索
第8行: 第8行:
 
Thin clients use some of the same principals but they also connect to a remote X session, which means everything runs on the remote server, all applications will consume the servers resources, such as RAM and CPU cycles.
 
Thin clients use some of the same principals but they also connect to a remote X session, which means everything runs on the remote server, all applications will consume the servers resources, such as RAM and CPU cycles.
 
Diskless Booting simply uses the remote server for storage and still runs all applications on the local client station. This works better if you have full powered PC's to work with, and are working with a large number of clients that would require too much CPU and RAM to run all their applications on one server.
 
Diskless Booting simply uses the remote server for storage and still runs all applications on the local client station. This works better if you have full powered PC's to work with, and are working with a large number of clients that would require too much CPU and RAM to run all their applications on one server.
It is different enough to have multiple machines mounting the same / filesystem as opposed to simply being a remote monitor and keyboard to warrant a separate how-to I think.
+
It is different enough to have multiple machines mounting the same root filesystem as opposed to simply being a remote monitor and keyboard to warrant a separate how-to I think.
 
Oliver Grawert says :- ''you could have achieved this easier by following the thin client howto, remove the ltsp-client package from the chroot and install ubuntu-desktop (or whatever desktop you want) there, would save you a lot of configuration work ;)''
 
Oliver Grawert says :- ''you could have achieved this easier by following the thin client howto, remove the ltsp-client package from the chroot and install ubuntu-desktop (or whatever desktop you want) there, would save you a lot of configuration work ;)''
 
== How does it work? ==
 
== How does it work? ==
第52行: 第52行:
 
* configure tftp-hpa
 
* configure tftp-hpa
 
Before tftp will run, we need to configure it to run in daemon mode.
 
Before tftp will run, we need to configure it to run in daemon mode.
<br>    sudo vi /etc/default/tftp-hpa
+
<<BR>>    sudo vi /etc/default/tftp-hpa
<br>    Change  
+
<<BR>>    Change  
<br>    RUN_DAEMON="no"
+
<<BR>>    RUN_DAEMON="no"
<br>    to
+
<<BR>>    to
<br>    RUN_DAEMON="yes"
+
<<BR>>    RUN_DAEMON="yes"
<br>    and the second line to
+
<<BR>>    and the second line to
<br>    OPTIONS="-l -s /tftpboot"
+
<<BR>>    OPTIONS="-l -s /tftpboot"
<br>    so it should look like this:
+
<<BR>>    so it should look like this:
 
<pre><nowiki>
 
<pre><nowiki>
 
#Defaults for tftpd-hpa
 
#Defaults for tftpd-hpa
第65行: 第65行:
 
OPTIONS="-l -s /tftpboot"
 
OPTIONS="-l -s /tftpboot"
 
</nowiki></pre>
 
</nowiki></pre>
<br>now, start the tftp-hpa service:
+
<<BR>>now, start the tftp-hpa service:
<br>    sudo /etc/init.d/tftp-hpa start  
+
<<BR>>    sudo /etc/init.d/tftp-hpa start  
 
* create a new config file as /tftpboot/pxelinux.cfg/default
 
* create a new config file as /tftpboot/pxelinux.cfg/default
 
'''NOTE:''' There are more options available such as MAC or IP identification for multiple config files see syslinux/pxelinux documentation for help.
 
'''NOTE:''' There are more options available such as MAC or IP identification for multiple config files see syslinux/pxelinux documentation for help.
<pre><nowiki>LABEL linux
+
<pre><nowiki>
 +
LABEL linux
 
KERNEL vmlinuz-2.6.15-23-686
 
KERNEL vmlinuz-2.6.15-23-686
APPEND root=/dev/nfs initrd=initrd.img-2.6.15-23-686 nfsroot=192.168.2.2:/nfsroot ip=dhcp rw</nowiki></pre>
+
APPEND root=/dev/nfs initrd=initrd.img-2.6.15-23-686 nfsroot=192.168.2.2:/nfsroot ip=dhcp rw
 +
  </nowiki></pre>
 
'''NOTE:''' your nfs server IP address, kernel name, and initrd name will likely be different.  If you have a preconfigured system the names should be the names of the kernel and initrd (see below) on the client system
 
'''NOTE:''' your nfs server IP address, kernel name, and initrd name will likely be different.  If you have a preconfigured system the names should be the names of the kernel and initrd (see below) on the client system
 
* configure your /etc/exports to export your /nfsroot
 
* configure your /etc/exports to export your /nfsroot
<pre><nowiki>/nfsroot            192.168.2.xxx(rw,no_root_squash,async)
+
<pre><nowiki>
</nowiki></pre>
+
/nfsroot            192.168.2.xxx(rw,no_root_squash,async)
 +
  </nowiki></pre>
 
The '192.168.2.xxx' should be replaced with either the client IP or hostname for single installations, or wildcards to match the set of servers you are using.
 
The '192.168.2.xxx' should be replaced with either the client IP or hostname for single installations, or wildcards to match the set of servers you are using.
 
* sync your exports
 
* sync your exports
<pre><nowiki>exportfs -rv
+
<pre><nowiki>
</nowiki></pre>
+
exportfs -rv
 +
  </nowiki></pre>
 
=== Creating your NFS installation ===
 
=== Creating your NFS installation ===
 
There are a few ways you can go about this, debchroot, copying the install from your server, or the easiest is having a / fs with all the right configs, was to install [xk]ubuntu on the workstation from CD, after you've got your system installed and working on the network mount the /nfsroot and copy everything from your working system to it.
 
There are a few ways you can go about this, debchroot, copying the install from your server, or the easiest is having a / fs with all the right configs, was to install [xk]ubuntu on the workstation from CD, after you've got your system installed and working on the network mount the /nfsroot and copy everything from your working system to it.
 
''Plus we get to verify the NFS is working''
 
''Plus we get to verify the NFS is working''
 
First, we'll copy our current kernel into our home directory and make the initrd.img before we copy everything to the newly created nfs directory on the server.
 
First, we'll copy our current kernel into our home directory and make the initrd.img before we copy everything to the newly created nfs directory on the server.
 +
'''Note:''' The following commands should be carried out on the client machine.  You should also ensure the client has the following package installed <code><nowiki>nfs-common</nowiki></code>
 
* Find current kernel version and copy it to your home directory
 
* Find current kernel version and copy it to your home directory
 
Lets find which Linux kernel version we have and copy it in.  Chances are you will see more than one listed because you're kernel has been upgraded, so just take the more recent version, in this case /boot/vmlinuz-2.6.20-16-generic
 
Lets find which Linux kernel version we have and copy it in.  Chances are you will see more than one listed because you're kernel has been upgraded, so just take the more recent version, in this case /boot/vmlinuz-2.6.20-16-generic
第90行: 第95行:
 
-rw-r--r-- 1 root root 1745100 2007-04-15 03:07 /boot/vmlinuz-2.6.20-15-generic
 
-rw-r--r-- 1 root root 1745100 2007-04-15 03:07 /boot/vmlinuz-2.6.20-15-generic
 
-rw-r--r-- 1 root root 1746636 2007-06-07 15:58 /boot/vmlinuz-2.6.20-16-generic  
 
-rw-r--r-- 1 root root 1746636 2007-06-07 15:58 /boot/vmlinuz-2.6.20-16-generic  
sudo cp /boot/vmlinuz-2.6.20-16-generic /home/user
+
sudo cp /boot/vmlinuz-2.6.20-16-generic /home/<USERNAME>
 
</nowiki></pre>
 
</nowiki></pre>
 
* Create an initrd.img file
 
* Create an initrd.img file
Some people prefer to append the kernel version to the end of the initrd.img file just to keep track of things.  Since we just found which version our kernel is, run the command
 
<pre><nowiki>
 
mkinitramfs -o /home/user/initrd.img-2.6.20-16-generic
 
</nowiki></pre>
 
Now we're going to copy everything over to the nfs directory on the server:
 
<pre><nowiki>mount -tnfs -onolock 192.168.1.2:/nfsroot /mnt
 
cp -ax /. /mnt/.
 
cp -ax /dev/. /mnt/dev/.
 
</nowiki></pre>
 
'''Note:''' Here is where you will need to copy your kernel and the initrd.img you made earlier from /nfsroot/home/user/ to /tftpboot/ on the server
 
 
* Change the BOOT flag to NFS in /nfsroot/etc/initramfs-tools/initramfs.conf
 
* Change the BOOT flag to NFS in /nfsroot/etc/initramfs-tools/initramfs.conf
 
<pre><nowiki>
 
<pre><nowiki>
第114行: 第109行:
  
 
BOOT=nfs
 
BOOT=nfs
 +
</nowiki></pre>
 +
Some people prefer to append the kernel version to the end of the initrd.img file just to keep track of things.  Since we just found which version our kernel is, run the command
 +
<pre><nowiki>
 +
mkinitramfs -o /home/<USERNAME>/initrd.img-2.6.20-16-generic
 +
</nowiki></pre>
 +
Now we're going to copy everything over to the nfs directory on the server:
 +
<pre><nowiki>
 +
mount -tnfs -onolock 192.168.1.2:/nfsroot /mnt
 +
cp -ax /. /mnt/.
 +
cp -ax /dev/. /mnt/dev/.
 +
</nowiki></pre>
 +
Now copy your kernel and the initrd.img you made earlier from /nfsroot/home/<USERNAME>/ to /tftpboot/ ""on the server""
 +
<pre><nowiki>
 +
cp /nfsroot/home/<USERNAME>/<vmlinuz-xxxx> /tftpboot/
 +
cp /nfsroot/home/<USERNAME>/<initrd.img> /tftpboot/
 
</nowiki></pre>
 
</nowiki></pre>
 
'''NOTE:''' You'll want to check resolv.conf and '''DO NOT''' allow the system to bring up eth0, it will already have been configured by the kernel and in use for your NFS filesystem, if you do not comment out 'auto eth0' from /etc/network/interfaces your system will try to reconfigure eth0 and sever your NFS connection and you'll lose your root FS.
 
'''NOTE:''' You'll want to check resolv.conf and '''DO NOT''' allow the system to bring up eth0, it will already have been configured by the kernel and in use for your NFS filesystem, if you do not comment out 'auto eth0' from /etc/network/interfaces your system will try to reconfigure eth0 and sever your NFS connection and you'll lose your root FS.
第132行: 第142行:
 
</nowiki></pre>
 
</nowiki></pre>
 
* edit /nfsroot/etc/fstab to look something like this ('note no swap')
 
* edit /nfsroot/etc/fstab to look something like this ('note no swap')
<pre><nowiki># /etc/fstab: static file system information.
+
<pre><nowiki>
 +
# /etc/fstab: static file system information.
 
#
 
#
 
# <file system> <mount point>  <type>  <options>      <dump>  <pass>
 
# <file system> <mount point>  <type>  <options>      <dump>  <pass>
第141行: 第152行:
 
none            /var/lock      tmpfs  defaults        0      0
 
none            /var/lock      tmpfs  defaults        0      0
 
none            /var/tmp        tmpfs  defaults        0      0
 
none            /var/tmp        tmpfs  defaults        0      0
/dev/hdc        /media/cdrom0  udf,iso9660 user,noauto 0      0</nowiki></pre>
+
/dev/hdc        /media/cdrom0  udf,iso9660 user,noauto 0      0
 +
  </nowiki></pre>
 
''note: if you have entries for other tmpfs that's fine to leave them in there''
 
''note: if you have entries for other tmpfs that's fine to leave them in there''
 
=== Setup your client ===
 
=== Setup your client ===

2008年10月19日 (日) 04:50的版本

What is diskless booting?

Diskless booting is using a remote system or systems to store the kernel and the filesystem that will be used on other computer(s).

Why do it?

Imagine my case I admin about 25 public workstations for a local library, if they want something changed across the board I can either go sit at each PC and spend X minutes on it, adding up to who knows how many hours, or I can simply make the change at any one of the 25 systems and have it effect every system equally. The same goes for updates and many other operations. It really eases support issues.

How is this different than ThinClientHowto?

Thin clients use some of the same principals but they also connect to a remote X session, which means everything runs on the remote server, all applications will consume the servers resources, such as RAM and CPU cycles. Diskless Booting simply uses the remote server for storage and still runs all applications on the local client station. This works better if you have full powered PC's to work with, and are working with a large number of clients that would require too much CPU and RAM to run all their applications on one server. It is different enough to have multiple machines mounting the same root filesystem as opposed to simply being a remote monitor and keyboard to warrant a separate how-to I think. Oliver Grawert says :- you could have achieved this easier by following the thin client howto, remove the ltsp-client package from the chroot and install ubuntu-desktop (or whatever desktop you want) there, would save you a lot of configuration work ;)

How does it work?

There are a lot of parallels to ThinClientHowto, diskless booting requires a DHCP server which a bootable PXE network card will query to get its configuration and location of the file to tftp from the server, after booting the PXE image the client will tftp and boot the kernel image(with args specified in the pxe config), those args will tell the kernel how to configure itself, and the path to mount the NFS share where it's / directory is located.

Requirements

  • An Ubuntu system with (preferably) nfs-kernel-server and tftpd server (the server)
  • At least one PXE-bootable system (the client)
  • It helps to have the client set up in its final configuration before you start
  • Enough disk space on the server to hold the client filesystem
  • A fast network connection between the client and the server
  • A DHCP server which is capable of supporting PXE clients, or a separate network segment where you can run a dedicated DHCP server
  • A good understanding of Linux

Getting Started

Set up your server

Install the following packages: dhcp3-server tftpd-hpa syslinux nfs-kernel-server initramfs-tools

sudo mkdir -p /tftpboot/pxelinux.cfg
sudo mkdir /nfsroot
sudo cp /usr/lib/syslinux/pxelinux.0 /tftpboot
  • Configure your DHCP server to offer /tftpboot/pxelinux.0 as a boot file and assign (possibly) assign a static IP to the machine you want to boot with PXE (the client). Your dhcpd.conf might look like this assuming your subnet is 192.168.2.0
allow booting;
allow bootp;

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.xxx 192.168.2.xxx;
  option broadcast-address 192.168.2.255;
  option routers 192.168.2.xxx;
  option domain-name-servers 192.168.2.xxx;

  filename "/pxelinux.0";
}

# force the client to this ip for pxe.
# This is only necessary assuming you want to send different images to different computers.
host pxe_client {
  hardware ethernet xx:xx:xx:xx:xx:xx;
  fixed-address 192.168.2.xxx;
}

NOTE: You will need to replace the 'xx:xx:xx:xx:xx:xx' and the '192.168.2.xxx' with your own values

  • configure tftp-hpa

Before tftp will run, we need to configure it to run in daemon mode. <
> sudo vi /etc/default/tftp-hpa <
> Change <
> RUN_DAEMON="no" <
> to <
> RUN_DAEMON="yes" <
> and the second line to <
> OPTIONS="-l -s /tftpboot" <
> so it should look like this:

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /tftpboot"

<
>now, start the tftp-hpa service: <
> sudo /etc/init.d/tftp-hpa start

  • create a new config file as /tftpboot/pxelinux.cfg/default

NOTE: There are more options available such as MAC or IP identification for multiple config files see syslinux/pxelinux documentation for help.

LABEL linux
KERNEL vmlinuz-2.6.15-23-686
APPEND root=/dev/nfs initrd=initrd.img-2.6.15-23-686 nfsroot=192.168.2.2:/nfsroot ip=dhcp rw
  

NOTE: your nfs server IP address, kernel name, and initrd name will likely be different. If you have a preconfigured system the names should be the names of the kernel and initrd (see below) on the client system

  • configure your /etc/exports to export your /nfsroot
/nfsroot             192.168.2.xxx(rw,no_root_squash,async)
  

The '192.168.2.xxx' should be replaced with either the client IP or hostname for single installations, or wildcards to match the set of servers you are using.

  • sync your exports
exportfs -rv
  

Creating your NFS installation

There are a few ways you can go about this, debchroot, copying the install from your server, or the easiest is having a / fs with all the right configs, was to install [xk]ubuntu on the workstation from CD, after you've got your system installed and working on the network mount the /nfsroot and copy everything from your working system to it. Plus we get to verify the NFS is working First, we'll copy our current kernel into our home directory and make the initrd.img before we copy everything to the newly created nfs directory on the server. Note: The following commands should be carried out on the client machine. You should also ensure the client has the following package installed nfs-common

  • Find current kernel version and copy it to your home directory

Lets find which Linux kernel version we have and copy it in. Chances are you will see more than one listed because you're kernel has been upgraded, so just take the more recent version, in this case /boot/vmlinuz-2.6.20-16-generic

ls -ltr /boot/vmlinuz-*
-rw-r--r-- 1 root root 1745100 2007-04-15 03:07 /boot/vmlinuz-2.6.20-15-generic
-rw-r--r-- 1 root root 1746636 2007-06-07 15:58 /boot/vmlinuz-2.6.20-16-generic 
sudo cp /boot/vmlinuz-2.6.20-16-generic /home/<USERNAME>
  • Create an initrd.img file
  • Change the BOOT flag to NFS in /nfsroot/etc/initramfs-tools/initramfs.conf
#
# BOOT: [ local | nfs ]
#
# local - Boot off of local media (harddrive, USB stick).
#
# nfs - Boot using an NFS drive as the root of the drive.
#

BOOT=nfs

Some people prefer to append the kernel version to the end of the initrd.img file just to keep track of things. Since we just found which version our kernel is, run the command

mkinitramfs -o /home/<USERNAME>/initrd.img-2.6.20-16-generic

Now we're going to copy everything over to the nfs directory on the server:

mount -tnfs -onolock 192.168.1.2:/nfsroot /mnt
cp -ax /. /mnt/.
cp -ax /dev/. /mnt/dev/.
 

Now copy your kernel and the initrd.img you made earlier from /nfsroot/home/<USERNAME>/ to /tftpboot/ ""on the server""

cp /nfsroot/home/<USERNAME>/<vmlinuz-xxxx> /tftpboot/
cp /nfsroot/home/<USERNAME>/<initrd.img> /tftpboot/

NOTE: You'll want to check resolv.conf and DO NOT allow the system to bring up eth0, it will already have been configured by the kernel and in use for your NFS filesystem, if you do not comment out 'auto eth0' from /etc/network/interfaces your system will try to reconfigure eth0 and sever your NFS connection and you'll lose your root FS. Note: For Ubuntu 7.04 (Feisty Fawn) it seems the /etc/network/interfaces needs a little tweak, in order *not* to have the NetworkManager fiddle with the interface since it's already configured (see also bug #111227 : "NFS-root support indirectly broken in Feisty") so, here's what your interfaces file should look like:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface, commented out for NFS root
#auto eth0
#iface eth0 inet dhcp
iface eth0 inet manual
  • edit /nfsroot/etc/fstab to look something like this ('note no swap')
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/nfs       /               nfs    defaults          1       1
none            /tmp            tmpfs   defaults        0       0
none            /var/run        tmpfs   defaults        0       0
none            /var/lock       tmpfs   defaults        0       0
none            /var/tmp        tmpfs   defaults        0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto 0       0
   

note: if you have entries for other tmpfs that's fine to leave them in there

Setup your client

  • Enter your BIOS settings and configure your system to boot from LAN

If you have options for different LAN boot methods choose PXE

Now What?

Reboot your client PC it should get it's net config from the DHCP server, download the pxelinux image, download and boot the kernel, mount your root fs and continue to boot just as if it were using its internal HD, only now you can yank that HD out and use it for something else, that machine doesn't need it any more :)

Adding a swap file

In case you do need or want to set up a swapfile, here's what I did to get one working:

sudo apt-get install dphys-swapfile

this package sets up a swap file at /var/swap that is 2x your current ram. however, it still doesn't setup the swapfile on its own, though it does try. to get the swap file working the rest of the way, do:

sudo losetup /dev/loop0 /var/swap
sudo swapon /dev/loop0

then, run top and you will see you have a swap file. however, put in as much ram as you need for what you are going to run, and just look at your swap file as "in case of emergency", because it is not efficient as a ram or a regular swap file, but should keep something from crashing. I'm running mythtv on top of a full feisty desktop, and tried it with 256mb ram, and myth-frontend would crash when i would try to bring it up. with the swap file, it would launch, but would take a while. i added an additional 256mb to bring the total to 512mb and it runs flawless, and i add the swap file just in case. i just make a script for it to set up the swap file at boot.

Static IP

As described in #175324 ipconfig have problems with DHCP relays. Static IP is configured by parameter:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>

<client-ip> IP address of the client. If empty, the address will either be determined by RARP/BOOTP/DHCP. What protocol is used de- pends on the <autoconf> parameter. If this parameter is not empty, autoconf will be used. <server-ip> IP address of the NFS server. If RARP is used to determine the client address and this parameter is NOT empty only replies from the specified server are accepted. To use different RARP and NFS server, specify your RARP server here (or leave it blank), and specify your NFS server in the `nfsroot' parameter (see above). If this entry is blank the address of the server is used which answered the RARP/BOOTP/DHCP request. <gw-ip> IP address of a gateway if the server is on a different subnet. If this entry is empty no gateway is used and the server is assumed to be on the local network, unless a value has been received by BOOTP/DHCP. <netmask> Netmask for local network interface. If this is empty, the netmask is derived from the client IP address assuming classful addressing, unless overridden in BOOTP/DHCP reply. <hostname> Name of the client. If empty, the client IP address is used in ASCII notation, or the value received by BOOTP/DHCP. <device> Name of network device to use. If this is empty, all devices are used for RARP/BOOTP/DHCP requests, and the first one we receive a reply on is configured. If you have only one device, you can safely leave this blank. <autoconf> Method to use for autoconfiguration. If this is either 'rarp', 'bootp', or 'dhcp' the specified protocol is used. If the value is 'both', 'all' or empty, all protocols are used. 'off', 'static' or 'none' means no autoconfiguration.

Gotchas

  • Remember to use -o nolock when first mounting your NFS or have portmapper running or you'll end up with a long (nearly 2 min) hang mounting the remote NFS.
  • If you are going to have multiple systems share this root you need to make sure some directories like /var/run, /var/lock, /tmp and some others are mounted in tmpfs so different systems won't be conflicting into each other.
  • You probably also want to mount /media in tmpfs space if you don't want every workstation having access to every other workstations storage media.
  • Think of things in cron like slocate - do you really want 25 computers trying to updatedb at 4AM all on the same HD?

Credits

For the feisty interfaces fix and locating your current kernel: http://developer.novell.com/wiki/index.php/HOWTO:_Convert_Ubuntu_to_Diskless For the tftp-hpa config - dodox in the forums: http://ubuntuforums.org/showthread.php?t=236518