Ubuntu Jaunty Base Server Build

This guide has been superseded by Ubuntu Lucid VPS Base Build

This is a guide to the basic setup of a VPS on Ubuntu Server 9.04 (Jaunty). The aim is to provide a basic build that is secure for living out on the internet, has a basic web server stack (i.e. LAMP: Apache HTTP Server, MySql, PHP) and any other useful utilities. Future posts will rely on this build when covering additional application installations.

The VPS provider I chose was CheapVPS.

Base install

The initial image I was given was Ubuntu Server 9.04 with root being the only interactive user (i.e. able to log on). ssh was available using passwords. Apache2 and PHP packages were installed in addition to the essentials. The following commands can be run to provide information about the installation, which may be of use when asking for help on forums:

nuser -a
lsb_release -a

Getting up-to-date

Ubuntu uses apt as its default package manager. Run the following commands to upgrade the installed packages to the latest version.

apt-get update
apt-get upgrade
apt-get dist-upgrade

For more information visit the Ubuntu Community Documentation AptGet HowTo

apt has the concept of manually installed packages. A manually installed package is one which is passed to the apt-get install command. These packages are assumed to be required and will not be marked as unused dependency for commands such as apt-get autoremove. It would be nice if there were a command to see the list of manually installed packages (excluding the essential packages), however, as this discussion explains, there isn’t one that works as expected.

Keeping an eye on utilisation

Disk space can be checked using df. Memory usage can be checked using free.

Additional util packages

The following packages are also useful to have installed, so run the following command:

apt-get install nano

Configure hostname

The hostname is set using the hostname command and updating entries in /etc/hosts.

To set the hostname:

hostname servername.domainname

Update /etc/hosts with DNS entries and aliases like the following:

127.0.0.1 localhost.localdomain localhost
127.0.1.1 servername.domainname alias.domainname

The following commands should respond suitably:

uname -n
hostname -a
hostname -s
hostname -d
hostname -f
hostname

I also had to create the /etc/hostname file:

echo servername.domainname > /etc/hostname

Correcting the server time

Depending on the image used, the server may be in the wrong timezone. Run the following commands to reconfigure and utilise NTP to sync the clock:

dpkg-reconfigure tzdata
apt-get install ntpdate

Note that it may require a change by the VPS provider to fix the host machines clock if the time is still incorrect but the server is in the correct timezone.

For more information visit the Ubuntu Community Time documentation.

Sudoers

Sudoers controls who can run what commands as which users on which machines. The standard Ubuntu installation does not expose the root user, instead you create an admin user during the installation and can execute commands. The VPS image did not conform to this and had root access available with no additional users. Therefore, it is good practice to create an administrator with the appropriate permissions and use sudo as required.

Run the following command to add a user:

adduser <username>

Add the user to additional groups as required, e.g.:

usermod -a -G sudo,adm,www-data <username>

Modify /etc/sudoers to allow a given user root privileges using visudo:

visudo

Adding the following entry:

<username> ALL=(ALL) ALL

For more information visit the Ubuntu Community Documentation Sudoers Guide.

Email forwarding

Email is used as a primary notification mechanism for linux, however, by default, email is stored on the server. If you do not intend to set the server up as an email server (e.g. POP3 or IMAP), it is useful to forward email to an appropriate external email address. There are two main approaches to this (with sendmail which is the default MTA):

  1. root maintains email addresses in /etc/aliases
  2. each user maintains their email address in ~/.forward

It is possible to also combined the two approaches, by aliasing root to a given user and then the user being able to allocate the email address as they see fit.

This is covered in the man pages for aliases:

man aliases

Modifying aliases

e.g. alias root to another user, edit /etc/aliases, adding:

root:           <otheruser>

e.g. alias root to external email addresses (comma separated), edit /etc/aliases, adding:

root:           user1@example.com, user2@example.com

Note: after modifying /etc/aliases you must run newaliases to refresh the alias database for the changes to take affect, e.g.:

sudo newaliases

Creating .forward

The simplest way to do this is to log in as the user required and run the following command (replacing the email address as appropriate):

echo username@example.com > ~/.forward

Secure Shell (SSH)

Secure shell (ssh) is the defacto standard for remote shell access.

Client

You can connect to a remote machine using the following command:

ssh username@hostname

You will usually be prompted for your password.

Rather than using a password you can use key based authentication. On your client machine, create a key and use a string pass phrase:

ssh-keygen -v -t rsa

This will create a ~/.ssh directory containing id_rsa which is your private key and id_rsa.pub which is your public key. Its important to have the correct permissions, so check the output of ls -la ~/.ssh is similar for the following entries:

drwx------   5 user  group   170 22 Mar 07:04 .
-rwx------   1 user  group  1743 22 Mar 07:04 id_rsa
-rwxr--r--   1 user  group   397 22 Mar 07:04 id_rsa.pub

You can copy you public key up to a server using the following command:

scp ~/.ssh/id_rsa.pub username@hostname:~/.ssh/authorized_keys

You should now be able to ssh to the server without being challenged for a password, e.g:

ssh username@hostname

Depending on the client and your preference, you can either enter the passphrase for you private key each time you connect, or run ssh-agent and register the key using ssh-add.

Server

sshd is the ssh daemon and is responsible for providing ssh access to the server. Its important to ensure that this is secure as possible. There are a number of articles out there about changing the configuration of sshd to make it more secure, in particular I like to turn off password authentication (forcing the use of public/private key pairs) and disable root login. Of course, you should ensure that you have a suitable user able to log in using a key that you have tested before you lock yourself out permanently.

The configuration for sshd is found at /etc/ssh/sshd_config. Modify it to have the following lines:

PasswordAuthentication no
PermitRootLogin no

Restart sshd for your changes to take effect:

sudo /etc/init.d/ssh restart

Basic web server stack

The basic stack of Apache HTTP Server (A), MySQL (M) and PHP (P) is known as AMP due to the initials, or LAMP on Linux.

Apache HTTP Server and PHP were already installed and available on the VPS, however, you can make sure by running the following:

sudo apt-get install apache2 php5

As part of the MySQL installation, I like to install phpMyAdmin as this is a really useful admin application. Install mysql server and phpMyAdmin packages, entering suitable values when prompted:

sudo apt-get install mysql-server phpMyAdmin

To enable phpMyAdmin, symlink the apache conf as a site and enable it:

sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/sites-available/phpmyadmin
sudo a2ensite phpmyadmin
sudo /etc/init.d/apache2 reload

Check connectivity by accessing the site using http://servername/phpmyadmin.

Note that phpmyadmin could be used by hackers to brute force attack your databases. As always, you should use suitably strong passwords to ensure that this is not easily done, and also use suitable permissions for the database users to minimise external access. I also tend to disable the site (using the a2dissite command) when its not in active use.

Issues

opening /dev/null failed (Permission denied)

This is mentioned in 63031

After a reboot the permissions on /dev/null are incorrect:

ls -l /dev/null
crw------- 1 root root 1, 3 Sep  5 14:26 /dev/null

This can be fixed by running the following:

sudo rm /dev/null
sudo mknod -m 0666 /dev/null c 1 3

Comments

blog comments powered by Disqus
Fork me on GitHub