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

Contents