Author: sbalneav
Date: Tue Sep 11 05:42:41 2007
New Revision: 4330
Modified:
trunk/edubuntu/handbook/C/bookinfo.xml
trunk/edubuntu/handbook/C/server.xml
Log:
Added multi-server setup from Francis, updated authors
Modified: trunk/edubuntu/handbook/C/bookinfo.xml
==============================================================================
--- trunk/edubuntu/handbook/C/bookinfo.xml (original)
+++ trunk/edubuntu/handbook/C/bookinfo.xml Tue Sep 11 05:42:41 2007
@@ -78,6 +78,13 @@
Jonathan Mueller
</para>
</listitem>
+
+<listitem>
+<para>
+Francis Giraldeau
+</para>
+</listitem>
+
</itemizedlist>
</legalnotice>
Modified: trunk/edubuntu/handbook/C/server.xml
==============================================================================
--- trunk/edubuntu/handbook/C/server.xml (original)
+++ trunk/edubuntu/handbook/C/server.xml Tue Sep 11 05:42:41 2007
@@ -992,7 +992,8 @@
<para>The host selection system is simple, and flexible enough
to allow
administrators to implement their own policy on how they
want
the load balancing to happen: either on a random,
load-based, or
- round robin system.
+ round robin system. See the chapter entitled "Multiple
server setup"
+ for details.
</para>
</sect3>
</sect2>
@@ -1792,6 +1793,237 @@
</sect2>
</sect1>
+
+ <!--multiple-server-setup-->
+ <sect1 id="multiple-server-setup" status="draft">
+ <title>Multiple server setup</title>
+ <para>
+ A multiple server setup is useful for larger thin client networks.
Instead of using one big server,
+ it makes it possible to use smaller servers, and dispatch users on
them. You can adjust computing
+ resources as the demand grows simply by adding a new server.
+ To make sure that every server behaves the same from the users
point of view, new services and
+ configurations that are required will be discussed. In addition,
some configurations specific
+ to thin clients will be presented.
+ </para>
+ <sect2 id="multiple-server-setup-common-services" status="draft">
+ <title>Infrastructure setup</title>
+ <sect3>
+ <title>Network topology</title>
+ <para>
+ The network topology is the same as a standalone server
setup, except that
+ there are more than one server on the thin client lan.
+ </para>
+ <para>
+ You will need to select one server to behave as the
primary server. This server
+ will be used to run additional services, hold users files,
and network boot thin clients.
+ </para>
+ <para>
+ Secondary servers will be used only to run desktop
sessions. They are simpler, and will
+ be configured to use the central services from the primary
server. Installing the package
+ <command>ltsp-server</command> will install required
software.
+ </para>
+ </sect3>
+ <sect3><title>Common authentication</title>
+ <para>
+ A user should be able to start a session with the same
login and password, no matter
+ which server it connects to. For this purpose, a central
authentication mechanism must
+ be used. There are many possibilities offered. Here are
the major technologies.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>LDAP authentication: On the master server, setup
an OpenLDAP server.
+ Configure each servers to use this LDAP server as
the authentication base,
+ with the pam_ldap plugin.
+ </para>
+ </listitem>
+ <listitem>
+ <para>NIS authentication: On the master server, setup
a NIS server. Configure
+ each servers to use this NIS server for the
authentication.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Winbind authentication: Useful if you already
have an Active Directory server.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ For detailed instructions, see their respective manuals.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Shared home directories</title>
+ <para>
+ Shared home directories are easy to setup using an NFS
server on the primary server.
+ To configure the share, install the package
<command>nfs-kernel-server</command>.
+ Then, edit the file <filename
class="directory">/etc/exports</filename> and add the following line,
+ by replacing <command>secondary_server_ip</command> by the
real IP address of the server.
+ <screen>
+/home secondary_server_ip(rw,no_root_squash)
+ </screen>
+ After this modification, the service needs to be restarted.
+ <screen>
+sudo invoke-rc.d nfs-kernel-server restart
+ </screen>
+ You can define the mount point on each secondary servers,
by editing the file
+ <filename>/etc/fstab</filename> and adding the following
line:
+ <screen>
+192.168.0.1:/home /home nfs hard,intr,rsize=8192,wsize=8192,bg 0 0
+ </screen>
+ </para>
+ <para>
+ With the default setup, the home directory of the user
must exist before the
+ first login. To create the home directory on the fly on
the first login,
+ you can use the pam_mkhomedir plugin. The NFS export option
+ <command>no_root_squash</command> allows any secondary
server to create
+ directories on the primary server.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Shared printers</title>
+ <para>For printers to be accessible on each server, the cups
server must be
+ configured to share printers. Refer to the CUPS manual for
detailed instructions.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Synchronization of packages</title>
+ <para>Once you install one desktop application on one server,
then you must
+ install it on all the other servers, as well. Otherwise,
users may not be able to
+ use the same set of applications. First, make sure that
+ <command>/etc/apt/sources.list</command> file is the same
on each server.
+ Then, list packages of the reference server. Using the
primary server for
+ this purpose is not recommended, since it may install
other server packages
+ that are not necessary on secondary servers. To build the
package list:
+ <screen>dpkg --get-selections > deblist </screen>
+ Then, copy this file on the target server you want to sync
applications,
+ and perform following steps.
+ <screen>
+sudo dpkg --set-selections < deblist
+sudo apt-get dselect-upgrade
+ </screen>
+ Apt will install additional packages that are not already
installed on the target machine.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Managing the SSH known hosts file</title>
+ <para>
+ For security reasons, a thin client won't connect to an
untrusted server. You
+ must add the keys of secondary servers inside the client
root on the primary
+ server. To do this, first export the key file of the
secondary server to add:
+ <screen>
+sudo ltsp-update-sshkeys --export ssh_known_hosts.myhostname
+ </screen>
+ Then, copy the file on the primary server, in the directory
+ <filename class="directory">/etc/ltsp/</filename>, and run
<command>ltsp-update-sshkeys</command>
+ on the primary server. Then, thin clients will trust the
freshly added server,
+ and will be able to connect to it.
+ </para>
+ <para>
+ If a secondary server changes it's IP address, then this
procedure must be repeated.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Setting network forwarding</title>
+ <para>Primary server will act as an network gateway for other
servers. With this
+ configuration, other workstations will be able to access
the network behind
+ the primary server. Here is an example of script that
setup the network forwarding.
+ We put it in
<command>/etc/network/if-up.d/forward.sh</command>, and make it
+ executable. The script will run at each network start. In
this example, the
+ primary server private IP is
<command>192.168.0.1</command>. It must be
+ adapted for the IP address used.
+ </para>
+ <screen>
+#!/bin/bash
+
+echo 1 > /proc/sys/net/ipv4/ip_forward
+
+echo Setting up the forwarding
+
+LAN_IP_NET="192.168.0.1/24"
+LAN_NIC="eth1"
+OUT_NIC="eth0"
+
+iptables -t nat -A POSTROUTING -s $LAN_IP_NET -o $OUT_NIC -j MASQUERADE
+iptables -A FORWARD -j ACCEPT -i $LAN_NIC -s $LAN_IP_NET
+iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
+ </screen>
+ </sect3>
+ <sect3>
+ <title>Replication of desktop profiles</title>
+ <para>If you customize user's desktop, then custom desktop
profiles should be
+ copied to every server. Gnome desktop profiles created
with Sabayon are
+ located in <command>/etc/desktop-profiles</command>
+ </para>
+ </sect3>
+ </sect2>
+ <sect2 id="multiple-server-setup-config" status="draft">
+ <title>Session dispatching</title>
+ <sect3>
+ <title>Define the server list</title>
+ <para>
+ LDM is a login manager for thin clients. Users can select
a server
+ from the available ones in the host selection dialog box.
+ </para>
+ <para>
+ The displayed server list is defined by the
<command>LDM_SERVER</command>
+ parameter. This parameter accepts a list of server IP
address or host names,
+ separated by space. If you use host names, then you DNS
resolution must work
+ on the thin client. If defined in the
<filename>lts.conf</filename> file, the
+ list order will be static, and the first server in the
list will be selected
+ by default.
+ </para>
+ <para>
+ You can also compute a new order for the server list, by
creating the script
+ <command>/opt/ltsp/i386/usr/lib/ltsp/get_hosts</command>.
The parameter
+ <command>LDM_SERVER</command> overrides the script. In
consequence, this
+ parameter must not be defined if the
<command>get_hosts</command> is going
+ to be used. The <command>get_hosts</command> script writes
on the standard
+ output each server IP address or host names, in the chosen
order.
+ </para>
+ </sect3>
+ <sect3>
+ <title>Dispatching method</title>
+ <para>
+ You can change this behavior by using a script to
rearrange the
+ list. The simplest way to do it is by randomizing the
list. First, define
+ a custom variable in the file <command>lts.conf</command>,
for example
+ <command>MY_SERVER_LIST</command>, that will contain the
list of servers,
+ the same way as <command>LDM_SERVER</command> Then, put
the following
+ script in
<command>/opt/ltsp/i386/usr/lib/ltsp/get_hosts</command>.
+ <screen>
+#!/bin/bash
+# Randomize the server list contained in MY_SERVER_LIST parameter
+
+TMP_LIST=""
+SHUFFLED_LIST=""
+
+for i in $MY_SERVER_LIST; do
+rank=$RANDOM
+let "rank %= 100"
+TMP_LIST="$TMP_LIST\n${rank}_$i"
+done
+
+TMP_LIST=$(echo -e $TMP_LIST | sort)
+for i in $TMP_LIST; do
+SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"
+done
+
+echo $SHUFFLED_LIST
+ </screen>
+ </para>
+ <para>
+ More advanced load balancing algorithms can be written.
For example,
+ load balancing can be done by querying ldminfod for the
server rating.
+ By querying ldminfod, you can get the current rating state
of the server.
+ This rating goes from 0 to 100, higher is better. Here is
an example of
+ such a query:
+ <screen>
+nc localhost 9571 | grep rating | cut -d: -f2
+ </screen>
+ </para>
+ </sect3>
+ </sect2>
+ </sect1>
+
<!-- Network Swap -->
<sect1>
<title>Network Swap</title>
--
ubuntu-doc-commits mailing list
ubuntu-doc-commits@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc-commits
