This chapter is about configuring all the services that were installed in the previous steps. First we will set up a comfortable working environment, and then we will check and perhaps modify various configuration files. It is recommended to perform these steps in the order in which they are presented here.

NOTICE: While configuring the various services you often need to type commands at the command prompt. By default the command prompt looks like this: [root@praeceptor etc]# _. The word 'root' is the name of the user account you are logged into. The word 'praeceptor' indicates the hostname of the server you are currently working on. The word 'etc' in this example shows the last part of the name of the current working directory (here: '/etc').
All commands should be confirmed by pressing the [Enter] key on the keyboard. In order to keep the examples and illustrations clean, it is assumed that you will press [Enter] after every command even if this is not explicitly indicated in the text.

(top)

2. Basics

Before we begin with configuring, we can make our working area a little more comfortable. Note that we don't have a connection to the Internet yet (eth0); perhaps even the internal network is not yet connected (eth1).

NOTICE: In order to make sure that no intruder breaks into your server while you are configuring it, it is a good idea to leave the network cable for the external network interface eth0 unconnected. You can plug it in after you have completed the configuration in section 21.9 below.

NOTICE: For added safety you may want to take a peek ahead in section 21.5 Autoupdate and switch the automatic update off by setting the parameter DoUpdate to 0. This prevents the server from updating itself while you are busy configuring it. If you let the server update itself, the lack of correlation between the documentation you are reading and a newer version of some software package that has been installed automatically may be very confusing. Note that autoupdate will not work as long as you don't have a connection to the outside world.

In this section we will be changing a few configuration files to make life easier while configuring the various subsystems. You can use either vi(1) (/bin/vi) or nano(1) (/usr/bin/nano) to edit these files. If you selected to install the documentation, you can read more about these editors by typing the command man vi or man nano, respectively.

NOTICE: It is quite common to refer to a command by its name followed by a number in parenthesis, e.g. vi(1) or passwd(1). The name itself (here: vi or passwd) refers to the corresponding file which comprises the command (/bin/vi or /usr/bin/passwd). The number in parentheses is the number of the section in the manual which holds the relevant documentation. Sometimes it is necessary to distinguish between the various sections in the manual, e.g. there is a manual page for passwd(1) describing the command but there is also a manual page passwd(5) which documents the layout of the file /etc/passwd. You can view the correct section of the manual by specifying the correct section number in the command like this: man 5 passwd. The most important sections of the manual are 1 (user commands and applications), 5 (file formats) and 8 (administrator commands). See also the manual's manual (man man).

In the remainder of this text we will assume that you are logged into the console (tty1) as root, using the root password you entered during the installation phase (see section 13. Root password in chapter III. Using the text mode installation program).

2.1 /etc/modules.conf

The ServerAtSchool software is based on the assumption that the actual server has two network interfaces. The interface eth0 is the interface which connects to the outside world (Internet). The server is connected to the LAN via interface eth1.

The bare installation of the network interfaces and the assignment of the names eth0 and eth1 depends on the order in which the various kernel modules for network devices were loaded during installation. There is a chance that the interface for the LAN was assigned the name eth0 and the interface for the external connection became eth1.

The names eth0 and eth1 are aliases for the network drivers. These aliases are defined in the file /etc/modules.conf. Here is an example of the contents of such a file:

configuring_modules.conf1.png

Note that the driver e1000 (an Intel PRO/1000 Gigabit interface on an ASUS motherboard) is assigned the name eth0. It makes no sense to assign such a fast interface to the outside connection, especially when the server is connected to a gigabit switch serving the LAN. The other interface (in this case a 3Com 3c905C-TX-M) with the 3c59x driver is only a 10/100 Mb/s card, which is more than good enough for the external interface, but for the internal interface the Intel Pro/1000 would be better. You could change the file /etc/modules.conf to look like this:

configuring_modules.conf2.png

If you want to make sure that the changes work as you intended, you should stop the network (which is doing nothing at this point anyway), unload the relevant modules, and restart the network. This ensures that the relevant modules are reloaded and that the network interfaces are assigned the names you specified in /etc/modules.conf.

Issue the following commands:

Find out the current status of eth0 and eth1 by issuing this command: ifconfig | grep HWaddr
Stop the network with this command: service network stop.
Unload the relevant kernel modules with (in this example): rmmod e1000 and rmmod 3c59x.
Edit the file /etc/modules.conf and make necessary changes.
Check the contents of the file, e.g. with cat /etc/modules.conf.
Start the network again with this command: service network start.
Verify that the names are now assigned correctly with the command ifconfig | grep HWaddr.

If everything went as planned, you should see that the names eth0 and eth1 are now assigned to the correct hardware address. Here is an image that documents these steps:

[ checking the corrected file /etc/modules.conf ]

configuring_checking_modules.conf.png

NOTICE: The hardware addresses of network interfaces always start with three vendor-specific octets called OUI (Organisational Unique Identfier). These numbers are assigned globally (by the IEEE). The Intel network interface in this example can be recognised by the sequence 00:0E:A6:xx:xx:xx, the 3Com interface is 00:0A:5E:xx:xx:xx. A searchable list of these OUIs can be found at http://standards.ieee.org/regauth/oui/index.shtml.

NOTICE: From the example above you can see that it is helpful to have two different network cards in the server, since it makes it easier to distinguish between them. However, you can of course equip the server with two identical network cards if you wish. In this case the rule of thumb is that the card closest to the CPU is eth0 and the other one is eth1.

2.2 Session logging

Sometimes it is very useful to be able to recall what you did, exactly, on a command line. A handy way to keep track of all your commands is to use the command 'script(1)' (see man script for more information). This command copies your complete terminal session to a file. This file (a 'typescript' in a way, hence the name 'script') can be studied afterwards. It can also be used to help auditing the server.

During the installation of ServerAtSchool a collection of goodies was installed in the directory /home/share/install/goodies. You may want to copy the file /home/share/install/goodies/bash_profile to the file /root/.bash_profile. This modified file .bash_profile will then be executed every time you log in. You can copy the file with the command below. Your input is shown emphasised in the illustration.



