Slicehost Articles - Home

Debian Lenny - Installing Nginx via aptitude

2009-07-17T12:02:00Z

Nginx is a popular lightweight server for those who do not need the bulk and extra services that Apache may offer.

This article will look at installing Nginx on a Debian Lenny Slice using the 'aptitude' package manager.

Using the built-in package manager to install packages is a great idea as it solves dependency issues and you are assured of any security updates, if and when they occur.

However, one drawback can be that it is rare for a version upgrade to be placed into the repositories. As such, it is possible for a newer version of an application to be released and not be placed into the repository.

Versions

At the time of writing, aptitude will install Nginx version 0.6.32.

However, at the time of writing, the latest stable version of Nginx is 0.7.61. You can check the latest versions and change logs at the main nginx site.

Which one you choose is, of course, entirely up to you.

Install and Dependencies

Installing Nginx is incredibly simple as it involves only one command:

sudo aptitude install nginx

This will install any and all dependencies that Nginx requires, such as libpcre.

Start

One odd thing is that Nginx is not started automatically:

sudo /etc/init.d/nginx start

Done.

Navigate

Now simply navigate to your IP address, and you will see the wonderfully simple welcome screen:

Init scripts

As you would imagine when installing an application with the aptitude package manager, all init scripts have been created and added to the relevant run levels.

Controlling nginx is done with these commands:

sudo /etc/init.d/nginx start
...
sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx restart

That's it.

Summary

Using the aptitude package manager makes the installation of Nginx and associated dependencies very simple indeed.

The only thing to consider is the version disparity between the one offered by aptitude and the one available via source code.

—

Ben B

Automate File Transfer with WinSCP

2009-07-16T11:33:00Z

In our first

How to automate file transfers

WinSCP provides a strong set of command line tools, useful for writing scripts. Let's open notepad in Windows and write our first script.

option batch on
option confirm off
open mySlice1
get /home/users/demo/example_file.txt C:\Backups\
exit

save this file as testScript.txt.

Basically, we are telling WinSCP that it can answer all prompts negatively and disable overwrite confirmation.

Then the script opens our mySlice1 session which we configured in the first

Click next to choose how frequently we want to run the script. In this case, I chose daily. On the next screen set 8pm as the starting time.

Nice!

How to Synchronize Directories

Sometimes it will be useful to work in a local directory and then synchronize those files with a directory on our slice. WinSCP make this possible with a single command.

Suppose we want to synchronize our local directory C:\www with our remote directory /home/demo/public_html.

 winscp \command "option batch on" "open mySlice1" "synchronize remote C:\www /home/demo/public_html" "exit"

Note that the remote directory must be specified after the local directory, otherwise the command doesn't work. For a full explanation of the syntax, please refer to the official documentation

Summary

Quite a lot here, but as you see WinSCP makes our life easier with its scripting capability. By combining it with Windows Task Scheduler, we can automate file transfer between slices and our local machines. Moreover, we can synchronize remote and local directories. WinSCP has lots of commands. Please check here for WinSCP commands.

Ismail

RHEL - Shorewall installation

2009-07-15T15:18:00Z

So you're ready to start installing applications on your slice and, rightly, you want to make sure that you're nice and secure. IPTables, right? Well, sure, but the only thing is that IPTables can be a messy beast to deal with. That's where Shorewall comes in.

Shorewall is the common name for the Shoreline firewall, a “wrapper” for IPTables that will handle all the heavy lifting for you. This article will get you started, showing you how to get Shorewall on your system.

This article is the first in a series designed to get you started using the Shorewall firewall system. Shorewall will help simplify tasks done with IPTables, making those tasks more intuitive and easier to deal with.

Installation

Now then, I have good news and bad news for you. The bad news is that you probably won't be able to get Shorewall with your standard RHEL package manager, YUM. But don't worry, the good news is that it's still very easy to install with RPMs.

Let's go ahead and get the packages. Go ahead and change directories so that you're in your home directory and let's pull down the packages we need.

cd ~

At the time of this writing, the latest stable version of Shorewall is 4.2.10-3. That's the version that we're going to work with.

Currently, the standard version of Shorewall needs two packages, shorewall and shorewall-perl, to function. Subsequent versions are reported to have those packages combined into one, but as of right now, we'll need both packages to get up and running.

Let's get the RPMs downloaded onto our system.

wget http://www.invoca.ch/pub/packages/shorewall/4.2/shorewall-4.2.10/shorewall-4.2.10-3.noarch.rpm

wget http://www.invoca.ch/pub/packages/shorewall/4.2/shorewall-4.2.10/shorewall-perl-4.2.10-3.noarch.rpm

When it comes time to update, you can check on the Shorewall download page for new versions to download.

Okay now that we have the RPMs in our clutches, let's install them.

sudo rpm -ihv shorewall-*

Don't look now, but you just installed Shorewall. I told you, easy right? Don't believe me? Let's check:

sudo rpm -q shorewall
Password:
shorewall-4.2.10-3

Hard to argue with that. We've just installed and confirmed the latest version of Shorewall. In the next article, we're going to set up a nice, basic one-interface configuration for it. Excited? Yep, me too.

Gentoo - Using Masked Packages

2009-07-14T12:58:00Z

When a package is masked, it means you have to explicitly alter some configuration files to emerge it.

Usually packages are masked because they’re not considered stable enough for the standard Gentoo environment. This can be because they just need more testing, or they’re incompatible with another package, or there may be something seriously wrong with the package itself.

In this article we’ll see how we can access these packages.

Warning!

Packages are usually masked for a very good reason.

Although the aim of these articles is to assist in building a stable server environment and we do show you what to do, we recommend that you don’t unmask packages in most situations.

Just keep in mind what we are trying to achieve when creating and building our Slice.

Remembering these recommendations, let’s see what to do if we really need to have a masked package installed…

Using a masked package

In our example esearch is masked; the stable version is broken and only the testing version is available. This is what happens when we try to emerge esearch:

$ emerge -vp esearch
...
!!! All ebuilds that could satisfy "app-portage/esearch" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-portage/esearch-0.7.1-r7 (masked by: ~amd64 keyword)
- app-portage/esearch-0.7.1-r6 (masked by: ~amd64 keyword)
- app-portage/esearch-0.7.1 (masked by: package.mask, ~amd64 keyword)
/usr/portage/profiles/package.mask:
# Paul Varner <fuzzyray@gentoo.org> (31 Dec 2008)
# Masked due to being broken with portage 2.1 and 2.2.
# Users can use either the unstable versions or switch to app-portage/eix

