Differences between revisions 79 and 81 (spanning 2 versions)
Revision 79 as of 2014-11-22 07:18:35
Size: 6742
Editor: ?VagrantCascadian
Comment: remove ancient lenny documentation.
Revision 81 as of 2017-05-05 09:54:34
Size: 11454
Editor: ?RichardKweskin
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:

== Hardware requirements ==

In order for ltsp to meet your needs it is necessary to prepare both hardware and software configuration. In this section we look at the hardware requirements.

The network is crucial and requires more attention using ltsp. In a typical ltsp setup several clients will be sending and receiving packets with the server(s).

1 – switch vs hub

Do not use a simple hub. When a packet is sent to a hub, all segments of the lan will see all packets. Traffic slows to a useless crawl. A switch, managed or unmanaged, however, keeps a record of the MAC addresses of all the devices connected to it. With this information, a switch can identify which system is sitting on which port. So when a frame is received, it knows exactly which port to send it to, without significantly increasing network response times. Unlike a hub, a 10/100Mbps switch will allocate a full 10/100Mbps to each of its ports. So regardless of the number of PCs transmitting, users will always have access to the maximum amount of bandwidth.

2 – 1000Mbps or gigabit vs 100Mbps

If one has gigabit everywhere, i.e. all the clients and server(s) are all equipped with gigabit network cards, the switch has all gigabit ports, the router, ethernet wall points and rj45 jacks are all gigabit-rated and the cabling is category 5e or 6 (i.e. gigabit-rated) then there is no flow control issue and the bandwidth is ample for ltsp usage.

This is what is recommended when planning a setup from scratch.

Otherwise using legacy hardware requires careful attention to certain details.

a – The router need only handle 100Mbps through its wired ports which is ample for most typical internet connections. Wireless is much slower which, while still able to deliver internet to non-ltsp devices is much more complicated trying to use it with ltsp.

b – A hub (see above) is not useful for ltsp.

c – The switch can be managed or unmanaged but (in most cases) should have at least one gigabit port for each server.

d – The server should have at least one gigabit (onboard or not) network device. In simple cases where it is feasible to run everything within one subnet the server only needs the one network device. Otherwise if you need to run a subnet (separate from the router) containing the clients, then the server needs two network devices. (100Mbps or gigabit) to connect to the subnet with the router and another, which should be a gigabit device, connected to the subnet with the clients. In other words the server must have two network devices and if only one of these is gigabit capable then this device must be connected with the subnet containing the clients.

e – Clients which have only 100Mbps (onboard or not) network device are adequate and can be connected to 100Mbps or gigabit ports on the switch. In either case, however, there arises the issue of flow control. Using the latest ltsp software resolves this issue.

f – Cabling and wall sockets may be only 100Mbps capable except for the connection from the gigabit device from the server to the gigabit port on the switch which all must be gigabit capable.

In addition to the above, legacy pc’s need further scrutiny.

