Debian Etch setup - page 2

Continuing from page 1 of the Debian Etch setup, we'll now configure the terminal to be more useful and readable and create some aliases so we don't repeat entering long commands.

Then we can configure the locale(s) and go ahead and update Debian to the latest secure software ready for the 'working' software such as web servers and so on.

OS check and Free

Let's confirm the Linux type and version:

cat /etc/issue

I hope you get something like this:

Debian GNU/Linux 4.0

If not, you're probably logged into the wrong VPS.....

We can start our server administration straight away by looking at the memory usage:

free -m

My test VPS has 256MB of memory and 'free -m' reports usage in MB as follows:

.                  total       used     free     shared    buffers     cached
Mem:           254         37        217          0           0              9
-/+ buffers/cache:       26        228
Swap:          511          0         511

Concentrate on the second line of the output and you'll see that I am actually using 26MB of RAM with 228MB free. The first line suggested I was already using 37MB but 9MB of that is in buffers and cached.


You'll notice the terminal is a little bland and is not very informative. Let's add some colour and let it tell us which Slice we are logged into and what directory we are in. It's actually quite easy to forget simple things like this if you have more than one or two Slices!

We'll do this by editing .bash_profile to fit our needs:

nano ~/.bash_profile

To add some colour to the terminal and to show who we are and where we are, add the following line at the end of the file:

export PS1='\[\033[0;35m\]\h\[\033[0;33m\] \w\[\033[00m\]: '

That will show the VPS name in purple and the working directory in brown.

Now we can add some aliases. An alias is simply a shortcut to a command or sequence of commands.

Some examples are:

alias free="free -m"

alias aptitude="sudo aptitude"
alias update="sudo aptitude update"
alias upgrade="sudo aptitude upgrade"
alias install="sudo aptitude install"
alias remove="sudo aptitude remove"

The first example gives the memory usage in MB whenever I enter 'free' and the rest are aliases involved with the aptitude command.

Feel free to change the alias names to something else and add and remove more as you see fit. You'll get into your own habits pretty quickly.

Once happy, save the file and to activate the changes enter:

source ~/.bash_profile

The terminal is more usable now the VPS name and current directory are shown.


Now we have some customisation completed, we need to update the software that's installed.

First thing is to update the sources.list. This is a file which contains a list of repositories from which to fetch software and updates.

Fire up your favourite text editor (I use nano) and open the sources.list file:

sudo nano /etc/apt/sources.list

The following list is installed by default:

deb etch main
deb-src etch main

deb etch/updates main contrib
deb-src etch/updates main contrib

Be wary of entering repositories which are not designed for servers as some repositories, whilst 'official' do not receive security updates. The list above will suffice for most servers.


Now we need to update the list of packages available to us:

sudo aptitude update

Remember that if you have set your .bash_profile as suggested above, you will not need to enter the full command. You will only need to enter the alias 'update'.

Good. Now we have an updated list of packages we can install.


Before we install anything else we need to configure the locales package:

sudo aptitude install locales

and then configure them:

sudo dpkg-reconfigure locales

During the configuration, simply select the locale(s) you want available on your VPS. In my case I selected 'en_GB.UTF-8 UTF-8'.


Now we can get down and install the latest security updates with a full upgrade command:

sudo aptitude upgrade
sudo aptitude dist-upgrade

Half way through the first command it will pause and ask if you want to set your timezone. It would be a good idea to set it here by following the terminal prompts. It's usually a good idea to select UTC as the server timezone (by entering '12' and then 'UTC').


You would have noticed that quite a few programmes were upgraded so now we need to reboot the Slice.

There's rarely any need to reboot a Linux based server but as we have changed quite a few base packages it's a good idea this time:

sudo shutdown -r now

The reboot should only take a few seconds (mine took around 10 seconds before I could log in again).

Now log back in to your VPS ready for the next stage of the Slice setup:

ssh -p 30000 demo@


Let's get started by installing screen. This is a great application that allows 'virtual' terminals to be opened in one console. Switching between them is done with the press of a key.

The advantages are that you can be working on more than one shell at a time, say one installing software and another monitoring network activity - all without having more than one physical shell open. If the SSH connection is cut for some reason or you have to leave the room then close the terminal and the work will still carry on in the background.

I highly recommend installing and getting used to using screen. This screen tutorial gives an excellent introduction.

sudo aptitude install screen

To start a screen session simply enter the command:


Press the space bar to remove the introduction page and to activate any custom bash_profile entries, enter:

source ~/.bash_profile

Build essentials

Most software requires libraries and compilers to work properly. As you would imagine, they (nearly) all share the same libraries and compilers. If they didn't it would be a bit messy really.

Debian provides what is known as 'meta-packages'. The meta-packages are a defined set of programmes for particular situations. One such set of packages include the 'essential' programmes described above such as shared libraries and compilers.

This is a nice time saver and ensures we don't forget anything. So go ahead and install the 'essentials':

sudo aptitude install build-essential

