~kjcole/edubuntu.cookbook-delete/wip : contents of lore/chap09.lore at revision 24

~kjcole/edubuntu.cookbook-delete/wip : (revision 24)
<html>
<head>
  <title>Server configuration</title>
</head>

<body>
<h1>Server configuration</h1>
</p>

<p>9.1. Wizzy configuration
</p>

<p>A Wizzy server plays two roles. In the first place, it serves
as an internet proxy, serving cached pages to a lab without a
permanent internet connection. In the second place, it
connects to the internet and retrieves requested pages to
store them locally, sends queued email, and fetches received
mail.
</p>

<p>These two roles don't have to be fulfilled by the same server:
they may be split across two servers, for example if the
school has no internet access. In this case, there will be a
Wizzy in the Edubuntu lab and another one at a remote location with
internet connectivity.
</p>

<p>The hardware requirements for the Wizzy server are far less
than those of the classroom application server, since it has
to do far less work. All it needs to do most of the time is to
serve up saved pages from its hard disk. For this, a server
with a 200+MHz CPU, 256MB RAM, and a 40GB RAID 1 disk array is
adequate.
_________________________________________________________
</p>

<p>9.1.1. Software used by the Wizzy server
</p>

<p>* The Wizzy server uses DHCP ( Section 9.2) and TFTP for
booting, the same as the classroom server.
XXX: What does the Wizzy server use TFTP for? Does it also
boot from the classroom server?
* It uses the Lightweight Directory Access Protocol (LDAP)
for authentication. When users access their email on the
Wizzy server they will need to supply a username and
password. This information is kept by an LDAP server,
which maintains a directory where user information may be
looked up. It is analogous to a telephone directory.
Ideally, there should be only one directory for an Edubuntu lab,
which contains the information on all the users and
resources (such as printers) in the lab. Currently,
however, the directory maintained by the Wizzy server is
separate from the user database on the classroom server.
* The Unix-to-Unix Copy Protocol (UUCP) is used for all
email sending and receiving, as well as for fetching web
pages. As long as a service can be configured to use UUCP
for communication, it is possible to provide the service
without a permanent internet connection. For this reason,
Wizzy sticks to UUCP.
* The Wizzy server uses BIND (the Berkeley Internet Name
Daemon) for domain name services ( DNS), on the local
network. DNS is how IP addresses, such as 192.168.0.254,
are resolved to readable domain names, such as
server.myschool.Edubuntu lab.org.za.
XXX: I'm not sure what "on the local network" means here.
Does that mean it only resolves names that are local to
the Edubuntu lab?
XXX: What domain name does a classroom server get?
* For email, Wizzy uses the Courier IMAP server for inbound
mail and webmail.
IMAP (the Internet Mail Access Protocol) provides a way
for all kinds of mail clients (such as Thunderbird, or
Mozilla's email component) to access a mail store. In
Wizzy's case, the Courier package handles mail storage and
IMAP access. Wizzy also provides a webmail client to
access the mail store using a web browser.
* To send mail, Wizzy uses the exim program.
* As discussed in Section 7.2, one of the most important
jobs the Wizzy does is to provide a browsable offline copy
of all the web pages that interest Edubuntu lab users. It does
this using the wwwoffle program to provide a local web
cache. It augments wwwoffle (the World Wide Web Offline
Explorer) with some custom programs, since Wizzy's
disconnected mode of operation goes beyond the options
offered by wwwoffle on its own.
* The Wizzy server provides its administration functions as
well as webmail as web pages, and uses the apache
webserver to serve these pages. They may be accessed by
going to XXX http://wizzy/ on the Edubuntu lab LAN.
* For a local FTP server, Wizzy uses XXX: vsftpd (XXX: but
what is the local FTP server used for?)
* In its role as a connection to the internet, the Wizzy
server can connect to any ISP with which the school has an
account, in order to retrieve web pages. It does not,
however, use any email facilities that the ISP may
provide: all mail goes through Andy Rabagliati's server in
Cape Town using UUCP.
* For the sake of data integrity, Wizzy uses a RAID disk
system for storage. RAID is a Redundant Array of
Inexpensive Disks. It is a way to federate multiple hard
disk drives in such a way that the failure of any one disk
does not result in data loss.
_________________________________________________________
</p>

<p>9.1.2. Wizzy as a classroom server
</p>

<p>The Wizzy project predates Edubuntu labs. It can also be configured
to provide a similar range of application serving functions as
the Edubuntu lab classroom server provides. In this configuration,
it uses the following packages:
</p>

<p>* Like the Edubuntu lab server, Wizzy uses the LTSP packages (
Section 6.2) for its thin-client NFS-mounted root
directory.
* It also uses NFS (the Network FileSystem) for home
directories that are NFS-mounted by the thin clients.
XXX: I don't know if I'm understanding this correctly.
Does Wizzy mount the users' home directories from the
classroom server, e.g. in order to server web pages from
them?
_________________________________________________________
</p>

<p>9.2. Dynamic Host Configuration Protocol
</p>

<p>Every computer on a local area network ( LAN) needs to have a
unique IP address (see Section 8.4) so that it may send and
receive data. The Dynamic Host Configuration Protocol ( DHCP)
is a networking protocol that allocates IP addresses
dynamically to computers on a LAN. Without it, an
administrator needs to give each client computer a static IP
address manually. This may seem simple enough to begin with,
but given time, it slowly turns into a nightmare: computers
are added, removed or moved about, and the number assignments
eventually become arbitrary and troublesome to keep track of.
On a network with manually assigned addresses, it's also
awkward to connect transient devices such as laptop computers
that are also used on many other networks. You have to talk to
the system administrator to find out the network
configuration, and then check the network to find a free
address. With DHCP, it's easy: just plug in an Ethernet cable
for the new device, and it will immediately request an IP
address from the classroom server, which will assign an unused
number to it.
</p>

<p>In an Edubuntu lab, the classroom server is configured as a DHCP
server. A system administrator assigns a range of IP addresses
to the server. Each client computer on the LAN has its TCP/IP
software configured to request an IP address automatically
from the DHCP server when that client computer starts up. The
request-and-grant process uses a lease concept with a
controllable time period. This eases the network installation
procedure on the client computer side considerably.
</p>

<p>In addition to the IP address, a DHCP server can set other
configuration information, such as the address of the DNS
server, the DNS domain of the client, and the gateway IP
address, so that the client computer can be fully functional.
</p>

<p>Before I continue, let me explain the concepts I've just
introduced. First, the DNS domain: all Linux computers are
given a hostname upon installation of the OS, which is used in
system messages and configuration. When the computer joins a
network, its hostname and the domain of the network together
combine to form the Fully Qualified Domain Name ( FQDN) of the
computer. In the case of an Edubuntu lab, the FQDN of each
workstation will be something like XXX
client1.myschool.Edubuntu lab.org.za. The public DNS servers that
resolve the domain names of Edubuntu labs on the internet are
maintained by SchoolNet
http://www.schoolnet.org.za/schoolsurveys/suveys_index.htm
</p>

<p>Secondly, the gateway IP address. In Section 8.3 I explained
that the internet is a network of networks. For data packets
from a computer on one network to reach a server on another
network, there needs to be a gateway that is connected to both
networks at once. Usually, the gateway computer will have a
network card for every network to which it is connected.
</p>

<p>By default, the LTSP server uses its first network card (
eth0, numbered from 0 like most things in the computer world)
for the classroom LAN. It runs DHCP on this card, and
automatically gives out IP numbers upon request. It then
accepts BootP (Boot Protocol) and PXE (Pre-boot eXecution
Environment) boot requests, and passes on the Linux kernel to
the client using TFTP for the transfer. Once the client has
received the kernel, it boots into Linux. The default
dhcpd.conf file will support over 200 clients. The LTSP server
will not answer DHCP requests over eth1 (with the default
settings.)
_________________________________________________________
</p>

<p>9.2.1. Files
</p>

<p>The configuration settings for the DHCP server are contained
in the /etc directory --- standard Linux location for
configuration data --- in the file /etc/dhcpd.conf. XXX which
settings in here should be explained?
_________________________________________________________
</p>

<p>9.3. Network configuration
</p>

<p>The first network card, eth0, is the interface on the
thin-client side of your LTSP server. This network card
connects to your terminal hub. The 192.168.0.x address range
is designated as a "private" IP range for internal networks.
It is not routed on the internet. IP traffic from your clients
are routed to the internet through eth1. (Note that if there
is a Wizzy server, it will be the one with the two network
cards.)
</p>

<p>The classroom server has the last available address in this
range, namely 192.168.0.254 ( 192.168.0.255 is the broadcast
address: packets sent to this address reach all the computers
on the network). The first client will be assigned an IP
number of 192.168.0.253. [16]
</p>

<p>(XXX: make a local one) Dialogue (screenshot):
http://www.k12ltsp.org/screen7.gif
_________________________________________________________
</p>

<p>9.3.1. Wizzy network configuration
</p>

<p>When the Edubuntu lab has a Wizzy server, there are a couple of
other aspects to network configuration.
</p>

<p>* Protocols
Wizzy Digital Courier relies on standard networking
protocols for the interactive portions, linked by UUCP for
the intermittent sections.
* Mail configuration
During installation, you must choose a hostname for the
Wizzy server. This hostname will identify the server
within the mail domain, which is wizzy.org.za (because
Wizzy provides the email infrastructure), so that your
complete mail domain becomes myschool.wizzy.org.za (where
myschool is the hostname you chose). This means that all
the Edubuntu lab users will get email addresses like
user@myschool.wizzy.org.za.
You will also need to contact Andy Rabagliati at XXX, to
tell him your UUCP password, as he must set up mail
routing for you.
For Edubuntu labs, Wizzy servers have a special configuration
available --- accessible by typing the following at the
Syslinux boot prompt:
boot: linux ks=cdrom:/tsf-ks.cfg
_________________________________________________________
</p>

<p>9.4. Network Filesystem
</p>

<p>Edubuntu lab uses NFS, the Network Filesystem, to make the home
directories of lab users appear to be local to the client
workstations, even though they really reside on the classroom
server. The NFS configuration is specified in the file
/etc/exports on the classroom server.
_________________________________________________________
</p>

<p>9.5. LTSP configuration
</p>

<p>The LTSP configuration is specified in the file lts.conf on
the classroom server. For more detail about this file, see
Section 13.5.
_________________________________________________________
</p>

<p>9.6. tftpboot
</p>

<p>Upon power-up, the BIOS of each client workstation contacts
the classroom server, and retrieves the Linux kernel from it
via the TFTP protocol. XXX: more detail.
_________________________________________________________
</p>

<p>9.7. Users and groups
</p>

<p>All the users of the Edubuntu lab will have accounts on the
classroom server. (Additionally, if they have email they will
have accounts stored in the Wizzy server's LDAP directory.)
</p>

<p>XXX: who adds them? Root? Using some RedHat config tool?
_________________________________________________________
</p>

<p>9.7.1. Permissions
</p>

<p>Access to directories, files and executable programs under
Linux is managed in terms of users, groups and permissions.
Every user belongs to a group, and every file belongs to a
user and a group. The basic permissions are read, write and
execute. For every file and directory, these permissions can
be set for the user who owns the file, the group, and for all
others (i.e. everyone but the owner or the group). For
example, here are the permissions of a user's home directory:
jean@klippie jean $ ls -ld /home/jean
drwxr-xr-x 112 jean users 6664 Des 26 17:31 /home/jean
</p>

<p>The permissions are shown by the string drwxr-xr-x. The first
character, d, indicates that this is a directory. You should
read the following 9 characters in groups of three, that show
the permissions for the owner jean ( rwx), the group users (
r-x), and all others ( r-x). In this case, the owner has read
( r), write ( w) and execute ( x) permissions, while the group
and others only have read and execute permissions. In the case
of a directory, execute permissions means that you are allowed
to access the contents of the directory. This home directory
may therefore be read by everyone, but only the user may
change it.
</p>

<p>Here are the permissions on the file that contains the system
user database:
jean@klippie jean $ ls -l /etc/passwd
-rw-r--r-- 1 root root 2118 Des 1 05:32 /etc/passwd
</p>

<p>These indicate firstly that this is a regular file, not a
directory (the leading -), and that the owner root has read
and write permissions ( rw-), and everyone else have only read
permissions ( r--). In effect, this means that only the root
user may add, modify or delete users.
</p>

<p>You may further note that the group to which this file belongs
is also root. This group only has one member (the root user),
and is used for files that are under control of only this
unique user.
_________________________________________________________
</p>

<p>9.7.1.1. The superuser
</p>

<p>Every Linux machine normally has a user called root, who has
all permissions. When a system administrator needs to do
maintenance, they log in as root only to make the necessary
changes, and then switch to their regular user again.
_________________________________________________________
</p>

<p>9.7.2. Retiring users
</p>

<p>XXX: what happens when a user is retired? Is the password just
reset, or is the whole home directory and all email deleted?
_________________________________________________________
</p>

<p>9.8. Printing
</p>

<p>XXX: Cups ...
_________________________________________________________
</p>

<p>9.9. Developing a backup procedure
</p>

<p>The importance of backing up a system can never be stressed
enough. You never know when the power may cut out or the hard
drive may crash. Even though you can restore the operating
system from the distribution CD-ROM, there are other files
that you need to consider. What about the configuration
changes that you made? There are also files created by users,
what about those?
</p>

<p>Follow these steps to create a backup plan:
</p>

<p>1. Make a list of the files and directories that you need
backups of. You'll always want to backup system
configuration files in the /etc directory, other
configuration files may be found in /usr/lib. In addition,
you may want to backup user files in the /home directory
as well as the superuser ( root) files in /root.
2. Find a few tools to use when backing up and archiving
files and directories. Several tools are available that
will archive a group of files, and there are tools that
will compress files and archives.
3. Decide how often the system and individual files need to
be backed up. How often do your files change? If files
change frequently, the your backup frequency should match
the change frequency. So, you may need to perform a backup
every day. If you only make one or two configuration
changes on occasion, you can easily backup the
configuration files only when the changes is made.
4. Select a storage medium that will store the backup file.
If you have a few files to backup, you could just store
them on a floppy disk. If you have more files, or larger
files, you can consider using a zip drive or a CD-RW
drive.
5. Store the files in a safe place. The safest place to store
the backup media is at a location different from where the
computer is located. To be really safe, this location
needs to be protected from fire and other hazards. You may
also want to keep a copy of the backup files close by so
that you can quickly restore lost files.
</p>

<p>Tip: Always make a copy of configuration files before you make
any configuration changes. That way, should your new settings
not work, you can restore the old configuration files.
_________________________________________________________

</body>
</html>