i – A server’s hardware requirements are less severe with fat clients. The amount of ram memory is calculated: 1500 MB + 30 MB for each fat client it serves + 300 MB for each thin client. Examples: 10 fat clients only, 1800 MB of ram memory is the minimum but will do; 10 thin clients only, 4.5 GB is the minimum; 5 fat clients and 2 thin clients, 3.6 GB is the minimum. The recommended cpu benchmark rating (http://www.cpubenchmark.net/cpu_list.php) is similarly calculated: 1500 + 30 for each fat client + 300 for each thin client. Thus a 1800 rating is a minimum if running 10 fat clients only; a 4500 rating for 10 thin clients only; a 3600 rating for 5 fat and 2 thin clients. Of course these numbers represent the least amount acceptable.

ii – At the very least a fat client should have more than 400 MB ram memory (preferably not SDRAM but DDR, the newer the version, the better.) 1 or better 2 GB is recommended. Its cpu benchmark rating is the most important. A rating of 1000 or more is recommended but when client usage is less demanding smaller ratings will do.

In general legacy pc’s which have similar characteristics are easier to setup and maintain. Otherwise variety requires more work.

iii – A thin client needs less memory but should have at least 256 MB. Otherwise the above remarks for fat clients apply.

iv – All clients may be diskless, uefi or legacy bios, 64 or 32 bit. Where these are similar there is less work for the administration.
Line 79: Line 121:
 1. Note that at the time of writing the wheezy kernel was 3.2.0-4-486.
{{{
 1. Note that at the time of writing the wheezy kernel was 3.2.0-4-486. {{{

Translation(s): Português Brasileiro


LTSP How To

Upstream documentation with official, detailed information about installing LTSP is at http://wiki.ltsp.org/wiki/LTSPedia.

Hardware requirements

In order for ltsp to meet your needs it is necessary to prepare both hardware and software configuration. In this section we look at the hardware requirements.

The network is crucial and requires more attention using ltsp. In a typical ltsp setup several clients will be sending and receiving packets with the server(s).

1 – switch vs hub

Do not use a simple hub. When a packet is sent to a hub, all segments of the lan will see all packets. Traffic slows to a useless crawl. A switch, managed or unmanaged, however, keeps a record of the MAC addresses of all the devices connected to it. With this information, a switch can identify which system is sitting on which port. So when a frame is received, it knows exactly which port to send it to, without significantly increasing network response times. Unlike a hub, a 10/100Mbps switch will allocate a full 10/100Mbps to each of its ports. So regardless of the number of PCs transmitting, users will always have access to the maximum amount of bandwidth.

2 – 1000Mbps or gigabit vs 100Mbps

If one has gigabit everywhere, i.e. all the clients and server(s) are all equipped with gigabit network cards, the switch has all gigabit ports, the router, ethernet wall points and rj45 jacks are all gigabit-rated and the cabling is category 5e or 6 (i.e. gigabit-rated) then there is no flow control issue and the bandwidth is ample for ltsp usage.

This is what is recommended when planning a setup from scratch.

Otherwise using legacy hardware requires careful attention to certain details.

a – The router need only handle 100Mbps through its wired ports which is ample for most typical internet connections. Wireless is much slower which, while still able to deliver internet to non-ltsp devices is much more complicated trying to use it with ltsp.

b – A hub (see above) is not useful for ltsp.

c – The switch can be managed or unmanaged but (in most cases) should have at least one gigabit port for each server.

d – The server should have at least one gigabit (onboard or not) network device. In simple cases where it is feasible to run everything within one subnet the server only needs the one network device. Otherwise if you need to run a subnet (separate from the router) containing the clients, then the server needs two network devices. (100Mbps or gigabit) to connect to the subnet with the router and another, which should be a gigabit device, connected to the subnet with the clients. In other words the server must have two network devices and if only one of these is gigabit capable then this device must be connected with the subnet containing the clients.

e – Clients which have only 100Mbps (onboard or not) network device are adequate and can be connected to 100Mbps or gigabit ports on the switch. In either case, however, there arises the issue of flow control. Using the latest ltsp software resolves this issue.

f – Cabling and wall sockets may be only 100Mbps capable except for the connection from the gigabit device from the server to the gigabit port on the switch which all must be gigabit capable.

In addition to the above, legacy pc’s need further scrutiny.

i – A server’s hardware requirements are less severe with fat clients. The amount of ram memory is calculated: 1500 MB + 30 MB for each fat client it serves + 300 MB for each thin client. Examples: 10 fat clients only, 1800 MB of ram memory is the minimum but will do; 10 thin clients only, 4.5 GB is the minimum; 5 fat clients and 2 thin clients, 3.6 GB is the minimum. The recommended cpu benchmark rating (http://www.cpubenchmark.net/cpu_list.php) is similarly calculated: 1500 + 30 for each fat client + 300 for each thin client. Thus a 1800 rating is a minimum if running 10 fat clients only; a 4500 rating for 10 thin clients only; a 3600 rating for 5 fat and 2 thin clients. Of course these numbers represent the least amount acceptable.

ii – At the very least a fat client should have more than 400 MB ram memory (preferably not SDRAM but DDR, the newer the version, the better.) 1 or better 2 GB is recommended. Its cpu benchmark rating is the most important. A rating of 1000 or more is recommended but when client usage is less demanding smaller ratings will do.

In general legacy pc’s which have similar characteristics are easier to setup and maintain. Otherwise variety requires more work.

iii – A thin client needs less memory but should have at least 256 MB. Otherwise the above remarks for fat clients apply.

iv – All clients may be diskless, uefi or legacy bios, 64 or 32 bit. Where these are similar there is less work for the administration.

Installating and configuring LTSP

This section documents a standard Debian LTSP installation on recent versions of Debian (wheezy and jessie), which uses NFS for a root filesystem, and ISC DHCPD.

  1. If you want a complete LTSP server with all the bells and

    whistles:

    apt-get install ltsp-server-standalone

    If you want more fine-grained control, splitting some services off to separate servers, you can install ltsp-server instead, and manually install each of the other services.

  2. Build the LTSP client environment, downloading packages from the internet:

    ltsp-build-client

    If your clients do not support 64-bit extensions (amd64), and your server is 64-bit, you may want to build your chroot specifying the i386 architecture:

    ltsp-build-client --arch i386
  3. Configure DHCP. Edit /etc/ltsp/dhcpd.conf to adapt to your network.

    Include the LTSP dhcpd.conf at the bottom of /etc/dhcp/dhcpd.conf:

    include "/etc/ltsp/dhcpd.conf";

    Restart isc-dhcp-server:

    service isc-dhcp-server restart
  4. Configure /etc/exports:

    /opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

    Restart nfs-kernel-server:

    service nfs-kernel-server restart
  5. Boot a PXE capable machine and enjoy.

Installing LTSP using the LTSP-PNP method

At the time of writing the version of LTSP in Debian Jessie is 5.5.2-1, while in Debian Wheezy 5.4.2-6+deb7u1. This particular model has much less flexibilty since the clients must run the same version of distribution and platform as the server. The upside is that the model is easier to maintain. Thus a 32bit version (Jessie i386 or Wheezy i386) is suggested. There is no separate chroot (sometimes referred to as ltsp-pnp) and nbd (rather than nfs) is used to provide a squashfs image.

The use of dnsmasq provides ease of configurability and maintenance. The default config file generated provides its use as the tftp server as well as handling dhcp-proxy or dhcp-server proper with the adjustment of commenting and/or uncommenting lines provided.

  1. Update the server, ensure the ip(s) is/are as desired (static is recommended) and /etc/hosts is as desired.
  2. Install ltsp-server-standalone, ltsp-client (since there is to be no separate chroot) dnsmasq (an easy to configure tool) other desired software and the desktop environment of your choice.
  3. On the commandline run as root

    ltsp-config dnsmasq
    This reports: Created /etc/dnsmasq.d/ltsp-server-dnsmasq.conf [ ok ] Restarting DNS forwarder and DHCP server: dnsmasq.
  4. If the server will run one subnet containing the Internet connection and the clients it need have only one network interface card. In this case dnsmasq can be configured to run a dhcp-proxy if there already is another dhcp server active. In this case edit the above file to comment out the dhcp range line and ensure there is a line (uncommented) stating dhcp-proxy.
  5. If the server will also run a dhcp-server then comment out the dhcp-proxy line and leave the dhcp-range line uncommented, ensuring the subnet entries are correct.
  6. Edit the config file /etc/ltsp/update-kernels.conf to have the uncommented lines:

    BOOT_METHODS=NBD
    IPAPPEND=3
  7. The version of the kernel running on the server can be determined by:

    uname -r
  8. Note that at the time of writing the wheezy kernel was 3.2.0-4-486.

    dpkg-reconfigure linux-image-3.2.0-4-486
    This reports update-initramfs: Generating /boot/initrd.img-3.2.0-4-486 adding the changes above and triggers the call to /usr/share/ltsp/update-kernels.
  9. Inspect and edit as desired /etc/ltsp/ltsp-update-image.excludes as some software running on the server will not be appropriate for the clients.
  10. On the commandline run as root:

    ltsp-update-image --cleanup /
    This reports updating /var/lib/tftpboot directories for chroot: i386 (i.e. putting pxelinux.0 and pxelinux.cfg and the latest kernel into /var/lib/tftpboot/ltsp/i386/) and triggers ltsp-config nbd-server reporting created /etc/nbd-server/conf.d/swap.conf and created /etc/nbd-server/conf.d/ltsp_i386.conf and nbd-server. It also creates /etc/nbd-client but did not report it as well as putting the latest squashfs image for nbd into /opt/ltsp/images.
  11. On the commandline run as root:

    ltsp-config nbd-server
    This creates 3 files: /etc/nbd-server/conf.d/swap.conf /etc/nbd-client and /etc/nbd-server/conf.d/ltsp_i386.conf. If there is an error message "FATAL: Module overlayfs not found" it is a non-issue since aufs is used instead of overlayfs.
  12. On the commandline run as root:

    service nbd-server restart
  13. On the commandline run as root:

    ltsp-config lts.conf

This creates a default lts.conf file which many should study and edit as appropriate. Note that all headings (written between square brackets) should have at least one entry each so don't leave any empty.

This file plays a role similar to xorg.conf for xorg and there are many options for it to choose from. One is worth mentioning here:

Under [Default] the option LDM_DIRECTX = True (the default is false) allows one to turn off the encrypted X tunnel via SSH, and instead run a less secure, but much faster unencrypted tunnel. If speed is important and security is less so then it is recommended.

As this model describes a usage with nbd rather than Debian's default using nfs note that the useful file lts.conf is in/var/lib/tftpboot/ltsp/i386/ which among other things means that changes made to this file do NOT require a re-creation of the squashfs image.

When ready to try ltsp don't forget to create users as appropriate for the clients. This also does NOT require a re-creation of the squashfs image.

Notes:

The following changes require a re-creation of the squashfs image:

When the server is updated.

Software is added to the server that is desirable for clients.

This means one repeats the step:

On the commandline run as root:

ltsp-update-image --cleanup /

At the time of writing Debian Jessie's version of xserver-xorg is 1.16. This may not run well on some older graphic cards. Debian Wheezy, on the other hand, has the 1.12 version and will work on many of those older graphic cards.