Have a look at what is going to be installed and, once you are happy with the build-essential package, click 'Y' to continue.


Quite a lot has happened here but now we have a secured slice.

The console is now informative and less drab and we can use the handy 'screen' tool.

The Debian sources have been updated, the slice upgraded and the meta-package build-essential has been installed.

If you do this more than once or twice it doesn't take long at all and we now have the ideal base to install the 'meat' of our server - whether the primary task is to serve web pages, act as a database server, be a file repository and so on.


Article Comments:

Petejan commented Tue Oct 02 17:28:28 UTC 2007:

I have problemb with the default locales and emacs, I can't write accents

PickledOnion commented Tue Oct 02 17:36:52 UTC 2007:


Sorry, I'm not sure what you are saying. What are you trying to do?


grazi commented Fri Nov 30 03:19:01 UTC 2007:

yeah, same problem here with (swiss)german locales... typing äöü etc. prints anything else but these...

Cameron commented Sat Dec 08 12:15:22 UTC 2007:

You would have noticed that quite a few programmes were upgraded so now we need to reboot the Slice.

Unless you're doing a kernel upgrade, there really is not a need to reboot the slice.

Birger J. Nordølum commented Wed Mar 05 00:52:39 UTC 2008:

~/.bash_profile is not in my slice. I am used to use ~/.bashrc.

Birger :)

Vincent De Baere commented Wed Mar 19 13:00:13 UTC 2008:

You may want to consider the fail2ban and logcheck packages to tighten your slice a little more.

fail2ban bans an IP after a configurable number of attempts has been done to connect to a service running on your slice.

logcheck will mail you anomalies it finds in your logs.

Quite usefull...

Jelloir commented Tue Apr 22 15:47:02 UTC 2008:

I use aptitude also and prefer it over apt-get however the default aptitude installs suggested and recommended packages by default which tends to cause unnecessary bloat.

Adding the following to ~/.aptitude/config prevents aptitude from doing this and keeps things lean.

Aptitude ""; Aptitude::Recommends-Important "false"; Aptitude::Suggests-Important "false";

Remember to "aptitude update" afterward.

Sam commented Tue Jun 17 18:29:04 UTC 2008:

So after a few times through trying to get a trac 0.11rc2 setup with svn1.4.6, swig1.3.35, python2.5.2, and other bleeding-edge gimmicks, I noticed a problem that I'm speculating might have to do with sudo aptitude install build-essential

Since all the Slicehost boxes are 64-bit (afaik), all sorts of icky things can crop up when building from source if you're using a 32-bit compiler. Now, because I don't really want to backup, rebuild, then restore my slice I'm not positive that installing build-essential is actually the cause (it may well just be this way by default), but I DO know that once it is installed, the gcc that gets priority in $PATH is NOT the 64-bit compiler that does so many smart things for building on our slices. The big red flag came when I was configuring Subversion, which complains in big letters that it's being compiled with gcc, whereas Apache (the build of it that comes on etch) was compiled with the x86_64 compiler. Instead, its symlinked to gcc-4.1. Simple enough to fix, but can cause some REAL headaches. Just:

sudo rm /usr/bin/gcc sudo ln -s /usr/bin/x86_64-linux-gnu-gcc /usr/bin/gcc

and watch the building-from-source headaches melt away :)

PS - note that the subversion compiler mismatch error will still pop up even after you've fixed the symlink, but as far as I can tell, it's no longer true/relevant.

Michael glass commented Thu Feb 26 03:29:52 UTC 2009:

is it just me or is dpkg-reconfigure gone in my new lenny install? Help?

Chris commented Thu Mar 05 03:19:44 UTC 2009:

Works okay for me, Michael.

Michael Glass commented Wed Mar 18 18:52:46 UTC 2009:

yeah. not in users path doesn't mean it doesn't exist. Thanks for following up chris

Daniel Ritchie commented Sun Jun 14 10:50:04 UTC 2009:

Concerning what Sam has said about the default GCC bin not being 64-bit, I found this:

 --($:/)-- ls -la /usr/bin/*gcc -rwxr-xr-x 1 root root 428 2006-05-07 09:28 /usr/bin/c89-gcc
 -rwxr-xr-x 1 root root 451 2006-05-07 09:27 /usr/bin/c99-gcc
 lrwxrwxrwx 1 root root   7 2009-06-14 10:17 /usr/bin/gcc -> gcc-4.3
 lrwxrwxrwx 1 root root   7 2009-06-14 10:17 /usr/bin/x86_64-linux-gnu-gcc -> gcc-4.3

 --($:/)-- ls -la /usr/bin/gcc*
 lrwxrwxrwx 1 root root      7 2009-06-14 10:17 /usr/bin/gcc -> gcc-4.3
 -rwxr-xr-x 1 root root 239000 2009-01-02 11:16 /usr/bin/gcc-4.3

It all points to the same place.

Want to comment?

(not made public)


(use plain text or Markdown syntax)