[root@praeceptor root]# cp /home/share/install/goodies/bash_profile /root/.bash_profile 
cp: overwrite `/root/.bash_profile'? y
[root@praeceptor root]# _

Note that cp(1) requires a confirmation before overwriting an existing file. We will deal with that issue in 2.3 Common command aliases: yes or no? below.

The differences with the original file .bash_profile are these:

the user prompt is changed to show the current time
the user prompt is changed to show a large blinking cursor rather than a small blinking underline
a script subddirectory is created in the user's $HOME, with a name based on today's date, e.g. /root/script/2005-03-05.
the script is created in a file in this directory. The name of the script is based on the current time and the process ID of the bash process that started the script.

When you log out and then on again, a script of every terminal session will be created. This is illustrated in the image below.

[ example of creating a session typescript ]

configuring_session.script.png

NOTICE: Because of the session scripting, it is necessary to log out twice in order to end the session. The first time ends the typescript, the second time ends the session.

NOTICE: You can use the exit command or the [Ctrl-D] key combination to log out from script(1) and from the Bash session.

2.3 Common command aliases: yes or no?

In the standard Bash Runtime Configuration for root (the file /root/.bashrc) three aliases are defined:

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

These aliases enforce the interactive use of the commands /bin/rm, /bin/cp and /bin/mv respectively. The interactive mode prompts you, user 'root', every time a potentially destructive command is given, e.g. the removal of a file or an attempt to overwrite an existing file. This interactive mode can be a life saver, especially when the command is issued when you are logged in as root. If you do not use the interactive mode, the command rm -rf / will destroy your complete file system, no questions asked.

For the more experienced systems administrator, this interactive use can be very annoying. Such users may want to comment out or remove these three commands in /root/.bashrc. If you are uncertain about this, please don't touch the file .bashrc and you may save yourself some unpleasant experiences. Note that any changes you make to this startup script are effective after you next log in; you have to log out and log in again to let the changes take effect.

NOTICE: There lies a danger in using these interactive aliases. You may get used to them and eventually depend on them, e.g. when removing selected files with rm * and replying 'n' for every file you want to keep. This is really bad practice. You simply cannot and should not rely on this feature: if at some point someone changes or removes these aliases, your 'trick' will stop working and you will lose files. Also, if you happen to find yourself at the root prompt on another (Linux) machine, you may find out the hard way that you are not protected by the interactive use of these commands. If you expect to become a seasoned sysadmin, you might as well get used to living dangerously and remove these aliases. It's up to you.

2.4 /etc/DIR_COLORS

By default all directory listings are coloured. This means that different filetypes and files with certain permissions are shown in different colours when you give the ls(1) command. Depending on your preference, this can be either extremely helpful or extremely annoying. You can switch off the coloured ls by editing the file /etc/DIR_COLORS. Near the top of the file there is an entry that looks like this:

COLOR tty

This means that the output of ls will show colours when output on a tty, but not when output is redirected to a pipe. You can switch off the colour feature completely by changing this entry to read:

COLOR none

NOTICE: The file /etc/DIR_COLORS configures the system-wide default for ls colourisation. The default can be overruled on a per user basis by copying the file /etc/DIR_COLORS to $HOME/.dir_colors and subsequently customising the copy in the user's home directory. The settings in $HOME/.dir_colors override the system defaults.

2.5 Choosing passwords

During the configuration of the various services and subsystems you will need a few good passwords. You already had to come up with a good password in section 13. Root password in chapter III. Using the text mode installation program.

A good password has at least one digit (0,...,9), at least one lower-case letter (a,...,z), at least one upper-case letter (A,...,Z), and preferably at least one special character. Suitable special characters are: at-sign '@', hash '#', dollar '$', percent '%', caret '^', ampersand '&', asterisk '*', left parenthesis '(', right parenthesis ')', dash '-', underscore '_', plus '+', equals '=', left curly brace '{', right curly brace '}', opening bracket '[', closing bracket ']', semicolon ';', slash '/', dot '.', and question mark '?'. It is also a good idea to choose a password at least 8 characters long.

As part of the installation of ServerAtSchool, two small utility programs were installed that can help you with generating passwords: pwgen(1) and makepasswd(1).

pwgen(1) generates (more or less) pronouncable passwords that are relatively easy to memorise. After entering the command, you will see a screen like this:



ea8Nuiwo ohF9quei Re6oifax iaghee4H Nae8upae cooT9joo Thohc4fo oolaeh0E
ookuoC5u Shaevuf5 quu4Thei yee0Opew ing1Eshe sai5Geph ooDeeng8 Odu8thah
Lie1ieka Tee5geiv ahP1iefo Joku0iew el2Aisho Huaqu6ju tai2Xaid aiyeij2U
Mus5aete Eil3oozu oX9pheif oiz4Ohph Woo6vair uu2taiZi Jas0ahpo yiuKoo6y
Chuut7xe eiC6chou Yi3piepa Eiw9ocoh phai3Cha Quaifa5a Meiyo9mo oot5Dohb
wahNgoj9 ro9Phoat aeKa7ash eig5Hogh gahw3Rae aid0Sahc Vaiv2doo choom0Ch
Zohy8fuu Rier2rie eechai5I Hof3woet Ohh9udon ba9jeWei phaeZ2ci eequae7U
aejahNg8 Pie6seib Ahng3eeb Aing0jie Quieyai9 Aen4okae mi3lahTo aaTh5yit
Pheez5th che6Uowa yaR6aegh uoc0Eesh Rah5aaxi veiVee9d Iethaaj0 gohleiW6
theeRie3 Eit6zoos Eesh6vah Pae7vagh uK0juxel eef9Iuyo Ajahso3a caaX1hoo
Veepa9ko wushei7B Aex3nafo ohzoe3No ve0ooWon xeixaa1D daifet6I eCh2reik
Xiayooy7 Ohbooc8e vu6Veemu ea3ohMei be5Phahw Geepha8e aWahv0hu suXue5ai
Eich7ako gooPai7i phoofe0A Hoo9heiv Eich4fid mioTh0ze Phui8wee Eejoh7ki
aeh8Oofu chiqu8Fi Aeg2eboh Waed8zel ohw1zeeX So4aedoh Aeheegi8 Ohnae2au
Phei4mas Eep7ooxi uPhueb2a feimeX3k ail3veiT tePiel6e eic2ooTe Oboolei7
Aebang0y otooF5bu La3neboo Aab3oodo eiDe0hai echae7Ke ob6Xiung phiv0Lie
eigh7Xah toa7Uzao Ies2xaew Aex8haid cea1eiWo ooP5geez Mee6ihef Sohlee8e
choJoh6n Jee0kohh ieL1lawa Ahsh6qui Ohkaita1 iaYee8ku Aeph3gip Cohr4eex
Ze4ohsij Shi5chee aeth2oNi enejuuB9 ril6eoSo Phoor6oo Yotae0mo dulohNi8
Woosahj1 eeMi1aet Eir4oree heY1yaro wao2Poov Aothu6ah Kou1jaen Ta3akahm

From this list you can pick a password you like. If you want to make the generated password more secure, you can add the -s switch to the command. If you want to generate a single password consisting of 8 characters, you can use the command 'pwgen 8 1'. See man pwgen for more information.

makepasswd(1) generates a single password by default. The difference with pwgen(1) is that the emphasis is on secure passwords rather than pronouncable passwords. You can generate more passwords at the same time, say seven, by using the command 'makepasswd --count=7'. See man makepasswd for more information.

You need to think of passwords when configuring MySQL, Site@School, Mailman and of course when adding user accounts to the system.

It is bad practice to re-use the same password over and over again. If you use the same password for everything, an intruder will only have to crack your password once to gain access to everything, which could include the all important root account. You really do not want that to happen.

It is also very bad practice to use existing words and names as passwords because it is easy to crack such passwords using a (precompiled) dictionary of words and names. Particularly bad choices for passwords are your own name, the name of your spouse, your children's names, the name of the dog, your postcode (zipcode) or the number on your car's license plate.

In section 3. Password list in Appendix D. Worksheets you will find a worksheet that can help you keep track of all the different passwords.

2.6 Remote maintenance via SSH

In order to maintain the server from a remote location it is very convenient to be able to set up a terminal session using SSH. SSH allows for a secure (encrypted) connection. The ServerAtSchool server uses OpenSSH as the implementation of this secure protocol. An in-depth discussion of OpenSSH can be found in chapter 16 of [Mourani 2002].

Apart from the possibility of using SSH to log in from a remote location (inbound traffic), OpenSSH is also used to copy backups from the server to a remote location (outbound traffice). See section 11.3 Creating remote backups for more information. You may also want to consult the manual pages for ssh_config(5) and sshd_config(5).

A few settings may have to be changed in order for this to work:

the settings for the SSH server (inbound) in /etc/ssh/sshd_config
the settings for the SSH client (outbound) in /etc/ssh/ssh_config
the firewall settings for SSH traffic in /etc/giptables.conf

The default configuration for the SSH server is illustrated below. Lines of interest are shown emphasised.



# /etc/ssh/sshd_config: OpenNA, Inc. (last updated 2004 Jan 05)

Port                            22
Protocol                        2
ListenAddress                   0.0.0.0
HostKey                         /etc/ssh/ssh_host_key
HostKey                         /etc/ssh/ssh_host_rsa_key
HostKey                         /etc/ssh/ssh_host_dsa_key
ServerKeyBits                   768
LoginGraceTime                  60
KeyRegenerationInterval         3600
PermitRootLogin                 no
IgnoreRhosts                    yes
IgnoreUserKnownHosts            yes
StrictModes                     yes
X11Forwarding                   no
X11DisplayOffset                10
PrintMotd                       yes
KeepAlive                       yes
SyslogFacility                  AUTHPRIV
LogLevel                        INFO
RhostsRSAAuthentication         no
RSAAuthentication               yes
PasswordAuthentication          no
PermitEmptyPasswords            no
UsePrivilegeSeparation          yes
Compression                     yes
Subsystem                       sftp /usr/libexec/openssh/sftp-server
AllowGroups                     teleworkers buddies

Explanation:

You should never set the directive PermitRootLogin to yes; you should not even give outsiders half a chance to get a go at guessing your root password this way.
You may want to set the directive PasswordAuthentication to Yes in order to be able to log in as a regular user with just a password.
The directive AllowGroups limits access to the server to members of the specified groups. By default only teleworkers and buddies are allowed to log in (but see the notice below).

NOTICE: The AllowGroups directive may be missing from the configuration file. In that case it is recommended to add it manually, including the space-delimited list of allowed groups. ServerAtSchool already has the groups 'teleworkers' and 'buddies' predefined.

NOTICE: If you want to make access more secure, you could leave the directive PasswordAuthentication set to no. However, this means that you will always have to log in using a private/public key pair. This is a good example of the trade off between convenience and security.

NOTICE: It may be convenient, at least for the time being, to have PasswordAuthentication set to yes while you are setting up your server to receive backups from another school. See section 11.5 Creating buddies below.

NOTICE: If you have changed the configuration file for the SSH server, you should restart the server. You can do so with the command 'service sshd restart'.

The default (system-wide) configuration for the SSH client is illustrated below. Lines of interest are shown emphasised.



# /etc/ssh/ssh_config: OpenNA, Inc. (last updated 2004 Jan 05)
  
Host                            *
  ForwardAgent                  no
  ForwardX11                    no
  RhostsRSAAuthentication       no
  RSAAuthentication             yes
  PasswordAuthentication        no
  FallBackToRsh                 no
  UseRsh                        no
  BatchMode                     no
  CheckHostIP                   yes
  StrictHostKeyChecking         yes
  Compression                   yes
  IdentityFile                  ~/.ssh/identity
  IdentityFile                  ~/.ssh/id_dsa
  IdentityFile                  ~/.ssh/id_rsa
  Port                          22
  Protocol                      2
  Cipher                        blowfish
  EscapeChar                    ~

Explanation:

You may want to temporarily change the PasswordAuthentication to yes in order to log into another server using just a password (instead of a key pair). This can be convenient when setting up remote backups (see section 11.3 Creating remote backups below). You should change it back to no afterwards to prevent your (compromised) system being used as a 'stepping stone' by crackers to compromise other computers from.
You can set the StrictHostKeyChecking to no during the configuration phase on your server. This way you can 'automatically' collect common host keys. Afterwards you could then reset this directive to yes to prevent Trojan Horse attacks. This is a security feature.

NOTICE: The SSH configuration files contain many more options than those shown here. You can distinguish between various hosts and use different settings for each of them. This topic, too, is discussed in chapter 16 of [Mourani 2002].

Even when the SSH server and client configuration files are set up correctly, it may be necessary to check the firewall settings for SSH. The illustration below shows the default settings for SSH in /etc/giptables.conf.



# ****************************************************************************
#                                                                            *
#                                    S S H                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_SSH="yes"

# ----------------------------------------------------------------------------
# SSH outgoing client request
#

# Interface 0 SSH outgoing client request

    INTERFACE0_SSH_CLIENT="no"

    INTERFACE0_SSH_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_SSH_OUT_DST_IPADDR[0]=$ANY_IPADDR

# Interface 1 SSH outgoing client request

    INTERFACE1_SSH_CLIENT="no"

    INTERFACE1_SSH_OUT_SRC_IPADDR[0]=$INTERFACE1_IPADDR
    INTERFACE1_SSH_OUT_DST_IPADDR[0]=$NETWORK1

# Network 1 SSH forwarded outgoing client request

    NETWORK1_SSH_CLIENT="no"

    NETWORK1_SSH_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_SSH_OUT_DST_IPADDR[0]=$ANY_IPADDR

# ----------------------------------------------------------------------------
# SSH incoming client request
#

# Interface 0 SSH incoming client request

    INTERFACE0_SSH_SERVER="yes"

    INTERFACE0_SSH_IN_SRC_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_SSH_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

# Interface 1 SSH incoming client request

    INTERFACE1_SSH_SERVER="yes"

    INTERFACE1_SSH_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_SSH_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

    INTERFACE1_SSH_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_SSH_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR

Explanation:

Outgoing traffic to the Internet (via eth0) is not allowed
Outgoing traffic to the LAN (via eth1) is not allowed
Traffic from the LAN to the Internet is not allowed
Incoming traffic from the Internet (via eth0) is allowed
Incoming traffic from the LAN (via eth1) is allowed

Basically this means that it is allowed to log into the server (for maintenance or otherwise) from either the Internet or the LAN. No outgoing traffic is allowed, nor is forwarded traffic from the LAN to the Internet allowed. This is a security measure.

NOTICE: By enabling SSH login from the LAN, you can perform maintenance tasks on the server while sitting behind a workstation somewhere in the building, in a comfy chair, rather than hanging upside down in a broom closet.

NOTICE: If you will not be carrying out remote server maintenance via the Internet and you do not want to allow teleworking (i.e. letting teachers access their documents on the server from home) you should close the firewall for SSH on interface eth0 by setting INTERFACE0_SSH_SERVER to "no". Then restart the firewall for the changes to take effect. You can use the command 'service giptables restart' for this purpose.

NOTICE: If you really want to access the server via SSH (from the Internet or from the LAN), you should use a regular user account (see section 10. Janitor for more information on creating user accounts). This user account must also be a member of the predefined user group teleworkers. Only members of this group are allowed to access the server in this way. This is taken care of in the configuration file /etc/security/access.conf.

(top)

3. Bind

One of the standard components of the ServerAtSchool server is the DNS (Domain Name System) server. This software is named Bind (Berkeley Internet Name Domain) and is used to map computer names to IP addresses and vice versa. The actual name of the Bind daemon is 'named' (for 'Name Daemon'). It is pronounced 'name-dee'.

A default configuration file is generated during the installation of ServerAtSchool, as are two 'zone files'. These files are located in directories within the chroot jail in which Bind runs. The configuration file is /chroot/named/etc/named.conf and the zone files are located in /chroot/named/var/named/. The names of the zone files are derived from the local domain. Using the example from earlier chapters (host praeceptor.exemplum.serveratschool.net serving the internal network 172.17.2.0/24), the forward zone file (mapping names to numbers) is called /chroot/named/var/named/db.exemplum.serveratschool.net and the reverse zone file (mapping numbers to names) is called /chroot/named/var/named/2.17.172.in-addr.arpa.

As a rule, the configuration can be used as it is. However, depending on your actual situation you may need to modify one or more of the configuration files. In the remainder of this section we will discuss the default setup and the reasons why this particular setup was chosen. Also a few typical examples are shown, based on the same demonstration host praeceptor we used earlier.

A more thorough and in-depth explanation of Bind can be found in chapter 28 of [Mourani 2002]. You may also want to consult the Bind homepage at http://www.isc.org/sw/bind.

3.1 Default configuration in ServerAtSchool

The default configuration as provided by the ServerAtSchool installation program sets up Bind to act as a caching name server and also an authorative name server for the local domain. Requests that can not be handled by this name server are forwarded to one of the two forwarders. In our example these are the name servers 62.58.94.130 and 62.58.62.132. These name servers were defined in section 10. Network configuration in chapter III. Using the text mode installation program. The name server only listens to requests that come from the LAN-side of the server, i.e. from the client computers, and not to requests from the Internet at large.

By default the complete internal network is named after the host's domain name: exemplum.serveratschool.net. The individual clients all have a name in that domain: c2, c3, ..., c254. All the client names map to the corresponding IP address within the subnet: c2 has address 172.17.2.2, c3 has address 172.17.2.3 and so on.

Allthough it might seem boring to name the client computers with a letter followed by a number, this scheme actually makes it easier to keep track of individual client computers. You can give all your client computers a number (which you can write on the computer case with a big felt tip pen) and have your users easily identify the computer by number, which can be handy if you're troubleshooting over the phone.

The server itself has a series of different names within the domain: ns, mail, news, gw, gateway, server and of course praeceptor. All these different names for the server are translated to the internal IP address 172.17.2.1. There is one exception: the primary hostname (praeceptor in our example) also yields the external IP address. That is the address that is assigned to eth0 during the installation; 62.59.32.61 in our example.

It may sound confusing to have so many names for the same server. The reason for doing so is to make it easier to remember the function of the server in a particular context. If you refer to the server using the name ns, chances are that you are interested in the name server aspect of the server. If, however, you are talking about mail, you are probably working with Exim or other software related to electronic mail. The added advantage of using all these different names is that you could easily move say the mail server to another machine (perhaps 172.17.2.2) by adjusting the zone files accordingly, without having to reconfigure all your client computers for the new mail server. If the client computers refer to the mail server under the name mail, it doesn't really matter to the client if this is the same server as ns or not.

The name server runs in a chroot jail. That means that if someone manages to abuse named to gain remote access to the server, the damage can be kept to a minimum because the intruder cannot get to the system itself from the chroot jail. This is a security measure.

3.2 Scenario 1 - in-house web server

If you want to host a website on praeceptor.exemplum.serveratschool.net and you want to be able to use the well-known name www for it, you must add the hostname www to the (forward) zone file. Use an editor (vi or nano; both are provided) and edit the zone file /chroot/named/var/named/db.exemplum.serveratschool.net mentioned earlier. You should add a single line in the zone file which maps the name www to the address 172.17.2.1.

Every time you make a change to a zone file you should increase the zone file serial number. This indicates to any slave name servers that a master zone file has been changed and that the slave should update its cached data. Even though ServerAtSchool does not use slave name servers, it is still a good habit to update this serial number after every change. By convention the serial number has ten digits consisting of a 4-digit year, a 2-digit month, a 2-digit day and a 2-digit sequence number.

You also have to restart the name server in order for the changes to the zone file to take effect. You can use the command 'service named restart' for this purpose.

The example below shows the important parts of the modified zone file for this scenario. The modified and added lines are shown emphasised. (Note that a long list of host definitions was removed in this illustration to save space).



;$ORIGIN exemplum.serveratschool.net
$TTL    86400
@       IN      SOA     ns.exemplum.serveratschool.net. hostmaster.exemplum.serveratschool.net. ( 
                        2005031801      ; serial, todays date + date serial #
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum

                IN      NS      ns.exemplum.serveratschool.net.
                IN      MX 20   mail.exemplum.serveratschool.net.

localhost       IN      A       127.0.0.1
ns              IN      A       172.17.2.1
mail            IN      A       172.17.2.1
news            IN      A       172.17.2.1
gw              IN      A       172.17.2.1
gateway         IN      A       172.17.2.1
server          IN      A       172.17.2.1
www             IN      A       172.17.2.1

praeceptor      IN      A       172.17.2.1
c2              IN      A       172.17.2.2
[...snip...]
c254            IN      A       172.17.2.254

; The line below adds the external IP-address of the server to this zone
; You may want to add more (fixed) IP-addresses for external servers, e.g.
;
; mail          IN      A       192.168.1.1
;
; or
;
; www           IN      CNAME   webserver.isp.net
;
; Note that the host praeceptor now has 2 different IP-addresses defined in this zone

praeceptor      IN      A       62.59.32.61

; eof db.exemplum.serveratschool.net

This modified zone file yields the IP address of the server (172.17.2.1) whenever the name server is queried for the address www.exemplum.serveratschool.net. Of course this is only relevant to the clients on the LAN because the address 172.17.2.1 has no meaning on the Internet at large since it is in a private address range. The net result is that any client computer on the LAN can now 'surf' to www.exemplum.serveratschool.net.

This only works on the inside (on the LAN) because our name server does not serve names to the outside world. This is stated in the configuration file named.conf in the option allow-query { trusted; }; where the trusted clients are limited to the clients on the LAN.

By adding www to this zone file, nothing changes for the outside world. If you want to make www.exemplum.serveratschool.net visible from the outside too, you should also change the mapping between the name www.exemplum.serveratschool.net in the name server(s) that serve the domain names to the Internet. This is usually done by your ISP. You can probably simply ask your ISP to add or change the mapping for the host www in your domain to the external IP address of your server. In our example that would be 62.59.32.61. The situation is now as follows:

any internal host receives the reply 172.17.2.1 from the name server when querying the name www.exemplum.serveratschool.net.
any other host receives the reply 62.59.32.61 from the name server of the ISP when querying the name www.exemplum.serveratschool.net.

This is exactly the result we were looking for; effectively the host www.exemplum.serveratschool.net can now be reached from inside and from outside.

NOTICE: This discussion only facilitates the access to the server using a name rather than a numeric IP address. You still have to set up the web server and perhaps check the firewall settings for HTTP if you really want to serve your website to the LAN or the outside world. BIND only deals with mapping names to numbers and vice versa. We just used the hostname www as an example here.

3.3 Scenario 2 - web server running at ISP

Another scenario is to host your website www.exemplum.serveratschool.net on a server in your ISP's data center. This could save you a lot of bandwidth on your xDSL or cable connection, especially if your website is very popular. In this case your ISP probably already has set up the correct mapping between www.exemplum.serveratschool.net and the IP address of one of the ISP's servers, say 192.0.34.166.

This means that any host on the Internet that tries to resolve www.exemplum.serveratschool.net is directed to the host with the IP address 192.0.34.166 and so reaches your website which is hosted on that machine.

The notable exceptions to this story are the clients on your LAN. As soon as one of the clients tries to resolve the name www, the authorative name server (your name server, not the one at your ISP) will tell the client computer it cannot find the host www. This is of course due to the fact that we told our name server that it is authorative for the domain exemplum.serveratschool.net and we did not tell the name server to map the name www in the domain to the IP address of the ISP's server.

If you change the zone file db.exemplum.serveratschool.net and add www this issue will be resolved. The modified zone file looks like this (changed/added lines emphasised; irrelevant lines removed):



;$ORIGIN exemplum.serveratschool.net
$TTL    86400
@       IN      SOA     ns.exemplum.serveratschool.net. hostmaster.exemplum.serveratschool.net. ( 
                        2005031802      ; serial, todays date + date serial #
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum
[...snip...]
c254            IN      A       172.17.2.254

; The line below adds the external IP-address of the server to this zone
; You may want to add more (fixed) IP-addresses for external servers, e.g.
;
; mail          IN      A       192.168.1.1
;
; or
;
; www           IN      CNAME   webserver.isp.net
;
; Note that the host praeceptor now has 2 different IP-addresses defined in this zone

praeceptor      IN      A       62.59.32.61
www             IN      A       192.0.34.166

; eof db.exemplum.serveratschool.net

After you have changed these lines in the zone file all clients on your LAN will be able to resolve the name www to the relevant IP address 192.0.34.166, just like the rest of the Internet.

NOTICE: This scenario fails as soon as the ISP moves your site from 192.0.34.166 to another server. You can circumvent this problem by using a CNAME record rather than an A record in the zone file, e.g. www IN CNAME webserver.isp.net. This works as long as the ISP keeps your site on the machine webserver.isp.net and does not move it to another server altogether.

3.4 Firewall considerations

In order for your name server to function correctly, it is necessary for the firewall to be configured in such a way that:

the name server can serve information to the local network, i.e. answer queries from client computers
the name server can receive information from the name servers at the ISP, i.e. act as a client itself.

During the installation of the firewall (see section 4. Firewall in chapter III. Installing optional ServerAtSchool components) a default configuration file for the firewall was installed in /etc/giptables.conf. This default configuration file is already set up correctly for the name server. The illustration below shows these default settings.



# **************************************************************************** 
#                                                                            *
#                                    D N S                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_DNS="yes"

# ----------------------------------------------------------------------------
# DNS outgoing client request
#

# Interface 0 DNS outgoing client request

    INTERFACE0_DNS_CLIENT="yes"

    INTERFACE0_DNS_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_DNS_OUT_DST_IPADDR[0]=$ISP_PRIMARY_DNS_SERVER
    INTERFACE0_DNS_OUT_UDP_REQUEST[0]="yes"
    INTERFACE0_DNS_OUT_TCP_REQUEST[0]="yes"
    INTERFACE0_DNS_OUT_SPORT53_REQUEST[0]="no"

    if [ "$ISP_SECONDARY_DNS_SERVER" ]; then

        INTERFACE0_DNS_OUT_SRC_IPADDR[1]=$INTERFACE0_IPADDR
        INTERFACE0_DNS_OUT_DST_IPADDR[1]=$ISP_SECONDARY_DNS_SERVER
        INTERFACE0_DNS_OUT_UDP_REQUEST[1]="yes"
        INTERFACE0_DNS_OUT_TCP_REQUEST[1]="yes"
        INTERFACE0_DNS_OUT_SPORT53_REQUEST[1]="no"

    fi

# Network 1 DNS forwarded outgoing client request

    NETWORK1_DNS_CLIENT="no"

    NETWORK1_DNS_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_DNS_OUT_DST_IPADDR[0]=$ISP_PRIMARY_DNS_SERVER
    NETWORK1_DNS_OUT_UDP_REQUEST[0]="yes"
    NETWORK1_DNS_OUT_TCP_REQUEST[0]="yes"
    NETWORK1_DNS_OUT_SPORT53_REQUEST[0]="no"

    if [ "$ISP_SECONDARY_DNS_SERVER" ]; then

        NETWORK1_DNS_OUT_SRC_IPADDR[1]=$NETWORK1
        NETWORK1_DNS_OUT_DST_IPADDR[1]=$ISP_SECONDARY_DNS_SERVER
        NETWORK1_DNS_OUT_UDP_REQUEST[1]="yes"
        NETWORK1_DNS_OUT_TCP_REQUEST[1]="yes"
        NETWORK1_DNS_OUT_SPORT53_REQUEST[1]="no"

    fi
# ----------------------------------------------------------------------------
# DNS incoming client request
#

# Interface 1 DNS incoming client request

    INTERFACE1_DNS_SERVER="yes"

    INTERFACE1_DNS_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_DNS_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE1_DNS_IN_UDP_REQUEST[0]="yes"
    INTERFACE1_DNS_IN_TCP_REQUEST[0]="yes"
    INTERFACE1_DNS_IN_SPORT53_REQUEST[0]="no"

    INTERFACE1_DNS_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_DNS_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR
    INTERFACE1_DNS_IN_UDP_REQUEST[1]="yes"
    INTERFACE1_DNS_IN_TCP_REQUEST[1]="yes"
    INTERFACE1_DNS_IN_SPORT53_REQUEST[1]="no"

Explanation:

Outgoing traffic to a maximum of two specific hosts (via eth0) is allowed
Traffic from the LAN to the Internet is not allowed
Incoming traffic from the LAN (via eth1) is allowed

NOTICE: These default settings prohibit clients on the local network from querying outside name servers directly; all queries are to be answered by the name server running on the ServerAtSchool server. If necessary, the name server on the ServerAtSchool server will forward the requests to the name servers of the ISP. This is a security measure.

3.5 DNS-records and your ISP

By setting up the name server in the way described above, all clients in the local network will be able to resolve the various names of the server and also the names of other clients (both computers and printers) on the network.

However, in order to resolve the 'official' names of the server from the outside, something has to be done by the administrator of your domain name. In this documentation that would be the administrator of the domain exemplum.serveratschool.net. If you plan to serve your own website on the ServerAtSchool server (see scenario #1 above), you will want to have a mapping between the name www and the IP address 62.59.32.61. If you also want to be able to reach your server via the Internet under the name praeceptor, that name should map to 62.59.32.61 too. You may also find it convenient to map the empty hostname to the IP address 62.59.32.61. Finally, if you plan to handle your mail directly on the ServerAtSchool server, you may want to have a mapping between the name mail and 62.59.32.61.

The ISP's administrator should at least add the following entries to the external zone file for the domain. That is: the zone file that is used to serve the hostnames within the domain to the Internet at large.



praeceptor.exemplum.serveratschool.net. IN  A       62.59.32.61
mail.exemplum.serveratschool.net.       IN  A       62.59.32.61
www.exemplum.serveratschool.net.        IN  A       62.59.32.61
exemplum.serveratschool.net.            IN  A       62.59.32.61
exemplum.serveratschool.net.            IN  MX  20  mail.exemplum.serveratschool.net

If you plan to host your website at a server run by your ISP, the zone file should look like this.



praeceptor.exemplum.serveratschool.net. IN  A       62.59.32.61
mail.exemplum.serveratschool.net.       IN  A       62.59.32.61
www.exemplum.serveratschool.net.        IN  A       192.0.34.166
exemplum.serveratschool.net.            IN  A       62.59.32.61
exemplum.serveratschool.net.            IN  MX  20  mail.exemplum.serveratschool.net

NOTICE: It will probably be up to your ISP to make these changes to these zone files. You do not have to apply these changes to the zone file on your server. However, both zone files should agree on the mapping of 'external' names such as www to IP addresses.

(top)

4. Exim

Exim is the Message Transport Agent (MTA) used on OpenNA/ServerAtSchool Linux. It has been compiled and configured to give the best security and optimization. The most important features are:

Integrated anti-spam measures (using SpamAssassin)
Integrated anti-virus measures (using ClamAV)
Integrated support for mailing lists (using Mailman)
Integrated support for Sender Policy Framework (using libspf)

A more thorough explanation of Exim can be found in chapter 30 of [Mourani 2002]. You may also want to consult the Exim homepage at http://www.exim.org. More information on Sender Policy Framework can be found at http://www.openspf.org

4.1 Default configuration in ServerAtSchool

The installer has prepared a default configuration file for Exim in /etc/exim/exim.conf. This file already contains the hostname and the domain name that were specified earlier. The configuration file is also prepared for sending mail via Squirrelmail (if you chose to install that package) and for using Mailman (if you chose to install that package).

You should check the configuration file to see if everything looks all right. You also need to edit one more configuration file: /etc/exim/localdomains. Both files are discussed below.

4.1.1 /etc/exim/exim.conf

This is the main configuration file. You may want to change a few parameters. The illustration below shows the important parts of the configuration file. The modified and added lines and also other lines of interest are shown emphasised. (Note that a lot of lines were removed in this illustration to save space).


# /etc/exim/exim.conf: OpenNA, Inc. (last updated 2004 Oct 06)

######################################################################
#                    MAIN CONFIGURATION SETTINGS                     #
######################################################################

# Please change the following settings.
MAILNAME = praeceptor.exemplum.serveratschool.net
MAINDOMAIN = exemplum.serveratschool.net

# If you want to enable smarthost support, then uncomment the following line
# and define your smarthost.
#SMARTHOST_ROUTELIST =

# If you want to enable Mailman support, then uncomment the following line.
MAILMAN_HOME=/var/lib/mailman

# If you want to enable SSL Support, then uncomment the following line.
#CERTNAME = /etc/exim/certs/smtp.pem

# Enable teergrubing on acl errors and say how long we delay (unset to disable).
TEERGRUBE = 60s

[...]

smtp_banner = "Welcome on our mail server!\n\
        This system does not accept Unsolicited \
        Commercial Email\nand will blacklist \
        offenders via our spam processor.\nHave a \
        nice day!\n\n${primary_hostname} ESMTP ${tod_full}"

.ifdef CERTNAME
tls_certificate = CERTNAME
tls_privatekey = CERTNAME
tls_advertise_hosts = ${if exists {CERTNAME}{*}{127.0.0.1/8}}
.endif

allow_domain_literals = false
never_users = root:daemon:bin:sync
host_lookup = *
helo_allow_chars = _
trusted_users = mail : www
trusted_groups = mail

[...]

######################################################################
#                       ACL CONFIGURATION                            #
#         Specifies access control lists for incoming SMTP mail      #
######################################################################

begin acl

[...]

######################################################################
#                      ROUTERS CONFIGURATION                         #
#               Specifies how addresses are handled                  #
######################################################################
#     THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT!       #
# An address is passed to each router in turn until it is accepted.  #
######################################################################

begin routers

[...]

######################################################################
#                      TRANSPORTS CONFIGURATION                      #
######################################################################
#                       ORDER DOES NOT MATTER                        #
#     Only one appropriate transport is called for each delivery.    #
######################################################################

begin transports

[...]

local_delivery:
  debug_print = "T: local_delivery for $local_part@$domain"
  driver = appendfile
  maildir_format
  create_directory
  maildir_tag = ,S=$message_size
  directory = ${home}/Maildir/
  return_path_add
  delivery_date_add
  envelope_to_add
  group = mail
  mode = 0660
  no_mode_fail_narrower
  headers_remove = "Lines"
  headers_add = "Lines: $body_linecount\n"
  check_string = ""
  directory_mode = 700
  message_prefix = ""
  message_suffix = ""
  quota = 10M
  quota_size_regex = S=(\d+)$
  quota_warn_threshold = 75%

[...]

# End of Exim configuration file

Explanation:

The variables MAILNAME and MAINDOMAIN should have been set correctly during the installation, but it is a good idea to double-check them.
The variable SMARTHOST_ROUTELIST has been commented out by prepending the relevant line with a hash, '#'. This configures Exim to try and deliver all outgoing mail by itself. If you want to use your ISP's mail hosts to deliver your outgoing mail, you should uncomment this line and add the name of your ISP's smart host, e.g. SMARTHOST_ROUTELIST = smtp.isp.net.
If you chose to install the Mailman mailing list manager earlier, the line defining MAILMAN_HOME is not commented out. This variable enables Mailman support.
The list of trusted users (parameter trusted_users) is limited to just the user mail by default. If, however, you decided to install the Webmail package (Squirrelmail), the user www is added to the list of trusted users. This makes it possible for Squirrelmail users to send mail under their own name rather than under the name of the user www. That is, the user www is trusted to change the sender's address for outgoing mail.
In the definition of the local_delivery transport (near the end of the configuration file) the maximum size of a mailbox is defined in the line that reads quota = 10M. This default setting allows for a maximum of 10 megabytes of stored mail per mailbox. It may be necessary to increase this number. If the mailbox is filled for 75% or more, the user will automatically receive a message from Exim with a request to clean up the mailbox. This threshold can be set via the quota_warn_threshold parameter. If you do not want to enable mail quota at all, you could set the parameter quota to 0.

If you change the configuration file, make sure you restart Exim for the changes to take effect. You can use the command 'service exim restart' to do so.

4.1.2 /etc/exim/localdomains

Exim needs to know the names of the local domain in order to decide whether to send a message to the internet or to deliver a message locally. The name of the local domain is configured in the file /etc/exim/localdomains. If the name of the local domain is not already preconfigured, you should add the name of the local domain as shown in the illustration below.



# /etc/exim/localdomains: OpenNA, Inc. (last updated 2004 May 12)
#
# localdomains - include all of your local domains name here.
# Virtual domains must be listed here to be recognized as local.
# N.B.: Exim must be restarted after this file is modified.
#
#openna.com
exemplum.serveratschool.net

If you changed the configuration file, make sure you restart Exim for the changes to take effect. You can use the command 'service exim restart' to do so.

NOTICE: If you have a more complex setup than the standard ServerAtSchool setup, you may need to specify more than one domain in this configuration file, e.g. downtown.stevensonschool.net and stevensonschool.net. This is necessary if the server 'downtown' handles both the mail for the location 'downtown' and also for the Stevensonschool as a whole. Note that the domains are specified one per line. See also the discussion of the search option near the end of section 11. Internet connection details in chapter III. Using the text mode installation program.

4.2 Firewall considerations

In order for your mail server to function correctly and as securely as possible, it is necessary for the firewall to be configured in such a way that:

outgoing mail from the server can be delivered to the Internet
mail forwarding (directly from the LAN to the Internet) is disabled
incoming mail is accepted from the Internet
incoming mail from the LAN is rejected

During the installation of the firewall (see section 4. Firewall in chapter IV.Installing optional ServerAtSchool components) a default configuration file for the firewall was installed in /etc/giptables.conf. This default configuration file is already set up correctly for the mail server. The illustration below shows these default settings.



# ****************************************************************************
#                                                                            *
#                                  S M T P                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_SMTP="yes"

# ----------------------------------------------------------------------------
# SMTP outgoing client request
#

# Interface 0 SMTP outgoing client request

    INTERFACE0_SMTP_CLIENT="yes"

    INTERFACE0_SMTP_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_SMTP_OUT_DST_IPADDR[0]=$ANY_IPADDR

# Network 1 SMTP forwarded outgoing client request

    NETWORK1_SMTP_CLIENT="no"

    NETWORK1_SMTP_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_SMTP_OUT_DST_IPADDR[0]=$ANY_IPADDR

# ----------------------------------------------------------------------------
# SMTP incoming client request
#

# Interface 0 SMTP incoming client request

    INTERFACE0_SMTP_SERVER="yes"

    INTERFACE0_SMTP_IN_SRC_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_SMTP_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

# Interface 1 SMTP incoming client request

    INTERFACE1_SMTP_SERVER="no"

    INTERFACE1_SMTP_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_SMTP_IN_DST_IPADDR[0]=$INTERFACE1_IPADDR

The effect of these settings is that no client on the LAN has direct mail access to the outside world. This means that if an e-mail virus breaks loose on a client somewhere on the LAN, the virus will not be able to mail itself to other victims because no mail from the LAN is accepted by the server.

It is possible, however, to send mail via the web-based Squirrelmail. This outgoing mail will originate on the server and is therefore not blocked.

NOTICE: If you plan to use e-mail clients on the LAN rather than just webmail, you will have to open up the firewall for incoming traffic on interface eth1. That is, the parameter INTERFACE1_SMTP_SERVER should then be set to "yes".

(top)

5. DHCPD

By default the DHCP server runs on the ServerAtSchool server. That makes it easier to configure client computers on the LAN because it is not necessary to configure individual IP addresses on the client computers. This in turn makes it easier to deal with client disk images (see section 13. Ghost for Unix below).

An in-depth explanation of the DHCP server can be found in chapter 29 of [Mourani 2002]. You may also want to consult the DHCP homepage at http://www.isc.org/sw/dhcp.

5.1 Default configuration in ServerAtSchool

The DHCP server was already configured automatically during installation. That is, the exact IP addresses of both eth0 and eth1 were used to create the correct subnet definitions. The generated configuration file should work as it is. However, you may want to check the relevant file (/etc/dhcpd.conf) just to make sure that everything is configured correctly. Below is an example of the file (with some lines removed to save space).



# /etc/dhcpd.conf - DHCP server configuration for Server At School

[...]

# Clients will be sent the DNS name associated with their allocated address.
get-lease-hostnames true;

[...]

# For completeness, we mention the first subnet on the external interface
# eth0 even if we don't use it with DHCP. We define no pools in this subnet,
# so no addresses can be allocated on this subnet.
subnet 62.59.32.56 netmask 255.255.255.248 {
    not authoritative;
    }

subnet 172.17.2.0 netmask 255.255.255.0 {
    option routers 172.17.2.1;
    option subnet-mask 255.255.255.0;
    option broadcast-address 172.17.2.255;
    option netbios-name-servers 172.17.2.1;
    option domain-name "exemplum.serveratschool.net";
    option domain-name-servers 172.17.2.1;
    option log-servers 172.17.2.1;

    # Dynamic pool
    pool {
        # Range of IP addresses the DHCP server can use to
        # assign dynamic IP addresses to the clients machine.
        range 172.17.2.141 172.17.2.240;

        # Uncomment the line below if you have H Peter Anvin's PXELINUX
        # installed and want to use it for booting client computers
        # in this pool:
#        filename "pxelinux.0";

        } # end of dynamic pool

    # Static pool (with fixed addresses and mac addresses)
    pool {
        # Uncomment the line below if you have H Peter Anvin's PXELINUX
        # installed and want to use it for booting client computers
        # in this pool:
#        filename "pxelinux.0";

        # Uncomment and replicate the lines below to define
        # hosts with fixed addresses. Don't use IP-addresses that
        # are already used in the dynamic pool above. You can
        # use the range 172.17.2.21 - 172.17.2.120 without problems.

#host firsthost { hardware ethernet 01:02:03:04:05:01; # Description of computer
#        fixed-address 172.17.2.21; }

#        ...

#host lasthost { hardware ethernet 01:02:03:04:05:FF; # Description of computer
#        fixed-address 172.17.2.120; }
        } # end of static pool

    } # end of subnet 172.17.2.0

Explanation:

The setting get-lease-hostnames true; means that the DHCP server will provide client computers with their 'official' name (as it is defined via the name server, see section 3. Bind above). This means there is no need to define host names in this file /etc/dhcpd.conf; it is all done automatically.
The LAN is defined via subnet 172.17.2.0 netmask 255.255.255.0. This definition starts with a few definitions of client options: default gateway (routers), subnet mask, broadcast, name servers, log server. These functions are all performed by the same computer ('the' server at 172.17.2.1).
The LAN is split in two different pools. The first pool is defined as the range 172.17.2.141 - 172.17.2.240. This means that 'unknown' computers on the LAN will receive an address in this range.
The second pool in the LAN covers the range 172.17.2.21 - 172.17.2.120. In this pool all clients will always receive the same IP address. This is linked to their hardware address (also known als the mac address). A few commented out examples are shown. The mapping between hardware addresses and IP addresses has to be maintained manually in this file.
If you have H. Peter Anvin's PXELINUX installed, you may want to enable the line(s) filename "pxelinux.0";. A full discussion of this package is beyond the scope of this manual.

If you made any changes to the configuration file /etc/dhcpd.conf, you should restart the DHCP server for the changes to take effect. You can use the command 'service dhcpd restart' for this purpose.

NOTICE: The choices for both the 'dynamic' and the 'fixed' pool are arbitrary. The only real restrictions are

the address of the server 172.17.2.1 should not be assigned to a client
no address should be assigned twice (so both pools should not overlap and the same 'fixed' IP address should not be used more than once)
the network address (172.17.2.0) should not be assigned to any computer
the broadcast address (172.17.2.255) should not be assigned to any computer

NOTICE: For the sake of completeness you can add 'fixed' definitions of other network devices to the 'fixed' pool. Examples of such devices would be network printers or smart network switches. If you wish, you can assign these devices a number between .2 and .20. This would make it easier to remember which is which, e.g. 172.17.2.1 - 172.17.2.9 are servers, 172.17.2.10 - 172.17.2.19 are printers and the rest are client computers. It is up to you.

5.2 Firewall considerations

In order for the DHCP server to function properly, a few ports have to be open in the firewall.

During the installation of the firewall (see section 4. Firewall in chapter IV. Installing optional ServerAtSchool components) a default configuration file for the firewall was installed in /etc/giptables.conf. This default configuration file is already set up correctly for the DHCP server. The illustration below shows these default settings.



# ****************************************************************************
#                                                                            *
#                                  D H C P                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_DHCP="yes"

# ----------------------------------------------------------------------------
# DHCP incoming client request
#

# Interface 1 DHCP incoming client request

    INTERFACE1_DHCP_SERVER="yes"

# If above option is "yes", do not forget to configure the following
# lines in the "Spoofing and bad addresses" section
# REFUSE_SPOOFING_IPADDR[2]="0.0.0.0/8"
# INTERFACE1_IN_REFUSE_SPOOFING[2]="no"

    INTERFACE1_DHCP_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_DHCP_IN_DST_IPADDR[0]=$INTERFACE1_IPADDR

(top)

6. Portsentry

Portsentry is a program designed to detect and respond to port scans. Any offending hosts that are caught in the act by portsentry will be blocked at the firewall. This way an attack from the outside can be nipped in the bud.

Any hosts blocked at the firewall by portsentry are 'released' once a week by means of a cronjob (see /etc/cron.weekly/portsentry.cron).

Portsentry is configured by means of configuration files in the directory /etc/portsentry. Of those files, one is especially important: portsentry.ignore. This file defines hosts that should never be blocked by portsentry. The installation software already has added both IP addresses of the server (62.59.32.61 and 172.17.2.1) to this file. You may want to take a peek to see if everything looks all right.

An in-depth discussion of Portsentry can be found in chapter 21 of [Mourani 2002].

NOTICE: Since /etc/cron.weekly/portsentry.cron restarts the firewall every week, any blocked hosts are unblocked. So, if you happen to have a script that blocks outsiders attempting to break in via port 22 (ssh), these outsiders are 'freed' again every week.

(top)

7. MySQL

MySQL is a multi-user, multi-threaded SQL database server. SQL (Structured Query Language) is a popular database language. MySQL offers a client/server implementation via the mysqld daemon and various client programs and libraries. The most important application on the ServerAtSchool server is acting as the backend for the website content management system (see section 9. Site@School for more information).

A thorough discussion of MySQL can be found in chapter 30 of [Mourani 2002]. You may also want to consult the MySQL homepage at http://www.mysql.com or more specifically the on-line documentation at http://dev.mysql.com/doc.

7.1 Default configuration in ServerAtSchool

The database is started automatically. The configuration of MySQL is done via the file /etc/my.cnf. You may want to take a look at the contents of this file to see if everything looks all right.

The parameter skip-networking in the section [mysqld] in the configuration file /etc/my.cnf is particulary noteworthy. Here MySQL is configured not to listen to the network; only connections originating at the server itself ('localhost') are accepted.

If you make any changes to the configuration file, you should restart the database server with the 'service mysqld restart' command.

7.2 Configuring MySQL access

After installation the database has a single 'root' account without a password. The first thing you should do is to add a password to this root account. How to set the MySQL root password is shown below. The commands you need to give are shown emphasised.

NOTICE: The password 'ea8Nuiwo' in the example below was chosen from the output of pwgen(1). You should not copy the example below verbatim but use a password of your own choice. See section 2.5 Choosing passwords for more information.



[root@praeceptor root]# mysql -u root mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.23a

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> set password for root=password('ea8Nuiwo');
Query OK, 0 rows affected (0.01 sec)

mysql> _

At this point you have the opportunity to improve the security of the database by dropping access to the 'test' database for anonymous users. The test database is created by default. There really is no need to have this kind of access other than for testing purposes. If you do not wish to experiment with this MySQL server, you can safely execute the commands shown in the illustration below. Do not forget the command 'flush privileges' for the changes to take effect. Alternatively, you can restart the database server lateron with 'service mysqld restart'. Deleting the anonymous user accounts and the test database increase security.



mysql> drop database test;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from db where user = '';
Query OK, 2 rows affected (0.00 sec)

mysql> delete from user where user = '';
Query OK, 2 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> _

Since you are already working with MySQL, now is a good time to create a new database, with appropriate permissions and a new user, especially for the website database that will be accessed via the Site@School content management system (CMS). This CMS will be configured shortly, see section 9. Site@School. Again, the commands to type are shown emphasised in the illustration below. The password 'ohF9quei' is used as an example. You should use a password of your own choice.


mysql> create database www;
Query OK, 1 row affected (0.00 sec)

mysql> grant all on www.* to sasuser@localhost identified by 'ohF9quei';
Query OK, 0 rows affected (0.02 sec)

mysql> _

At this point you have created a new database named 'www' and a user named 'sasuser' who has been given full access to this database (but only from the host 'localhost'), provided the user produces the correct password, 'ohF9quei'.

The MySQL database is now ready for use. You can close the connection to the database and end the mysql program:


mysql> exit
Bye
[root@praeceptor root]# _

7.3 Firewall considerations

The default configuration for the MySQL database is extremely simple as shown in the relevant part of /etc/giptables.conf in the illustration below.


# ****************************************************************************
#                                                                            *
#                                  M Y S Q L                                 *
#                                                                            *
# ****************************************************************************

    ACCEPT_MYSQL="no"

NOTICE: even if the firewall were opened for port 3306 (the default port for MySQL), access would be denied due to the skip-network setting in /etc/my.cnf as stated above.

(top)

8. Apache

Apache has been the most popular web server on the Internet since April of 1996. The February 2005 Netcraft Web Server Survey found that more than 68% of the web sites on the Internet were using Apache, thus making it more widely used than all other web servers combined. The Apache HTTP Server is a project of the Apache Software Foundation.

The Apache web server is an integral part of the ServerAtSchool server. It can be used to publish the school's website via the Site@School Content Management System (see section 9. Site@School for more information). It is also used to serve the web-based interface for Janitor (see section 10. Janitor for more information). Finally the web server is used to make the ServerAtSchool documentation available at http://server/doc/.

A thorough discussion of the Apache HTTP server can be found in chapter 43 of [Mourani 2002]. You may also want to consult the homepage of the project at http://httpd.apache.org or more specifically, the documentation at http://httpd.apache.org/docs-2.0.

8.1 Default Apache configuration in ServerAtSchool

During the installation of the ServerAtSchool software a preconfigured configuration file was installed in /etc/httpd/conf/httpd.conf. This configuration file yields a working web server on the LAN. However, in order to serve pages to the outside world, a few details still need attention.

The illustration below shows relevant parts of the preconfigured configuration file. Some lines were removed in order to save space. The more interesting lines and the lines that may need to be edited are shown emphasised.


# /etc/httpd/conf/httpd.conf: adapted for ServerAtSchool

# $Id: httpd.conf,v 1.2 2005/04/29 12:51:23 peter Exp $
 
### Section 1: Global Environment
#################################
#
ServerTokens OS
ServerRoot "/etc/httpd"
PidFile /var/run/httpd.pid

Timeout 60
KeepAlive Off
MaxKeepAliveRequests 0
KeepAliveTimeout 10

# Prefork MPM
#
<IfModule prefork.c>
StartServers        5
MaxClients          512
MinSpareServers     5
MaxSpareServers     10
MaxRequestsPerChild 0
</IfModule>

# Uncomment these lines to listen to the external interface
#
#Listen 62.59.32.61:80
#Listen 62.59.32.61:443

# Always listen on the internal interface
#
Listen 172.17.2.1:80
Listen 172.17.2.1:443

# Dynamic Shared Object (DSO) Support
#
LoadModule access_module        modules/mod_access.so
[...]
LoadModule php4_module          modules/libphp4.so
#LoadModule security_module     modules/mod_security.so
#LoadModule dosevasive20_module modules/mod_dosevasive20.so


### Section 2: Main Server Configuration
########################################
#
User www
Group www

ServerAdmin peter@berestijn.nl
ServerName praeceptor.exemplum.serveratschool.net
UseCanonicalName Off

DocumentRoot "/home/httpd/htdocs"
<Directory />
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

[...]

<IfModule mod_dir.c>
    DirectoryIndex index.php index.htm index.html default.php index.cgi index.shtml index.php3
</IfModule>

AccessFileName .htaccess

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

<IfModule mod_mime.c>
    TypesConfig /etc/httpd/conf/mime.types
    AddEncoding x-compress Z
    AddEncoding x-gzip gz tgz
    AddHandler cgi-script .cgi
    AddType application/x-tar .tgz
    AddType image/x-icon .ico
    AddType application/x-httpd-php .php .php4 .php3 .phtml
    AddType application/x-httpd-php-source .phps
</IfModule>

DefaultType text/plain

<IfModule mod_mime_magic.c>
    MIMEMagicFile /etc/httpd/conf/magic
</IfModule>

HostnameLookups Off

LogLevel info
ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog /var/log/httpd/access_log combined

ServerSignature Off

<IfModule mod_alias.c>

[...]

Alias /webmail/ "/home/httpd/squirrelmail/"
<Directory "/home/httpd/squirrelmail">
   AllowOverride None
   Options None
   Order allow,deny
   Allow from all
</Directory>

[...]

# Make ServerAtSchool documentation available
Alias /doc/ "/usr/share/doc/serveratschool/en/"
<Directory "/usr/share/doc/serveratschool/en">
   AllowOverride None
   Options None
   Order allow,deny
   Allow from all

</Directory>
# Make ServerAtSchool admin tool available
Alias /janitor/ "/home/httpd/janitor/"
<Directory "/home/httpd/janitor">
   AllowOverride None
   Options None
   Order allow,deny
   Allow from all
</Directory>
</IfModule>

[...]

### Section 3: Virtual Hosts
############################
#
NameVirtualHost *:80

<VirtualHost *:80>
ServerAdmin peter@berestijn.nl
ServerName praeceptor.exemplum.serveratschool.net
#ServerAlias server server.exemplum.serveratschool.net
DocumentRoot "/home/httpd/htdocs"

<Directory "/home/httpd/htdocs">
 <IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    SetEnvIfNoCase Request_URI \
        \.(?:gif|jpe?g|png)$ no-gzip dont-vary
 </IfModule>
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

[...]

ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/httpd/access_log
</VirtualHost>


## SSL Global Context
#
<IfModule mod_ssl.c>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

SSLPassPhraseDialog     builtin
SSLSessionCache         none
SSLSessionCacheTimeout  300
SSLMutex                sem
SSLRandomSeed startup   file:/dev/urandom 1024
SSLRandomSeed connect   file:/dev/urandom 1024

## SSL Virtual Host Context
#
NameVirtualHost *:443

<VirtualHost *:443>
ServerAdmin peter@berestijn.nl
ServerName praeceptor.exemplum.serveratschool.net
DocumentRoot "/home/httpd/htdocs"

<Directory "/home/httpd/htdocs">
 <IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    SetEnvIfNoCase Request_URI \
        \.(?:gif|jpe?g|png)$ no-gzip dont-vary
 </IfModule>
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/httpd/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile      /usr/share/ssl/certs/www.crt
SSLCertificateKeyFile   /usr/share/ssl/private/www.key
SSLVerifyClient none
SSLVerifyDepth  10

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

CustomLog /var/log/httpd/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>
</IfModule>

Explanation:

In Section 1: Global Environment, there are two Listen directives which make the server listen (or not listen) to the external interface. If you want to serve your website to the outside world (via eth0, IP address 62.59.32.61), you should uncomment the two relevant lines.
In Section 2: Main Server Configuration, the preconfigured configuration file already has the e-mail address of the administrator defined (the ServerAdmin directive).
In Section 2: Main Server Configuration, the preconfigured configuration file already has the canonical name of the server defined (the ServerName directive).
In Section 2: Main Server Configuration, the preconfigured configuration file has a specific order in which index files are served (the DirectoryIndex directive). The order is: first index.php, then index.htm, and last, index.html. The effect is that the server will first serve the file /home/httpd/htdocs/index.php (which is the main file of the Site@School Content Management System) rather than /home/httpd/htdocs/index.html which is the default Apache placeholder.
In Section 2: Main Server Configuration, the preconfigured configuration file defines the alias /webmail/ as the entry for access to Squirrelmail. You can change this alias to something else if you wish, without moving the actual Squirrelmail directory. This alias is what users need to type in their browser. If you change it to /schoolmail/, Squirrelmail can be accessed via http://praeceptor.exemplum.serveratschool.net/schoolmail/. The choice is yours.
In Section 2: Main Server Configuration, the preconfigured configuration file defines the aliases /doc/ and /janitor/. You can change these aliases to something else if you wish, e.g. /documentazione/ or /maintainer/, without moving the actual underlying directories.
In Section 3: Virtual Hosts, the preconfigured configuration file defines the name of a single virtual host. This is the same name that was used earlier (the ServerName directive) in section 2). This virtual server can have one or more alternative names via the ServerAlias directive. In the preconfigured file these names (server and server.exemplum.serveratschool.net) are defined but commented out. If you wish to let the server respond to yet another alias e.g. www or www.exemplum.serveratschool.net, or mail or mail.exemplum.serveratschool.nl (see section 18.2 Customising Mailman below) you can define it here. Do not forget to remove the '#' before the directive ServerAlias and to add the required aliases if you want to use this ServerAlias feature.
In Section 3: Virtual Hosts, under SSL Virtual Host Context, a secure version of your website has already been partly configured, including the ServerName and ServerAdmin directives. See section 8.2 Hints for a secure web server below for a little more information.

If you really want to serve your website via the name www.exemplum.serveratschool.net, you need to make sure that that name resolves to the correct IP address. See also section 3.2 Scenario 1 - in-house web server and section 3.5 DNS-records and your ISP above.

If you make changes to the configuration file, you need to restart the web server for the changes to take effect. You can use the command 'service httpd restart' for this purpose.

8.2 Hints for a secure web server

The standard web server does not provide encrypted connections. This means that all interactions with the web server take place in plain text. For most purposes this is good enough.

An exact recipe for setting up an SSL-enabled web server is beyond the scope of this guide. An in-depth explanation and examples are given in chapter 15 OpenSSL and chapter 43 Apache (pp. 1051, Running Apache with TLS/SSL support) of [Mourani 2002]. You may also want to refer to [Holbrook] (starting at page 36) for a discussion with an example of this kind of setup.

Below is a short checklist to give you an idea what needs to be done for setting up a secure web server. The basic strategy is as follows:

Determine the Fully Qualified Domain Name of the SSL-enabled web server
Find a few large files that can act as random seeds
Create a private RSA key
Generate a Certificate Signing Request
Send the Certificate Signing Request to an official Certifying Authority
When you receive the signed certificate from the Certifying Authority, install the certificate on your server
The Apache web server has to have SSL enabled (by uncommenting a line in /etc/sysconfig/httpd)
The Apache web server has to know about the location of certificates via the directives SSLCertificateFile and SSLCertificateKeyFile
The mod_ssl module must be uncommented in /etc/httpd/conf/httpd.conf
The firewall must be opened for port 443 (the default well-known port for the secure https protocol)
The web server must be restarted.

You can also act as your own Certifying Authority and sign your own certificates ('self-signing'). This is much cheaper than obtaining an official certificate. The drawback is that any user who wishes to connect to your secure site has to install or at least accept your certificate, without knowing for certain that the certificate is really the correct one and really belongs to you.

8.3 Firewall considerations

Before the web server can be accessed, either from the LAN or from the Internet at large, the firewall has to be configured to accept the web server traffic. By default the file /etc/giptables.conf as it is installed with ServerAtSchool allows the following:

outgoing traffic from the server to any website on the Internet (this is used to update the ClamAV virus definition files, see section 19. ClamAV below)
outgoing traffic from any network client to any website in the Internet
incoming traffic from the Internet at large (via interface eth0)
incoming traffic from the LAN (via interface eth1).

The settings are illustrated below.


# ****************************************************************************
#                                                                            *
#                                  H T T P                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_HTTP="yes"

# ----------------------------------------------------------------------------
# HTTP outgoing client request
#

# Interface 0 HTTP outgoing client request

    INTERFACE0_HTTP_CLIENT="yes"

    INTERFACE0_HTTP_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_HTTP_OUT_DST_IPADDR[0]=$ANY_IPADDR


# Network 1 HTTP forwarded outgoing client request

    NETWORK1_HTTP_CLIENT="yes"

    NETWORK1_HTTP_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_HTTP_OUT_DST_IPADDR[0]=$ANY_IPADDR

# ----------------------------------------------------------------------------
# HTTP incoming client request
#

# Interface 0 HTTP incoming client request

    INTERFACE0_HTTP_SERVER="yes"

    INTERFACE0_HTTP_IN_SRC_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_HTTP_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

# Interface 1 HTTP incoming client request

    INTERFACE1_HTTP_SERVER="yes"

    INTERFACE1_HTTP_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_HTTP_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

    INTERFACE1_HTTP_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_HTTP_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR

NOTICE: If you want to serve your website to the Internet at large you should uncomment the appropriate Listen directive in the httpd.conf file and you should set the variable INTERFACE0_HTTP_SERVER to "yes". If either one is misconfigured, you will not be able to retrieve pages from the web server. This is a security consideration.

If you want to set up a secure web server (using TLS/SSL and the https protocol), you need to change the section in the firewall that deals with https. By default the firewall is closed for this protocol, as is illustrated below.


# ****************************************************************************
#                                                                            *
#                                  H T T P S                                 *
#                                                                            *
# ****************************************************************************

    ACCEPT_HTTPS="no"

If you wish to enable https, you should at least set ACCEPT_HTTPS to "yes". You should also take time to check the other relevant settings in this section of the firewall.

(top)

9. Site@School

Site@School is a website Content Management System (CMS) designed especially for (primary) schools. It is written in PHP and requires a working web server (Apache) and a working MySQL database.

The Site@School CMS is well-documented. If you chose to install the documentation earlier (see section 8. Documentation in chapter III. Using the text mode installation program), you can find the manual on your own server at http://server/starnet/manual/ or http://praeceptor.exemplum.serveratschool.net/starnet/manual/.

The Site@School project's homepage can be found at http://siteatschool.sourceforge.net. There is also a support forum with an active community. The forum can be accessed via http://siteatschool.sourceforge.net/index.php?section=5&page=59.

Site@School must be configured with the name and login info of an existing MySQL database. This can be done via the Site@School install script which can be found at http://server/starnet/install/install.php or http://praeceptor.exemplum.serveratschool.net/starnet/install/install.php. If the external name servers are properly configured and you have the name www mapped to your server, you can access the install script at http://www.exemplum.serveratschool.net/starnet/install/install.php. See section 3.2 Scenario 1 - in-house web server above for more information.

Configuration of the CMS requires a working database server (see section 7. MySQL above) and a working web server (see section 8. Apache above). Configuration is done by running the install script via a browser. This means that you also need a client computer with a browser connected to your server. Note that you can also access the install script from 'outside'. That is, if you have the external network connection up and running (via eth0), you can use any computer connected to the Internet to surf to the install script.

9.1 Starting the install.php script

Point the browser to the install script and follow the directions on the screen. You will see the following.

[ opening screen of Site@School install script ]

configuring_siteatschool_opening.png

Press the [Continue] button.

9.2 Setting web server properties

At this point you see the screen where you can enter the web server properties. You will see something like this:

[ setting web server properties in the Site@School install script ]

configuring_siteatschool_webserver.png

Explanation:

Website title: Exemplum Primary School This is the name of your website. By default it will appear on all your pages.
Serverpath:
- /home/httpd/htdocs/
  This is the path to the document root. There is no need to change this default value on the ServerAtSchool server.
- starnet
  This is the subdirectory (relative to the document root /home/httpd/htdocs/) where the CMS itself is located. There is no need to change this default value on the ServerAtSchool server.
URL of the site: http://www.exemplum.serveratschool.net
Securitycode: enter a number of random characters here. These characters are used as a 'salt' when setting up sessions. This field must not be left empty.

Press the [Continue] button to confirm the dialogue.

NOTICE: The Serverpath, i.e. the combination of the document root and the starnet directory must yield a valid path. Please make sure that the document root keeps its trailing slash '/'.

NOTICE: Assuming the name servers are properly configured, you can use different names for your server. We chose the name 'www.exemplum.serveratschool.net' in this screen. However, you might have entered the name 'exemplum.serveratschool.net' here (some people prefer to leave out the 'www' part of a website's address because they consider it a cleaner designation).

9.3 Setting database server properties

At this point you will see the screen where you can enter the MySQL database server properties. You will see something like this:

[ setting database server properties in the Site@School install script ]

configuring_siteatschool_database.png

Explanation:

MySQL server address: localhost There is no need to change this default value on the ServerAtSchool server.
MySQL username: sasuser You should enter the username that was defined for the website database near the end of section 7.2 Configuring MySQL access above.
MySQL password: ohF9quei You should enter the password that was defined for the website database near the end of section 7.2 Configuring MySQL access above.
MySQL Database name: www You should enter the name that was defined for the website database near the end of section 7.2 Configuring MySQL access above.
Tablename prefix: sn_ There is no need to change this default value on the ServerAtSchool server.

Press the [Continue] button to confirm the dialogue.

9.4 Filling the site with demo data

At this point you will see a screen that lets you choose whether to fill the website with demonstration data or not. It looks something like this:

[ optionally filling the website with demo data in the Site@School install script ]

configuring_siteatschool_demodata.png

Choose Yes or No by checking the appropriate option. Press the [Continue] button to confirm your choice.

NOTICE: If you choose to install the demonstration data, you will get a working web site with a few sections and pages that show off the many features of Site@School. You can always delete these pages if you wish. However, if you already know about the Site@School features and you already have a good idea on structure and content of your website to be, you may be better off with an empty website to start with.

9.5 Creating the administrator user account

At this point you will see a screen that lets you enter the details of the user account to be used by the website administrator. You will see something like this:

[ creating the administrator user account Site@School install script ]

configuring_siteatschool_user.png

Explanation:

Full name: Freddie Frinton This is the real name of the person responsible for website administration.
Username: webmaster This is the name of the user account that will be used by the administrator. This should preferably be a single word not longer than 8 characters, without any spaces or punctuation characters (letters and digits are fine).
Password: Re6oifax This is the password that the administrator will use to authenticate.
E-mail address: webmaster@exemplum.serveratschool.net This is the e-mail address associated with this user account. It is used in the event the user forgets the password.

The password 'Re6oifax' is used as an example. You should use a password of your own choice. See section 2.5 Choosing passwords for more information.

In this example the e-mail address 'webmaster@exemplum.serveratschool.net' is used. This implies that mail for 'webmaster' will be processed on the server itself. By default this address is an alias for 'root' which in turn is an alias for 'postmaster'. By default all mail for 'postmaster' is redirected to the e-mail address you specified during installation, see section 14. E-mail address configuration in chapter III. Using the text mode installation program. This aliasing of e-mail addresses takes place in the file /etc/exim/aliases. See also section 10.4.1 The webmaster alias for more information about linking the webmaster alias to the account of Freddie Frinton.

NOTICE: Freddie Frinton is a member of the Exemplum Primary School community. See section 5. The Exemplum Primary School in Appendix C. How the ServerAtSchool documentation was written for more information about this example school.

Press the [Continue] button to confirm the new settings.

9.6 Finishing the Site@School configuration

At this point you will see a screen to confirm the user account you have created, and to indicate that the configuration is now ready. If you decided not to install the demonstration data in section 9.4 Filling the site with demo data above, you will now see something like this:

[ Site@School install script completed (without demo data) ]

configuring_siteatschool_finish1.png

If, however, you did install the demonstration data, the screen will look slightly different:

[ Site@School install script completed (with demo data) ]

configuring_siteatschool_finish2.png

Please make a note of the username and the password if you did not do so already; you will need them to log in whenever you want to manage the website.

NOTICE: If you did not install the demo data, you should at least add 1 section and 1 page in that section to the website, otherwise your website visitors will see an error message like this: No page was set as startpage for this section of the site.

NOTICE: If you want to add content to the website, you can press the [Login] button. However, please do not forget that a little cleaning up needs to be done on the server at this point. See section 9.7 Cleaning up on the server below.

If you did install the demonstration data, your website will look like this:

[ default Site@School site with demo data ]

configuring_siteatschool_first.png

You can log in via http://www.exemplum.serveratschool.net/starnet/index.php to maintain your website.

9.7 Cleaning up on the server

Once the Site@School script is done, you will need to clean up a little on the server. First you will need to change the permissions of the file /home/httpd/htdocs/starnet/configuration/database.inc.php. When the Site@School installation script finishes, this file is left with its permissions set to 0777. This means that anyone with access to the server will be able to read the database password stored in this file and will also be able to write to this file. You definitely do not want that. As a matter of fact, no write access is necessary at all once this file has been created by the installation script. Therefore, you should change the permissions of this file to 0400. The file already belongs to user www and group www so no changes are necessary in that respect.

Secondly, the contents of the directory /home/httpd/htdocs/starnet/install/ will no longer be needed. You can remove the entire directory.

Use the following commands (emphasised in the illustration below) to do the cleanup.


[root@praeceptor root]# cd /home/httpd/htdocs/starnet/configuration/
[root@praeceptor configuration]# chmod 0400 database.inc.php
[root@praeceptor configuration]# cd ..
[root@praeceptor starnet]# rm -r install/
[root@praeceptor starnet]# cd
[root@praeceptor root]# _

Your website and Site@School are now ready for use. Refer to the Site@School manual (if you installed that) for more information.

(top)

10. Janitor

Janitor is the tool that is used to manage user accounts and groups. It can also be used for some miscellaneous administration tasks such as creating CD images. Janitor consists of a set of shell scripts (janitor(1) and janitorcmd(1)) for use at the command line and a web interface (http://server/janitor/index.php). It was designed especially for ServerAtSchool.

Before Janitor can be used, the directory tree containing the users' home directories and the shared groups must be created and configured. Also the hourly backup of user data must be initialised. When this one-time initialisation is completed, at least a single user account has to be created. This is a three-step procedure.

Edit the Janitor configuration file /etc/janitor/janitor.conf
Execute the one-time initialisation via janitor init
Add the first user account using janitor(1) at the command line. This would be the account of a local systems administrator or a 'janitor' as it is called in ServerAtSchool.

NOTICE: Unless you know exactly what you are doing, the Janitor initialisation is a process that can only be executed once. Please check and double-check the configuration file before you issue the init command.

10.1 The main Janitor configuration file

Janitor configuration is done via configuration files in /etc/janitor/, notably the file janitor.conf. The default configuration file is shown below. Lines of interest are shown emphasised and are explained below.


#   /etc/janitor/janitor.conf -- general configuration file for Janitor
#
#   $Id: janitor.conf,v 1.22 2006/03/22 10:23:18 peter Exp $
#
#   Copyright (C) 2004-2005 Peter Fokker, <peter@berestijn.nl>
#
#   This file is part of Janitor.
#
#   Janitor is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.
#
#   Janitor is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#

# 2005-02-14/PF - added configuration for (fixed) group 94 (programs)
# 2005-02-14/PF - reshuffled the hourly backup stuff; we now keep 1
#                 backup dir instead of 8 (!); too space consuming...
# 2005-04-15/PF - change setting for location of webinterface JANITOR_CONF_PHP
#                 to the new location (outside the document tree)

# This file is sourced in /usr/sbin/janitor/janitorcmd

# ################################################## #
# IMPORTANT NOTE: ALL VARIABLES SHOULD BE FLUSH LEFT #
# ################################################## #

# JANITOR_MSG
# This is where Janitor keeps language elements.
# Feel free to point JANITOR_MSG to your translations
#
# Default: "/etc/janitor/janitor.msg"
#
JANITOR_MSG="/etc/janitor/janitor.msg"


# JANITOR_INIT
# This parameter flags that the one-time init has been done
# The file should NOT exist when we do initialise.
#
# Default: "/etc/janitor/janitor_init.txt"
#
JANITOR_INIT="/etc/janitor/janitor_init.txt"


# PROGRAMS_GID
# This defines the gid of the existing group which owns all Samba programs.
# This group also owns the Desktop and the Start Menu of every user.
# This way we can manipulate the user's links to program files.
# Note that this group MUST exist, or else... (Samba won't work OK)
#
# Default: "94"
#
PROGRAMS_GID="94"


# PROGRAMS
# This defines the name of the group corresponding with PROGRAMS_GID
#
# Default: "programs" (for a standard setup)
#
########################################################################
# This parameter is also used to name a directory in the userdata tree #
# DON'T CHANGE THIS SETTING AFTER Janitor HAS BEEN INIT'ed             #
# Consider yourself warned!                                            #
########################################################################
#
PROGRAMS="`/bin/grep ":.*:$PROGRAMS_GID:" </etc/group | /bin/cut -f1 -d:`"


# INSTALL_GID
# This defines the user group for dealing with disk images with g4u (Ghost for Unix)
#
# Default: "95"
#
INSTALL_GID="95"


# BUDDIES_GID
# This defines the gid of the (possibly) existing group of buddies.
#
# Default: "96"
#
BUDDIES_GID="96"


# TELEWORKERS_GID
# This defines the gid of the (possibly) existing group of teleworkers.
#
# Default: "97"
#
TELEWORKERS_GID="97"


# JANITORS_GID
# This defines the gid of the (existing) group of janitors
#
# Default: "98"
#
JANITORS_GID="98"


# JANITORS
# This defines the name of the corresponding group for JANITORS_GID
#
# Default: "janitors" (for a standard setup)
#
#
########################################################################
# This parameter is also used to name a directory in the userdata tree #
# DON'T CHANGE THIS SETTING AFTER Janitor HAS BEEN INIT'ed             #
# Consider yourself warned!                                            #
########################################################################
#
JANITORS="`/bin/grep ":.*:$JANITORS_GID:" </etc/group | /bin/cut -f1 -d:`"


# UID_XXX
# Janitor manages users between UID_MIN and UID_MAX + exceptions in UID_EXP
#
# Defaults: UID_MIN="501", UID_MAX="45499", UID_EXP=""
#
UID_MIN="501"
UID_MAX="45499"
UID_EXP=""


# GID_XXX
# Janitor manages groups between GID_MIN and GID_MAX + exceptions in GID_EXP
#
# Defaults: GID_MIN="100" GID_MAX="45499" GID_EXP="94 95 96 97 98"
#
GID_MIN="100"
GID_MAX="45499"
GID_EXP="$PROGRAMS_GID $INSTALL_GID $BUDDIES_GID $TELEWORKERS_GID $JANITORS_GID"


# GID_UPG
# Janitor attempts to keep shared groups below GID_UPG and User Private Groups
# above that limit. Janitor also keeps the gid and uid identical
# for users with UPG's (this is part of the definition of a UPG for Janitor)
#
# Default: "499"
#
GID_UPG="499"


# EXIM_XXX
# This defines the location of the email aliases file and the command
# to rewrite the aliases database file,
#
# Defaults: "/etc/exim/aliases" and "/usr/sbin/newaliases"
#
EXIM_ALIASES="/etc/exim/aliases"
EXIM_NEWALIASES="/usr/sbin/newaliases"


# HTTPD_XXX
# This defines user and group under which the web server runs
#
# Defaults: "www" and "www"
#
HTTPD_USERID="www"
HTTPD_GROUP="www"


# SQM_PREFS_XXX
# This defines the location where SquirrelMail keeps
# user preferences and the name of this file. The exact
# file is $SQM_PREFS_DIR/<userid>$SQM_PREFS_EXT
#
# Note:
# These 'tricks' with SQM only work when SQM is configured
# to use file_prefs rather than db_prefs. See SQM config.php or conf.pl.
# The allowed_remote_addr only works when SQM is patched to check
# the remote address. Janitor only prepares the low-level settings.
#
# Defaults: SQM_PREFS_DIR="/usr/lib/squirrelmail/prefs" SQM_PREFS_EXT=".pref" SQM_PREFS_DEFAULT="default_pref"
#
SQM_PREFS_DIR="/usr/lib/squirrelmail/prefs"
SQM_PREFS_EXT=".pref"
SQM_PREFS_DEFAULT="default_pref"


# SQM_XXX
# This defines a few essential fields within the preferences file.
#
# Defaults: SQM_ALLOWED_REMOTE_ADDR="allowed_remote_addr" SQM_FULL_NAME="full_name" SQM_EMAIL_ADDRESS="email_address"
#
SQM_ALLOWED_REMOTE_ADDR="allowed_remote_addr"
SQM_FULL_NAME="full_name"
SQM_EMAIL_ADDRESS="email_address"


# FULL_DOMAIN
# This is used to construct a user's full email address
# By default we use the domain part of our own hostname from sysconfig
# You may want to provide a static fully qualified domain name here.
#
# Default: constructed from hostname
#
FULL_DOMAIN="$(. /etc/sysconfig/network; echo "$HOSTNAME" | /bin/cut -f2 -d= | /bin/cut -f2- -d.)"


# INTERNAL_ADDR 
# This defines the internal network address, e.g. 172.17.2.0/24
# We read it from sysconfig (or pick a suitable default)
#
# Note:
# Because of the way janitor.conf.php is generated from Janitor, the
# commands within the subshell below should NOT be flushleft because
# otherwise the variables in this subshell are exported to janitor.conf.php.
# Furthermore, you shouldn't really change all this... ;-)
#
# Default: "172.17.2.0/24" (for a standard setup)
#
INTERNAL_ADDR="$(IFCFG_ETH1="/etc/sysconfig/network-scripts/ifcfg-eth1"
         if [ -r "$IFCFG_ETH1" ]; then
           . "$IFCFG_ETH1"
         fi
         if [ -z "$NETWORK" ]; then
           NETWORK="172.17.2.0"
           NETMASK="255.255.255.0"
         fi
         PREFIX="`/bin/ipcalc -p "$NETWORK" "$NETMASK" | /bin/cut -f2 -d=`"
         echo "$NETWORK/$PREFIX")"


# JANITOR_LANG
# This is a helper-parameter which makes it easier to configure this
# application for other languages. The contents of JANITOR_LANG is
# eventually written into the file JANITOR_CONF_PHP. This might yield
# another language in the web interface.
#
# Default: "EN"
#
JANITOR_LANG="EN";


# JANITOR_CONF_PHP
# This defines the place to store janitor.conf in a form suitable
# for the PHP web interface. This file is (re)generated from this
# janitor.conf file, in order to keep both parts of the Janitor
# application in sync.
#
# Default:"/home/httpd/janitor/config/janitor.conf.php"
#
JANITOR_CONF_PHP="/home/httpd/janitor/config/janitor.conf.php"


# PHP_ALLOWED_REMOTE_ADDR
# Not everyone is allowed to access Janitor from a browser.
# By default access is limited to the localhost and the internal
# network (connected to eth1, see above). You can add additional
# allowed IP-addresses to this comma-delimited list or use
# 0.0.0.0/0 for unrestricted access.
#
# Default: "127.0.0.0/8,172.17.2.0/24" (for a standard setup)
#
PHP_ALLOWED_REMOTE_ADDR="127.0.0.0/8,$INTERNAL_ADDR"


# BU_XXX
# The program bu(1) is used to create hourly backups during hours.
# These parameters define when BU works. By default a daily backup is
# done (every day, even in the weekends) when the hourly cronjob is
# run and the hour equals BU_DAILY (default value: 4).
#
# The definition of the 'day' is skewed via BU_OFFSET. When
# the daily backup is done before BU_OFFSET o'clock in the morning,
# the backup is considered to be yesterday's. The regular hourly
# backups are done between the hours BU_HOURLY_BEGIN and BU_HOURLY_END.
# Please note that hourly backups via BU are never done in weekends,
# only mondays to fridays. Due to the skew, the backup for Friday
# is done on Saturday at 4.00 a.m.
#
# Defaults: BU_DAILY=4 BU_OFFSET=6 BU_HOURLY_BEGIN=7 BU_HOURLY_END=18
#
BU_DAILY=4
BU_OFFSET=6
BU_HOURLY_BEGIN=7
BU_HOURLY_END=18


# JANITORCD_XXX
# Below are the configuration parameters necessary for creating
# CD-ROM images. These settings are used in /usr/sbin/janitor/janitorcd.
# This is a separate script that runs in the background in order to
# create ISO-images of CD-ROMS via the server's CD-ROM drive.
# Running in the background allows for long running tasks without the
# user having to wait for the job to complete.


# JANITORCD_DIR
# Janitorcd stores ISO CD-ROM images in this directory
#
# Default: /home/share/iso
#
JANITORCD_DIR="/home/share/iso"


# JANITORCD_EXT
# Janitorcd appends this extension to the base name of the CD-ROM image
#
# Default: .iso
#
JANITORCD_EXT=".iso"


# JANITORCD_RUN
# This is the directory via which janitorcmd and janitorcd communicate.
# The files JANITORCD_PID, JANITORCD_LOG and JANITORCD_LNK are created 
# in this directory.
#
# Default: /var/run/janitor
#
JANITORCD_RUN="/var/run/janitor"


# JANITORCD_PID
# This file is used as a sentinel which indicates that a janitorcd command
# is running. In a crude way this prevents two processes to access the
# CD-rom drive at the same time. The file is created in JANITORCD_RUN.
#
# Default: janitorcd.pid
#
JANITORCD_PID="janitorcd.pid"


# JANITORCD_LOG
# This file is used by janitorcd to store the (textual) results of the
# operation, error messages, etc. The file is created in JANITORCD_RUN.
# 
# Default: janitorcd.log
#
JANITORCD_LOG="janitorcd.log"


# JANITORCD_LNK
# This file is used by janitorcd to keep track of the image that is
# currently being created. The file is created in JANITORCD_RUN.
# It is nothing but a symbolic link to the CD-image file.
# 
# Default: janitorcd.lnk
#
JANITORCD_LNK="janitorcd.lnk"


# JANITORCD_DEV
# The name of the device that holds the CD-ROM of which an image is to
# be made.
#
# Default: /dev/cdrom
#
JANITORCD_DEV="/dev/cdrom"


######################################################################
# The parameters below define the directory structure for userdata   #
# DON'T CHANGE THESE SETTINGS AFTER Janitor HAS BEEN INIT'ed         #
# OR ELSE YOU'LL END UP IN DANGLING SYMLINK HELL.                    #
# Consider yourself warned!                                          #
# See also the definitions of PROGRAMS and JANITORS above            #
######################################################################


# CHROOT_USERDATA_XXX
# SUB_XXX
# These parameters define the standard directory structure.
# The various parameters are used to create a chroot()'ed environment
# for ordinary users. Users with a dot in their $HOME (as found in
# /etc/passwd) always land in a chrooted environment. Ordinary users
# have a $HOME like this: /home/userdata/./home/users/<userid> This
# only works with a patched kernel (such as those provided by OpenNA).
#
# Default directory structure:
#
# /home/userdata/                 = CHROOT_USERDATA
# /home/userdata/home/            = CHROOT_USERDATA/SUB_HOME
# /home/userdata/home/users/      = CHROOT_USERDATA/SUB_HOME/SUB_USERS
# /home/userdata/home/groups/     = CHROOT_USERDATA/SUB_HOME/SUB_GROUPS
# /home/userdata/home/skeletons/  = CHROOT_USERDATA/SUB_HOME/SUB_SKELETONS
#
# User's home directories go in /home/userdata/home/users/<userid>
# Shared directories go in /home/userdata/home/groups/<group>
# Skeletons go in /home/userdata/home/skeletons/<skeleton> (like /etc/skel)
#
# CHROOT_USERDATA_FILES points to a list of files required
# in the chroot()'ed environment. Default value for
# CHROOT_USERDATA_FILES is "/etc/janitor/userdata_files.conf".
#
CHROOT_USERDATA="/home/userdata"
CHROOT_USERDATA_FILES="/etc/janitor/userdata_files.conf"
SUB_HOME="home"
SUB_SKELETONS="skeletons"
SUB_USERS="users"
SUB_GROUPS="groups"
SUB_SKEL="skel"
SUB_BACKHOME="backhome"


# SMB_XXX
# These parameters define the Windows environment for the
# user. This environment is constructed within the user's $HOME
# Default (with $HOME == /home/userdata/./home/users/<userid>):
#
# $HOME/H/                     = SMB_HOME
# $HOME/H/.profile/            = SMB_HOME/SMB_PROFILE
# $HOME/H/.profile/Desktop/    = SMB_HOME/SMB_PROFILE/SMB_DESKTOP
# $HOME/H/.profile/Start Menu/ = SMB_HOME/SMB_PROFILE/SMB_STARTMENU
# $HOME/H/My Documents/        = SMB_HOME/SMB_MYDOCUMENTS
# $HOME/H/My Backups/          = SMB_HOME/SMB_BACKUP
#
# User's Windows Home is $HOME/H (a.k.a. H:\ from a client)
# User's roving profile (Windows 9x) is in $HOME/H/.profile,
# with icons on the Desktop and in the Start Menu stored in
# $HOME/H/.profile/Desktop and $HOME/H/.profile/Start Menu
# User's documents go in $HOME/H/My Documents (which is
# also the path the "My Documents" icon on the Desktop points
# to, i.e. H:\My Documents as seen from the client.
# The directory H:\My Backups contains a read-only backup of
# the user's data (backed up every hour during hours;
# see bu(1)). The parameter SMB_NESTS is used to group the
# Desktops and Start Menus of groups of pupils (called 'nests')
# in /home/userdata/home/groups/janitors/Desktop/SMB_NESTS/<group>
# and /home/userdata/home/groups/janitors/Start Menu/SMB_NESTS/<group>
# in order to make the desktops of many users (pupils) more managable.
#
SMB_HOME="H"
SMB_PROFILE=".profile"
SMB_STARTMENU="Start Menu"
SMB_DESKTOP="Desktop"
SMB_MYDOCUMENTS="My Documents"
SMB_BACKUP="My Backups"
SMB_NESTS="nests"


# SUB_SHORTCUTS
# This defines the directory in the shared group directory
# /home/userdata/home/groups/janitors/
# containing the various shortcuts ('program links') that can be
# placed on the users' Desktops and/or Start Menus
#
SUB_SHORTCUTS="shortcuts"


# SUB_BACKHOME
# This parameter defines where backups of the
# userdata/home-tree are stored in userdata/backhome-tree.
# The backup-tool (bu(1)) copies /home/userdata/home/ to 
# /home/userdata/backhome/
# and the user has symlinks in her $HOME like this:
# /home/userdata/home/users/<userid>/H/My Backups
# -> ../../../../../backhome/users/<userid>/H/
# Default: "backhome"
#
SUB_BACKHOME="backhome"


# CHROOT_BUDDIES_XXX
# This defines the chroot()'ed environment for buddies,
# i.e. outsiders who are allowed to store their
# nightly backups on our server.
# CHROOT_BUDDIES_FILES points to a list of files required
# in the chroot()'ed environment for these buddies. This
# environment might be even tighter than the CHROOT_USERDATA,
# hence a different list of required files.
#
# Default directory structure:
# /home/buddies/                 = CHROOT_BUDDIES
# /home/buddies/home/            = CHROOT_BUDDIES/BUD_HOME
# /home/buddies/home/<buddyname> = CHROOT_BUDDIES/BUD_HOME/<buddyname>
#
# Note: the idea is to have a separate partition mounted
# on /home/buddies/home. This partition only has to store
# the data of the buddies, so no exec needs to be allowed.
# This is a security measure. 
#
CHROOT_BUDDIES="/home/buddies"
CHROOT_BUDDIES_FILES="/etc/janitor/buddies_files.conf"
BUD_HOME="home"


# eof /etc/janitor/janitor.conf

Explanation:

JANITOR_MSG
This parameter contains the absolute path to the file that holds all the messages used in janitor(1). By concentrating all language elements in a single file it is relatively easy to translate the messages into another language. You could create your own messages file and point Janitor to it using this parameter.
PROGRAMS
This parameter defines the name of the predefined group that will be the owner of all the files that are shared with the LAN via Samba. In addition, the directories Desktop and Start Menu under the users' home directories will be owned by this group. The definition of this parameter is dynamic, i.e. it is recalculated from the system database in /etc/group every time a janitor command is issued. If the name of the group (default: programs) will never be changed, this parameter may be changed into a static definition like this: PROGRAMS="programs" This saves a little processing power. Note that the name must correspond with the name of the predefined group. If you are uncertain what to do, just leave this parameter as it is.
JANITORS
This parameter defines the name of the predefined group that is used as the name of a shared directory. As with the PROGRAMS-parameter above, this parameter is defined dynamically. You may want to change the definition of this parameter to "janitors" for performance reasons via JANITORS="janitors". If you are uncertain what to do, just leave this parameter as it is.
FULL_DOMAIN
By default this parameter defines the full domain name of the server. It is derived from the hostname as it is defined in the file /etc/sysconfig/network. The parameter is used to create the full e-mail addresses of the users (see section 17. Squirrelmail below). In the case of the Exemplum Primary School, this parameter eventually would yield exemplum.serveratschool.net. If you are sure this domain name will not change in the forseeable future, you may want to change the definition of this parameter to something like FULL_DOMAIN="exemplum.serveratschool.net". If you are uncertain what to do, just leave this parameter as it is.
NOTICE: In the case of the Robert L. Stevensonschool (see section 9. Hostname configuration in chapter III. Using the text mode installation program) you may want to overrule the 'automatic' domain name (e.g. uptown.stevensonschool.net or downtown.stevensonschool.net) with the domain name that applies to both locations of the school, e.g. FULL_DOMAIN="stevensonschool.net". In that case e-mail addresses would look like username@stevensonschool.net.
INTERNAL_ADDR
This parameter defines the IP address of the local area network in CIDR notation (Classless Inter-Domain Routing), that is: the IP address of the network followed by a slash followed by the network prefix. You may want to replace the (moderately complex) definition with a static string, e.g. 172.17.2.0/24 (the default network address in ServerAtSchool). This saves some processing power every time a janitor command is executed. If you are uncertain what to do, just leave this parameter as it is. The parameter is used to optionally limit webmail users to handling their mail via the LAN only (see section 17. Squirrelmail below).
JANITOR_LANG
This parameter defines the language for the web interface of Janitor. Currently only the English language is defined, hence the default value of EN. The parameter is used in the web interface code to construct the name of the language file, e.g. /home/httpd/janitor/language/EN.php. The value of this parameter is propagated to the web interface via the (automatically created) configuration file /home/httpd/janitor/config/janitor.conf.php as defined by the parameter JANITOR_CONF_PHP.
PHP_ALLOWED_REMOTE_ADDR
This parameter defines, in CIDR notation (Classless Inter-Domain Routing), a list of IP addresses that are allowed to connect to the Janitor web interface. By default access is granted only to the server itself and all clients on the LAN. If you wish, you can add specific addresses that should be able to use the web interface to this comma-delimited list. For instance, it could be convenient for a systems administrator to be able to access the Janitor web interface from home. If the IP address of the administrator's Internet connection is 192.0.34.166, the parameter would be defined as follows: PHP_ALLOWED_REMOTE_ADDR="127.0.0.0/8,$INTERNAL_ADDR,192.0.34.166/32". Note that the network prefix of 32 yields a single host rather than a 'real' network. If you want to allow access to the web interface from any host (which is not recommended), you would need to specify 0.0.0.0/0, which acts as a wildcard.
SMB_HOME
SMB_PROFILE
SMB_STARTMENU
SMB_DESKTOP
SMB_MYDOCUMENTS
SMB_BACKUP
SMB_NESTS
These parameters define the Windows environment for the user. This environment is constructed within the user's $HOME. By default (with $HOME=/home/userdata/./home/users/<userid>) this environment looks like this: $HOME/H/ = SMB_HOME $HOME/H/.profile/ = SMB_HOME/SMB_PROFILE $HOME/H/.profile/Desktop/ = SMB_HOME/SMB_PROFILE/SMB_DESKTOP $HOME/H/.profile/Start Menu/ = SMB_HOME/SMB_PROFILE/SMB_STARTMENU $HOME/H/My Documents/ = SMB_HOME/SMB_MYDOCUMENTS $HOME/H/My Backups/ = SMB_HOME/SMB_BACKUP The users Windows Home is $HOME/H (a.k.a. H:\ from a Windows-client) The roving profile of the user (Windows 9x) is stored in $HOME/H/.profile, with icons on the Desktop and in the Start Menu stored in $HOME/H/.profile/Desktop and $HOME/H/.profile/Start Menu respectively. The user's documents go in $HOME/H/My Documents. The directory H:\My Backups contains a read-only backup of the user's data (backed up every hour during school hours; see bu(1)). The parameter SMB_NESTS is used to group the Desktops and Start Menus of groups (classes, grades) of pupils (called 'nests' here) in /home/userdata/home/groups/janitors/Desktop/SMB_NESTS/<group> and /home/userdata/home/groups/janitors/Start Menu/SMB_NESTS/<group> in order to make the desktops of many users (pupils) more manageable.
NOTICE: The names specified in the SMB_XXX-parameters should match those specified in the Samba configuration file /etc/samba/smb.conf, notably SMB_PROFILE in parameter logon home in section [global] and SMB_HOME in parameter path in section [homes] (see also section 12. Samba below).
SUB_SHORTCUTS
This parameter defines the name of the subdirectory which is created to hold the repository of Windows shortcuts, i.e. files with extensions .lnk or .pif which are used to launch Windows applications.

10.2 Other configuration files

The file /etc/janitor/janitor.conf is obviously the most important configuration file for Janitor, but there are some more configuration files. As a rule nothing will need to be changed in these files. The additional files are listed below for the sake of completeness.

/etc/janitor/janitor-bu.conf
/etc/janitor/janitor-bu.exclude
/etc/janitor/janitor-bu.include
These configuration files determine the behaviour of the hourly backup via bu(1). The actual hourly backup is done via a cron job; see /etc/cron.hourly/janitor-bu.cron. By default a backup of /home/userdata/home is made to /home/userdata/backhome every hour between eight a.m. (08:00) and six p.m. (18:00), Monday to Friday.
/etc/janitor/userdata_files.conf
/etc/janitor/buddies_files.conf
These two files define the necessary files for the chroot jails which a normal user with shell access or a buddy is allowed to enter. The list of available commands in the chroot jail is exactly enough to allow the user to log in via ssh(1), to manipulate files (using ls(1), cp(1), rm(1) etc.), and to upload and download files using scp(1). Users who are only allowed in the chroot jail can be recognised by the dot (full stop, '.') in the path to their home directory, e.g. $HOME=/home/userdata/./home/users/<userid>. Additional commands for these users may be specified in the file userdata_files.conf, although it is recommended to leave the configuration as it is. The necessary files are updated periodically from the system files, e.g. /bin/ls is copied to /home/userdata/bin/ls, etc.
/home/httpd/janitor/config/config.php
This configuration file defines various attributes of the web interface, e.g. screen colours, button names and default import file layouts. Normally there is no need to change this file.
/home/httpd/janitor/config/janitor.conf.php
This file contains all the parameters from the main configuration file /etc/janitor/janitor.conf in a form that is easily understood by the web interface program. The contents of this configuration file can be regenerated from the main configuration file with the command janitor configphp.

10.3 Janitor initialisation

When you consider the main configuration file to be correct, Janitor must be initialised.

NOTICE: Please double-check the contents of the configuration file /etc/janitor/janitor.conf before performing the Janitor initialisation. This initialisation is only done once, so please make sure you get it right the first time.

You can initialise Janitor as shown below. The command you need to give is emphasised.


[root@praeceptor root]# janitor init
050 success (re)writing '/home/httpd/janitor/config/janitor.conf.php'
[root@praeceptor root]# _

The effect of this command is that the directory trees under /home/userdata/ and /home/buddies are created. Also the configuration data from janitor.conf is copied to the configuration of the web interface.

NOTICE: If, despite all the warnings, you initialised Janitor with the wrong parameters in janitor.conf, even after you had double-checked everything, you may need to redo the initialisation. You can see what was done by reading the contents of /etc/janitor/janitor_init.txt. If you really need to redo the initialisation, you will need to perform the following steps.

remove any users and groups you may have added via Janitor
remove the directory trees under /home/userdata and /home/buddies
force a new initialisation with janitor -f init

Note that this procedure is not recommended and that there are no guarantees that it will in fact work.

If you wish, you can compare your file /etc/janitor/janitor_init.txt with the one in the illustration below. This file was created using all defaults, i.e. without changing anything in janitor.conf.


Tue Jul 12 09:42:45 CEST 2005: mkdir /home/buddies
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/buddies/home
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/users
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/bu
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/backhome
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/backhome/users
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/backhome/groups
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/Maildir
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/Maildir/cur
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/Maildir/new
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/Maildir/tmp
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/H
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/H/My Documents
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/H/.profile
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/H/.profile/Start Menu
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/skeletons/skel/H/.profile/Desktop
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors/shortcuts
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors/Desktop
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors/Desktop/nests
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors/Start Menu
Tue Jul 12 09:42:45 CEST 2005: mkdir /home/userdata/home/groups/janitors/Start Menu/nests

10.4 Adding the first user account

Janitor is now ready to create the first user account. It is a good idea to start with the regular user account that will be used by the systems administrator. This user account can subsequently be used to manage other user accounts via the web interface. You have to have at least 1 user account to be able to log into the web interface. This user account can simply be created from the command line.

NOTICE: The password 'iaghee4H' in the example below was chosen from the output of pwgen(1). The password 'fr56fr' was constructed manually. You should not copy the example below verbatim but you should instead use passwords (and usernames) of your own choice. See section 2.5 Choosing passwords for more information.

You can create a user account with Janitor as shown below. The command you need to give is shown emphasised.

NOTICE: In this illustration your input, which is shown emphasised, is split over multiple lines using the backslash character ('\'). This is done to make the illustration a little more readable. You are very welcome to create a long input line without backslashes; it works exactly the same. The output, consisting of the various bits of information entered for this user account, is shown in chunks of 76 characters per line. This too was done to make the illustration a little more readable.


[root@praeceptor root]# janitor useradd \
> -c "Freddie Frinton" \
> -d /home/userdata/home/users/ffrint \
> -G janitors,teleworkers,programs \
> -s /bin/bash \
> -P 'iaghee4H' \
> -W 'fr56fr' \
> -E freddie.frinton,listmaster \
> -I 0.0.0.0/0 \
> ffrint
ffrint:501:ffrint:Freddie Frinton:/home/userdata/home/users/ffrint:/bin/bash 
:janitors,teleworkers,programs:iaghee4H:fr56fr:/home/userdata/home/skeletons
/skel:freddie.frinton,listmaster:0.0.0.0/0
[root@praeceptor root]# _

Explanation:

janitor useradd
This is the call to the Janitor program janitor(1), asking it to perform the function useradd. (In total there are some 18 functions that can be executed this way; use janitor without parameters to get a quick overview). The remainder is a list of arguments for Janitor's useradd function.
-c "Freddie Frinton"
The parameter -c sets the comment field in the system's user database /etc/passwd. This field is sometimes referred to as the GECOS field. This field is used to store the name of the user in human-readable form.
-d /home/userdata/home/users/ffrint
The parameter -d defines the full path to the user's home directory. If this user were to be limited to the chroot jail mentioned earlier, the full path would have to be specified with an extra dot and a slash between 'userdata' and 'home' like this: /home/userdata/./home/users/ffrint.
-G janitors,teleworkers,programs
The parameter -G defines the secondary groups for this user. These secondary groups must already exist before any of them are used. In this case they are all predefined and can therefore be used without having to add them to the system first. By making this account a member of these groups, the following privileges are granted to the account:
- Members of the 'janitors' group are allowed to use the Janitor program, both from the command line and via the web interface. They are also allowed to log in at the console (i.e. via the keyboard/monitor attached to the server).
- Members of the 'teleworkers' group are allowed to access the server at school using ssh from the outside (i.e. via the Internet from home) or from the LAN (maybe with PUTTY.EXE).
- Members of the 'programs' group are allowed to access Windows programs and files via the Samba server.
-s /bin/bash
The parameter -s defines the command shell for this account. By default the 'shell' /sbin/nologin is assigned to a user account. This 'shell' simply denies access (it immediately logs out the user). This is a security measure. Only if the account has a real shell like /bin/bash will the user be able to log in (via ssh or at the console). Note that the account must be both a member of the teleworkers (for access via ssh) or janitors (for access via the console) group and have a real shell.
-P 'iaghee4H'
The parameter -P defines the shell password for the user account. This is the password that is used to authenticate the user for
- access to the user's mailbox via webmail (if access to webmail is not disabled, see parameter -I below)
- remote access to the server via ssh (if /bin/bash is specified as shell and the user is a member of the teleworkers group)
- local access to the server at the console (keyboard/monitor of the server) if the user is a member of the janitors group
- access to the web interface of Janitor if the user is a member of the janitors group
Obviously this is a very important password, especially for members of the janitors group, so it should be a good one. See section 2.5 Choosing passwords for more information.
-W 'fr56fr'
The parameter -W defines the user's password for Windows Networking via the Samba server. This password is used to access the server from a Windows client computer. Note that a user account has two passwords. It is a good idea to make sure that these passwords are not the same. This keeps the -P password (sometimes called the 'difficult' password) secret, even if the -W password (sometimes called the 'easy' password or the SMB password) were to be compromised.
-E freddie.frinton,listmaster
The parameter -E defines the user's e-mail aliases. It consists of a comma-delimited list of different aliases for this user's mailbox. In this case the mailbox name is ffrint (see below, the last item in this list) and the aliases defined via -E ensure that mail addressed to freddie.frinton@exemplum.serveratschool.net and listmaster@exemplum.serveratschool.net also ends up in mailbox ffrint. Note that the first alias in the list is also used as the From address in Squirrelmail. Note also that the domain name should not be specified here, just the bare alias. The domain name is derived from the FULL_DOMAIN parameter in /etc/janitor/janitor.conf. See section 10.4.1 The webmaster alias below for a discussion of how the 'webmaster' aliases should be added to this account. Note that the listmaster alias is used while configuring the (optional) Mailman mailing list manager, see section 18.3 Creating the mailman mailing list below.
-I 0.0.0.0/0
Parameter -I defines a comma-delimited list of IP addresses from which it is allowed to access webmail (Squirrelmail). By default, access to webmail is limited to the LAN by using 127.0.0.0/8,172.17.2.0/24. For this user account, access is unlimited; the user is allowed to access webmail from anywhere in the world. Specifying no access at all could be done via 255.255.255.255/32.
ffrint
This parameter specifies the name of the account. After creating the account, this name can not be changed; it can only be 'changed' by deleting and recreating the account.

NOTICE: Another important parameter for janitor useradd is -g. This parameter defines the user's primary group. By default (if no primary group is specified), a group with the same name as the userid is created automatically. This is called a User Private Group or UPG for short. User accounts for the school staff are usually created with UPGs. Accounts for pupils are usually not created with UPGs.

NOTICE: The abbreviation GECOS stands for General Electric Comprehensive Operating System. The GECOS field used to be used to enable Unix computers to print on machines running GECOS. Nowadays the field is used for pertinent information about the user, such as the full name. You may want to consult the entry for GCOS in the Jargon File for more information.

If the user account was created successfully, Janitor responds with a colon-delimited string containing all the details of the account that was just created, including the default values for fields that were not explicitly defined. The format of this string is as follows:

userid:uid:pgroup:gecos:home:shell:sgroups:pwd:smbpwd:skel:aliases:ips

Brief explanation:

userid: the name of the account (max. 16 letters and digits)
uid: numerical user id
pgroup: the name of the primary group (max. 16 letters and digits)
gecos: a comma-delimited list of additional information, first subfield is user's name in human-readable form
home: full path to user's home directory
shell: full path to the command shell for this account
sgroups: comma-delimited list of secondary groups (max. 16 letters and digits each)
pwd: shell password
smbpwd: smb password, also known as the Windows Networking password
skel: skeleton directory
aliases: comma-delimited list of e-mail aliases, the first one is also used as the sender address in squirrelmail
ips: comma-delimited list of allowed IP addresses for web mail access (CIDR format)

An in-depth discussion can be found in the chapter III. Janitor in ServerAtSchool User Manual.

With the new user account it is now possible to use the web interface to Janitor. If you wish to add other user accounts via the web interface, you should point a browser to http://server/janitor/index.php and enter the username ffrint and the 'difficult' password. You should see the following.

[ login screen for web interface Janitor ]

configuring_janitor_login.png

Press the [OK] button to log in. Note that there is no need to rush; the other user accounts can be added later on. It is best to finish the server-related configuration tasks first and leave user management for later.

Full documentation of the Janitor program can be found in chapter III. Janitor in the ServerAtSchool User Manual.

10.4.1 The webmaster alias

In the configuration of the Site@School Content Management System (see section 9.5 Creating the administrator user account above) we have configured the e-mail address 'webmaster@exemplum.serveratschool.net'. By default this address is aliased to 'root' which is aliased to 'postmaster' which in turn is aliased to the systems administrator's address as specified in section 14. E-mail address configuration in chapter III. Using the text mode installation program. This aliasing of e-mail addresses takes place in the file /etc/exim/aliases.

Because of the way Janitor works, it is not possible to use an alias that already exists for a new user account. The alias first has to be deleted from the account that currently uses the e-mail alias. In this case, the alias is associated with the root account. Since that account can not be managed with Janitor (for security reasons), it is necessary to change this specific alias manually. The best way to add the special alias 'webmaster' to the account 'ffrint' is to first delete the alias from the file /etc/exim/aliases and subsequently modify the account 'ffrint'.

Take the following steps:

Edit the file /etc/exim/aliases, e.g. with vi(1) or nano(1).
Remove the line that reads webmaster: root.
Save the file.
Issue the command /usr/sbin/newaliases in order to rebuild Exim's aliases database. At this point the 'webmaster' e-mail alias no longer exists.
Issue the following command to modify the ffrint account:
janitor usermod -E freddie.frinton,listmaster,webmaster ffrint.

This sequence of commands ensures that the three aliases 'freddie.frinton', 'listmaster', and 'webmaster' are linked to the account 'ffrint' in the correct order, i.e. the first alias specified will also be used as the sender address in Squirrelmail.

NOTICE: Of course it would have been possible to simply change the line 'webmaster: root' into 'webmaster: ffrint' in /etc/exim/aliases followed by the command newaliases. However, this would change the sender address in Squirrelmail to 'webmaster' the next time the ffrint account is modified.

NOTICE: This direct editing of /etc/exim/aliases is only necessary for the predefined e-mail aliases such as 'webmaster'. For regular users and ordinary aliases these changes can be done via Janitor. Janitor also takes care of automatically recreating the aliases database. If you change the aliases file manually, you should run newaliases.

(top)

11. REOBack

REOBack is the daily backup program. It is scheduled to run automatically every night via /etc/cron.daily/reoback.cron. However, before REOBack can run smoothly, a few things have to be done first:

A backup partition and a corresponding mount point /backup must exist.
The program must be configured via /etc/reoback/reoback.conf.
(optional) An off-site backup location must be prepared.

11.1 Creating a backup partition and mount point

REOBack is used to create a server backup every night. This is done by storing all the files from the server into one or more compressed tar files. These tar files are stored on a different partition on another disk but in the same server computer. See section 2.3 Disks in chapter II. Preparing the hardware for installation for more information.

At this point we need to prepare a partition on another disk for storing backups. Assuming the allocation of disks conforms to the one in the section mentioned above, we need to create a partition on disk /dev/hdc or the Secondary Master. The fastest way do do so is to use /sbin/fdisk. Below is an example that illustrates the process with:

starting fdisk(8) from the command line,
showing the current partition table of the device (in this case a disk that was already used for something else) with the p command,
creating a completely empty partition table with the o command,
showing the empty partition table of the device, again with the p command,
creating new primary partition with the n command, allocating the complete disk /dev/hdc to primary partition 1 using the default values by pressing [Enter] when asked about first and last cylinder,
once again showing the new partition table with the p command, and finally
writing the new partition table to the disk (and at the same time leaving the fdisk program) using the w command.

This newly created partition will be known as /dev/hdc1.


[root@praeceptor root]# fdisk /dev/hdc

The number of cylinders for this disk is set to 1216.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hdc: 10.0 GB, 10005037056 bytes
255 heads, 63 sectors/track, 1216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1   *           1          17      136521   83  Linux
/dev/hdc2              18        1216     9630967+   5  Extended
/dev/hdc5              18          50      265041   83  Linux
/dev/hdc6              51         116      530113+  83  Linux
/dev/hdc7             117         149      265041   83  Linux
/dev/hdc8             150         215      530113+  83  Linux
/dev/hdc9             216         281      530113+  83  Linux
/dev/hdc10            282         347      530113+  82  Linux swap
/dev/hdc11            348         639     2345458+  83  Linux
/dev/hdc12            640        1216     4634721   83  Linux

Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.



The number of cylinders for this disk is set to 1216.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected bu w(rite)

Command (m for help): p

Disk /dev/hdc: 10.0 GB, 10005037056 bytes
255 heads, 63 sectors/track, 1216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1216, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1216, default 1216): 
Using default value 1216

Command (m for help): p

Disk /dev/hdc: 10.0 GB, 10005037056 bytes
255 heads, 63 sectors/track, 1216 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1               1        1216     9767488+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks
[root@praeceptor root]# _

Once the partition /dev/hdc1 has been defined, a file system must be created on the partition. The preferred ServerAtSchool file system is 'ReiserFS'. A file system is created with the command mkreiserfs(8) as is illustrated below.


[root@praeceptor root]# mkreiserfs /dev/hdc1
mkreiserfs 3.6.11 (2003 www.namesys.com)

A pair of credits:
Vladimir Demidov wrote the parser for sys_reiser4(), the V3 alpha port, part of
the V3  journal  relocation code,  and helped  Hans keep  the business  side of
things running.

Continuing core development of ReiserFS is  mostly paid for by Hans Reiser from
money made selling licenses  in addition to the GPL to companies who don't want
it known that they use ReiserFS  as a foundation for their proprietary product.
And my lawyer asked 'People pay you money for this?'. Yup. Life is good. If you
buy ReiserFS, you can focus on your value add rather than reinventing an entire
FS.

Guessing about desired format.. Kernel 2.4.29-1 is running.
Format 3.6 with standard journal
Count of blocks on the device: 2441872
Number of blocks consumed by mkreiserfs formatting process: 8286
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: a7ffe483-7d83-49cf-bd10-b8034154b535
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/hdc1'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok

Tell your friends to use a kernel based on 2.4.18 or later, and especially not a
kernel based on 2.4.9, when you use reiserFS. Have fun.

ReiserFS is successfully created on /dev/hdc1.
[root@praeceptor root]# _

After creating a file system on /dev/hdc1 an entry must be added to fstab(5), the table with file systems. This table is stored in the file /etc/fstab. The entry should enable the system to make the connection between the partition (/dev/hdc1) and the mount point (/backup).

NOTICE: The mount point /backup should already exist; it was created during the installation of the ServerAtSchool server. If for some reason the mount point does not exist, you can create it (as root) with the command 'mkdir /backup'.

The line mapping /dev/hdc1 to /backup is shown emphasised in the illustration below. You should edit the file /etc/fstab and apply this change.


/dev/hda5   /            reiserfs  noatime,notail               0 0
/dev/hda1   /boot        reiserfs  noatime,notail               0 0
/dev/hda6   /usr         reiserfs  noatime,notail               0 0
/dev/hda7   /chroot      reiserfs  noatime,notail               0 0
/dev/hda8   /var         reiserfs  noatime,notail               0 0
/dev/hda9   /tmp         reiserfs  noatime,notail,noexec,nosuid 0 0
/dev/hda11  /var/lib     reiserfs  noatime,notail               0 0
/dev/hda12  /home        reiserfs  noatime,notail,nosuid        0 0
/dev/hda10  swap         swap      defaults                     0 0
none        /proc        proc      defaults                     0 0
tmpfs       /dev/shm     tmpfs     defaults                     0 0
none        /dev/pts     devpts    gid=5,mode=620               0 0
/dev/cdrom  /mnt/cdrom   iso9660   noauto,owner,ro              0 0
/dev/fd0    /mnt/floppy  auto      noauto,owner                 0 0
/dev/hdc1   /backup      reiserfs  noauto,noatime,notail        0 0

The backup partition is now ready to receive backups.

NOTICE: Note that the backup partition is not mounted at this time and is not even mounted automatically at all. The daily cronjob reoback.cron takes care of mounting and unmounting the partition. The only time the partition is mounted is while the backup is being made. It is unmounted and therefore inaccessable for the rest of the time. This is a security measure.

NOTICE: You should mount the partition with mount /backup at least once. By issuing the mount command this way, you not only mount the partition, but you also test to see if the system is able to make the connection between the partition and the mount point, confirming that you did not make any typing errors. After you have succesfully mounted the partition, you can unmount it again.

11.2 Checking the default ServerAtSchool configuration

The default REOBack configuration file /etc/reoback/reoback.conf is shown in the illustration below. A few lines of interest are shown emphasised. Please take a look at this file to see if everything is all right.


############################################################################
# REOBack - reoback.conf
# $Id: reoback.conf,v 1.2 2004/05/22 13:54:58 peter Exp $
############################################################################
#
# REOBack Simple Backup Solution
# http://sourceforge.net/projects/reoback/
#
# Copyright (c) 2001 Randy Oyarzabal (techno91@users.sourceforge.net)
# Parts Copyright (c) 2004 Peter Fokker <peter@berestijn.nl> for ServerAtSchool
#
# Other developers and contributors:
#    Richard Griswold
#    Nate Steffenhagen (frankspikoli@users.sourceforge.net)
#
############################################################################
#
# See the manpage for reoback.conf(5) for full documentation of this file.
# The name of this file can be passed to reoback.pl(1) as a parameter, e.g.
# reoback.pl /etc/reoback/reoback.conf
#
############################################################################
#
host          = UNKNOWN
email         = root
backupdays    = 7
files         = /etc/reoback/reoback-files.conf
tmpdir        = /var/lib/reoback/tmp/
datadir       = /var/lib/reoback/data/
localbackup   = /backup/reoback/
keeplocalcopy = 1
remotebackup  = 0
rbackuptype   = SSH
localmount    = /mnt/server/
remotehost    = backup.server.net
remotepath    = ~/reoback/
remoteuser    = ssh_username
ftpuser       = ftp_username_here
ftppasswd     = ftp_password_here
encryptbackup = 0
encryptkey    = This_Is_The_TOP_SECRET_KEY_12345
#
# EOF reoback.conf

Explanation:

The parameter host should be configured to the name of the host that is being backed up. In our case the word UNKNOWN should be changed to praeceptor. The hostname ends up as part of the filenames of the compressed tar files that REOBack creates.
If backups are to be copied to remote locations using SSH/SCP (see section 11.3 Creating remote backups below), the parameter remotebackup should be set to 1 instead of 0.
If backups are to be copied to remote locations via SSH/SCP, the systems administrator of the remote server should have provided you with correct values for the remotehost and remoteuser parameters.
If backups are to be stored in encrypted form, the parameter encryptbackup should be set to 1 instead of 0 and parameter encryptkey should contain an encryption key. (See NOTICE below).

NOTICE: There is a known issue with remote backups: the parameter remotepath should be changed from ~/reoback to ./reoback. This is a quirk in this version of REOBack which will be fixed in future versions.

NOTICE: Please make sure that you keep a copy of the exact encryptkey written down in a safe place, i.e. not in your desk drawer at school. Any encrypted backup files will be rendered absolutely useless if you do not have the exact same key as was used to encrypt the data. Without it, you will be unable to decrypt the data. If you lose the paper with the secret key, you will also lose all your encrypted backups. Consider yourself warned. Alternatively, you could store the encryptkey on a USB stick, see section 15.3 Using USB storage below.

NOTICE: The format of the file /etc/reoback/reoback.conf is documented in the man page. See man reoback.conf for more information.

After editing this file /etc/reoback/reoback.conf you should check the file /etc/reoback/reoback-files.conf. This file lists the directory trees that are backed up, basically one tree per backup file in the default setup. The default configuration creates backups of the following directory trees: /bin, /boot, /chroot, /dev, /etc, /home, /lib, /root, /sbin, /tmp, /usr, /var (excluding /var/lib/mysql) and /var/lib/mysql. The default reoback-files.conf(5) is shown below.


############################################################################
# REOBack - reoback-files.conf
# Based on files.conf - adapted for ServerAtSchool by Peter Fokker
# <peter@berestijn.nl> 2004-04-27
# $Id: reoback-files.conf,v 1.1 2004/05/20 20:12:57 peter Exp $
############################################################################
#
# REOBack Simple Backup Solution
# http://sourceforge.net/projects/reoback/
#
# Copyright (c) 2001 Randy Oyarzabal (techno91@users.sourceforge.net)
# Parts Copyright (c) 2004 Peter Fokker <peter@berestijn.nl>
#
# Other developers and contributors:
#    Richard Griswold
#    Nate Steffenhagen (frankspikoli@users.sourceforge.net)
#
############################################################################

# This file uses the additional directives 'PreExec:' and 'PostExec:' 
# in order to suspend services and/or daemons while performing backups.
# See below for an example. Full documentation in the man page for
# reoback-files.conf(5).

# Comments must start with a "#" as shown
############################################################################

# This is a list that works with a basic ServerAtSchool installation

File: bin
/bin

File: boot
/boot

File: chroot
/chroot

File: dev
/dev

File: etc
/etc

File: home
/home

File: lib
/lib

File: root
/root

File: sbin
/sbin

File: tmp
/tmp

File: usr
/usr

File: var
Skip: /var/lib/mysql
Skip: /var/lib/reoback/tmp
/var

File: var-lib-mysql
PreExec: /etc/init.d/mysqld stop
PreExec: /bin/sleep 10
/var/lib/mysql
PostExec: /etc/init.d/mysqld start

# Explanation:
#
# 'File:' followed by the name of the tar file that will be created
# Note that we don't include a path as that is added in the settings.conf
# Example:
#
#     File: TestFile1

# Simply list all directories to be recursively backed up (1 per line)
# after the first 'File:' directive.
# Example:
#
#     /home/sforge

# 'Skip:' followed by any subdirectories you want not to be included
#         from the above backup directory. Multiple 'Skip:'s are OK.
# Examples:
#
#     Skip: /home/sforge/backups
#     Skip: /home/sforge/reoback/data

# Note: You can use Perl regular expressions (wild cards) for Skip: For
# example, to skip all files and directories in your home directory that
# start with a dot, you can use:
#
#     Skip: /home/myself/\..*
#
# Wondering what '\..*' does?  The leading backslash, '/', tells REOBack
# (actually Perl) to treat the next dot, '.', as a literal dot.  The
# third dot tells Perl to match any character, and the asterisk, '*',
# tells Perl to perform the match zero or more times.

# 'PreExec:' followed by a command makes that the command is executed
# _before_ the backup is created. Multiple 'PreExec:'s are OK. If there
# are more, they are executed in the order specified.

# 'PostExec:' followed by a command makes that the command is executed
# _after_ the backup is created but _before_ it is transferred to a remote
# location. Multiple 'PostExec:'s are OK. If there are more, they are
# executed in the order specified.

# Example:
#
#     PreExec: /etc/init.d/mysqld stop
#     PreExec: /bin/sleep
#     PostExec: /etc/init.d/mysqld start
#
# When these lines are added to a 'File:', the MySQL database
# is stopped before the backup is created. Also, the system sleeps
# for 10 seconds. This allows for clearing all MySQL's child
# processes. After the backup is finished, MySQL is started
# again.

# That's it. Good luck.

By splitting various directory trees over different files the individual backup files won't be as big as they would be if all the backups were stored in a single file.

NOTICE: If the backup files grow too large to your taste, you can always change the configuration to split them into smaller chunks. A good candidate for splitting up is /home: you may want to split this tree into subtrees, e.g. /home/share/program1, /home/share/program2, /home/share/iso and the remainder of /home. Another good candidate is the subtree /var/lib/g4u if you have a few large client disk images (see section 13. Ghost for Unix below).

11.3 Creating remote backups

If you want to use the remote backup feature, i.e. storing your backups on a remote server, you should have access to the remote server. Also you need to enter additional information in /etc/reoback/reoback.conf.

Assuming that you have an agreement with the Elisa Dolittle School to store your backups on their server, their systems administrator would have provided the following information:

the name of the remote server: higgins.elisadolittle.org
the name of the account on that server: exemplum
(optional) a temporary password for the account

In order to be able to perform unattended backups (in the still of the night), you need to be able to log in on the remote server without having to enter a password or a pass phrase. This can be achieved by:

creating an RSA key pair for root on your server, and
transferring the public part of the of the key pair to the remote server

11.3.1 Generating a keypair

At this point you should generate an RSA key pair with no pass phrase using the command ssh-keygen -t rsa -N ''. Accept the default name and location by pressing [Enter]. This procedure is illustrated below. Your input is shown emphasised.


[root@praeceptor root]# ssh-keygen -t rsa -N ''
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
3f:6d:5b:36:d1:17:6d:e4:41:c9:f6:b0:4c:84:b2:70 root@praeceptor.exemplum.serveratschool.net
[root@praeceptor root]# _

At this point, two files will have been generated. The first one, /root/.ssh/id_rsa is the private part of the keypair. The second one, /root/.ssh/id_rsa.pub, contains the public part of the keypair.

NOTICE: It is important to keep the private part of a keypair strictly confidential. Please make certain that only the public part of the keypair leaves the server. Also the permissions on the private key should be as tight as possible: do not allow more than read and write access for the file owner, i.e. set permissions to 0600. The public key can have permissions 0644 if you wish.

11.3.2 Transferring the public key

When you have generated the key pair, you should copy the file with the public part of the key pair to the remote server. This is easiest done if you have a (temporary) password for the remote server. You could ask the administrator of the remote server to provide you with one. Assuming you do have a password, you should take the following steps to transfer a copy of your public key to the remote server.

Log into the remote server with ssh(1), using the password you received from the administrator of the remote server.
Create a subdirectory .ssh in your home directory on the remote server.
Log out of the remote server using the command exit.
Copy your public key to the remote server with scp(1), using the password you received from the administrator of the remote server.
Make sure the automatic login procedure works by logging into the remote server again, this time without using a password.

This procedure is illustrated below. Your input is shown emphasised.


[root@praeceptor root]# ssh exemplum@higgins.elisadolittle.org
Warning: Permanently added 'higgins.elisadolittle.org,192.0.34.166' (RSA) to the list of known hosts.
exemplum@higgins.elisadolittle.org's password: 
-bash-2.05b$ mkdir -m 0700 .ssh
-bash-2.05b$ exit
Connection to higgins.elisadolittle.org closed.
[root@praeceptor root]# scp /root/.ssh/id_rsa.pub exemplum@higgins.elisadolittle.org:.ssh/authorized_keys
exemplum@higgins.elisadolittle.org's password: 
id_rsa.pub                                    100%  253     0.3KB/s   00:00
[root@praeceptor root]# ssh exemplum@higgins.elisadolittle.org
Last login: Sun Jul 31 19:15:23 2005 from praeceptor.exemplum.serveratschool.net
-bash-2.05b$ ls -laR
.:
total 6
drwx------    3 exemplum buddies       104 Jul 31 17:14 .
drwxr-xr-x   10 root     root          240 Jul 28 08:21 ..
-rw-------    1 exemplum buddies        41 Jul 31 17:15 .bash_history
drwx------    2 exemplum buddies        80 Jul 31 17:15 .ssh

./.ssh:
total 5
drwx------    2 exemplum buddies        80 Jul 31 17:15 .
drwx------    3 exemplum buddies       104 Jul 31 17:14 ..
-rw-r--r--    1 exemplum buddies       253 Jul 31 17:15 authorized_keys
-bash-2.05b$ exit
Connection to higgins.elisadolittle.org closed.
[root@praeceptor root]# _

NOTICE: If you cannot log into the remote server, you may need to check the settings for ssh(1) in /etc/ssh/ssh_config, notably the parameters 'PasswordAuthentication' and 'StrictHostKeyChecking'; see section 2.6 Remote maintenance via SSH above for details.

NOTICE: You also should have the firewall configured to allow outgoing traffic. See section 11.4 Firewall considerations below for more information.

Once these steps are completed, the user 'root' from the Exemplum Primary School (with ssh(1)) can log into the account exemplum on the server higgins.elisadolittle.org of the Elisa Dolittle School without being prompted for a password. Also, files can be copied (with scp(1)) without the need to specify a password. This is what REOBack will be doing every night when remote backups over SSH are enabled.

NOTICE: More information about setting up public key authentication can be found in the manual page; see man reoback.conf. An in-depth discussion of the subject can be found in chapter 16 OpenSSH (pp. 432, Creating OpenSSH private & public keys) of [Mourani 2002].

11.3.3 Configuring remote backups

After the 'automatic' login on the remote server is configured, you should enter the pertinent information you received from the systems administrator of the remote server in your file /etc/reoback/reoback.conf. You will also need to enable remote backups. The necessary changes are illustrated in the snippet below. Lines of interest are shown emphasised.


host          = praeceptor
email         = root
backupdays    = 7
files         = /etc/reoback/reoback-files.conf
tmpdir        = /var/lib/reoback/tmp/
datadir       = /var/lib/reoback/data/
localbackup   = /backup/reoback/
keeplocalcopy = 1
remotebackup  = 1
rbackuptype   = SSH
localmount    = /mnt/server/
remotehost    = higgins.elisadolittle.org
remotepath    = ./reoback/
remoteuser    = exemplum
ftpuser       = ftp_username_here
ftppasswd     = ftp_password_here
encryptbackup = 0
encryptkey    = This_Is_The_TOP_SECRET_KEY_12345
#
# EOF reoback.conf

Explanation:

The parameter remotebackup must be set to 1 in order to enable remote backups.
The parameter remotehost must be set to the name of the server that will receive your backups.
The parameter remotepath must be changed to './reoback/', i.e. the tilde '~' must be changed into a dot '.'. This a known issue in the default configuration file.
The parameter remoteuser is the name of the account on the remote server.
(optional) The parameter encryptbackup must be set to 1 in order to create encrypted backups. If you do, be sure to
- change the default encrypting key (see below);
- store a copy of your encrypting key in a safe place.
(optional) The parameter encryptkey is the secrect code which is used to encrypt your backups (if encryptbackup is set to 1). Please do not use 'difficult' characters in this key. The easiest is to stick to letters, digits, comma's, dots and underscores. Characters to avoid are spaces, single and double quotation marks, the backquote, and other punctuation characters.

11.4 Firewall considerations

In order to be able to copy backups to a remote location, the firewall (/etc/giptables.conf) has to be edited. The entry that allows outgoing traffic to the Internet (via eth0) needs to be changed. The relevant line is shown emphasised in the illustration below. (Some lines have been removed in order to save space).


# ****************************************************************************
#                                                                            *
#                                    S S H                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_SSH="yes"

# ----------------------------------------------------------------------------
# SSH outgoing client request
#

# Interface 0 SSH outgoing client request

    INTERFACE0_SSH_CLIENT="yes"

    INTERFACE0_SSH_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_SSH_OUT_DST_IPADDR[0]=$ANY_IPADDR

[...]

You may also need to check the SSH client configuration. See section 2.6 Remote maintenance via SSH for more information on configuring SSH (both client and server).

Do not forget to restart the firewall after you have made changes to the firewall configuration. You can do so with the command 'service giptables restart'.

11.5 Creating buddies

If you do not wish to configure your system to receive backups from other schools, you can safely skip the remainder of this section and proceed with section 12. Samba.

If you have an agreement with the Elisa Dolittle School for storing your backups on their server it is likely that you will return the favour by configuring your server to receive their backups. In order to make this work, you, the local systems administrator of the Exemplum Primary School, have to perform the following tasks.

Prepare the buddies disk and partition.
Create the buddy account elisadolittle on your server praeceptor.exemplum.serveratschool.net.
Exclude the directory tree with their backups from your backups.

These tasks will be discussed below.

NOTICE: The whole discussion in this section 11.5 can be considered the counterpart of the procedures described in section 11.3 above. In section 11.3 you were configuring your remote backups on their server, here in section 11.5 you are providing facilities for them to store their backups on your server.

11.5.1 Preparing the buddies partition

The first thing that must be done is partitioning the buddies disk in your server, formatting the partition, adding the partition to fstab(5) and mounting the partition. The procedure is basically the same as the one described in section 11.1 Creating a backup partition and mount point above, be it with a different disk. If you have followed the instructions in section 2.3 Disks in chapter II. Preparing the hardware for installation, your buddies-disk would be /dev/hdd.

You should take the following steps.

Partition the disk using the command fdisk /dev/hdd.
You can assign all the space on the disk to a single partition. That partition will be called /dev/hdd1. Do not forget to actually write the partition table to the disk with the w command in fdisk(1).
Format the new partition with mkreiserfs /dev/hdd1.
Add the link between the partition and the mount point by editing fstab(5).
You should add the following line to this table:
/dev/hdd1 /home/buddies/home reiserfs noatime,notail,noexec,nosuid 0 0
Note that this partition will be mounted automatically at boot time; the option noauto is not specified. This means that the partition will be mounted every time the system is booted. For the buddies-partition this is what you want, since you cannot predict when they will want to store their backup. Therefore the buddies partition must always be mounted.
Also note that it is not allowed to execute programs from this partition (noexec) and it is also not allowed to have files with the set-userid-bit set (nosuid). Even though you may completely trust the Elisa Dolittle School with an account on your server, it is better to be safe than sorry.
Mount the partition with mount /home/buddies/home.
By issuing the mount command this way, you not only mount the partition, but you also test to see if the system is able to make the connection between the partition and the mount point, confirming that you did not make any typing errors.

11.5.2 Creating a buddy account

At this point the buddies partition is mounted at the correct location in the file system. It is now time to add a buddy account to the system.

The fastest way to add a buddy to the system is to use janitor(1). Assuming you want to create an account 'elisadolittle' for the Elisa Dolittle School, with password 'Nae8upae', you would issue the command shown in the illustration below.


[root@praeceptor root]# janitor useradd \
> -c "Buddy Elisa Dolittle School" \
> -d /home/buddies/./home/elisadolittle \
> -g buddies \
> -s /bin/bash \
> -P 'Nae8upae' \
> elisadolittle
elisadolittle:502:buddies:Buddy Elisa Dolittle School:/home/buddies/./home/ 
elisadolittle:/bin/bash::Nae8upae::::
[root@praeceptor root]# _

Explanation:

janitor useradd
As before, this is the request to the janitor command to execute the function 'useradd'.
-c "Buddy Elisa Dolittle School"
This parameter is used to add a readable name to the account.
-d /home/buddies/./home/elisadolittle
This parameter defines the absolute path to the home directory of this user. Note that there is a dot and an extra slash between 'buddies' and 'home'. This confines the user to a chroot jail. Also note that this user's home directory will end up on the partition /dev/hdd1 which is mounted at /home/buddies/home.
-g buddies
This parameter isolates the user in a common group for all buddies. This is a group separated from all other users. The intention is to keep the buddies separated from the other users as much as possible.
-s /bin/bash
This provides the buddy account with a command shell. This is necessary for uploading backups via ssh(1) and scp(1).
-P 'Nae8upae'
This is the password for the account. Note that this password can be changed to something else as soon as the public key of the Elisa Dolittle School is in place as it will no longer be necessary if authentication is done via the exchange of keys.
elisadolittle
This is the name of the account. By convention the account name would be something that resembles the domain of the buddy (which was elisadolittle.org in this case). The next best choice would have been the name of the server of the Elisa Dolittle School, e.g. higgins. The name should consist of no more than 16 letters and digits, as usual.

NOTICE: It would also have been possible to create the buddy account via the web interface; that is a matter of choice and convenience.

At this point you should talk to the systems administrator of the Elisa Dolittle School (by telephone or in person) and provide her with the following information:

The hostname of your server: praeceptor.exemplum.serveratschool.net.
The name of their account on your server: elisadolittle.
The password for their account: Nae8upae.

NOTICE: You should not use e-mail to transfer this information because e-mail is very insecure. Sending e-mail is like sending a postcard: anyone can read the contents because there is no envelope to protect the message. Eavesdropping on a telephone conversation is a lot harder.

As soon as they have configured their 'automatic' login on your server, you can change the password for their account on your server. The password is no longer necessary as they will use their key pair to connect to your server.

11.5.3 Excluding buddies from your backups

Once the Elisa Dolittle School starts to create remote backups on your server, your partition /dev/hdd1 which is mounted on /home/buddies/home will fill up with data.

If your school, the Exemplum Primary School, starts creating remote backups on higgins.elisadolittle.org, their partition /dev/hdd1 will be filled with data, too.

If you back up the complete directory tree under /home, you would also back up their data under home/buddies/home/elisadolittle/. This implies that their backup is in fact stored a third time, on their buddies disk, under /home/buddies/home/exemplum/. This data would then be backed up one more time, from higgins to praeceptor, etcetera.

In order to prevent this endless loop (which would fill up all available space in no-time) from happening, you should exclude the directory tree /home/buddies/home from your reoback-files.conf(5). Edit the file /etc/reoback/reoback-files.conf and add the line that is emphasised in the illustration below.


File: etc
/etc

File: home
Skip: /home/buddies/home
/home

File: lib
/lib

Obviously, your peers at the Elisa Dolittle School should edit their configuration file in the same way.

NOTICE: You should be aware that a full backup of an average server may take a very long time and quite some bandwidth, even on an above average xDSL-connection. By creating a second instance of the REOBack cronjob, using a different configuration file specifying a well-chosen subset of files to backup, you can at least copy the most important files (school administration database, etc.) to a remote location without saturating the xDSL connection.

(top)

12. Samba

Samba is an Open Source/Free Software suite that has, since 1992, provided file and print services to all manner of SMB/CIFS clients, including the numerous versions of Microsoft Windows operating systems. Samba is freely available under the GNU General Public License and allows for interoperability between Linux/Unix servers and Windows-based clients. The home page of the project can be found at http://www.samba.org.

An in-depth discussion of the subject can be found in chapter 46 Samba of [Mourani 2002] and in the book Using Samba, 2nd Ed. (see [Ts, Eckstein, Collier-Brown]).

The Samba server has already been automatically configured for a standard ServerAtSchool installation based on the information you provided in section 15. Samba configuration in chapter III. Using the text mode installation program. It is merely a matter of checking the configuration file.

12.1 The Samba configuration file

The configuration file smb.conf(5) is shown in the illustration below. Documentation can be found in the man page via man smb.conf. Lines of interest are shown emphasised and are explained below.


# /etc/samba/smb.conf

# This file was generated with sas-config-samba
# on Thu Jul  7 14:25:22 UTC 2005 with these parameters:
# WORKGROUP = EXEMPLUM
# SMB.CONF  = /mnt/system/etc/samba/smb.conf
# OS_ROOT   = /mnt/system

# Note
# Items which are indented need attention; they may be configured wrongly
# This is on the ToDo-list

[global]


workgroup = EXEMPLUM
server string = Samba ServerAtSchool
netbios name = SERVER


# Run a WINS server
wins support = Yes
name resolve order = wins lmhosts host bcast


# Act as local and domain master
domain master = Yes
local master = Yes
preferred master = Yes
# set the value on the next line to 255 to FORCE this system as PDC
os level = 65


# Perform domain authentication
encrypt passwords = True
security = user
domain logons = True


# Logon path for Windows NT/2000/XP
logon path = \\%L\profiles\%u\%m


# Roaming profiles for Win95/Win98/WinME
# Complies with default Janitor setup (2004-06-29/PF)
logon drive = H:
logon home = \\%L\%u\.profile


# Advertise time server
time server = yes


# ToDo
# domain admin group =
# add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u 

null passwords = yes

smb passwd file = /etc/samba/smbpasswd
log file = /var/log/samba/m.%m.log
max log size = 150
socket options = IPTOS_LOWDELAY TCP_NODELAY

        deadtime = 15
        getwd cache = Yes
        lpq cache time = 45

        dns proxy = Yes

# Don't serve shares to the outside world
bind interfaces only = True
interfaces = eth1 172.17.2.1/255.255.255.0 127.0.0.1
hosts deny = ALL
hosts allow = 172.17.2. 127.0.0.1

        debug level = 1
        create mask = 0664
        directory mask = 0775
        oplocks = True
        level2 oplocks = True
        read raw = No
        write cache size = 262144

#       ssl = Yes
#       ssl CA certFile = /usr/share/ssl/certs/ca.crt
#       ssl server cert = /usr/share/ssl/certs/smb.crt
#       ssl server key = /usr/share/ssl/private/smb.key

# Default logon script for all users relative to the [netlogon] share
# 
        logon script = LOGON.BAT


# The [netlogon] share is required for a PDC. The directory should exist.
[netlogon]
path = /home/samba/netlogon
writable = no
browsable = no


# Place to store WinNT/2000/XP profiles
[profiles]
path = /home/samba/profiles
writable = yes
create mask = 600
directory mask = 700
browsable = no

[homes]
path = %H/H
comment = Home Directory
browseable = no
read only = no
# Fixme: map archive = yes?
invalid users = root bin daemon sync nobody sys tty disk mem kmem
create mask = 0770
directory mask = 0770
force create mode = 0060
force directory mode = 0070

[printers]
comment = Remote Printers
path = /var/spool/samba
browseable = No
printable = Yes
invalid users = root bin daemon sync nobody sys tty disk mem kmem
printer admin = @janitors

[tmp]
comment = Temporary File Space
path = /tmp
read only = No
invalid users = root bin daemon sync nobody sys tty disk mem kmem

[program1]
comment = Educational software (pupils)
path = /home/share/program1
read only = yes
public = no
write list = @janitors
create mask = 0770
directory mask = 0770
force create mode = 0060
force directory mode = 0070
force group = programs
valid user = @programs

[program2]
comment = More educational software (pupils)
path = /home/share/program2
read only = no
public = no
create mask = 0770
directory mask = 0770
force create mode = 0060
force directory mode = 0070
force group = programs
valid user = @programs

[install]
comment = Installation files
path = /home/share/install
read only = yes
public = no
write list = @janitors
create mask = 0770
directory mask = 0770
force create mode = 0060
force directory mode = 0070
force group = programs
valid user = @programs

[cdroms]
comment = CD-ROM ISO 9660
path = /home/share/iso
read only = yes
public = no
write list = @janitors
create mask = 0770
directory mask = 0770
force create mode = 0060
force directory mode = 0070
force group = programs
valid user = @programs

# eof /mnt/system/etc/samba/smb.conf

Explanation:

workgroup = EXEMPLUM
This is the name of the domain that the Windows clients will log onto. It should not be called WORKGROUP. You have selected this name during the installation, see section 15. Samba configuration in chapter III. Using the text mode installation program.
netbios name = SERVER
By default the Samba server is known simply as 'SERVER'. This name is displayed when you browse the "Network Neighbourhood". Note that the name 'server' was also defined in the Bind configuration. It means that you can refer to the server using the netbios name 'SERVER' and the DNS-name 'server'. There should be no doubts about the name of the server.
logon drive = H:
logon home = \\%L\%u\.profile
Together these parameters define the location of a user's roaming profile for Windows 98. The drive letter H: is later used to connect to the user's home directory with the DOS command NET USE H: /HOME. The actual profile is stored in a subdirectory with a name that starts with a dot. This makes the directory more or less 'invisible' for the average user on the client computer.
null passwords = yes
This parameter makes it possible to have user accounts that need no password at all for a Windows Network logon. For the lower grades in particular it can be useful to allow pupils to log on with their own account but without a password. If you want to assign no password to a user account you should specify the special SMB password NO PASSWORD (all capitals and a space between the two words) for that account via Janitor.
interfaces = eth1 172.17.2.1/255.255.255.0 127.0.0.1
This parameter defines the interfaces that the Samba server will listen to. Note that by default Samba only listens to the interface connected to the LAN. It would be unwise to listen to the other interface; you really do not want to share your server with the world at large via Samba.
hosts allow = 172.17.2. 127.0.0.1
This parameter defines the hosts that are allowed to use the Samba server. By default only hosts on the LAN are allowed.
path = %H/H
This parameter, which is taken from the section [homes], defines the exact directory which is considered to be the home directory of the user. Note that there is an unusual twist here. The macro %H resolves to the fully qualified path to the user's (Linux) home directory, e.g. /home/userdata/home/users/ffrint. The parameter here adds yet another directory level to this path, namely a subdirectory called H. This letter was defined in janitor.conf(5) earlier. See the discussion of SMB_HOME in section 10.1 The main Janitor configuration file above. The effect of this parameter path in combination with logon home and logon driver is that the roaming profile of Freddie Frinton is stored on the ServerAtSchool server in /home/userdata/home/users/ffrint/H/.profile, which is equivalent to \\SERVER\ffrint\.profile and H:\.profile as seen from the Windows 98 client.
write list = @janitors
This parameter (which is used in various share definitions) allows users who are a member of the group 'janitors' to write files and create subdirectories on those shares. As a rule ordinary users are not allowed to write files to those shares. This feature can be used to let users in the group 'janitors' install Windows software onto the server (i.e. copy files to the server) whereas ordinary users are allowed only read access, which should be enough to execute those programs on the client computer.
force group = programs
valid user = @programs
These parameters (which are used in various share definitions) make sure that all files that are copied to the server will be owned by the group 'programs'. This implies that anyone wishing to access these files on the server needs to be a member of the group 'programs' (or should be the file owner). The necessary permissions (membership of group programs) is enforced via the parameter valid user. Note that there are in fact user accounts on your server that do not require access to your Samba shares, e.g. the members of the group 'buddies'.

NOTICE: All Samba shares are defined in such a way that by default both read and write (and search) permissions are granted to both the owner and the group whereas others ('the world') are granted no permissions at all. For regular files this means permissions 0660, for directories this means 0770.

NOTICE: It may sound complex to add yet another level (the subdirectory 'H') to the path that equates to the H: drive as seen from the client. However, there is some method in this madness: the users will eventually associate the letter 'H' with their home directory, i.e. the place where their documents are stored, etc. as seen from the LAN at school. The moment these users access the server at school from their home computer (e.g. via a secure connection using WinSCP), they will always land in their Linux home directory. Almost the only thing they see there is a subdirectory (a 'folder') named 'H' which happens to contain all their documents. It should not be so hard for the users to discover that the H: drive and this H folder are in fact the same thing.

12.2 Logon script and drive letters

During the installation and automatic configuration of Samba, a standard LOGON.BAT was created on the ServerAtSchool server. This script is located at /home/samba/netlogon/LOGON.BAT. This script is executed every time a user logs onto Windows Networking on a client computer. The script is shown below.


@ECHO OFF
REM /mnt/system/home/samba/netlogon/LOGON.BAT - See smb.conf for details
REM This file was generated with sas-config-samba on Thu Jul  7 14:25:22 UTC 2005
NET TIME \\SERVER /SET /YES
NET USE H: /HOME
NET USE P: \\SERVER\PROGRAM1
NET USE Q: \\SERVER\PROGRAM2
NET USE R: \\SERVER\CDROMS
NET USE V: \\SERVER\TMP

This script performs the following tasks.

The real time clock on the client computer is synchronised with the time on the server.
The H: drive is designated as the home drive.
Four shares are assigned the drive letters P:, Q:, R:, and V:.

Once this script has been executed on the client computer, the user can refer to various Samba shares using the designated drive letters. The purpose of the drives is as follows.

The H: drive holds all the personal files of the user. All users have their own H: drive.
The P: drive is used to store programs. The files on the P: drive are read-only to ordinary users; only members of the group janitors may add and modify files on this drive.
The Q: drive is also used to store programs. The difference with P: is that effectively all members of the group programs are allowed to write to the Q: drive. Unfortunately many Windows programs insist on being able to write to their own program directory. This is a fact of life and the Q: drive was designed to take care of that.
The R: drive is intended to be the repository where CD-ROM images are stored. These images can be used to mount CD-ROMs in a virtual CD-ROM player (using the DAEMON Tools software). A CD-ROM image can easily be created via the web interface of Janitor (or you can use the function janitor cdimage from the command line).
The V: drive can be used as temporary storage space; it maps directly to the directory /tmp on the server.

NOTICE: By default there is a shared directory (\\SERVER\install) that is not assigned a drive letter. This share, which is writable only to the members of the group 'janitors', can be used as a central place for storing Windows packages that need to be installed, e.g. OpenOffice.org. If you like, you can add the line NET USE I: \\SERVER\install to the LOGON.BAT script in order to be able to access these installation files using drive letter I:.

NOTICE: If the virtual CD software package DAEMON Tools is installed on the Windows clients, it is handy to configure DAEMON Tools in such a way that there is only a single virtual CD available. By convention this would be drive letter K:. The DAEMON Tools software can be downloaded via the home page of the DAEMON Tools project which can be found at http://www.daemon-tools.cc.

More information on DAEMON Tools can be found in chapter VI. DAEMON Tools in the ServerAtSchool User Manual.

12.3 Firewall considerations

Before client computers can access the Samba server, the firewall has to be opened for this network traffic. The snippet below shows the relevant part of the firewall configuration file /etc/giptables.conf as it is installed by default on the ServerAtSchool server. By default, access is enabled, but only to and from interface eth1, the LAN side of the server. It would be a bad idea to open the firewall on eth0 for this type of traffic.


# ****************************************************************************
#                                                                            *
#                                N E T B I O S                               *
#                                                                            *
# ****************************************************************************

    ACCEPT_NETBIOS="yes"

# ----------------------------------------------------------------------------
# NETBIOS outgoing client request
#

# Interface 1 NETBIOS outgoing client request

    INTERFACE1_NETBIOS_CLIENT="yes"

    INTERFACE1_NETBIOS_OUT_SRC_IPADDR[0]=$INTERFACE1_IPADDR
    INTERFACE1_NETBIOS_OUT_DST_IPADDR[0]=$NETWORK1

# ----------------------------------------------------------------------------
# NETBIOS incoming client request
#

# Interface 1 NETBIOS incoming client request

    INTERFACE1_NETBIOS_SERVER="yes"

    INTERFACE1_NETBIOS_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_NETBIOS_IN_DST_IPADDR[0]=$INTERFACE1_IPADDR

NOTICE: The firewall allows access from an SMB client program on the server computer to any machine on the LAN (INTERFACE1_NETBIOS_CLIENT="yes"). This means that you would be able to access file shares on client computers (if they exist), e.g. with smbclient(1) which is part of the Samba suite. By the same token the firewall allows you to connect to a shared printer on a Windows client in the LAN from the server computer. In this way you could turn a shared local printer on the LAN into a system printer that is also accessible from the server. See chapter 10 Printing, section CUPS printers, page 332 of [Ts, Eckstein, Collier-Brown] for more information.

(top)

13. Ghost for Unix

g4u ('ghost for unix') is a NetBSD-based boot floppy/CD-ROM that allows easy cloning of PC harddisks to deploy a common setup on a number of PCs using FTP. The floppy/CD offers two functions. The first is to upload the compressed image of a local harddisk to an FTP server, the other is to restore that image via FTP, uncompress it and write it back to disk. Network configuration is fetched via DHCP. As the harddisk is processed as an image, any filesystem and operating system can be deployed when using g4u. Easy cloning of local disks as well as partitions is also supported. g4u was created and is maintained by Hubert Feyrer. More information can be found on the project's home page at http://www.feyrer.de/g4u.

Before g4u can be used in the ServerAtSchool environment, a few things have to be done:

An FTP account must be created on the server.
An FTP server must be active.
A DHCP server must be active.
The firewall must be configured for both FTP and DHCP.
A g4u bootfloppy (or CD) must be created.

13.1 Creating a g4u user account

Before g4u can be used, a special user account has to be created on the server. This user account will be used to upload disk images from client computers to the server or download disk images from the server to the client computer. By default g4u uses the username install to connect to the server.

NOTICE: It is not necessary to name this user account install because you can specify another user account when using g4u from a client computer. However, it is very convenient to use this default name.

The fastest way to add this account to the system is to use janitor(1). Assuming you want to create the account 'install' with password 'cooT9joo', you would issue the command shown in the illustration below.


[root@praeceptor root]# janitor useradd \
> -c "Ghost for Unix" \
> -d /var/lib/g4u \
> -g install \
> -m -k /usr/share/empty \
> -I 255.255.255.255/32 \
> -P 'cooT9joo' \
> install
install:503:install:Ghost for Unix:/var/lib/g4u:/sbin/nologin::cooT9joo::
/usr/share/empty::255.255.255.255/32
[root@praeceptor root]# _

Explanation:

janitor useradd
As before, this is the request to the janitor command to execute the function 'useradd'.
-c "Ghost for Unix"
This parameter is used to add a readable name to the account.
-d /var/lib/g4u
This parameter defines the absolute path to the home directory of this user. Note that this user's home directory will end up on the partition /dev/hdd11 which is mounted at /var/lib. By default this partition occupies about a third of the total disk space for the benefit of g4u and the large files g4u creates.
-g install
This parameter isolates this user in a special common group. This group was predefined at install time. This group is intended to be the primary group of the g4u user account.
-m -k /usr/share/empty
These parameters instruct Janitor to use the directory /usr/share/empty as a skeleton directory for the new user account. As its name implies, this directory is empty. This means that the home directory of the new account will also be empty, or at least as empty as possible.
-I 255.255.255.255/32
This user account is strictly to be used for upload/download via FTP on the LAN. There is no need to allow access to webmail at all. If you do not specify this particular parameter, the account will be granted access to webmail from the LAN by default. (This is the way things work with Janitor.)
-P 'cooT9joo'
This is the password for the account. This password needs to be typed in every time g4u is used. You may want to consider using a password that is easy to remember.
install
This is the name of the account. The name should consist of no more than 16 letters and digits, as usual.

NOTICE: It would also have been possible to create the install account via the web interface; that is a matter of choice and convenience.

NOTICE: No shell has been specified. This means that (by default) this user will be using /sbin/nologin. Access via FTP does not require a real shell. Using nologin(8) prevents this user account from logging in either at the console or via ssh(1) over the network.

NOTICE: Specifying an empty skeleton directory helps to keep the home directory clean. However, Janitor still insists on creating a subdirectory H. For this account even that is not necessary. You can safely remove this directory tree with the command 'rm -r /var/lib/g4u/H'.

13.2 FTP server and DHCP server

Before g4u can be used, an FTP server must be activated. By default vsftpd(8), the Very Secure FTP Daemon, is started automatically in a standard ServerAtSchool configuration.

If this is not the case, the daemon can be started immediately with 'service vsftpd start'. This makes that the FTP server will run until the server is rebooted (or the FTP server is stopped again, e.g. with 'service vsftpd stop').

If you want to make sure the FTP server is started every time the server is rebooted, you should activate it using chkconfig(8). For the purpose of ServerAtSchool, the FTP server should be started at least at runlevel 3. By convention it is also started at runlevels 4 and 5. The correct command would be 'chkconfig --level 345 vsftpd on'. You can check the current settings via 'chkconfig --list vsftpd'. More information about this FTP server can be found in chapter 42 vsFTPd of [Mourani 2002].

More or less the same reasoning applies to the DHCP server. This server too should be running by default in a standard ServerAtSchool configuration.

If this is not the case, you should start the DHCP server with 'service dhcpd start'. If you want to make this change permanent (in order to survive a server reboot), you should use 'chkconfig --level 345 dhcpd on'. You can check the settings with 'chkconfig --list --dhcpd'.

The default settings for the DHCP server were discussed in section 5. DHCPD above.

NOTICE: If you start a service manually, e.g. with 'service vsftpd start' and forget to make the changes permanent with 'chkconfig --level 345 vsftpd on', you could be in for a surprise if many months later the server is rebooted for whatever reason. You could easily spend hours wondering why g4u 'suddenly' stopped working.

13.3 Firewall considerations

In order to be able to use g4u on the LAN, the firewall must be opened for both DHCP and FTP on eth1. The settings for DHCP where already discussed in section 5.2 Firewall considerations above.

The snippet below shows the relevant part for FTP of the firewall configuration file /etc/giptables.conf as it is installed by default on the ServerAtSchool server. Lines of interest are emphasised.


# ****************************************************************************
#                                                                            *
#                                    F T P                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_FTP="yes"

# ----------------------------------------------------------------------------
# FTP outgoing client request
#

# Interface 0 FTP outgoing client request

    INTERFACE0_FTP_CLIENT="yes"

    INTERFACE0_FTP_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_FTP_OUT_DST_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_FTP_OUT_PASIVE[0]="yes"
    INTERFACE0_FTP_OUT_ACTIVE[0]="no"

# Interface 1 FTP outgoing client request

    INTERFACE1_FTP_CLIENT="yes"

    INTERFACE1_FTP_OUT_SRC_IPADDR[0]=$INTERFACE1_IPADDR
    INTERFACE1_FTP_OUT_DST_IPADDR[0]=$NETWORK1
    INTERFACE1_FTP_OUT_PASIVE[0]="yes"
    INTERFACE1_FTP_OUT_ACTIVE[0]="yes"

# Network 1 FTP forwarded outgoing client request

    NETWORK1_FTP_CLIENT="yes"

    NETWORK1_FTP_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_FTP_OUT_DST_IPADDR[0]=$ANY_IPADDR
    NETWORK1_FTP_OUT_PASIVE[0]="yes"
    NETWORK1_FTP_OUT_ACTIVE[0]="no"

# ----------------------------------------------------------------------------
# FTP incoming client request
#

# Interface 1 FTP incoming client request

    INTERFACE1_FTP_SERVER="yes"

    INTERFACE1_FTP_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_FTP_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE1_FTP_IN_PASIVE[0]="yes"
    INTERFACE1_FTP_IN_ACTIVE[0]="yes"

    INTERFACE1_FTP_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_FTP_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR
    INTERFACE1_FTP_IN_PASIVE[1]="yes"
    INTERFACE1_FTP_IN_ACTIVE[1]="yes"

By default, the configuration file enables access to the FTP-related firewall rules with ACCEPT_FTP="yes". Access to the FTP server from the LAN ($NETWORK1) is granted via INTERFACE1_FTP_SERVER="yes". This is exactly what is required for g4u.

NOTICE: If you do not want to use g4u (anymore) you may want to shut down the FTP server with service vsftpd stop and close the firewall by setting variable INTERFACE1_FTP_SERVER to "no". Do not forget to restart the firewall with 'service giptables restart' after you have made the changes. The FTP server can be disabled permanently with the command chkconfig --level 345 vsftpd off. You could even remove it completely from your server with rpm -e vsftpd.

13.4 Creating a g4u boot floppy

At this point the server is ready for g4u; all the necessary services have now been configured. However, you still need to have a floppy disk or a bootable CD-ROM in order to start the actual g4u program on a client computer. By default both a raw floppy image and a CD-ROM ISO-image were copied to the ServerAtSchool server at intall time. You can find both files in /home/share/install/goodies/g4u/. The file g4u-1.17.fs (1,474,560 bytes) contains the image with which you can create a bootable 1.44 MB floppy disk. The file g4u-1.17.iso (1,572,864 bytes) contains an ISO-image which can be used to create a CD-ROM.

The exact procedure for creating a bootable CD-ROM from g4u-1.17.iso is beyond the scope of this manual. However, creating a bootable floppy disk while sitting at the server is extremely easy, unlike the process of creating such a floppy using RAWRITE.EXE on a Windows client.

In order to create a bootable g4u floppy you need to take the following steps.

Insert a 1.44 MB diskette into the diskette drive of the server. Note that all information on this diskette will be overwritten.
Issue the following command at the (root) prompt:
dd if=/home/share/install/goodies/g4u/g4u-1.17.fs of=/dev/fd0
After a short while dd(1) is done and your bootable floppy is ready.
Remove the floppy from the drive and label it something like 'g4u boot floppy'.

This makes g4u ready for use. Further instructions on using g4u can be found in chapter V. Managing disk images with ghost for unix in the ServerAtSchool User Manual.

NOTICE: Version 1.17 is not the latest version of g4u. This is not an oversight, but a conscious decision. This version is the latest version that still fits on a single floppy disk. Newer versions require two disks, which makes using g4u more complicated. If, however, you want to use the latest and greatest version, perhaps because your client computer's network interface is not supported in 1.17, you can always download it from http://www.feyrer.de/g4u.

NOTICE: If you are more comfortable at a DOS prompt, you could also use the RAWRITE.EXE program to create a bootable floppy disk. This tool is also available in the 'goodies' directory, (including documentation and source code); look for rawrite.*.

NOTICE: If you created the g4u boot floppy using dd(1), you might as well repeat the process and also create the 'Autoclave' diskette that is used in chapter IV. Workstation setup in the ServerAtSchool User Manual. Of course you need to use a different image file; use /home/share/install/goodies/autoclave/clave03.img. If you can not find the 'Autoclave' image file on the ServerAtSchool server or on the ServerAtSchool distribution CD, you can download it via http://staff.washington.edu/jdlarios/autoclave-discontinued/index.html.

(top)

14. Squid

If you did not install the Squid package during the installation of optional components in section 2. Proxy in chapter IV. Installing optional ServerAtSchool components, you may want to skip the remainder of this section.

Squid is a high-performance proxy caching server for web clients, supporting FTP, Gopher, and HTTP data objects. It keeps metadata and often requested pages and files (also known as 'hot objects') cached in RAM, caches DNS lookups, supports non-blocking DNS lookups, and implements negative caching of failed requests.

An in-depth discussion of Squid can be found in chapter 11 Squid in [Mourani 2002]. More information can be found on the project's home page at http://www.squid-cache.org or in [Wessels]. A full discussion of all the idiosyncrasies of this complex piece of software is beyond the scope of this document. However, a lot of bandwidth can be saved and performance can be gained by using Squid in proxy-caching mode. The remainder of this section is dedicated to that subject.

14.1 Adding a new DNS record for the proxy server

In order to be able to refer to the server under the name proxy, that hostname must be defined via the name server. We have already manipulated the zone files for exemplum.serveratschool.net before, e.g. in section 3.2 Scenario 1 - in-house web server.

You can simply add a line to the file /chroot/named/var/named/db.exemplum.serveratschool.net that looks like this:


proxy           IN      A       172.17.2.1

NOTICE: Do not forget to increment the serial number of the zone file before saving the file!

After saving the file, you should restart the name server, e.g. with 'service named restart'. The name 'proxy' should now resolve to IP address 172.17.2.1.

14.2 Configuration file squid.conf

Squid is configured via the file /etc/squid/squid.conf. There are a lot of options that can be set in this file. The default file in ServerAtSchool contains only a small subset of the available parameters. All the parameters that are not specified (or commented out) will be used with their well-chosen default values.

The illustration below shows the trimmed-down version of squid.conf. Lines of interest and lines that may need to be added or edited (with vi(1) or nano(1)) are shown emphasised.


# /etc/squid/squid.conf: OpenNA, Inc. (last updated 2003 Aug 27)

http_port 172.17.2.1:3128
icp_port 0
ssl_unclean_shutdown on
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 128 MB
cache_replacement_policy heap GDSF
memory_replacement_policy heap GDSF
cache_dir diskd /var/spool/squid 250 16 256
cache_store_log none
log_fqdn on
auth_param basic program /usr/lib/squid/pam_auth
auth_param basic children 5
auth_param basic realm Squid Proxy-Caching Web Server
auth_param basic credentialsttl 2 hours
acl authenticated proxy_auth REQUIRED
acl localnet src 172.17.2.0/255.255.255.0
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025-65535 280 488 591 777
acl CONNECT method CONNECT
acl PURGE method PURGE
acl all src 0.0.0.0/0.0.0.0
# http_access allow authenticated
http_access allow localnet
http_access allow localhost
http_access allow PURGE localhost
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny CONNECT
http_access deny PURGE
http_access deny all
cache_mgr webmaster@exemplum.serveratschool.net
cache_effective_user squid
cache_effective_group squid
visible_hostname proxy.exemplum.serveratschool.net
logfile_rotate 0
log_icp_queries off
cachemgr_passwd Thohc4fo all
buffered_logs on

Explanation:

http_port 172.17.2.1:3128
This directive specifies the IP address and port that Squid will be listening to. By specifying the IP address of interface eth1, access is limited to the hosts connected to that interface, i.e. the machines on the LAN, so external hosts have no access. This is a security measure. The specified port 3128 is the default port for Squid in Proxy-Caching Mode. Note that this port still has to be opened in the firewall. This works much the same as the Listen directive we discussed in section 8.1 Default Apache configuration in ServerAtSchool above.
cache_mem 128 MB
This directive controls the maximum size of the memory that Squid will use to buffer often requested pages and files (known as 'hot objects'). If memory is tight, you may want to lower this limit. Note that this directive only applies to the memory used for in-memory caching. Squid itself uses even more memory while running; it is a real memory hog.
cache_dir diskd /var/spool/squid 250 16 256
This directive controls the amount of disk space that Squid uses to store 'cooled down objects' (i.e. pages and files that have not been requested lately) and the way it is structured. In this case the amount of disk space is set to 250 MB, split over 16 subdirectories of /var/spool/squid, each of those with 256 subdirectories. Note that at busy times Squid will exceed the limit for short periods of time. A rule of the thumb is to use 80% of your real limit. Also note that the available space on the /var partition is limited to 512 MB by default. See section 14.5 Increasing the size of the cache on disk below for a way to increase the size of the cache.
acl localnet src 172.17.2.0/255.255.255.0
This directive defines an access control list ('acl') with the name ('localnet') for the hosts in the LAN. This acl is used lateron with http_access directives to grant access to hosts on the local network.
# http_access allow authenticated
This directive is commented out (there is a '#' at the beginning of the line). This ensures that this particular directive is not evaluated. If the '#' were not there, every access to Squid would require a valid username and password. This works via the acl 'authenticated' and the 'auth_param' directives. If Squid is to be used as a no-frills school-wide cache proxy, there is no need to use this authentication (it would simply be annoying and counterproductive).
cache_mgr webmaster@exemplum.serveratschool.net
This directive defines the e-mail address of the Squid administrator. This address is displayed in error messages produced by Squid (which appear in the user's browser window). It is best to make this a fully qualified e-mail address rather than root@localhost which might lose its meaning on another host than localhost.
visible_hostname proxy.exemplum.serveratschool.net
This directive forces a specific name in error messages produced by Squid (which appear in the user's browser window). If this directive is commented out, Squid attempts to find the canonical hostname of the server. That would yield the well-known praeceptor.exemplum.serveratschool.net. Using the hostname proxy is perhaps slightly more elegant.
cachemgr_passwd Thohc4fo all
Squid comes with a web-based administration tool called the Cache Manager. This tool is installed at http://proxy.exemplum.serveratschool.net/cgi-bin/cachemgr.cgi. Access to the Cache Manager is protected with the password specified via the cachemgr_passwd directive, in this case 'Thohc4fo' (without the quotation marks). Do not use this password verbatim, but choose your own password, as dicussed earlier in section 2.5 Choosing passwords. Note that you can disable access to Cache Manager alltogether by specifying the special password disable. With cachemgr_passwd disable all access to the Cache Manager is completely blocked.

NOTICE: The order in which acl and in particular http_access directives are specified is important. The acl directives must be specified first, followed by the http_access directives. The latter will be evaluated in the order in which they are given. Evaluation of the http_access directives ends with the first matching directive.

NOTICE: Setting up Squid as a sophisticated tool for controlling access to the world-wide web can be a very complex task. This is illustrated by the fact that there is a book fully dedicated to Squid, see [Wessels].

When you have edited /etc/squid/squid.conf, you must make sure that this configuration file has the correct permissions. The permissions should be no more than 0600 (read and write access for the file owner) and possibly even as low as 0400 (read-only). The file must be owned by user root and group root. The file should certainly not be world-readable because of the plain-text password for the Cache Manager which is stored in the file.

You may want to use the following commands to adjust permissions.


[root@praeceptor root]# chmod 0600 /etc/squid/squid.conf
[root@praeceptor root]# chown root /etc/squid/squid.conf
[root@praeceptor root]# chgrp root /etc/squid/squid.conf
[root@praeceptor root]# _

Finally, as always, you should restart Squid for the changes to take effect. You could use the command 'service squid restart' for that purpose.

14.3 Firewall considerations

Before Squid can be reached from the LAN, the firewall has to be opened for the appropriate port. In this case we need to open the port associated with Squid in Proxy-Caching Mode. There is no need to open the port associated with HTTPD-accelerator Mode.

The snippet below illustrates the relevant part of the firewall configuration in /etc/giptables.conf. Lines of interest are shown emphasised.

NOTICE: You may find that the 5 lines starting with INTERFACE1_ are not preconfigured in your /etc/giptables.conf. In that case you should add these lines manually using vi(1) or nano(1). Please make sure you enter these lines exactly as they are shown here.


# ****************************************************************************
#                                                                            *
#                                  S Q U I D                                 *
#                                                                            *
# ****************************************************************************

    ACCEPT_SQUID="yes" # Squid in Proxy-Caching Mode

# ----------------------------------------------------------------------------
# SQUID incoming client request
#

# Interface 1 SQUID incoming client request

    INTERFACE1_SQUID_SERVER="yes"

    INTERFACE1_SQUID_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_SQUID_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE1_SQUID_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_SQUID_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR

Explanation:

By setting the parameter ACCEPT_SQUID to yes, you enable the SQUID module of the firewall.
By setting the parameter INTERFACE1_SQUID_SERVER to yes you allow traffic from the LAN to the internal interface.
As a result of the Squid mode configured here (Proxy-Caching Mode), the firewall will be opened on port 3128.

NOTICE: The default port for Squid in HTTPD-accelerator Mode is 8080. This port is not used in this scenario.

When you have made the changes to the firewall script, you should restart the firewall, e.g. with 'service giptables restart'.

14.4 Configuration issues for client computers

If you want to let all the client computers on the LAN use Squid as a school-wide cache to increase performance, you will need to configure the browser software on all clients in such a way that it knows about the proxy server.

You need to specify two parameters:

The name of the proxy server: proxy.exemplum.serveratschool.net
The port to use: 3128

By configuring the software on the clients this way, the clients will all use the cached files. This will be considerably faster if more than a few users (pupils) access the same web site. It will take only a little time to copy a file from the remote site to the cache the first time the file is accessed. Once that is done, all subsequent requests for the same file will be served from the local server rather than by fetching the file over and over again via the external connection.

If, however, you wish to use Squid as a sophisticated tool for access control, perhaps blocking specific computers and/or specific users (pupils) from Internet access, you should close the direct access to the Internet, at least via port 80 (HTTP). You can do so by editing the firewall /etc/giptables.conf and changing the relevant directive: NETWORK1_HTTP_CLIENT="no". Do not forget to restart the firewall, e.g. with 'service giptables restart' for the changes to take effect.

After closing this 'direct route' you will want to allow limited access via the appropriate access control lists ('acl') in /etc/squid/squid.conf. Please refer to the project's home page at http;//www.squid-cache.org or [Wessels] for more information on this advanced topic.

14.5 Increasing the size of the cache on disk

Via the directive cache_dir (discussed in 14.2 Configuration file squid.conf above) you can limit the amount of disk space used by Squid. The maximum amount of disk space is limited by the partition size. The standard ServerAtSchool partitioning scheme allocates 512 MB space to the partition where Squid stores the cached files. This is obviously a very hard limit.

If you want to be able to perform other tasks on the server such as sending and receiving mail via Exim or printing documents via Cups, you simply cannot have Squid use all the available space, since Exim uses space on the same partition (in /var/spool/mail), as does Cups (in /var/spool/cups). Also, the system log files are located on the same partition (in /var/log).

If you want to increase the size of the Squid cache, you have no other option than to move it to another partition. A suitable partition would be /var/lib. If you want to increase the size of the disk-based cache to say 750 MB, you should take the following steps.

Stop the currently running Squid program, e.g. with 'service squid stop'.
Move the cache directory tree to the new partition, e.g. with 'mv /var/spool/squid/ /var/lib'.
Edit the configuration file /etc/squid/squid.conf and change the line with the cache_dir directive to read cache_dir diskd /var/lib/squid 750 16 256 (i.e. two changes: the path and the maximum size).
Start Squid, e.g. via 'service squid start'.

The disk-based cache has now been moved to the new location.

(top)

15. USB/Laptop

If you did not install the Laptop packages during the installation of optional components in section 3. USB/Laptop in chapter IV. Installing optional ServerAtSchool components, you may want to skip the remainder of this section.

If you did install the Laptop packages, the following software was installed.

Linux USB utilities - the helper programs to inspect devices connected to a USB (Universal Serial Bus)
Hotplug - the helper application which dynamically loads kernel modules for USB devices
Daemon for PCMCIA-adapters - a set of modules and drivers for PCMCIA cards (sometimes called 'credit card adapters') and a card manager daemon

These three packages together are capable of adding and removing USB and PCMCIA devices to the server at runtime. This means that you do not have to shut down the server to add or remove such a device.

In addition, the following software was installed.

APMD - a daemon and a set of programs for controlling the Advanced Power Management features found on many laptop computers.

This APM daemon is capable of watching the laptop's battery and can shut down the PCMCIA sockets before a suspend event.

15.1 Configuring USB, hotplug and PCMCIA

As a rule the installer would have automatically detected the USB hardware in the server. You can verify this by looking in the file /etc/modules.conf: if an alias usb-controller exists, the hardware was detected. The image below illustrates this.

configuring_modules.conf2.png

If the USB hardware is available, the main system startup script /etc/rc.d/rc.sysinit takes care of initialising the USB subsystem at boot time, even at a fairly early stage. This means that it is not necessary to configure anything for USB; it should simply work.

You can verify this by checking the log files. Take the following steps:

Start looking at (and following) the tail of the log file with tail -f /var/log/messages.
Connect your USB device (e.g. a USB hard disk) to the USB connector on the server.

These steps are illustrated below.


[root@praeceptor root]# tail -f /var/log/messages
Jul 31 10:58:05 praeceptor kernel: hub.c: new USB device 00:07.2-2, assigned address 2
Jul 31 10:58:05 praeceptor kernel: usb.c: USB device 2 (vend/prod 0x5e3/0x702) is not claimed by any active driver.
Jul 31 10:58:08 praeceptor /etc/hotplug/usb.agent: Setup usb-storage for USB product 5e3/702/2
Jul 31 10:58:08 praeceptor kernel: SCSI subsystem driver Revision: 1.00
Jul 31 10:58:08 praeceptor kernel: Initializing USB Mass Storage driver...
Jul 31 10:58:08 praeceptor kernel: usb.c: registered new driver usb-storage
Jul 31 10:58:09 praeceptor kernel: usb_control/bulk_msg: timeout
Jul 31 10:58:09 praeceptor kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Jul 31 10:58:09 praeceptor kernel:   Vendor: ST34321A  Model: Rev: 0811
Jul 31 10:58:09 praeceptor kernel:   Type:   Direct-Access ANSI SCSI revision: 02
Jul 31 10:58:09 praeceptor kernel: USB Mass Storage support registered.

You will notice that the USB disk has been registered and that the SCSI subsystem is being used. When you disconnect the USB device, something like the following entry will be added to the log file:


Jul 31 11:03:01 praeceptor kernel: usb.c: USB disconnect on device 00:07.2-2 address 2

As you can see, USB disconnection also works. At this point you can end the tailing of the log file by pressing [Ctrl-C].

NOTICE: If it appears that the USB subsystem initialisation does not work as it should, you could try to initialise it manually by executing the script /etc/hotplug/usb.rc start. If you discover you need to do this every time the server is booted, you may want to edit the file /etc/rc.d/rc.local and add this command there. The effect will be that the command will be executed at every boot time, but in this case as one of the last tasks in the system initialisation procedure. As an alternative you could try removing the USB device, waiting a few seconds, and reinserting the USB device in order to get the USB subsystem to work.

The PCMCIA daemon is started automatically via the script /etc/rc.d/init.d/pcmcia. If the startup script does not detect PCMCIA hardware, the card manager daemon will not be started. If you happen to have PCMCIA sockets in your server, the daemon will be activated and will remain in memory to handle PCMCIA inserts and removals. There is no need to configure anything.

NOTICE: If your server does not have any PCMCIA hardware, you may want to remove the PCMCIA software from the server alltogether. You could do that with the command rpm -e pcmcia-cs.

15.2 Configuring APMD

You may want to check the settings for APMD in the file /etc/sysconfig/apmd. Notice that APMD works as a wrapper around existing software in your system's BIOS. If you do not need the Advanced Power Management daemon you can remove the software with rpm -e apmd.

15.3 Using USB storage

The main reason for installing the USB/Laptop packages is to be able to use USB storage devices such as USB hard disks and USB keys.

A USB disk could give you a (large) disk that can be easily plugged in without bringing the server down. It is a convenient route to copy many files from the server to a disk with a high storage capacity that can subsequently be stored somewhere off-site.

A USB key, also known as a USB stick, usually has a somewhat lower storage capacity. It can be used, however, to store important information. An example of important information would be the secret code you use to encrypt your REOBack backups (see the parameter encryptkey in /etc/reoback/reoback.conf in section 11.2 Checking the default ServerAtSchool configuration).

If you want to use a USB stick with the server, you should take the following steps.

Create a mount point for the USB storage device, e.g. /mnt/usbstick. You can do that with the command mkdir /mnt/usbstick.

Add a line to the table /etc/fstab like the following:


/dev/sda1  /mnt/usbstick  vfat  noauto,noatime,notail,noexec,nosuid  0  0

Insert the USB stick into the USB connector on the server.
Mount the device via mount /mnt/usbstick

The USB stick is now mounted, and you can use it to store important files. Use the command cp /etc/reoback/reoback.conf /mnt/usbstick to make a copy of the file with the password that encrypts your off-site backups.

NOTICE: Even though a USB device is hot-pluggable and you can physically remove the device from the connector at any time, you still have to unmount the device first! This is necessary because the Linux kernel may still have some data in RAM that needs to be written to the device. By unmounting the device you can be certain that all pending data is actually stored on the device. If you simply remove the device, the data may not yet be completely written.

You can unmount the USB stick with umount /mnt/usbstick. Once the USB stick is unmounted, you can safely remove it from the USB connector on the server.

NOTICE: By default only 'root' is allowed to mount and unmount devices. This is a security measure.

NOTICE: USB storage uses the SCSI subsystem. This explains why the first partition of the first SCSI disk (/dev/sda1) is used to access the USB stick. If your server already has some real SCSI disks, you may need to use another SCSI device to access your USB stick, such as /dev/sdb1 or/dev/sdc1. This depends on the available hardware.

NOTICE: It may be necessary to partition your USB device and to put a file system on it. This can be done the usual way, with fdisk(8) and mkfs(8). USB keys often come readily partitioned and formatted with a filesystem of the FAT type.

(top)

16. GIPTables

If you did not install the Firewall package during the installation of optional components in section 4. Firewall in chapter IV. Installing optional ServerAtSchool components, you may want to skip the remainder of this section. Note, however, that you may put your server at risk by not having a firewall.

GIPTables Firewall is a free set of shell scripts that helps you generate iptables rules for Linux 2.4.x and newer kernels. It is very easy to configure and at present, designed to run on hosts with one or two network cards. It doesn't require you to install any additional components to make it work with your GNU/Linux system. All you need to set up a very secure firewall for your GNU/Linux machines is iptables and GIPTables Firewall. An in-depth discussion of the basic firewall concept and the GIPTables Firewall can be found in chapters 9 and 10 in [Mourani 2002]. The home page of the GIPTables Firewall project can be found at http://www.giptables.org.

The default ServerAtSchool installation of the GIPTables Firewall is quite strict. Only the following services or ports are opened, some of them only partially; the rest is simply closed or disabled. This is a security consideration; nothing is allowed unless it is explicitly allowed.

DNS (port 53)
Bind is allowed to talk to one or two name servers of the ISP. Clients on the LAN are only allowed to talk to Bind running on the server. This means that the computers on the LAN must consult Bind for name resolving. No direct access to any Internet name servers is allowed. This way there cannot be any confusion for the clients as to which is the authoritative name server for the domain exemplum.serveratschool.net. (see section 3.4 above).
FTP (ports 21/tcp and 20/tcp)
Files can be retrieved from the internet at large to the server (e.g. for automatic downloading of updates) or directly from the client computers in the LAN. Also, the FTP server on the server can be accessed, but only from the LAN. This is used with g4u (see section 13.3 above).
SSH (port 22/tcp)
By default the SSH server can be reached from the internet and from the LAN. SSH connections originating on the server, i.e. by using the SSH client program ssh(1) are not allowed. Direct SSH sessions from the LAN to the internet are also not allowed. You may already have changed these default settings because of remote maintenance (see section 2.6 above) or because of setting up a backup exchange with another school (see section 11.4 above).
SMTP (port 25/tcp)
By default, the mail server Exim is allowed to send and receive mail via the internet connection. The SMTP port is closed to the LAN; no client computer can access Exim on the server, and no client computer on the LAN can access any other mail server outside the school (see section 4.2 above).
HTTP (port 80/tcp)
The Apache web server can be reached from both the internet and the LAN. Also, web pages and files can be retrieved directly from the server (e.g. for automatic downloading of new ClamAV antivirus definitions, see section 19). Finally all client computers on the LAN are allowed to access the world-wide web directly (see section 8.3 above). If you installed Squid you may already have reconfigured this part of the firewall (see section 14.3 above).
NTP (port 123/udp)
The port for the Network Time Protocol is opened for sessions originating on the server, aimed at time servers on the internet. Access to and from the LAN is denied (see section 21.1 below).
NETBIOS (ports 137/udp, 138/udp and 139/tcp)
Connections from the LAN to the Samba server are allowed. Also connections from the server to the LAN are allowed. Access from and to the outside world is strictly forbidden (see section 12.3 above).
SYSLOG (port 514/udp)
The system logger on the server is allowed to receive messages from devices connected to the LAN. The server is not allowed to send log messages (see section 21.2 below).
ICMP
All ICMP (Internet Control Message Protocol) messages between the server and the LAN are allowed. Furthermore clients are allowed to use ICMP to the internet. ICMP calls originating at the server with a destination on the Internet are also allowed. The server does not respond to 'ping' calls from the Internet.
DHCP (ports 67/udp and 68/udp)
The DHCP server is only allowed to provide IP addresses to clients on the LAN (see section 5.2 above).

The details of the configuration of the various GIPTables Firewall modules are discussed in the various sections where the corresponding subsystem is discussed. These details will not be repeated here.

NOTICE: If you change any settings in the firewall, be sure to restart it, using the command 'service giptables restart'.

16.1 Firewall customisation

Most of the popular ports and services are already preconfigured in the GIPTables configuration file, even though they might not be enabled by default. Perhaps you have already changed a few of the standard settings, e.g. SSH or even SQUID in Proxy Caching Mode.

Sometimes, however, it is necessary to punch a hole through the firewall for a very specific purpose. These customisations can be done in a structured way via the file /etc/rc.d/rc.giptables.custom. Every time you (re)start the firewall with 'service giptables restart', the code in rc.giptables.custom is executed. Therefore, this is the natural place for additional non-standard firewall commands.

The example below illustrates how this script can be used to open the relevant port for a printserver with IP address 172.17.2.11. This device uses port 9100 for direct ('raw') access to the printer (see also section 20.1 Setting up a JetDirect network printer with CUPS). The lines that were added are shown emphasised.


# ----------------------------------------------------------------------------
# GIPTables Firewall v1.1 http://www.giptables.org
# Copyright (C) 2002 Adrian Pascalau <apascalau@openna.com>
# rc.giptables.custom file
#
# ----------------------------------------------------------------------------
# This file is part of GIPTables Firewall
#
# GIPTables Firewall is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

# Add your custom iptables rules here

#
# Add support for the printer 
#
JETDIRECT_IPADDR="172.17.2.11"
JETDIRECT_PORT=9100

echo -ne "\n - with support for Jetdirect ($JETDIRECT_IPADDR:$JETDIRECT_PORT)"

$IPTABLES -A interface1_out -p TCP \
	-s $INTERFACE1_IPADDR --sport $UNPRIV_PORTS \
	-d $JETDIRECT_IPADDR --dport $JETDIRECT_PORT \
	-m state --state NEW,ESTABLISHED \
	-j ACCEPT

$IPTABLES -A interface1_in -p TCP \
	-s $JETDIRECT_IPADDR --sport $JETDIRECT_PORT \
	-d $INTERFACE1_IPADDR --dport $UNPRIV_PORTS \
	-m state --state ESTABLISHED \
	-j ACCEPT

# ---- THE END OF THE FIREWALL ----

# This is the end of the firewall's chains
# All packets that reach this point, will be dropped
# All incomming packets that reach this point will be also logged
# if DROP_EVERYTHING_FROM_HERE="yes"
# If you would like to see those packates that are dropped, uncomment the
# following 4 lines (this is very good during fireall developement & testing)

# [ "$DEBUG" = "on" ] && echo -e "\n# Logging needed during developement"
# $IPTABLES -A INPUT -j LOG --log-prefix "giptables-end-of-firewall: "
# $IPTABLES -A OUTPUT -j LOG --log-prefix "giptables-end-of-firewall: "
# $IPTABLES -A FORWARD -j LOG --log-prefix "giptables-end-of-firewall: "

# Do not add any iptables rules after this point,
# since this is the end of the firewall !!!

# ----------------------------------------------------------------------------
# End of file

In essence, two rules have been added to the firewall. The first one accepts (-j ACCEPT) network traffic for a connection (either a NEW or an ESTABLISHED one) from the server (from address $INTERFACE1_IPADDR or 172.17.2.1 and ports $UNPRIV_PORTS or 1024:65535) to the printer (via $JETDIRECT_IPADDR or 172.17.2.11 and at port $JETDIRECT_PORT or 9100).

The second rule allows replies from the printer to the server. Note that the printer is not allowed to initiate a transaction; only existing connections (--state ESTABLISHED) are allowed.

More information on iptables can be found on the home page of the Netfilter project at http://www.netfilter.org. You may also want to take a look at the manpage of iptables(8).

NOTICE: It is important to make sure that the firewall is correctly configured and that it stays that way. If you are uncertain about tweaking this customisation file you are probably better off not touching it at all. All standard functions have already been dealt with in the regular configuration file /etc/giptables.conf.

16.2 Firewall debugging and monitoring

When you set up a new server, it helps to get an idea of what is happening at the borders or your jurisdiction, i.e. what kind of traffic is being blocked by the firewall. An easy and illuminating way to monitor the workings of the firewall is to enable (uncomment) the last three commands in the file /etc/rc.d/rc.giptables.custom as illustrated in the snippet below.


# [ "$DEBUG" = "on" ] && echo -e "\n# Logging needed during developement"
$IPTABLES -A INPUT -j LOG --log-prefix "giptables-end-of-firewall: "
$IPTABLES -A OUTPUT -j LOG --log-prefix "giptables-end-of-firewall: "
$IPTABLES -A FORWARD -j LOG --log-prefix "giptables-end-of-firewall: "

# Do not add any iptables rules after this point,
# since this is the end of the firewall !!!

# ----------------------------------------------------------------------------
# End of file

Together, these three lines ensure that every packet that reaches the end of the firewall is logged in the system log file, /var/log/messages.

This enables you to see who is trying to get in from the outside, probing all sorts of exotic and trivial ports on your server. At the same time you will be reassured to know that the firewall is actually working and is blocking everything that is not specifically allowed.

And, even more interesting, you can often see particular machines from the LAN trying desperately to connect to suspect ports on strange IP addresses on the Internet. This is often the case when pupils download programs onto their computers that may appear innocent but turns out to be anything but. Often this is software such as peer-to-peer servers or simply spyware or browser plugins. It is nice to know that the firewall also blocks outgoing traffic if it is not explicitely allowed.

(top)

17. Squirrelmail

If you did not install the Webmail package during the installation of optional components in section 5. Webmail in chapter IV. Installing optional ServerAtSchool components, you may want to skip the remainder of this section.

SquirrelMail is a standards-based webmail package written in PHP4. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no JavaScript required) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an e-mail client, including strong MIME support, address books, and folder manipulation. The home page of the project can be found at http://www.squirrelmail.org.

NOTICE: The version of Squirrelmail used in ServerAtSchool has a special patch which allows for IP-based access control to the webmail application. The code of this patch is contained in the file /home/httpd/squirrelmail/serc/janitor-sqm.php and this file is included on line 90 in /home/httpd/squirrelmail/serc/redirect.php.

17.1 Configuring Squirrelmail

The Squirrelmail application is located under /home/httpd/squirrelmail. It should be configured by running the menu-based perl script conf.pl in the directory /home/httpd/squirrelmail/config/. Take the following steps to configure Squirrelmail.

Change to the configuration directory using the command cd /home/httpd/squirrelmail/config/.
Start the configuration script using the command perl conf.pl.
Use the commands 1,...,9 (followed by [Enter]) to access the submenus to change the various settings and preferences (see below for a list of options of interest). Use the R command (followed by [Enter]) to return to the main menu from a submenu.
Save the configuration using the S command (followed by [Enter]).
Return to the prompt using the Q command (followed by [Enter]).

The image below shows the main menu of the Squirrelmail configuration program.


SquirrelMail Configuration : Read: config.php (1.4.0)
---------------------------------------------------------
Main Menu --
1.  Organization Preferences
2.  Server Settings
3.  Folder Defaults
4.  General Options
5.  Themes
6.  Address Books (LDAP)
7.  Message of the Day (MOTD)
8.  Plugins
9.  Database

D.  Set pre-defined settings for specific IMAP servers

C.  Turn color on
S   Save data
Q   Quit

Command >> _

The following options are of interest.

Menu 1 - Organization Preferences
- Option 1 - Organization Name
  You could change the default value of 'WebMail' to 'Exemplum Primary School Webmail'. This text is shown on the Webmail login screen.
- Option 4 - Organization Title
  You could enter the value 'Exemplum Webmail' here. This text is displayed in the browser's title bar.
- Option 5 - Signout Page
  If you log out, Squirrelmail will take you to the page with this URL (see secttion 17.2 Integrating Squirrelmail in Site@School below). If this option is left blank, you will return to the standard Squirrelmail login page.
- Option 6 - Default Language
  By default Squirrelmail uses language en_US. You can change the default language by entering one of the supported language codes. The codes of the supported languages can be found in /home/httpd/squrrelmail/locale/.
- Option 8 - Provider link
  You could change the default value of 'http://www.openna.com' to the URL of your school: 'http://www.exemplum.serveratschool.net'. This value is used to create a clickable link in the main screen of the Squirrelmail application (once the user is logged in).
- Option 9 - Provider name
  You could change the default value of 'OpenNA Linux' to the name of the school: 'Exemplum Primary School'. This value is used as the readable text for the link specified in option 8.
Menu 4 - General options
- Option 11 - Allow server thread sort
  You should set this option to false because the default IMAP server (BincIMAP) has a problem with server thread sorting.
- Option 12 - Allow server-side sorting
  You should set this option to false because the default IMAP server (BincIMAP) has a problem with server side sorting.

NOTICE: There are many options not discussed above. You should consult the documentation at http://www.squirrelmail.org/wiki/SquirrelMail or take a look at a list of Frequently Asked Questions regarding installation of Squirrelmail at http://www.squirrelmail.org/wiki/en_US/InstallingSquirrelMail.

NOTICE: Currently only an English dictionary is installed on the ServerAtSchool server. This means that using the spelling checker plugin from Squirrelmail will check against the English dictionary or will fail because the dictionary for your language is not installed. The underlying spelling checker is aspell and that project's home page is located at http://aspell.sourceforge.net. This would be a good starting point to look for dictionaries in other languages.

When you use the S command, conf.pl will save the configuration in the file /home/httpd/squirrelmail/config/config.php. If you run conf.pl again in the future, it will use the values that were saved in this configuration file. You could also edit the configuration file manually. However, that is not recommended.

After configuration is complete, you can access Squirrelmail via http://www.exemplum.serveratschool.net/webmail/ if you run your own web server (see section 3.2 Scenario 1 - in-house web server above) or http://praeceptor.exemplum.serveratschool.net/webmail/ (if your main website is hosted at your ISP's server as described in section 3.3 Scenario 2 - web server running at ISP above).

NOTICE: The local part of the URL ('/webmail/') is configured in the configuration file of the Apache web server, see section 8.1 Default Apache configuration in ServerAtSchool. If you have changed the alias to something else, you should use the changed local part of the URL to access webmail.

17.2 Integrating Squirrelmail in Site@School

If you run your web server on the ServerAtSchool server (and not at your ISP) and you opted to install Squirrelmail, you can integrate the two in a fairly simple way. The effect will be that Squirrelmail will be accessable via the main website rather than via an 'obscure' URL like http://praeceptor.exemplum.serveratschool.net/webmail/. All you need to do is to add the following HTML code to a new page.


<!-- Start of Webmail Login -->
<h2><a href="http://www.exemplum.serveratschool.net/webmail/src/login.php">Webmail Login</a></h2>
<p>
<form action="/webmail/src/redirect.php" method="post">
  Name:<br>
  <input name="login_username">
  <p>
  Password:<br>
  <input type="password" name="secretkey">
  <p>
  <input type="hidden" name="js_autodetect_results"> 
  <input type="hidden" name="just_logged_in"> 
  <input type="submit" value="Login">
</form>
<!-- End of Webmail Login -->

NOTICE: The only thing you may have to adapt to your situation is the exact name of your web server. This name is shown emphasised in the image above.

Take the following steps.

Use a browser and open the following URL: http://praeceptor.exemplum.serveratschool.net/starnet/
Login using the webmaster account you created in section 9.5 Creating the administrator user account above.
Add a new page called 'Webmail', say in the first section ('School info'), using the page manager of Site@School. Let's say this will be page 11 in section 1.
Open the new page you just created.
In the page editor, press the [SRC] button.
Copy the HTML code shown in the image above into the text area of the editor.
Do NOT hit the [SRC] button again at this point, because otherwise the editor will mangle your carefully crafted HTML code! Instead, save the page without further ado.
Logout of Site@School.

At this point you have duplicated the essential fields for Webmail login. If you open your website and go to the first section 'School info', then select the second item on the left hand side, 'Webmail', you will see the following displayed on your screen.

configuring_integrating_webmail.png

If you (or any of your users) enter the correct name and password, you can open your webmail.

If you also want to integrate the Squirrelmail signout page, you have to use conf.pl again. In Menu 1 - Organizational Preferences, change Option 5 - Signout Page to read /index.php?page=11&section=1 so you will be taken back to the integrated login screen you created rather than the rather sparse Squirrelmail signout page.

NOTICE: Remember never to 'touch' this page 11 in the editor again. The editor is actually quite unforgiving with handmade input forms like the login screen you just created. If you really have to do something with this page, it is best to repeat the procedure you did, i.e. copying the snippet above into the text area after pressing the [SRC] button. This is one of the idiosyncrasies of this particular editor.

(top)

18. Mailman

If you did not install the Mailman package during the installation of optional components in section 6. Mailman in chapter IV. Installing optional ServerAtSchool components, you may want to skip the remainder of this section.

Mailman, the GNU Mailing List Manager, is used for managing electronic mail discussion and e-newsletter lists. Mailman is web-integrated, making it easy for users to manage their accounts and for list owners to administer their lists. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, spam filters, and more. Mailman is free software, distributed under the GNU General Public License. It is written in the Python programming language, with a little bit of C code for security. The name of this software is spelled Mailman with a capital leading M and a lowercase second m. It is incorrect to spell it "MailMan" (i.e. you should not use CamelCase). The home page of this project can be found at http://www.gnu.org/software/mailman.

Before Mailman can be used to create real mailing lists, a few things have to be done first.

The main Mailman site administrator password has to be set.
A configuration file has to be edited.
The internal mailman mailing list has to be created.

Once these tasks are completed, new lists can be created, either via the Mailman web interface or at the command line.

18.1 Setting the Mailman site administrator password

The first thing that must be done is to set the password for the Mailman site administrator. This is an important password because with it the administrator can create mailing lists. Therefore it should be a good one. See section 2.5 Choosing passwords for more information. You can set the password with mmsitepass, as illustrated below. Note that the password, say 'oolaeh0E', is not echoed to the screen. This is a security consideration.


[root@praeceptor root]#/var/lib/mailman/bin/mmsitepass
New site password:
Again to confirm password:
Password changed.
[root@praeceptor root]# _

18.2 Customising Mailman

At this point you need to edit the configuration file /var/lib/mailman/Mailman/mm_cfg.py (with vi(1) or nano(1)) and enter the correct values for the DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST, somewhere around line 72 . Take the following steps.

Open the file /var/lib/mailman/Mailman/mm_cfg.py for editing, and move to line 72.
Change the contents of the variable DEFAULT_URL_HOST from mm_cfg_has_not_been_edited_to_set_host_domains to www.exemplum.serveratschool.net (but see notice below). Make sure the surrounding single quotation marks are not deleted.
Change the contents of the variable DEFAULT_EMAIL_HOST from mm_cfg_has_not_been_edited_to_set_host_domains to exemplum.serveratschool.net. Make sure the surrounding single quotation marks are not deleted.
Save the changes and exit from the editor.

NOTICE: You can specify a line number on the command line when you start the editor so the editor will place the cursor at the correct line after opening the file. Examples: nano +72 mm_cfg.py, vi +72 mm_cfg.py.

At this point Mailman knows about the place where users visit the web interface and the domain name that will be used to send messages.

NOTICE: You can use the name www.exemplum.serveratschool.net as value for DEFAULT_URL_HOST. This tells Mailman that users will be using URLs like http://www.exemplum.serveratschool.net/mailman/listinfo to access the Mailman web interface. If you host your website at your ISP (see section 3.3 Scenario 2 - web server running at ISP above), you need to use a name that resolves to your server rather than the one at your ISP. A suitable name would be mail.exemplum.serveratschool.net. In this case you also need to tell Apache to respond to this (virtual) hostname. See the discussion of ServerAlias in section 8.1 Default Apache configuration in ServerAtSchool above.

NOTICE: The variable DEFAULT_EMAIL_HOST should match the settings you used earlier in the configuration of Exim (see section 4.1 Default configuration in ServerAtSchool above), notably the variable MAINDOMAIN in the file /etc/exim.

As you can see, configuring software like Mailman can be a daunting task because of the interaction with Bind, Exim and Apache.

18.3 Creating the mailman mailing list

After the mm_cfg.py is configured, the mailing list mailman must be created. This mailing list is used internally by Mailman. Take the following steps to create this mailing list.

(optional but efficient) Start a typescript recording your session with this command: script /tmp/mm.tmp. This will record all your input into and (more important) all output from the next command in a file.
Create the mailing list 'mailman' with the following command: /var/lib/mailman/bin/newlist. Use listmaster@exemplum.serveratschool.net when prompted for an e-mail address (see notice below).
(optional) Close the typescript using the command exit.
(optional) Edit the typescript you created and keep the 10 lines with aliases (discard the rest).
Add the 10 aliases to the aliases file. /etc/exim/aliases as per the instructions of the newlist command.
Execute the command newaliases in order to rewrite Exim's aliases database.
Start the Mailman daemon via service mailman start.

NOTICE: When you are prompted for an e-mail address, you could use the address listmaster@exemplum.serveratschool.net. This alias for user ffrint has already been defined in section 10.4 Adding the first user account above. It is helpful to use functional e-mail aliases for a webmaster or a mailing list administrator. If you were to use a personal alias rather than a functional one, then if the person in question were to leave the school, you would have to reconfigure an entire application rather than simply change the mailbox to which the alias points.

The image below illustrates the procedure. The commands you should enter are shown emphasised. Note that once again you need to enter a password, for example 'ookuoC5u'. The password is not echoed to the screen. This is a security consideration.


[root@praeceptor root]# script /tmp/mm.tmp
Script started, file is /tmp/mm.tmp
[root@praeceptor root]# /var/lib/mailman/bin/newlist
Enter the name of the list: mailman
Enter the email of the person running the list: listmaster@exemplum.serveratschool.net
Initial mailman password: 
To finish creating your mailing list, you must edit your /etc/aliases (or
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:

## mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

Hit enter to notify mailman owner...

[root@praeceptor root]# exitScript done, file is /tmp/mm.tmp
[root@praeceptor root]# nano /tmp/mm.tmp

     (...remove all lines except the 10 aliases...)

[root@praeceptor root]# cat /tmp/mm.tmp >>/etc/exim/aliases
[root@praeceptor root]# newaliases
53 entries written
[root@praeceptor root]# service mailman start
[root@praeceptor root]# _

At this point the Mailman mailing list manager is configured.

NOTICE: The 10 aliases are the lines between ## mailman mailing list and Hit enter to notify mailman owner.... The effect of adding these lines to the aliases file is that messages directed to say mailman-owner are directed through a pipe (hence the |) to a program called /var/lib/mailman/mail/mailman with parameters owner and mailman. In effect all messages that are destined for one of the 10 aliases (from 'mailman' to 'mailman-unsubscribe') are processed by the mailman program, which eventually deals with the messages, taking the responsability off Exim. Exim only has to pass on these messages to mailman rather than deliver the messages to a mailbox.

NOTICE: Starting the mailman service via 'service mailman start' does not show the familiar green OK. This is one of the idiosyncrasies of this particular service. You can check if the mailman service is running by searching through the process list, e.g. with ps ax | grep mailman. This should give you a list of the processes associated with mailman.

18.4 Creating a mailing list for teachers

If you want to have a mailing list to use as a means of communication with all the teachers of the Exemplum Primary School, you could create a new mailing list, either from the command line or via the web interface.

You can create a new mailing list via the web interface at http://www.exemplum.serveratschool.net/mailman/create (or http://mail.exemplum.serveratschool.net/mailman/create depending on what you configured in mm_cfg.py in section 18.2 Customising Mailman above) as illustrated in the image below.

NOTICE: Some of the available languages have been removed from the list in the image below in order to save space.

configuring_add_mailinglist.png

Explanation:

Name of the list: teachers
The name of the list will become the e-mail address via which messages can be posted. In this case it will be teachers@exemplum.serveratschool.net.
Initial list owner address: listmaster@exemplum.serveratschool.net
This address is used by Mailman to send administrative messages regarding this mailing list.
Auto-generate initial list password? No
Initial list password:
Confirm initial password:
This is the password that is required for mailing list maintenance. Please pick a good on, e.g. 'Shaevuf5'.
Should new members be quarantined before they are allowed to post unmoderated to this list? [...] No
Answer Yes to hold new member postings for moderator approval by default. By default, members' postings are forwarded to the list immediately.
Initial list of supported languages.
Select one or more possible languages for the mailing list's interface. Users can select the interface language from the list of languages you specify here.
Send "list created" email to list owner?Yes
This makes Mailman send a message to the list owner to report that the list has been created.
List creator's (authentication) password:
This is the place where you have to input the site password you entered in section 18.1 Setting the Mailman site administrator password: 'oolaeh0E' (without the quotation marks).

After pressing [Create List], Mailman will create the list. The following message will be shown.

configuring_mailinglist_added.png

The last thing you need to do is to add 10 aliases to the file /etc/exim/aliases and run the command newaliases again. You have already done this before with the mailman mailing list in section 18.3 Creating the mailman mailing list above. The lines to add are shown below.


## teachers mailing list
teachers:              "|/var/lib/mailman/mail/mailman post teachers"
teachers-admin:        "|/var/lib/mailman/mail/mailman admin teachers"
teachers-bounces:      "|/var/lib/mailman/mail/mailman bounces teachers"
teachers-confirm:      "|/var/lib/mailman/mail/mailman confirm teachers"
teachers-join:         "|/var/lib/mailman/mail/mailman join teachers"
teachers-leave:        "|/var/lib/mailman/mail/mailman leave teachers"
teachers-owner:        "|/var/lib/mailman/mail/mailman owner teachers"
teachers-request:      "|/var/lib/mailman/mail/mailman request teachers"
teachers-subscribe:    "|/var/lib/mailman/mail/mailman subscribe teachers"
teachers-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe teachers"

Do not forget to run the command newaliases after adding these aliases.

This list of aliases is also sent in a message to the mailman administrator (the one behind the alias 'mailman-owner' created earlier). The mailman administrator should ask the systems administrator to add those 10 aliases to the aliases file. However, in the case of the Exemplum Primary School, both administrators are the same person, namely ffrint.

The difference between these 10 aliases and the 10 aliases that were defined earlier (for the mailman mailing list) only differ in the first and the last word on each line. Here it is 'teacher' where it was 'mailman' in the previous set of aliases. The rest is the same.

The mailing list for teachers can now be managed, members can be added, additional settings can be configured, etcetera, via http://www.exemplum.serveratschool.net/mailman/admin/teachers, using the password 'Shaevuf5' (without the quotation marks). As a confirmation of the list creation, Mailman will send the following message to the list owner.

Subject: Your new mailing list: teachers
To: listmaster@exemplum.serveratschool.net
Sender: teachers-bounces+listmaster=exemplum.serveratschool.net@exemplum.serveratschool.net
Errors-To: teachers-bounces+listmaster=exemplum.serveratschool.net@exemplum.serveratschool.net

The mailing list 'teachers' has just been created for you.  The
following is some basic information about your mailing list.

Your mailing list password is:

    Shaevuf5

You need this password to configure your mailing list.  You also need
it to handle administrative requests, such as approving mail if you
choose to run a moderated list.

You can configure your mailing list at the following web page:

    http://praeceptor/mailman/admin/teachers

The web page for users of your mailing list is:

    http://praeceptor/mailman/listinfo/teachers

You can even customize these web pages from the list configuration
page.  However, you do need to know HTML to be able to do this.

There is also an e-mail-based interface for users (not administrators)
of your list; you can get info about using it by sending a message
with just the word `help' as subject or in the body, to:

    teachers-request@exemplum.serveratschool.net

