Basic installation of a Linux server

We would like here not to explain in details how to install a Linux server from scratch, but useful tips to customize the installation once the base OS is installed.
Nowadays, installing Linux has became very straight forward, the modern installers just ask you to click next and you're on the go !

SE Linux

SE Linux is a security enhancement above the usual Linux permissions which gives administrators and users more granular controls over access control. It implements what is called "Mandatory Access Control", in regards with the standard security model which is called "Discretionary Access Control". More info about this system on the official site of the SE Linux project. When activated but left unconfigured, this enhanced security layer may let some software to not function properly on you box. For instance, despite correct Linux permissions and users & groups rights on files, Apache may be unable to read some file or execute PHP code for instance. So, to avoid loosing time or bad side effects, start by disabling it if you're sure you don't require it.

If you missed the setting during installation, you can manually deactivate it in the file /etc/selinux/config on RedHat / CentOS / Ubuntu / Debian
In this file, by putting the following parameters :
SELINUX=disabled

you will deactivate completely SElinux at next reboot.

To check if SELinux is enabled or not on your box, do the following (as root) :

# selinuxenabled
# echo $?
1

The return result of the selinuxenabled command will be 1 if SELinux is disabled, 0 if it is enabled. If the selinuxenabled command is not installed, you can have it by installing selinux-utils on Debian / Ubuntu or libselinux-utils on RedHat / CentOS (but due to the way this package is needed by other base packages, it is unlikely that it is not installed).

On Ubuntu / Debian, you can remove completely the SELinux layer, but not on RedHat / CentOS (version 6 at least) due to the way these packages are required by some base packages.
To remove on Ubuntu / Debian :

> sudo apt-get purge selinux-basics selinux-policy-default selinux-utils
> sudo apt-get --purge autoremove

Cron or Anacron ?

Sometimes, both or only one of them is installed. To avoid strange behaviour with your programmed tasks, here a small recap :
  1. crond (also known as vixie-cron) runs jobs at the time given. If the machine was off during the time the job was programmed, the job won't be run. Therefore, on a "always on" server, this is the recommanded option.
  2. anacron (also know as asynchronous cron) runs jobs at almost the given time (anacron may decide to run jobs in XX minutes upon starting - usually this is needed to let the rest of the processes initialize completely in case we are just booting our system) but also check when starting if some jobs programmed during the off time need to be run. Therefore, on a PC / laptop, this is the recommended solution.
On RedHat / CentOS version 6:
# yum install cronie cronie-noanacron
# yum remove cronie-anacron

You can then adjust the time at which daily, weekly and monthly jobs are run in /etc/cron.d/dailyjobs
On Debian / Ubuntu :

# apt-get install cron
# apt-get purge anacron

Yes, one remark, as some other packages needs a cron system installed, you have first to install the new cron you want, then remove the old one.

Keeping an eye on your logs

As system administrator, we have to keep an open eye on the logs of our systems. To help you with this task, there is one nice program called logwatch. This is a PERL script which allows you to analyze your logs at recurring interval to detect anomalies in them. Logwatch by default comes with a very exhaustive collection of "parser" supporting merely all system and application logs of your box, independantly of the distribution - usually from distribution to distribution, the name of logs change, etc.
This tool if run once a day from crontab, will analyse you logs, generate a report that can be mailed to you. By default, it will look into all your syslog generated logs, returning information such :

  • login, failed and succeed
  • iptables messages summarized by source (of course, you need to have rules logging to the syslog in your iptables chain)
  • disk usage
  • any error or warning message that he found
  • mail server summary (quantity of mails sent and received, amount of bytes transferred through the mail server, ...)
  • return codes and URL generating them in your web server logs
  • packages installed and removed
  • users and groups created and removed
  • and many more
Look in /usr/share/logwatch/default.conf/services to have an idea of which services are supported in your installation.
As the program performs "string matching" using PERL regex, it is very straight forward to add new parser to the installed instance. Use /etc/logwatch/conf/services for this.
Under /etc/logwatch/conf you can put a logwatch.conf file that will hold your specific parameters, overwritting the default one present in the script itself or in the cron launcher. Use it to overwrite the type of report (html instead of text for instance) or to specifiy mail source and destination, like in this exemple :
MailTo = user@domain.com
MailFrom = logwatch@my-domain.com

Alongside the "services" directory, you will found the "logfiles" directory, it contains definition to tell logwatch where the log file(s) for a given service is (are) located and how it is (they are) called. In the next exemple, the configuration file tells logwatch which is the error log of the MySQL daemon (the uncompressed log(s), and also the archived one (the compressed logs) :

LogFile = /var/log/mysql/error.log
Archive = /var/log/mysql/error.log.*.gz

Simple send mail agent

Another thing of importance, is to configure your newly installed machine to let her sent mail from various script and programs. If you think that to achieve this you will need to install a full blow mail server like Postfix or Sendmail, you're wrong.
In fact you can use the Simple SMTP (ssmtp) program to achieve this. The package for ssmtp can be found in the EPEL repository for RedHat / CentOS (RPM) or in the default Ubuntu repository for Ubuntu and its derivative.
When installing this package, the package manager will remove any other installed mail server.
The configuration is done in the /etc/ssmtp/ssmtp.conf file :

root=someuser@mydomain.org
mailhub=smtp.mydomain.org
rewriteDomain=mydomain.org
hostname=myhost.mydomain.org
FromLineOverride=YES

In the above exemple, you will :

  1. Redirect mail sent to the root and all users with an ID less than 1000 to <someuser@mydomain.org>
  2. Use <smtp.mydomain.org> as a mail relay for your mails. Of course this server must be configured to accept mail from the machine where ssmtp is installed
  3. Rewrite the domain of the From field of all outgoing mail to @mydomain.org
  4. Overwrite the hostname of your server to <myhost.mydomain.org>. Not needed if you can use the default hostname of your server. This is the hostname that will be sent into the SMTP connection to the Mailhub
  5. Allow local user sending mail to override the From: field of the mail (so allow providing a specific From: address)
To send mail, there is a binary called sendmail installed by the package, but a more easy trick would be to use the command mail at the command line. This command can be installed by the bsd-mailx, mailutils, ... packages. An easy way to use it is the following :
$ echo "Some text here" | mail -s "My subject" username@domain.net

Attention

The command mail is a simple mail agent, who will just submit a mail to the SMTP server defined in the SSMTP config file. If this server accept the mail, this is this server that will handle all the retries in case of non-delivery at the first try. But if the mailhub is not responding or refusing mail directly at the connection, the mail won't be retried any more unless you implement retires in the scripts / programs submitting mail from your server.
If the mail command fails to sent mail, the message will be written in the $HOME/dead.letter file with a possible reason why the mail was not submitted.


Need more packages than in the default repository ?

I've always been satisfied with the software you get from the default Ubuntu repository, but when I'm running Red Hat / CentOS / Fedora distributions, I always add the following repositories, who bring quite a lot of numerous valuable packages :
  • EPEL (Extra Packages for Enterprise Linux), a sub-project of the Fedora project : EPEL home site to get the right install procedure for your distribution (basically you just have to download and install an RPM that will configure the package manager of your server)
  • RepoForge, a large collection of RPM (previously called RPMforge) : RepoForge home site to get the appropriate rpmforge-release package that will configure your server.