There are two types of masks in this output; keyword masks (masked by: ~amd64 keyword), and hard masks (masked by: package.mask).

Keyword Masks

Keywords are defined in the ebuild file itself; in this case:

/usr/portage/app-portage/esearch/esearch-0.7.1-r7.ebuild

This mask is declaring that the version we want to install is flagged as ”testing only” on our amd64 architecture Slice.

We can enable the latest testing version on our system by adding the following line to /etc/portage/package.keywords:

=app-portage/esearch-0.7.1-r7 ~amd64

You can see more information on the syntax on this file by entering man portage on the Linux command prompt:

man portage

Once inside the man program, you can type /package.keywords and hit enter to find the correct place in the file. Hitting the q key will exit the man program.

Once the package.keywords file has been updated, we should be able to emerge esearch without any further problems. As always, we’d test with -vp first, then when we’re ready, run the real command:

sudo emerge esearch

Hard Masks

The other type of mask shown comes from the package.mask file, indicating that the 0.7.1 version is broken or has a security risk and is not supported by the Gentoo team. In the emerge output, it looks like this:

...
- app-portage/esearch-0.7.1 (masked by: package.mask, ~amd64 keyword)
/usr/portage/profiles/package.mask:
# Paul Varner <fuzzyray@gentoo.org> (31 Dec 2008)
# Masked due to being broken with portage 2.1 and 2.2.
# Users can use either the unstable versions or switch to app-portage/eix

In this particular case, there are two masks on this package; the hard mask represented by masked by: package.mask, plus a keyword mask shown as ~amd64 keyword.

The last 3 lines of the output are actually an excerpt from the /usr/portage/profiles/package.mask file; they explain the reason that it is masked.

To override the hard mask we could add a line like this to /etc/portage/package.unmask:

=app-portage/esearch-0.7.1

More info on this file can be found in the portage man page.

That’s the hard mask out of the way, but we’d still need to get around the keyword mask if we wanted to emerge this version of the esearch package. To do this we could repeat the earlier process, only with a different version number, by adding a line like the following to /etc/portage/package.keywords:

=app-portage/esearch-0.7.1 ~amd64

Just be careful when installing these types of packages - they’re usually masked for a reason.

matiu

Debian Lenny - using passenger to serve your applications with Apache

2009-07-14T12:31:00Z

Following from the first article, we now have passenger (mod_rails) installed.

As such, we can move on and create a Ruby on Rails application and see how easy it is to serve using passenger.

Rails application

Move into the public_html folder (if you don't have one, then simply create it):

cd ~/public_html

Then create a simple Ruby on Rails application:

rails testapp

Done.

Virtual Host

To serve the Rails application, we need to create a virtual host:

sudo nano /etc/apache2/sites-available/testapp

Although already mentioned, one of the exciting things about mod_rails is that you don't need any special settings in the virtual host configuration.

The contents can be as simple as this:

<VirtualHost *:80>

  ServerName  domain1.com
  ServerAlias www.domain1.com

  DocumentRoot /home/demo/public_html/testapp/public

</VirtualHost>

Of course, you can add custom log file locations and other settings but the main thing to understand is the lack of proxy and port settings.

Once done, we can enable the new site:

sudo a2ensite testapp

Rewrite

As you may know, Rails applications make use of an .htaccess file for various rewrite rules.

If this is a fresh Slice and you do not have the Apache rewrite module enabled, now would be a good time to enable it:

sudo a2enmod rewrite

Reload

Finally, restart Apache:

sudo /etc/init.d/apache2 restart

Note: If you get any port and NameVirtualHost errors on reloading Apache, please ensure you read the Apache Virtual Hosts article.

Done.

Is that it?

Yup. It really is that simple to serve Ruby on Rails applications with passenger (mod_rails).

Additional Rails apps can be configured in the same way — create a vhost and it's done.

Note: you may have noticed that we didn't even need to do anything special with regards to permissions here, as passenger will automatically run the application as the user who owns directory that the virtual host points to. In my case, the 'public_html' directory is in the 'demo' users home directory, as such, my application is being run as the 'demo' user. Which is a good thing. We don't want it to be running as root.

Changes to the application

Whenever you deploy changes to your application all you need to do to is:

touch /home/demo/public_html/testapp/tmp/restart.txt

That will enable the new content to be served — the command can be used in Capistrano or any script you use to deploy your applications.

Summary

Phusion's passenger (mod_rails) is easy to install and even easier to use.

There are no ports or proxies or any other complicated configurations — passenger offers a great deal to the Ruby on Rails community.

—

Ben B

PostgreSQL - creating and dropping tables

2009-07-14T12:24:00Z

This article will explain how to create and drop database tables using the psql client.

Many web frameworks, such as Ruby on Rails, handle creation and access to database tables automatically. But it's a good idea to learn the basics of working with them manually; also, not everyone running a postgres server will use it in conjunction with a web framework.

Preparation

Going forward I'll assume you have a database and a normal database role: 'demodb1' owned by role 'demorole1'.

See the creating and dropping roles and creating and dropping databases articles if you need help with role and database creation.

Connect with psql

Logged into my demo slice as a Linux user named "mike" I'll make a local TCP connection with psql:

mike@demo:~$ psql -U demorole1 -d demodb1 -h localhost
Password for user demorole1: 
Welcome to psql 8.3.6, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)

demodb1=>

Once we're connected with psql we can get started with the SQL commands. If you need help connecting to your postgres server, please see the three making connections articles in this series.

Creating a table

The first table within 'demodb1' will house a list of clients associated with our web app.

We'll need a unique ID number and an email address for each client. The following code can be pasted into our psql session; then we can hit enter to execute the command:

CREATE TABLE clients (
    id serial PRIMARY KEY,
    email varchar(50)
    );

Success! We now have a table named "clients" with two columns:

The "id" column will consist of unique, automatically incrementing integers (the 'serial' data type) and will act as the primary key for the table.

The "email" column will contain text strings no more than 50 characters long.

For a complete explanation see CREATE TABLE in the official documentation.

Note that postgres responded with two (expected) notices regarding the consequences of our command:

NOTICE:  CREATE TABLE will create implicit sequence "clients_id_seq" for serial column "clients.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "clients_pkey" for table "clients"

Listing all tables