To unsubscribe a user: from the mailing list 'listinfo' web page,
click on or enter the user's e-mail address as if you were that user.
Where that user would put in their password to unsubscribe, put in
your admin password.  You can also use your password to change
member's options, including digestification, delivery disabling, etc.

Please address all questions to
mailman-admin@exemplum.serveratschool.net.

(top)

19 ClamAV

Unfortunately it is necessary to scan for computer viruses nowadays. By default ServerAtSchool has ClamAV installed. Clam AntiVirus is a GPL anti-virus toolkit for UNIX. The main purpose of this software is the integration with mail servers (scanning e-mail messages and attachments). The package provides a flexible and scalable multi-threaded daemon, a command line scanner, and a tool for automatic updating via the Internet. The programs are based on a shared library distributed with the Clam AntiVirus package. Most importantly, the virus database is kept up to date. The home page of this project can be found at http://www.clamav.net.

On the ServerAtSchool server, updates of virus definitions are downloaded on a daily basis by means of a cron job, /etc/cron.daily/freshclam.cron. For the daily update to work correctly, the firewall has to be open, allowing HTTP traffic originating on the server to reach the outside world. By default this is already the case (see the discussion in section 8.3 Firewall considerations above).

NOTICE: You can see if freshclam.cron is working as it should by consulting the log files in /var/log/clamav. The downloaded virus definition files are stored in /var/lib/clamav.

