NTP - updating server time

Network Time Protocol (NTP) is a protocol used to sychronise a computer's system clock. To ensure your server maintains the correct time, it is a good idea to set up cron job to update you time settings nightly using ntpdate.

To do this, first check to see whether NTP is installed. On a Red Hat system you can do this by running:

rpm -qa | grep ntpdate

On a Debian/Ubuntu system you would run:

dpkg -l | grep ntpdate

If it's not installed, you can install it using your distro's package manager. On Red Hat systems run:

yum install ntpdate

On Debian/Ubuntu systems run:

apt-get install ntpdate

You can then test it works by running:

ntpdate -q uk.pool.ntp.org

The -q switch runs ntpdate in query mode, causing it to report what changes would be made, but making no actual changes. The example shown runs the query against the UK NTP server pool. Different countries have different pools, e.g. de.pool.ntp.org for Germany, fr.pool.ntp.org for France, etc.

Next, we need to set up the cron job. First type:

crontab -e

This will open the crontab program in editing mode. Press 'i' to enter insert mode and type:

0 2 * * * /usr/sbin/ntpdate -s uk.pool.ntp.org

Then save and exit.

This will update the server time at 2am every morning, from NTP servers in the UK pool. The -s switch diverts any output to the normal system logs.

Note: remember to restart cron after editing crontab using: /etc/init.d/cron restart

ProFTP fixes

Here are a couple of fixes to some common ProFTP problems.

*** Cannot view .htaccess files

First, make sure your FTP client is actually set to view hidden files. If it is, and you still can't see any of your .htaccess files using an FTP connection, try the following:

Open the main ProFTP config file:

vi /etc/proftpd.conf

And look for the 'ListOptions' directive. If it doesn't exist, add the following:


ListOptions "-la"


Then save the changes and restart the proftpd daemon.

This will make all hidden files - i.e., file preceded by a '.' - viewable in long-format. The global tags apply the changes server-wide.

*** Timestamp shown on files is wrong

If the timestamp on the files appears to be an hour or so out, ProFTP might not be using the correct timezone. To change the time, open proftpd.conf and add the following:


SetEnv TZ BST


In this example, the SetnEnv directive sets ProFTP to use British Summer Time, but you can use any valid timezone abbreviation, as required, e.g. GMT, CEST, etc.

Updating SpamAssassin

SpamAssassin is a popular anti-spam program, that uses content-matching rules to scan email and filter out potential spam. For it to remain effective, it's best to make sure you're running the latest version, and that the rule definitions are updated regularly.

The current version, at time of writing, is 3.3.1 - assuming you're running an older version, let's look at how you would update it:

Note: This example assumes a 64-bit rpm based operating system (i.e. Red Hat or CentOS). If you're running Debian, or a 32-bit OS, please consult the official SpamAssassin website and adjust the instructions accordingly.

First, check which version of SpamAssassin is currently installed by running:

rpm -qa | grep spamassassin

Next, backup the main config file and directories. It's unlikely there will be any problems, but it's always best to make backups before upgrading - just in case...

Make a backup of local.cf and tar up a copy of the spamassassin directory by running:

cp -p /etc/mail/spamassassin/local.cf /etc/mail/spamassassin/BAK-local.cf
cd /usr/share
tar czvf BAK-spamassassin.tar.gz spamassassin/

Once this is done, download the latest tarball into the /usr/src directory:

cd /usr/src
wget http://www.mirrorservice.org/sites/ftp.apache.org//spamassassin/source/Mail-SpamAssassin-3.3.1.tar.gz

You can then use the tarball to build the installation rpms by running:

rpmbuild -tb Mail-SpamAssassin-3.3.1.tar.gz

This will create two rpm files in /usr/src/redhat/RPMS/x86_64/, which can be installed by running:

cd /usr/src/redhat/RPMS/x86_64/
rpm -Uvh perl-Mail-SpamAssassin-3.3.1-1.x86_64.rpm spamassassin-3.3.1-1.x86_64.rpm

Note: Remember to choose the correct path and rpm's for your build. The 64-bit ones are shown in the example.

The new version of SpamAssassin is now installed. Next, you need to update the rules by downloading and unpacking the latest ruleset:

cd /usr/share/spamassassin
wget http://mirror.ox.ac.uk/sites/rsync.apache.org//spamassassin/source/Mail-SpamAssassin-rules-3.3.1.r923114.tgz
tar -xzvf Mail-SpamAssassin-rules-3.3.1.r923114.tgz

This will unpack the new rules into the /usr/share/spamassassin directory.

Next run the SpamAssassin update tool - sa-update - to make sure everything is completely up-to-date. It's often useful to run it with the -D switch (debug mode), as this will display a list of everything that it's updating:

sa-update -D

The updates will be uploaded into the /usr/share/spamassassin/ directory. This directory includes a config file that contains 'Includes' for these new rules, which can be viewed by running:

less /var/lib/spamassassin//updates_spamassassin_org.cf

Next, stop sendmail, or MailScanner (if installed), and make sure that no processes are running before attempting a restart - using 'killall sendmail', if necessary. Then restart sendmail/MailScanner and tail your maillogs to make sure there are no errors.

To make sure the rules are update regularly, you can setup a cronjob to run sa-update each night. Here's an example of what you might add:

0 3 * * * /usr/bin/sa-update &> /dev/null; /etc/init.d/spamd restart

This will run sa-update at 3am every morning, piping any output produced to dev/null, and then restart spamd (the SpamAssassin daemon) to load the new rules.

For more information see: http://spamassassin.apache.org