Mailhub Table Building

The mailhub tables should be rebuilt periodically to purge deleted aliases. The operation will typically take about 4 hours per mailhub and has a considerable impact on the performance of the X.500 server. Care should be taken to carry out the table rebuilds at suitable times to avoid too much impact on other operations e.g. student registrations. The instructions below should ensure the rebuilds happen as quickly as possible before resuming normal operations.

Restart the X.500 directory:

The X.500 directory process suffers from a memory leak so before starting the rebuild we need to ensure that it starts off with minimum memory usage. Perform the following operations as root on the X.500 server –

# /etc/rc2.d/S81eddy stop

This will shut down the main eddy directory process but leave the root process /opt/isode/sbin/isode.eddy -D /dirtables/root running. Once the main process has stopped find the process ID of the root process and kill it. Then restart the directory –

# /etc/rc2.d/S81eddy start

The registration client processes on the mailhubs should now be restarted. Run top on the X.500 server to monitor progress and restart the client on each of the mailhubs in turn using the command –

# systemctl start regclient

Wait until cpu idle returns to 90%+ before starting the client on the each mailhub in turn.

Now check that the openRA is still running on cvshost.qub.ac.uk and that the UNS and alias threads are running. The student thread will usually still be running in the qubRA process on the X.500 server. It is best to close down the thread whilst the table rebuild is running as sometimes large batches of delta files may be created that add significantly to the load on the server.

Start the table rebuild on the target mailhub:

First shut down the registration client on the mailhub –

# systemctl stop regclient

Now start the table rebuild as a background process –

# /home/exim/scripts/rebuild &

Now wait for around 4 hours until the job completes.

Tidying Up:

The memory leak in the directory process will mean that it has grown to 500Mb+ so the first thing to do is restart the directory according to the instructions above. Once the directory is running again start the registration clients on each of the mailhubs as above. Begin with mailhub that has just run the table build as that will take longer.

Now restart the student thread on the qubRA. You may need to start the qubRA process if it has crashed during the directory restart. Monitor cpu usage whilst the delta files are cleared down. This may take a while if significant numbers were created during the rebuild process.

Check the UNS and alias threads on the openRA on cvshost.qub.ac.uk and make sure the mailbox creation service is running on ex2k10-365a.ads.qub.ac.uk.

ClamAV on Mailhubs and SMTP Servers

ClamAV is used on the mailhubs and SMTP servers for content scanning of email messages. It is called via ACLs in the Exim configuration. The daemon is installed as a binary using yum. We also use additional unofficial signature definitions from SaneSecurity. The main files of interest are –

  • /var/clamav – directory containing signature definitions
  • /etc/clamd.d/scan.conf – main configuration file
  • /etc/freshclam.conf – signature update configuration
  • /etc/clamav-unofficial-sigs/master.conf – additional signatures

Configuration changes will require a restart of clamd using the command –

# systemctl restart clamd

Freshclam:

The main signature file is updated by the freshclam daemon according to the instructions in the /etc/freshclam.conf file. The daemon is set to use the default of checking for new signatures every two hours. The signature file is daily.cld located in the /var/clamav directory. There is also a main.cvd file that is no longer updated. It has been left in place as it does not seem to be causing any problems.

Unofficial Signatures:

The additional signatures are visible in the /var/clamav directory in various database formats. The ones to be used are defined in the file /etc/clamav-unofficial-sigs/master.conf. These should be reviewed frequently as some signatures become too aggressive. Check the signature listings at SaneSecurity. They list the signatures as low, medium or high risk of false positives. We only use low and medium risk signatures.

New signature files are checked for and downloaded hourly. This process is controlled by the clamav-unofficial-sigs and clamav-update scripts in /etc/cron.d.

Whitelisting:

Rules can be whitelisted by adding the definition to the file /var/clamav/local.ign2. This file is regularly rsync’d from mx1.qub.ac.uk to the other three mailhubs, so it only requires a single edit. The file on the SMTP servers needs to be updated separately.

Updates:

Updates to the Clam installation are made available via yum. Be cautious when updating Clam as changes may have been made to the configuration options. It is wise to update on one server and test before completing the others.