19.1 Scanning files with ClamAV

You can use ClamAV not only for scanning e-mail attachments, you can also use it to scan user files periodically. An example of a shell script (dubbed viruscan.sh) that does just that is shown below.


#!/bin/sh

# viruscan.sh -- Do scan /tmp and /home/userdata for virusses
# 2004-10-29/Peter Fokker
#
QUARANTAINE="/var/lib/clamscan"
LOG_SCAN="/var/log/clamav/clamscan.log"
TMP_SCAN="$LOG_SCAN-$$"
if [ ! -f ${LOG_SCAN} ]; then
    touch $LOG_SCAN
    chmod 640 $LOG_SCAN
    chown root:root $LOG_SCAN
fi

/bin/mkdir -p $QUARANTAINE 
/bin/chmod 700 $QUARANTAINE
/bin/chown root:root $QUARANTAINE
/bin/sleep 30

/usr/bin/clamscan \
	--database=/var/lib/clamav \
	--stdout \
	--log=$LOG_SCAN \
	--recursive \
	--infected \
	--move=$QUARANTAINE \
	/tmp /home/userdata >"$TMP_SCAN"
RETVAL="$?"

if [ "$RETVAL" == "0" ]; then
  SUBJECT="[`/bin/hostname | /bin/cut -f1 -d.`] clamscan `/bin/date +%Y-%m-%d`: OK"