We can get a list of all tables in the database to which we're connected using the '\dt' command in psql:

demodb1=> \dt
          List of relations
 Schema |  Name   | Type  |   Owner   
--------+---------+-------+-----------
 public | clients | table | demorole1
(1 row)

Great, it shows the one table we've created so far.

We can use the '\d' command with a table's name to inspect it more closely:

demodb1=> \d clients
                                Table "public.clients"
 Column |         Type          |                      Modifiers                       
--------+-----------------------+------------------------------------------------------
 id     | integer               | not null default nextval('clients_id_seq'::regclass)
 email  | character varying(50) | 
Indexes:
    "clients_pkey" PRIMARY KEY, btree (id)

Nice, we can see the column names, the data types we specified, and any modifiers — the data type and modifiers listed for the "id" column are a consequence of the 'serial PRIMARY KEY' argument in our first 'CREATE TABLE' command above.

Any indexes for the table will be reported too — note the one listed here matches up with the notices that appeared following our 'CREATE TABLE' command.

Renaming a table

We may occasionally need to rename a table, for clarity's sake or just personal preference; this is easily accomplished:

ALTER TABLE clients
    RENAME TO customers;

We'll paste it into psql, hit enter, and then rerun the '\dt' command to verify it worked:

demodb1=> \dt
           List of relations
 Schema |   Name    | Type  |   Owner   
--------+-----------+-------+-----------
 public | customers | table | demorole1
(1 row)

Fanstastic! Note this 'ALTER' command doesn't change any data inside the table.

Dropping a table

Tables can be dropped (deleted) from our database using the 'DROP TABLE' command:

DROPT TABLE customers;

NOTE: This deletion is irreversible; a dropped table and all the data it contains is permanently erased from the database.

Summary

Manual creation and management of tables in postgres is a useful skill. Future articles in this series will explore other common commands for manipulating table objects and the data they contain.

—

Mike

Ubuntu Hardy - Using mod_python to Serve Your Application

2009-07-14T12:18:00Z

If you've followed the previous article you should have Apache and mod_python ready to serve an app for you.

In this article we'll create a basic Django app and setup the virtual host that will allow Apache and mod_python to work their magic.

Create the Django Application

First thing's first, move to your home directory and go into your public_html/domain1.com directory (if you don't have one, create one and of course give it the name of your domain rather than domain1.com):

cd ~/public_html/domain1.com

Next you'll want to create a Django project which is done simply with the django-admin.py tool.

In this case we will call it 'testproject':

django-admin.py startproject testproject

Create the Virtual Host

For Apache to be able to actually serve a Django application it needs to know that it should hand off certain requests to mod_python. To accomplish this, we'll setup a virtual host that takes care of letting Apache know what to do in certain situations.

This example is very basic but it will get you going:

sudo nano /etc/apache2/sites-available/domain1.com

Then type or copy the following virtual host definition:

<VirtualHost *:80>
        ServerName domain1.com
        ServerAlias www.domain1.com

        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE testproject.settings
        PythonPath "['/home/demo/public_html/domain1.com'] + sys.path"
        PythonDebug On
</VirtualHost>

Once you've saved the virtual host you'll need to enable it and reload Apache:

sudo a2ensite domain1.com
sudo /etc/init.d/apache2 reload

Provided everything went as expected you should be able to visit your domain (or slice IP) in your browser and get your newly created Django application. It should look something like this:

Note: If you get any port and NameVirtualHost errors upon reloading Apache, please ensure you read the Apache Virtual Hosts article.

Static Content

There is a caveat to the virtual host definition provided, namely it does not allow serving of static content.

That is to say, no document root was specified and there is nothing to indicate that static files are not to be handled by mod_python and Django.

The Django team actually recommends you use a secondary web server to serve static content.

However, you can make a few tweaks in your testproject/settings.py file and use the following virtual host definition:

<VirtualHost *:80>
        ServerName domain1.com
        ServerAlias www.domain1.com

        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE testproject.settings
        PythonPath "['/home/demo/public_html/domain1.com'] + sys.path"
        PythonDebug On

        DocumentRoot /home/demo/public_html/domain1.com
        <Location "/static/">
            SetHandler none
            Options -Indexes
        </Location>
</VirtualHost>

The Location block tells Apache to not let Django handle anything that's located under /static/ on your site. You can set this to be anything you like, but you'll need to make the appropriate directory available under /home/demo/public_html/domain1.com. In this example the directory would be called "static".

Tweaks for the settings.py file involve setting the MEDIA_URL and MEDIA_ROOT settings appropriately:

nano /home/demo/public_html/domain1.com/testproject/settings.py

Find the following two settings and edit them like so:

MEDIA_ROOT = '/home/demo/public_html/domain1.com/static/'
MEDIA_URL = '/static/'

Reload Apache now to make the updates take effect:

sudo /etc/init.d/apache2 reload

Now any items placed in /home/demo/public_html/domain1.com/static can be accessed via http://domain1.com/static/path/to/file.

Changes to your Django Application

When you update your python code or templates in a Django application with mod_python, you'll usually need to give Apache a reload to see the changes. So it's good to get into the habit of reloading Apache after making any changes to your project.

At this point you should now be able to successfully build out a Django application and have mod_python and Apache serve it up for you.

Ben H.

Debian Lenny - Installing Passenger with Apache

2009-07-03T11:28:00Z

Phusion's Passenger (mod_rails) is an exciting development in serving your Ruby on Rails application with the Apache web server.

Incredibly simple to install and use, you can have a rails application up and running in no time. You don't even have to worry about ports or setting up a proxy to another server.

Prerequisites

To get the most out of this article you need to have a couple of things preinstalled:

Firstly, you need Apache installed (see this article).

Secondly, you need ruby and rubygems installed (if not please see the Ruby on Rails article).

mod_rails installation

Passenger (mod_rails) is a rubygem.

Let's install the passenger gem:

sudo gem install passenger

Once completed, we need to install the Apache2 module:

sudo passenger-install-apache2-module

A dialogue opens in the terminal and starts with:

As suggested, press 'Enter/Return':

I deliberately left the Apache headers off the installation until this point as I want to demonstrate how easy the installation is.

The passenger (mod_rails) install has found a missing dependency — let's press 'Enter/Return':

How cool is that? It tells us what to do.

Well, let's go ahead and install the headers (we'll use aptitude though):

sudo aptitude install apache2-prefork-dev