elif [ "$RETVAL" == "1" ]; then
  SUBJECT="[`/bin/hostname | /bin/cut -f1 -d.`] clamscan `/bin/date +%Y-%m-%d`: VIRUS DETECTED"
else
  SUBJECT="[`/bin/hostname | /bin/cut -f1 -d.`] clamscan `/bin/date +%Y-%m-%d`: FAILED ($RETVAL)"
fi

/bin/mail <"$TMP_SCAN" -s "$SUBJECT" root
cat "$TMP_SCAN" | /usr/bin/logger -t clamscan
rm "$TMP_SCAN"

This script uses /usr/bin/clamscan to scan both /tmp and /home/userdata. If an infected file is found, it is moved to /var/lib/clamscan so you can inspect the file if you want. The results of the scan are sent to root in an e-mail message. An example of such a message is shown below.


To: root@praeceptor.exemplum.serveratschool.net
Subject: [praeceptor] clamscan 2005-08-06: OK
Message-Id: <E1E1EJk-0001kE-Mq@praeceptor.exemplum.serveratschool.net>
From: root <root@praeceptor.exemplum.serveratschool.net>
Date: Sat, 06 Aug 2005 04:21:44 +0200


----------- SCAN SUMMARY -----------
Known viruses: 37769
Scanned directories: 11075
Scanned files: 27406
Infected files: 0
Data scanned: 5199.49 MB
I/O buffer size: 131072 bytes
Time: 1153.262 sec (19 m 13 s)

You could simply store the script in /etc/cron.daily/viruscan.sh in order to have it executed every day. However, if you want to make sure that you will be scanning with the latest virus definition files, you should arrange for this script to be executed after the automatic update freshclam has run. You can do this by performing the following steps.

Store the script viruscan.sh in a good place, e.g. /usr/sbin/viruscan.sh.
Change the permissions of the scipt to 0700 or even 0500.
Change the ownership of the script to 'root.root'.
Add the following line at the end of /etc/cron.daily/freshclam.cron:
/usr/sbin/viruscan.sh

The changed script freshclam.cron should now look as illustrated below (changes are emphasised):


#!/bin/sh

# Fix log file if needed.
LOG_FILE="/var/log/clamav/freshclam.log"
if [ ! -f ${LOG_FILE} ]; then
    touch $LOG_FILE
    chmod 644 $LOG_FILE
    chown mail:mail $LOG_FILE
fi

/usr/bin/freshclam \
    --quiet \
    --datadir=/var/lib/clamav \
    --log=$LOG_FILE \
    --log-verbose \
    --daemon-notify=/etc/clamd.conf

/usr/sbin/viruscan.sh

The effect is that first the freshclam.cron script will run /usr/bin/freshclam, the workhorse program that fetches the new virus definitions. Once that is done, the viruscan.sh is run, using the updated virus definitions.