Once done, we can try the install again:

sudo passenger-install-apache2-module

All being well, the install will complete with instructions at the end letting us know we need to add some lines to the main Apache2 config file.

No problem:

sudo nano /etc/apache2/apache2.conf

Note: Passenger is an active gem and is being updated all the time. Rather than copy and paste the output I show below, please ensure you copy and paste the output from the install itself.

At the time of writing the article, I installed passenger v2.2.4 — you may have installed a later version.

So, for my v2.2.4 install, I added the following lines to my apache2.conf:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /usr/bin/ruby1.8

Apache restart

Now all we need to do is restart Apache:

sudo /etc/init.d/apache2 restart

Done

That's all we need to do to install mod_rails onto our Slice.

The next article will show how to create a Ruby on Rails application and serve it using passenger — an incredibly easy process.

—

Ben B

WinSCP

2009-06-26T12:47:00Z

In this article you will learn how to securely transfer files between your windows machine and your slice, using the WinSCP application. You will also learn how to create new files and set their permissions.

Introduction

WinSCP is an open-source free SFTP client and FTP client for Windows. Its main function is safe copying and transfer of files between a local and remote computer. Windows Vista SP1 was used for this article. Different versions of Windows may have slightly different screens.

Download and install

First, WinSCP should be downloaded from this website. After you download the installation file, double click the executable file of WinSCP.

As you see you can check set permission box and set the permission for that directory by simply clicking R, W and X. You can also see the equivalent octal value for your settings. Please remember that we login as “sliceIsmail” so owner of the directory will be that user. You can change permission of an existing file or directory by right clicking and then selecting “properties” from the menu.

Summary

WinSCP is a great sftp client for windows users. Files can be copied/pasted between your windows machine and your slice securely since all of the communication is encrypted. It also allows flexibility for creating, modifying files, and changing file permissions. I will explain other features of WinSCP such as executing commands on the slice, how to automate file transfers, synchronization, etc., in the next article.

Ismail

Debian Lenny - Apache Virtual Hosts #2

2009-06-24T13:19:00Z

Following on from the first Debian Lenny - Apache Virtual Hosts article, we can now look in detail at some of the settings available to us in the Virtual Hosts file.

This will enable us to have complete control of the domain we want to serve.

Some of the settings discussed were introduced in the previous article but some are new.

Take the time to read through the explanations and you will soon have an understanding of how powerful vhosts actually are.

Email

ServerAdmin

ServerAdmin webmaster@domain.com

Sets the email address for the server administrator - this will be used if you have setup the server to contact you on errors. It is also shown in the ServerSignature (if set to 'Email' - see below)

Domain Name

ServerName and ServerAlias

ServerName domain.com
ServerAlias www.domain.com

Sets the domain name for the virtual host. You can have as many aliases as required. For example, you can have domain.com and domain.net point to the same content.