If you wish, you may want to verify the correct operation of the virus scanner by creating a special 'test virus'. There is a standard test, developed explicitly for testing antivirus programs. It was developed by the European Institute for Computer Anti-Virus Research (EICAR). You can easily create this test using any text editor. The test file consists of 68 plain ASCII characters as shown below. Note that the 3rd character is a capital 'O' and not the digit '0'.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

If you store these 68 characters in a file called EICAR.COM, say in the directory /tmp the viruscan.sh script should correctly identify it. More information can be found on the EICAR web site at http://www.eicar.org/anti_virus_test_file.htm.

Note that this EICAR.COM file in itself is a valid but harmless DOS program. When executed (in a DOS box), it simply displays the text 'EICAR-STANDARD-ANTIVIRUS-TEST-FILE!', nothing more.

(top)

20. CUPS

CUPS provides a portable printing layer for UNIX-based operating systems. It is developed and maintained by Easy Software Products to promote a standard printing solution and is the standard printing system in MacOS X and most Linux distributions. CUPS uses the Internet Printing Protocol (IPP) as the basis for managing print jobs and queues and adds network printer browsing and PostScript Printer Description (PPD)-based printing options to support real-world printing. The home page of the project can be found at http://www.cups.org.

There are different ways in which a printer can be accessed.

Printer with its own network interface (and built-in print server) connected directly to the LAN
Parallel or USB/serial printer connected to a workstation somewhere in the LAN
Parallel or USB/serial printer connected directly to the server
Parallel or USB/serial printer connected to an external print server

In the next two sections we will discuss the first two alternatives.

The third option is not discussed because using a parallel or serial printer connected directly to the server is not a very flexible solution, in that the printer has to be located close to the server. It is doubtful that there is sufficient room in the broom closet to accommodate the printer.

The fourth option is more or less the same as the first one. The only difference is that the print server may use a port number other than 9100.

NOTICE: There are more ways to connect a printer but an in-depth treatment is beyond the scope of this guide.

20.1 Setting up a JetDirect network printer with CUPS

Even though the CUPS subsystem is very complex, it sometimes is not too hard to get it to work. If you want to set up an HP Laserjet printer with network interface and a standard built-in JetDirect print server as a PostScript printer, you will need to take the following steps.

Create the printer queue with lpadmin(8) as follows:
lpadmin -p laserjet -v socket://172.17.2.11:9100
This assumes that your printer has IP address 172.17.2.11. When you give this command, the printer queue 'laserjet' will be created. Details are configured automatically in /etc/cups/printers.conf.
Open the firewall for the relevant port (in this case port 9100). See section 16.1 Firewall customisation for an example of opening the firewall for this port.
Enable the printer queue by giving the following command:
lpadmin -p laserjet -E
The -E switch used here is equivalent to the following combination of commands: accept(8) and enable(8). See also the manual pages (start with man lpadmin).

At this point the print queue laserprinter has been created and is ready to be used. It can subsequently be used to print documents from the server using the lpr(1)) command. You can also access this printer queue from the network using Samba, see section 20.3 Configuring Samba printing beiow.

NOTICE: The standard HP JetDirect port is 9100 for a single-port printer server. Check the documentation of your print server if you have an external model with 2 or more ports or if your print server is a different make.

This easy recipe works for a printer that understands the PostScript page description language. If you have a printer that uses another language, e.g. an Epson printer, you need to specify the appropriate PPD file, as shown below.


lpadmin -p epson -m epson9.ppd.gz -v socket://172.17.2.12:10000

Note that in this example the printer also uses a different port (10000 rather than 9100). You would have to open the firewall for this port at the IP address 172.17.2.12. Consult the printer documentation for more information.

NOTICE: The most commonly used PPD files are already installed on the server, in the directory /usr/share/cups/model. You may also find a suitable PPD file on the driver CD that comes with the printer.

20.2 Setting up a shared printer via SMB

It is also possible to print from the server to a printer that is shared on a client computer in the LAN, using the SMB protocol. This is a little more complicated than the previous example.

The example below assumes that an HP Deskjet 930C is connected to the parallel port of computer C34 (IP address 172.17.2.34) which is running Windows. Furthermore it is assumed that the printer is configured on computer C34 (i.e. the appropriate driver is installed) and that the printer is shared with the network under the name HP930C. The following things have to be done.

If necessary, create a link to the smbspool(8) program for Cups with: ln -s /usr/bin/smbspool /usr/lib/cups/backend/smb.
Uncomment the line #application/octet-stream in /etc/cups/mime.types (around line 157) in order to enable 'raw' printing.
Uncomment the line #application/octet-stream application/vnd.cups-raw 0 - in /etc/cups/mime.convs (around line 114) in order to enable 'raw' printing.
Add the printer with lpadmin -p deskjet -E -v smb://c34/hp930c
Activate the printer with lpadmin -p deskjet -E

When you have done this, you can submit print jobs to the queue 'deskjet' in much the same way as you can for 'laserjet' and 'epson' in the previous example. You are in fact using the Windows workstation as a print server for this printer.

More information on the subject can be found in [Ts, Eckstein, Collier-Brown], chapter 10, Printing, section CUPS printers, page 332.

NOTICE: You can specify a line number on the command line when you start the editor and then the editor will place the cursor at the correct line after opening the file. Examples: nano +157 mime.types or vi +114 mime.convs.

20.3 Configuring Samba printing

At this point (in the example) you would have three print queues: a PostScript printer called 'laserjet', an Epson printer called 'epson', and a Deskjet printer (which is connected to the client computer C34 using that computer's parallel port) by the name of 'deskjet'.

The integration between Samba and Cups is fairly tight; you really do not have to do anything special to get it to work. If you restarted Samba with 'service smb restart', the print queues become visible over the network with Samba. After configuring the correct printer driver on the Windows client computer, you could use any of these queues for network printing. The exact procedure of configuring a Windows printer is beyond the scope of this guide. Hoewever, it might be useful to know that the print queues can be access (from Windows) using the network addresses \\SERVER\LASERJET, \\SERVER\EPSON, and \\SERVER\DESKJET, respectively.

NOTICE: Of course you can also let other Windows clients access the printer on computer C34 directly by using the network address \\C34\HP930C. The advantage of using CUPS in this case is that documents will be queued on the server and will print as soon the computer C34 is switched on. With a direct connection the computer that is trying to print will not succeed until C34 is switched on.

(top)

21. Flotsam and jetsam

At this point all the important services have been configured. There are some more applications and daemons and cron jobs that you may need or wish to configure. The sections below merely provide you with hints on where to look and what to check.

21.1 NTP

It is very useful to have the computer use the correct time. A simple and convenient way to keep the correct time is to let the server synchronise with a time server on the Internet. Your ISP probably provides this service, perhaps via a server called ntp.isp.net or time.isp.net or maybe simply by providing a dotted decimal IP address.

A default time server is already configured in /etc/ntp.conf but as a matter of courtesy, please change the IP address 195.83.132.135 of the preconfigured server to that of a time server near you. Do not forget to check if the firewall is opened for NTP (see section 16. GIPTables above), even though by default the firewall is opened for traffic originating on the server, as is illustrated below.


# ****************************************************************************
#                                                                            *
#                                    N T P                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_NTP="yes"

# ----------------------------------------------------------------------------
# NTP outgoing client request
#

# Interface 0 NTP outgoing client request

    INTERFACE0_NTP_CLIENT="yes"

    INTERFACE0_NTP_OUT_SRC_IPADDR[0]=$INTERFACE0_IPADDR
    INTERFACE0_NTP_OUT_DST_IPADDR[0]=$ANY_IPADDR

# Interface 1 NTP outgoing client request

    INTERFACE1_NTP_CLIENT="no"

    INTERFACE1_NTP_OUT_SRC_IPADDR[0]=$INTERFACE1_IPADDR
    INTERFACE1_NTP_OUT_DST_IPADDR[0]=$NETWORK1

# Network 1 NTP forwarded outgoing client request

    NETWORK1_NTP_CLIENT="no"

    NETWORK1_NTP_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_NTP_OUT_DST_IPADDR[0]=$ANY_IPADDR

If you changed the ntp.conf configuration file, you should restart the ntpd daemon with 'service ntpd restart'. If you changed the firewall configuration, you will need to restart the firewall too, with 'service giptables restart'.

See also chapter 26 NTP of [Mourani 2002].

NOTICE: by default the firewall does not allow clients on the LAN to access time servers at the Internet. Assuming that the clients are Windows workstations, the time on those machines will already be synchronised by means of the LOGON.BAT script, see section 12.2 Logon script and drive letters above.

21.2 Enabling Syslog for remote reception

If you really want to receive log messages over the network (from printers and other devices on the LAN), not only will you need to open the firewall (see section 16. GIPTables above), but you will also need to start the syslog daemons with remote reception. Take a look at the file /etc/sysconfig/syslog and add the switch -r to the variable SYSLOGD_OPTIONS. Do not forget to restart the syslog daemons with 'service syslog restart'. You can check the log files, e.g. with tail /var/log/messages, to see if it works. Look for a line reading

praeceptor syslogd 1.4.1: restart (remote
reception)

21.3 Managing privileges via sudo

Some users are more equal than others. Throughout this chapter we have used the account 'ffrint' as that of the main administrator. However, even with all the configuration that took place and all the privileges that were granted, ffrint still is not allowed to escalate privileges to those of 'root'. That means that ffrint is able to log in remotely via SSH, but is not allowed to become root. And (if you configured SSH correctly), you cannot log in directly as 'root' via SSH. This deadlock can be resolved by allowing the account 'ffrint' to use sudo(8) to execute a root shell.

The way to do this is to edit the file /etc/sudoers. You could add 'ffrint' to the comma-delimited list of FULLTIME_USERS. Unless you know exactly what you are doing, you should edit this file using the visudo(8) command.

NOTICE: You may want to remove the default list in FULLTIME_USERS and replace it with just the name 'ffrint'.

NOTICE: If you are not comfortable with vi(1), you may want to set the environment variable EDITOR to nano before you start visudo. If you do so, nano(1) will be used to do the actual editing rather than vi(1). You may even want to add the line export EDITOR=/bin/nano to your startup script, .bashrc.

After you have promoted 'ffrint' to be a 'Sudo-er', this account can be used to escalate privileges. The first time, however, a warning message will be displayed to make the user aware that this privilege brings a lot of power; you can basically do anything on the system, see any file, remove anything. This can be quite a responsibility. The image below shows what you see when you use sudo(8) for the first time (assuming a connection via SSH from home).


[freddy@home freddy]$ ssh ffrint@praeceptor.exemplum.serveratschool.net
ffrint@praeceptor.exemplum.serveratschool.net's password:
Last login: Fri Jul 29 16:25:27 2005
[ffrint@praeceptor ffrint]$ sudo -s
 
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:
 
        #1) Respect the privacy of others.
        #2) Think before you type.
 
Password:
[root@praeceptor ffrint]# _

NOTICE: You need to know two passwords to become root this way. In the first place, you need to know your own password to log into the regular account. Then, when prompted by sudo(1), you need to enter the root password.

See also [Mourani 2002], chapter 17, Sudo.

21.4 Switching off tpop3d

By default a POP3 server is enabled. If you do not wish to serve mail via POP3, you should switch it off. You can do this for now with 'service tpop3d stop'. You can make the change permanent by issuing the command chkconfig --level 345 tpop3d off.

If you do wish to use the POP3 server, you should also open the firewall for POP3 by editing the relevant section in /etc/giptables.conf and restarting the firewall with 'service giptables restart'. The snippet below illustrates the default settings for POP3 in the firewall. The lines of interest are shown emphasised.


# ****************************************************************************
#                                                                            *
#                                  P O P 3                                   *
#                                                                            *
# ****************************************************************************

    ACCEPT_POP3="no"

# ----------------------------------------------------------------------------
# POP3 outgoing client request
#

# Network 1 POP3 forwarded outgoing client request

    NETWORK1_POP3_CLIENT="yes"

    NETWORK1_POP3_OUT_SRC_IPADDR[0]=$NETWORK1
    NETWORK1_POP3_OUT_DST_IPADDR[0]=$ANY_IPADDR

# ----------------------------------------------------------------------------
# POP3 incoming client request
#

# Interface 0 POP3 incoming client request

    INTERFACE0_POP3_SERVER="no"

    INTERFACE0_POP3_IN_SRC_IPADDR[0]=$ANY_IPADDR
    INTERFACE0_POP3_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

# Interface 1 POP3 incoming client request

    INTERFACE1_POP3_SERVER="no"

    INTERFACE1_POP3_IN_SRC_IPADDR[0]=$NETWORK1
    INTERFACE1_POP3_IN_DST_IPADDR[0]=$INTERFACE0_IPADDR

    INTERFACE1_POP3_IN_SRC_IPADDR[1]=$NETWORK1
    INTERFACE1_POP3_IN_DST_IPADDR[1]=$INTERFACE1_IPADDR

Explanation:

ACCEPT_POP3="no"
By default the POP3 module is disabled. It needs to be enabled (set to 'yes') before POP3 traffic can be allowed.
NETWORK1_POP3_CLIENT="yes"
If the module is enabled, traffic from the LAN to the outside world (i.e. POP3-boxes outside the LAN) can be accessed. Set this parameter to 'no' to disable the module.
INTERFACE0_POP3_SERVER="no"
Access to the POP3 server at school is not allowed. Set this parameter to 'yes' if you want to allow POP3 access to your server from the Internet.
INTERFACE1_POP3_SERVER="no"
Access to the POP3 server is also not allowed from the LAN. Set this parameter to 'yes' if you want to enable client computers on the LAN to use the POP3 server.

21.5 Autoupdate

By default autoupdate(8) is installed. This tool can be used to automatically download and install newer versions of software in .RPM-format. Configuration of this tool is done via /etc/autoupdate.d/autoupdate.conf. There is a manual page with more information.

It can be convenient to have the latest and greatest installed automatically and unattended. However, you may run into trouble if an update backfires and leaves the system in an inconsistent and/or inaccessable state.

A nice compromise is to have autoupdate download new RPMs but without actually updating them. In order for it to do so, you have to set the line DoUpdate=1 to DoUpdate=0 in the configuration file. Now autoupdate(8) will still check for new RPMs (via /etc/cron.daily/autoupdate.cron), and it will also download them (to /var/spool/autoupdate), but it will not perform the actual update.

If you decide to upgrade an RPM package, you should use rpm(8). There are many, many options that can be used with rpm(8), see the manual page for an overview. However, only a few options are essential, namely -i to install packages, -U to update packages, and -e to erase (remove) packages. Other useful options are -v for verbose messages, and -h to show hashes '#' to indicate progress during installation.

The illustration below shows how to upgrade a package using rpm(8). We use unzip as an example.


[root@praeceptor root]# rpm -Uvh /var/spool/autoupdate/unzip-5.52-1.i686.rpm
Preparing...                ########################################### [100%]
   1:unzip                  ########################################### [100%]
[root@praeceptor root]# _

If you wanted to install a completely new package, say the eject package, you would use something like rpm -ivh eject-0.99-1.i686.rpm.

NOTICE: If you tried to update a package with -U and the package was not already installed, rpm(8) is forgiving enough to continue anyway, pretending you said -i.

21.6 Adding a pause to read boot messages

Whenever the server starts up, a lot of services are started and a lot of messages flash by, much too fast to read everything. Usually these messages tell you that everything went fine by displaying a green OK. Sometimes, however, something goes wrong. This is usually indicated via a red FAILED. In those cases it would be helpful to have at least a little time to actually read the messages on the screen. You can achieve this by adding the following snippet to the end of the file /etc/rc.d/rc.local.


for t in 9 8 7 6 5 4 3 2 1 0; do
  echo -ne "\rReady for takeoff in $t seconds... "
  /bin/sleep 1
done

This displays a countdown before the screen is cleared and the login: prompt appears.

21.7 Miscellaneous goodies

During installation time a few 'goodies' were installed in /home/share/install/goodies. Some of them may come in handy when using client computers running MS Windows (e.g. QRes (qres-setup1090.exe) and WinSCP (winscp376setup.exe)), others can be used on the server (bash_profile, SopPasswd-0.1.tar.gz). You will also find copies of images (floppy disk or CD) for ghost for unix (g4u) and Autoclave.

21.8 Hourly backup and yearly maintenance

ServerAtSchool uses bu(1) to create hourly backups of all files in the directory tree /home/userdata/home/, which holds nearly all the user home directories, to /home/userdata/backhome/. The bu(1) program should be configured using the configuration files in /etc/janitor/ (see also section 10.2 Other configuration files above). The actual hourly backup (Monday to Friday, from 08.00 to 18.00 hours) of all user data is done by means of a cronjob, /etc/cron.hourly/janitor-bu.cron.

Because the hourly backup also keeps previous versions of files, the directory tree holding the backups will eventually grow to fill all the available disk space. Therefore it is essential for this tree of backup files to be cleaned up periodically. A good time of year to remove superfluous hourly backup files would be directly after all the pupil accounts have been promoted to the next grade and before the new school year begins. The net effect will be that users have backup copies of every version of documents created in the new school year, while at the same time they will have a backup copy of the last version of each document created in the previous school year.

A more or less safe way of cleaning up the hourly backup tree is illustrated below. Your input is shown emphasised. Note that you need to become root to perform this action.


[root@praeceptor root]# cd /home/userdata/backhome 
[root@praeceptor backhome]# pwd
/home/userdata/backhome
[root@praeceptor backhome]# rm -r *
[root@praeceptor backhome]# _

Note that rm(1) can be very destructive, especially if the wrong directory tree is deleted. The more or less safe way to perform this action is:

Change to the top of the directory tree that must be deleted with cd(1).
Check the current working directory (with pwd(1)) to verify that you made no error in the previous step.
Actually delete all the subdirectories of the current directory with rm -r *.

Once the directory tree under /home/userdata/backhome/ is deleted, it takes at most 1 hour (Monday to Friday, between 08:00 and 18:00 hours) for another, fresh hourly backup to be created of all the files under /home/userdata/home.

If empty disk space on the /home partition is running low, you may want to consider emptying the directory tree under /home/userdata/backhome/ more often than once a year.

21.9 Your server is ready

At this point all the necessary configuration work has been completed. All the relevant services have been enabled, any irrelevant services have been disabled, the firewall has been tuned, backups have been taken care of, etcetera, etcetera. In other words you're done.

The next step is to plug in the network cable of the external connection (see the notice in section 2. Basics at the beginning of this chapter). If is now safe to do so because configuration of the server is now complete.

NOTICE: At this point it is highly recommended to shut down the server, using /sbin/shutdown -h now. There should be no problem whatsoever at this stage; shutdown should be clean. When is done, you may even want to switch off the computer entirely before restarting it. This is the ultimate test of your hard work. All services should now start without errors (at this point you should see only green OK's) and everything should then be working the way it should.
The reason for doing this is to identify potential problems. Suppose that during installation you switched on a service 'foobar' manually, e.g. with 'service foobar start'. If you forgot to add this change permanently with chkconfig(8), the service will fail to start automatically. Now is a good time to find out about this mistake. If you leave the server on after installation, you could have a hard time figuring out why the foobar service 'suddenly' stopped working (and it may be many months from now before you find out).

At this point you have completed the configuration of your own rock-solid, industrial strength, secure server at school.

The next steps you could take might be:

Adding user accounts using Janitor.
Installing and configuring client computers and creating an image with g4u.
Installing educational software on the client computers.
Reading Appendix A of [Mourani 2002] for more things to tweak.

All these activities are beyond the scope of this ServerAtSchool Installation Guide. You may want to continue with the ServerAtSchool User Manual now.

(top)

Prev	Home	Next
IV. Installing optional ServerAtSchool components		Appendix A. Manual disk partitioning

Author: Peter Fokker <peter (at) berestijn.nl>

$Id: configuring.html,v 1.61 2006/04/06 21:06:45 peter Exp $

Contents