Note this is not a rewrite rule (we'll look at those later) but the domains defined here will serve the same content (assuming you have set the DNS to point to your Slice IP).

Index Files

DirectoryIndex

DirectoryIndex index.html

Defines the index file (the 'home' page that is shown on entering the domain address). Useful if you have want the user to be directed to an alternate page or to a non-standard home page.

Do note this is not a good way of redirecting users as they may go directly to a non specified page such as domain.com/index.php whilst the DirectoryIndex will only work for those entering domain.com.

Documents

DocumentRoot

DocumentRoot /home/demo/public_html/domain.com/public

The location of the domain's public files. Use an absolute path name.

Log Files

ErrorLog and CustomLog

LogLevel warn
ErrorLog  /home/demo/public_html/domain.com/log/error.log
CustomLog /home/demo/public_html/domain.com/log/access.log combined

Set the Log levels and the location for the Virtual Hosts log files. Very useful for easy analysis of the domain statistics.

Error Documents

ErrorDocument

ErrorDocument 404 /errors/404.html
ErrorDocument 403 /errors/403.html

Used for all the standard error messages.

In these examples I have an 'errors' folder in my public directory. I created each error document and place them in the 'errors' folder. The paths shown are relative to the DocumentRoot folder defined above.

If not defined, Apache will generate its own error pages. Custom error pages are more user friendly and can be customised as much, or as little, as you want.

Apache Footers

ServerSignature

ServerSignature On

Sets whether the server details are displayed in any server generated error pages or index lists. Options are On, Off and Email.

Note the level of detail in the signature is configured via ServerTokens which cannot be set in the Virtual Hosts file — for Debian Lenny's Apache layout this is properly set in '/etc/apache2/conf.d/security'. See the Apache configuration #2 article for more details.

If set to Email, the ServerAdmin email will be displayed.

cgi-bin

ScriptAlias

ScriptAlias /cgi-bin/ /home/demo/public_html/domain.com/cgi-bin/
<Location /cgi-bin>
  Options +ExecCGI
</Location>

Enables the cgi-bin location as defined by the custom virtual hosts layout. You can, of course, leave the cgi-bin in the DocumentRoot location if you so wish.

Directory Browsing

Options

Options -Indexes

To turn off directory browsing use '-Indexes' or 'None'. To turn them on, use '+Indexes'.

SSI

Options

Options -Includes

This Option disables Server Side Inlcudes. SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.

Symlinks

Options

Options -FollowSymLinks

Enable or disable the option to follow symlinks. Be careful with this option as it can lead to security risks (inadvertently linking to configuration folders).

You can consider using the SymLinksIfOwnerMatch directive instead of FollowSymLinks. The SymLinksIfOwnerMatch allows symbolic links to be followed only if the owner of the link is identical to the owner of the target file or directory (in terms of Linux filesystem ownership/permissions). Thus preventing many of the security risks that a simple FollowSymlinks directive can create.

.htaccess

AllowOverride

AllowOverride None

Setting AllowOverride to none disables .htaccess support. Set to All to allow them.

You can also specify which .htaccess features to enable such as:

AllowOverride AuthConfig Indexes

The Apache htaccess and AllowOverride docs have more information on the different features.

Remember to specifically protect your .htaccess file. This can be done in two ways:

Firstly rename it to something obscure and, secondly, deny access to the file from external sources:

AccessFileName .myobscurefilename
<Files ~ "^\.my">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

No Options

This will turn off all the available options.

Options None

We'll see more of this directive later.

Hierarchy

Remember that the Options directives can be set per directory like this:

<Directory />
  AllowOverride None
  Options None
</Directory>

<Directory /home/demo/public_html/domain.com/public>
  AllowOverride All
</directory>

This will turn of all Options and disable .htaccess support for all directories.

However, the second Directory setting will override the first and allow .htaccess support for the domain.com/public directory.

Summary

The Virtual Hosts file is at once an easy tool to use and a very powerful one. My advice is to enter one setting and test it. Then enter the next setting and so on.

Once familiar you will see you have fine control over all of your web folders and files.

—

Ben B

PostgreSQL - making connections #3

2009-06-08T11:41:00Z

Following part 2, this article addresses some security-related concerns affecting postgres servers open to remote TCP connections.

Motivation

As we worked through the previous article, we briefly considered several points regarding the security of our postgres server. We'll highlight them here, and address a few related concerns.

TCP connectivity to a postgres server from remote hosts is a common requirement in the design of many web applications, but we want to make sure our databases are not exposed or weakened unnecessarily — the Internet is full of hackers and other unsavoury individuals who might like to steal or damage our data, or hijack our database server for nefarious purposes.

Port change

Port 5432, the default postgres listening port, is well known and relatively common — hackers and bots will check whether it's open when scanning an Internet host, such as a slice.

One way to add a bit of extra protection to our postgres server is to change the port on which it's listening. We can choose any integer between 1025 and 65536 that doesn't conflict with another process listening on our slice, '43210' for example:

# - Connection Settings -

#listen_addresses = 'localhost, 123.45.67.890, 10.300.300.300'  # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost', '*' = all
                                        # (change requires restart)
port = 43210                            # (change requires restart)

It's not a necessary change, just a simple protective measure we can take. If we do change it, our iptables rules will need updating and we'll have to specify the custom port in a web application's settings and for any port forwarded connections.

For the remainder of this article and in subsequent articles, we'll stick with the default value (5432) for simplicity's sake.

Port exposure

We previously learned that our postgres server was configured by default to listen only on the slice's localhost interface (127.0.0.1).

For the purposes of the tutorial, we re-configured it to listen on both the slice's public and private IPs. Further, we loaded an iptables rule that opened port 5432 on both IPs. While this is convenient for exploration and testing of remote connections, doing so is not without long-term risks.

If our postgres server is listening on the public IP, and iptables is allowing inbound connections, that means it's a potential target for brute force attacks or attempts at known exploits (if any are known or discovered). And if it's listening on the private IP, an attack could come from another host on the Slicehost network — the latter is less likely than the former, but still a real possibility.

We want to make choices for our postgres setup that minimize its exposure right from the start.

Listen on an interface only as needed

The primary thing we can do to limit our security risks is to specify a listening interface in 'postgresql.conf' only when it's truly required for our application.

Hosts which are remote to the the Slicehost network — such as your local computer — will rarely need a persistent connection. SSH port forwarded connections will suffice, making it unnecessary to have postgres listen on the slice's public IP.

As was explained previously, SSH port forwarded connections appear to originate from the slice's localhost interface while connecting to the same, from the perspective of the postgres server. Review the section in the previous article titled "Remote clients with dynamic IPs" for a more detailed explanation and example.

So we can remove the public IP from the 'listen_addresses' list in 'postgresql.conf'. What about the slice's private IP? If our database server is split off from the slice(s) running our web application — a common setup — postgres will need to listen on that interface.

Let's modify 'postgresql.conf' accordingly:

sudo nano /etc/postgresql/8.3/main/postgresql.conf

# - Connection Settings -

#listen_addresses = 'localhost, 10.300.300.300'  # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost', '*' = all
                                        # (change requires restart)
port = 5432                             # (change requires restart)

In this example, we used 10.300.300.300 as the Slice internal IP - you would need to enter your Slice private IP.

We'll need to restart postgres to apply the changes.

Note that if postgres is running on the same slice as our application's other processes, and we don't otherwise plan on connecting to our databases from another slice, we should also remove the private IP from 'postgresql.conf', leaving only localhost specified for 'listen_addresses'. In fact, that's the default setup.

Tighten iptables

We should now modify the iptables rule we loaded in the previous article, such that port 5432 is open to inbound traffic destined only for our slice's private IP. For a Slicehost slice, the private IP is always bound to interface 'eth1', while the default public IP is bound to 'eth0'. Extra public IPs are bound to 'eth0:x' (x = 1, 2, 3 ... ). We can use the '-i' flag to specify an interface for our iptables rule:

sudo nano /etc/iptables.up.rules

# Allows connections to the PostgreSQL process
-A INPUT -i eth1 -p tcp --dport 5432 -j ACCEPT

The reasoning here: don't keep ports open unnecessarily. After saving the changes, we'll need to flush and reload our rules:

sudo iptables -F
...
sudo iptables-restore < /etc/iptables.up.rules

We should simply remove the iptables rule for the postgres port if the database server will be listening only on localhost.

pg_hba.conf - careful choices

There are a few principles to keep in mind when adding and pruning host records in 'pg_hba.conf', especially for production servers:

— Specify hosts only as necessary.

If we have four additional slices and only one of them will be connecting to the postgres server, we should make a host record only for that one slice's IP.

Most especially, if for convenience you ever set a record allowing connections from all hosts, don't run with it for long, and never on a production server. That would be asking for trouble.

If we're developing a setup that will eventually go into production, it's a good idea to occasionally review 'pg_hba.conf' and prune any host records that have turned out to be unnecessary.

— Use hostssl whenever possible.

We learned in the previous article that host records with the "host" connection type will allow both plain and SSL-encrypted connections. The "hostssl" connection type requires the postgres server and client to use SSL encryption.

The "host" type is okay for localhost's record — in fact we may have processes running on the slice which aren't SSL-enabled, yet need to communicate with postgres.

But for remote TCP connections, we should use "hostssl" whenever possible, whether the database client is on the Slicehost network or somewhere else on the Internet. Databases quite often store sensitive information we don't want traversing cyberspace naked before the peeping eyes of unscrupulous parties who would like to abuse it for their gain.

If we find that the database client software running on our remote host (another slice, some other server, or a local computer) doesn't support SSL-enabled connections, it's best to search for instructions on how to re-install or compile a version which does. If an SSL-enabled version doesn't exist, we can consider using SSH port forwarding to make the connection. Stunnel is another possibility in that situation.

Summary

Most anyone running a PostgreSQL server will make remote TCP connections to it.

The configuration files are flexible enough to leave the database server wide open to Internet connections. It's better though to specify only the necessary interfaces and hosts in its white lists — postgresql.conf, pg_hba.conf.

Encrypted connections are also possible, and should generally be required for all remote clients.

Further, the slice's iptables firewall should be adjusted to pass traffic on an interface and port only as needed.

It's your server and your data — configure PostgreSQL wisely.

—

Mike

Debian Lenny - Apache Virtual Hosts #1

2009-05-27T13:36:00Z

Now we have Apache installed and running, we can configure it to serve multiple domains using Virtual Hosts.

Do note the layout used in these articles is explained here - feel free to use the directories of your choice.

Create the layout

In this example we'll be using two domains: domain1.com and domain2.com.

In your home directory create a 'public_html' folder:

cd ~
mkdir public_html

Now for each domain we want to host create a folder with a standard set of sub-folders:

mkdir -p public_html/domain1.com/{public,private,log,cgi-bin,backup}

and

mkdir -p public_html/domain2.com/{public,private,log,cgi-bin,backup}

That will create the folders public, private, log, cgi-bin and backup for each of our domains (domain1.com and domain2.com).

index.html

The content of the public folder is, naturally, up to you but for this example I am going to use a very simple html file so we can check the virtual hosts work.

So for each domain create an index.html file:

nano public_html/domain1.com/public/index.html

add the following to the index.html file:

<html>
  <head>
    <title>domain1.com</title>
  </head>
  <body>
    <h1>domain1.com</h1>
  </body>
</html>

Repeat the process so you have a similar file for domain2.com (simply replace all instances of 'domain1.com' with 'domain2.com).

OK. Now we have a basic structure for our two domains we can look at defining two virtual hosts.

NameVirtualHost

With virtual hosts, one thing that often confuses people is the NameVirtualHost setting.

For each interface and port on which Apache is set to listen on, we need a NameVirtualHost directive. Something to keep in mind is you can only define it once per port.

In the Apache layout for Debian Lenny there is a default NameVirtualHost directive in the 'ports.conf' file. If you've worked through the Apache configuration #1 article for Lenny, you may remember it being noted previously.

Let's take another look at the contents of 'ports.conf':

cat /etc/apache2/ports.conf

You should get the following output (unless you've previously modified the file):

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

The default NameVirtualHost setting satisfies our requirements at present — Apache will apply named based virtual host logic and settings for HTTP requests made on any available interface (*) at port 80.

Custom Virtual Hosts

We've set up the basics and now we're ready to add our own virtual hosts so we can start to serve our domains.

Let's go ahead and create the vhost file for domain1:

sudo nano /etc/apache2/sites-available/domain1.com

The contents look like this:

# Place any notes or comments you have here
# It will make any customisation easier to understand in the weeks to come

# domain: domain1.com
# public: /home/demo/public_html/domain1.com/

<VirtualHost *:80>

  # Admin email, Server Name (domain name) and any aliases
  ServerAdmin webmaster@domain1.com
  ServerName  domain1.com
  ServerAlias www.domain1.com


  # Index file and Document Root (where the public files are located)
  DirectoryIndex index.html
  DocumentRoot /home/demo/public_html/domain1.com/public


  # Custom log file locations
  LogLevel warn
  ErrorLog  /home/demo/public_html/domain1.com/log/error.log
  CustomLog /home/demo/public_html/domain1.com/log/access.log combined

</VirtualHost>

a2ensite

Now we have the site available, we need to enable it:

sudo a2ensite domain1.com

The output of the command is:

Site domain1.com installed; run /etc/init.d/apache2 reload to enable.

Seems like good advice:

sudo /etc/init.d/apache2 reload

Navigate

To test the domain without creating a DNS zone and record(s) on some Internet namserver(s), I've modified the '/etc/hosts' file on my local computer to include some entries mapping 'domain1.com', etc. to the demo Slice's public IP:

127.0.0.1    localhost
...

# entries related to the demo slice
123.45.67.890   domain1.com
123.45.67.890   www.domain1.com
123.45.67.890   domain2.com
...

You can add similar entries in your own 'hosts' file, though it's location will vary depending on what OS is loaded on your local computer (try a Google search).

NOTE: entries in the 'hosts' file will need to be removed prior to testing and using live DNS zones and records created on Internet nameservers. Failure to remove them will likely lead to confusion on your part and inaccurate tests of new or modified public DNS records.

With such changes made for testing purposes, you can navigate to your site in a web browser on your local computer:

Tada! You now have the contents of public/index.html being shown:

ServerAlias

Note that in the vhost file, we set a ServerAlias. Providing you have the DNS set up correctly you can also use that address — for quick testing purposes you can place another entry in your 'hosts' file (I've already done so in the example code given above):

We'll talk about forcing one address or the other in a later article about rewrite rules.

Repeat as necessary

To create and enable domain2.com simply go through the process again:

sudo nano /etc/apache2/sites-available/domain2.com
...
# Enter the details for domain2.com as per the example shown above

Then enable the site and restart Apache:

sudo a2ensite domain2.com
...
sudo /etc/init.d/apache2 reload

Finally navigate to your second domain:

http://domain2.com
or
http://www.domain2.com

All being well, you will see the 'domain2.com' index file.

Log Files

As defined in the vhosts file, each domain has its own log files. Let's take a quick look:

ls /home/demo/public_html/domain1.com/log/

The output is exactly as expected:

access.log  error.log

This makes for much easier analysis as each set of logs is self contained.

Default

Remember that although we changed the default virtual host, we did leave it in place.

Now, if someone enters the IP address of the Slice they are served the contents of that default vhosts file (providing, of course, you have not set up a separate vhost for the IP address).

Why are they served from that vhost file?

Apache searches the enabled vhosts in alphabetical order and if it can't find one for the requested IP address or domain name, it serves the first one (alphabetically).

If we had disabled or deleted the default vhost, then the contents of domain1.com would be displayed (being before domain2.com alphabetically).

This is something to keep in mind when planning your websites. Do you want a particular domain to be the default? Do you want the IP address to have completely different content?

Summary

We've gone into some detail here but, overall, setting up a virtual host is relatively easy. Of course, there are many settings and configurations to take into account but you should have your site up and running in no time.

The next virtual host article will look in more detail at some of the settings that are available and what they mean.

—

Ben B

Debian Lenny - Apache configuration #2

2009-05-27T13:28:00Z

Continuing from the first Debian Lenny Apache configuration article, we'll now look at some of the other settings in the main apache2.conf file and what they can do.

Concentrating on efficiency and security, this will end our apache2.conf journey (for now.)

ServerName

Default: Not Set

The ServerName is usually a hostname or a FQDN (Fully Qualified Domain Name).

If you followed the Debian Lenny installing Apache2 and PHP5 article, you will have already set the ServerName configuration.

If you fail to set the ServerName then on an Apache restart you will see the following warning:

apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

To stop the warning and set the ServerName, add the following to the apache2.conf:

ServerName demo

Remember the test slice has a hostname of 'demo' - set this to your hostname or FQDN.

HostnameLookups

Default:

HostnameLookups Off

If you want happy users and to save traffic, keep this at Off.

Setting this to 'On' will enable DNS lookups so host names can be logged (it performs a reverse DNS check), setting it to 'Double' will not only perform the reverse DNS check it will then check the resulting hostname.

All a bit much and if you desperately need hostname information from your visitors it is advised to use logresolve (located in /usr/sbin/logresolve) for this purpose. A small explanation can be found here.

Security Settings

It's a good idea to review a couple of security-related settings for Apache — ServerTokens and ServerSignature — which in the Debian Lenny Apache layout are stored by default in the 'security' config file:

/etc/apache2/conf.d/security

ServerTokens

Default:

ServerTokens Full

The ServerTokens setting will dictate how much information is sent in the Headers with regard to Apache version and modules in use.

The default (Full) would send something like this:

Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch Server at demo

Does this make a difference? Well, yes. If we can suppress that information it will make it harder for someone to find an exploit.

It does not make the actual install any more secure but all someone has to do right now is look for an exploit in Debian Lenny, Apache 2.2.9 and so on. Why make it easy for them?

The options are (with example outputs):

Full

Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch Server at demo

Apache/2.2.9 (Debian) Server

Minimal

Apache/2.2.9 Server

Minor

Apache/2.2 Server

Major

Apache/2 Server

Prod

Apache Server

It's up to you what level of info you want to give out. I prefer setting ServerTokens to Prod.

ServerSignature

Default:

ServerSignature On

Server generated pages, such as 404 pages or directory listings, can contain a footer line which includes server information and can include the ServerAdmin email address.

If you navigate to your Slice IP address and a non-existent page, you will see a 404 Page not found page with the footer information:

The options are:

Off: Produces no footer

On: Produces footer information (at a level defined by the ServerTokens setting)

Email: Adds an email link to the information (email address is defined in the vhosts file with the ServerAdmin setting)

Keep in mind that many settings can be overridden by a virtual host file.

If you disable the ServerSignature in the 'security' config file, but a virtual host file has:

ServerSignature On

Then the global setting will be overridden and a footer will still be displayed on 404 pages, etc. for any sites associated with that virtual host.

Summary

There are some simple steps in this article, but ones which I believe are quite useful and aid in increasing the efficiency of your Slice and assist in the overall security of your Slice.

—

Ben B

Debian Lenny - Apache configuration #1

2009-05-27T13:22:00Z

As we know from the previous article, Debian Lenny uses a different layout from other non-Debian based systems - let's move on and take a look at the main apache2.conf and ports.conf.

We're not actually going to change a lot at this point, just look at the main settings and see what they mean and what a change will actually do.

Defaults

Why no specific changes to the default?

Well, it's difficult to give a definitive configuration as there are so many variables to consider such as expected site traffic, Slice size, site type, etc.

Remember that it is very unlikely the default Apache configuration will be ideal for your Slice. Don't be intimidated by the thought of 'optimizing' the install - following the next couple of articles will allow you to understand the meaning behind the concepts.

You'll also find the same things apply to any web server - they may call them different things, but the concepts remain the same.

My advice is very simple: experiment. Find what works best on your setup.

ports.conf

Let's start with the ports.conf file:

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
    # SSL name based virtual hosts are not yet supported, therefore no
    # NameVirtualHost statement here
    Listen 443
</IfModule>

Well, that seems fair enough. Port 80 is the standard HTTP port to listen on and if you have the ssl module loaded, then it will also listen on port 443 (HTTPS).

Also, name based virtual hosts are enabled by default, for HTTP requests made on all interfaces (*) on port 80, per the NameVirtualHost directive. Note the comment concerning the lack of support for SSL name based virtual hosts — in practical terms this means that you will need an additional public IP assigned to your Slice for each additional SSL-enabled site that you intend to host on the same Slice.

Configuring Apache to listen on another port, say 8080, is as simple as adding:

Listen 8080

Once that is added to the file and Apache restarted, it would listen on port 8080. You would want to change the port specified in the NameVirtualHost directive to match.

apache2.conf

now open up the main Lenny Apache config file:

sudo nano /etc/apache2/apache2.conf

I won't list the contents here but, if you are not familiar with the settings, have a read of the comments. I find them very informative and straight to the point.

You may be surprised how well config files are documented. I always recommend giving them a read - sure, they may not make a lot of sense to begin with but as time goes by you will be able to glance at them and know what to change.

Anyway, let's look at some of the main settings and what they mean:

Timeout

Default:

Timeout 300

This sets (in simple terms) the maximum time, in seconds, to wait for a request, action it and the response to the request.

The default is deliberately set high to allow for varied situations. You can reduce this to something more sane, such as 45 or even lower. A decrease may also help in reducing the effects of a DOS attack.

KeepAlive

Default:

KeepAlive On

Keep this set at 'On' as it allows for persistent connections to a client so each file, image, etc is not requested with a new connection. This allows for more efficiency. Define the KeepAlive settings as shown below:

MaxKeepAliveRequests

Default:

MaxKeepAliveRequests 100

Now we have our persistent connection, set the maximum number of requests per connection. Keep this high for maximum efficiency. If you have a site with lots of images, javascripts, etc, try increasing this to 200.

KeepAliveTimeout

Default:

KeepAliveTimeout 15

So how long does the persistent connection wait for the next request? The default setting is very high and can easily be reduced to 2 or 3 seconds. If no new requests are received during this time the connection is killed.

What does this mean? Well, once a connection has been established and the client has requested the files needed for the web page, this setting says "sit there and ignore everyone else until the time limit is reached or you get a new request from the client".

Why would you want a higher time? In cases where there will be a lot of interactivity on the site. However, in most cases, people will go to a page, read it for a while and then click for the next page. You don't want the connection sat there doing nothing and ignoring other users.

prefork MPM

During the Debian Lenny Apache install, we selected apache2-mpm-prefork and not apache2-mpm-worker. If you want to know more about the differences between the two I will point you towards the official Apache docs (which are actually very good).

Default:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

Again, it's difficult to give a suggestion here as to what is best for your site but have a read of the definitions below and see if anything could be improved when you consider what your site(s) serves.

StartServers: number of child server processes created at startup

MinSpareServers: minimum number of child server processes not doing anything (idle).

MaxSpareServers: maximum number of child server processes not doing anything (idle) — any more than the maximum will be killed.

Don't set Max lower than Min, but Apache will ignore silly numbers here and set the Max at Min+1.

MaxClients: sets the maximum simultaneous requests that Apache will handle. Anything over this number will be queued until a process is free to action the request.

MaxClients is not the same as the maximum number of visitors you can have. It is the maximum requests.

Remember the KeepAliveTimeout? This was set low so the next request can be actioned and the original (now 'idle') client will still be sat there reading your webpage — the new (active) request will be actioned or, if the MaxClients limit has been reached, will be queued ready for the next available process.

In most cases, the client is not 'active'. Take this page, for example: you requested it (using an active process) and then spent a while reading it which uses no processes — you are 'idle' (as far as the server is concerned!).

MaxRequestsPerChild: sets how many requests a child process will handle before terminating. The default is zero, which means it will never die.

Why change this if the Max numbers are set as shown above? Well, it can help in managing your Slice memory usage.

If you change the default you give a child a finite number of actions before it will die. This will, in effect, reduce the number of processes in use when the server is not busy. Thus freeing memory.

Freeing it for what though? If other software needed memory then it would also need it when the server is under load. It is unlikely you will have anything that requires memory only when the server is quiet.

Summary

Quite a lot here, but as you go through the different settings you will see that the theory is quite simple. Naturally, there is a lot more to it than this article (or set of articles) can go into.

In the second apache2.conf article, we will look at other settings that will add some more efficiency and help in increasing the security of our Slice.

—

Ben B

Debian Lenny - Apache config layout

2009-05-27T13:17:00Z

Debian Lenny uses a different Apache layout than you may have encountered if you have used Apache with non-Debian based Operating Systems.

The differences are not huge and, indeed, help in configuring and deploying websites.

Looksee

Assuming you have used aptitude to install Apache (see the Debian Lenny Apache and PHP5 install article), move into the config folder and have a look:

cd /etc/apache2
ls

You will see this:

The folders are highlighted in blue. Let's look at those first:

sites-available

Inside sites-available will be files containing the configurations for each site you want to serve - these are known as vhosts or virtual hosts.

Have a look now and see that there is one site (default) available:

ls sites-available/
...
default  default-ssl

The apache install has a 'default' and a 'default-ssl' vhost available - when we navigated to the Slice IP and got the 'It works!" message, it was the 'default' file that told Apache what to do and where the files where located.

We'll look at vhosts in more detail and create our own in a later article.

Do note that a file in sites-available does not mean they are active. They are simply available for serving if you enable them. Which brings us to...

sites-enabled

This folder contains symlinks to the sites you actually want to serve.

For example, you could have two vhosts configured and ready to use in the sites-available folder, but only one of them enabled. Only the one symlinked from the sites-enabled folder would be served.

Have a look at the default contents:

ls -l sites-enabled
...
lrwxrwxrwx 1 root root 26 Nov 28 22:38 000-default -> ../sites-available/default

This means that the 'default' site has been enabled - the symlink named '000-default' links to the 'default' file in the sites-available folder.

Without the symlink in this folder it would remain available (in the sites-available folder) but not active.

The other thing to note is the naming. It's possible for a domain to point to your Slice IP but have no site configuration file. In these cases, the first enabled site (alphabetically) will be displayed, i.e. 000-default's config will be used.

mods-available

Well, I guess you get the idea already but this folder holds the modules that are available to be loaded.

Have a look:

ls mods-available

A fair list is available from our base install but remember that they are not all enabled, merely available for use.

Just as with the vhosts files, any modules that we want to use must be enabled.

mods-enabled

This folder contains symlinks to the modules that we want enabled. Have a look and compare it to the list of modules available:

ls mods-enabled

This list is a lot shorter than the list of available modules (meaning not all the available modules are enabled) and includes php5.conf - which is handy as we installed PHP5 earlier.

a2en and a2dis

Being good sysadmins, we like to get hands on and create our vhosts, and now that we know how the symlinks work we could go ahead and 'ln -s' until all our sites are enabled.

However, there are some commands that make this process much easier.

They are a2dissite, a2ensite, a2dismod and a2enmod.

a2dissite

This will delete the symlink to a site you have previously enabled.

For example, let's disable the default site:

sudo a2dissite default

The symlink in sites-enabled has been deleted and the output is as follows:

Site default disabled.
Run '/etc/init.d/apache2 reload' to activate new configuration!

Reload Apache as indicated to ensure the site is fully disabled:

sudo /etc/init.d/apache2 reload

When you now visit your Slice IP, instead of the nice 'It Works!' page, you will get a 404 Not Found message:

Note the main vhosts file in sites-available is still there - all the a2dissite command did was remove the symlink in the sites-enabled folder.

a2ensite

Let's enable the default site again:

sudo a2ensite default

The output:

Enabling site default.
Run '/etc/init.d/apache2 reload' to activate new configuration!

Reload Apache:

sudo /etc/init.d/apache2 reload

Visit your Slice IP - the default 'It works!' page is being served again.

a2dismod

In the same way as just shown, a2dismod will disable any modules you have previously enabled:

sudo a2dismod php5

The output:

Module php5 disabled.
Run '/etc/init.d/apache2 restart' to activate new configuration!

That will disable the php5 module and if you look in the mods-enabled folder, you will see that the symlinks php5.conf and php5.load have been deleted.

a2enmod

I reckon you've got it now, but to enable the php5 module simply enter:

sudo a2enmod php5

The output:

Enabling module php5.
Run '/etc/init.d/apache2 restart' to activate new configuration!

And a quick check will show that indeed, the php5.conf and php5.load symlinks are back in the mods-enabled folder.

Done

Don't forget to reload Apache after each site or module change.

In the next article we'll discuss the main apache2.conf file and look at what changes can be made to optimise the install.

Ben