Webserver

From CafeWiki

Contents 1 Webserver Setup and General Configuration 1.1 Virtual Servers 1.2 Authentication and Authorization 1.3 mod_rewrite 1.4 SSL 2 Managing Websites 2.1 Internet Perspective 2.2 Server Perspective 2.2.1 Blogs (Wordpress) 2.2.2 Install and Setup 2.2.3 Updates 2.2.4 Server Migration

Webserver Setup and General Configuration

Virtual Servers

Check that the apache server defaults work correctly out of the box by browsing to http://<webserver ip> and checking that you get the "It works" page. Set up virtual hosts: Make a backup of the default virtual host file, just in case:

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default.bak

Edit the default host file so that the settings are correct for Name Virtual Hosting. Only the first part of the file is shown and the important bits are in bold, in particular the :80 port identifier is important to allow for the use of SSL enabled sites (port 443) in the future:

NameVirtualHost 192.168.1.2:80           # The ip address of the webserver box
<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/default
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/default>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
   # This directive allows us to have apache2's
   #  default start page
   # in /apache2-default/, but still have / go to 
   # the right place
                #RedirectMatch ^/$ /apache2-default/
        </Directory>

Create the document root directory and ensure that the directory contains an appropriate index.html file that can be displayed. Use a modified "It works" index.html file so you can see that you've reached the correct location.

mkdir /var/www/default

Enable the default site:

a2ensite default

Reload the apache server

/etc/init.d/apache2 reload

Check that the default index.html file is correctly displayed when browsing to the server.

Once the webserver is correctly configured this default site should never be reached by an external browser.

Each website that is to be hosted on the webserver will be configured as follows: Create the site specific hostfile, again only the first part of the file is shown and the important bits are in bold. The host file is located in /etc/apache2/sites-available:

#NameVirtualHost               # This directive only appears once, in the default site
<VirtualHost 192.168.1.2:80>   # The ip address of the webserver box    
        ServerAdmin webmaster@localhost
        ServerName www.examplesite.com     # The domain of the website
        DocumentRoot /var/www/examplesite  # The directory containing all website files
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/examplesitedir> # Access and security options for DocRoot directory
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
   # This directive allows us to have apache2's
   #  default start page
   # in /apache2-default/, but still have / go to 
   # the right place
                #RedirectMatch ^/$ /apache2-default/
        </Directory>
        

Note that if you wish to have multiple domain names reach a single server you can use the ServerAlias directive to associate a second domain name with the same name virtual host. This is useful for the situation where you want to have both www.example.com and example.com resolve to the same virtual host. See the Apache documentation for more information. It is important to realize that both the domain names must be in the DNS and pointing to your webserver's external IP address for this to work.

#NameVirtualHost              
<VirtualHost 192.168.1.2:80>       
        ServerAdmin webmaster@localhost
        ServerName www.examplesite.com                         # The domain of the website
        ServerAlias example.com example.org www.example.org    # The alias domain name(s) separated by spaces
        DocumentRoot /var/www/examplesite
        <Directory />

Create the document root directory and ensure that the directory contains an appropriate index.html file that can be displayed. Use a modified "It works" index.html file so you can see that you've reached the correct location.

mkdir /var/www/examplesite

Enable the default site:

a2ensite examplesite

Reload the apache server

/etc/init.d/apache2 reload         

Create the html file structure within the document root (minimally this is an index.html file) Check that the site (i.e. the content specified by the index.html file) is correctly displayed when browsing to the server.

Authentication and Authorization

Setting up an authenticated directory to allow access to html content only to authorized users is described in this howto article on the Apache website. The basic idea is that the directory that need access restrictions is secured by a username|password pair.

NOTE: The method described here does not provide super tight security as the username|password pair are passed from the browser to the server as plain text - a determined attacker could sniff out the data from the traffic between the client and server. This method is sufficient to provide a barrier to less determined attackers such as spammers. Combining this technique with SSL encryption would be a much more robust solution.

Start by creating a password file for the users that require access to the restricted directory. The password file must be in a location outside the web root for the server (i.e. not within /var/www for an ubuntu distribution) and must be locked down so that only root can write to the file and only the apache user can read the file.

touch /etc/apache2/passwords/passwords
htpasswd /etc/apache2/passwords/passwords username  

and provide a password (the -c (create) option on the htpasswd command can be used to create the password file, but you need to be cautious that you do not use the -c later as the existing password file will be overwritten, the touch method is a little safer).

chown root:www-data passwords

set the ownership to root and group to the apache user, www-data.

chmod 640 passwords

set the access to RW for root and R for www-data.

Next edit the Directory directive for the virtual host and directory location that you wish to secure. This will typically be an edit of one of the virtual hosts files in /etc/apache2/sites-available/

<Directory /path/to/directory>
     AuthType Basic
     AuthName "Restricted Access"
     AuthUserFile /etc/apache2/passwords/passwords
     Require user username
     Options None
     AllowOverride None
     Order allow,deny
     allow from all
</Directory>

If the entire virtual host is to be secured the argument to the directory command would be

<Directory />
    ...

which will apply to the directory specified as the DocumentRoot for the virtual host. Note that the Options None also prevents directory listings from being provided for any directory below the named directory. This is something that would be a useful security measure generally on all virtual hosts.

mod_rewrite

In the virtual host environment described above, the whole thing hangs together by virtue of the fact that all the destination URLs are referenced by a subdomain. For example, www.example.com, aaa.example.com or test.example.com. However, I could never get the bare domain (example.com) to resolve correctly to www.example.com when I had multiple subdomains defined. It always resolved to the first subdomain in alphabetical order (aaa.example.com). Somehow Sean never had the same problem, his example2.com redirected just fine to www.example2.com just by using the ServerAlias directive mentioned above (even when he ended up hosted on my server). I suspect this is because there was only a single example2 virtual host - www.example2.com.

In any event, I needed a solution that would work for my domain. The solution turned out to be mod_rewrite, an Apache module that I found to be more than a little complicated to figure out. There is lots of online documentation, but in traditional *nix style, if you don't already know what to do it doesn't help you to get started very easily!

First things first, although mod_rewrite is installed by default in Apache for Ubuntu, it is not enabled by default. To enable it:

$a2enmod rewrite
$/etc/init.d/apache2 restart

Now rewrite statements can be used in the configuration files for the system. There are two main ways this can be done; the rewrites can be done per server in the apache .conf files or per directory inside <Directory> directives or in .htaccess files. There are plenty of example of the use of rewrites in .htaccess files but precious little for the per server usage. Of course, the rewrite for canonical hostnames needs to be done for the server, so the .htaccess solutions aren't (as far as I can tell) suitable. One of the apache documents describes the rule required for this task, but is not helpful in guidance as to where the rule belongs within the apache configuration files. After some research I realized that this rewrite needed to be outside the virtual host directives but the virtual hosts needed to be able to "see" the rewrite rule. First, add the rule to apache2.conf:

/etc/apache2/apache2.conf

# Set a rewrite to change example.com to www.example.com
RewriteCond %{HTTP_HOST}   ^example\.com [NC]
RewriteCond %{HTTP_HOST}   !^$
RewriteRule ^/?(.*)        http://www.example.com/$1 [L,R,NE]

Translation: if the base url requested begins with example.com (case doesn't matter) and is not empty then rewrite what was requested to http://www.example.com plus any other characters in the request then stop further processing, issue a redirect notice and don't escape special characters. Got it?

So far, so good. Now we need to make sure that all of the virtual hosts can see this. Within each virtual host file, but not in a <Directory> directive, add the following:

RewriteEngine On
RewriteOptions Inherit 

This turns on the rewrite engine and allows rules from outside the host to use the rules in apache2.conf.

Test the changes. Don't for get that the DNS records for both example.com and www.example.com must point to your server's external IP address!

SSL

Managing Websites

Internet Perspective

• Domain registration
  • Duration
  • Privacy issues
  • Features
• Domain management
  • DNS control (A records)
  • Nameservers
• Router port forwarding

Server Perspective

Blogs (Wordpress)

Install and Setup

• mySQL considerations
• php considerations
• Blog Customization
  • Modifying css
  • Posting by email
  • Spam filtering
  • Backups (using crontab to backup dbase and directory)
  • Plugins

Updates

• Plugin updates
• Wordpress updates

Server Migration

Migration to a new server from an existing server is relatively straight forward, providing that the new server is configured similarly to the old server. The easiest migration is to an identical structure on the new server: same Document Root and database name. The Wordpress Codex describes the general steps to relocate a Wordpress blog, including more complex changes to directory structure.

NOTE: It is not recommended to make any other changes to the blog "while you are at it". Don't update plugins or the blog itself at the same time as the move. Do that before the move or afterwards.

On the new server, create the virtual host file for the blog (see the Virtual Servers section above) using the same name as the old blog, starting from the default template (or another blog virtual host file, if one exists).

cp /etc/apache2/site-available/default /etc/apache2/site-available/<blogname>

Edit the host file with the correct VirtualHost, ServerName, DocumentRoot and Directory:

Create the DocumentRoot directory as specified in the host file, usually /var/www/<blogname>

Create an index.html file in the DocumentRoot directory and test that you can see the html in a browser

Backup all the website data on the old server: Create a tarball of all files in the old root directory:

tar -czvf <blogname>backup.tar.gz /path/to/<oldblog> *

If applicable (e.g. for a Wordpress site), back up the mysql database, this is most easily done by selecting the database in webmin and creating a backup *.sql file.

Copy any other files necessary for the websites functionality (e.g. scripts that create data for the site)

Copy the backup files from the old server to the new server

scp username@oldserver /full/path/to/filename

For Wordpress create a new database in mysql, when moving a blog the databasename, username and password will typically be the same as the old site (be careful with the quotes):

$ mysql -u root -p mysql 
    mysql> mysql> CREATE DATABASE databasename;
    mysql> GRANT ALL PRIVILEGES ON databasename.* TO "username"@"hostIPaddress" IDENTIFIED BY "password";
    mysql> FLUSH PRIVILEGES;

Import the database content from the backup *.sql file (in Webmin, use the Execute SQL command)

Extract the contents of the backup tarball in the DocumentRoot directory

tar -xzvf <blogname>backup.tar.gz 

For Wordpress edit the wp-config.php file to reflect the databasename, username, password and hostIPaddress setup in mysql

Test the new site, all should be fine. If you get an "Error connecting to database", check that the data in the wp-config.php file is correct and check that the quotes were correct in the mysql command used to set up the database.

For Wordpress blogs that use the Yet Another PhotoBlog plugin, the following additional steps are require (once only, for the first blog migrated or set up on the host):

• install GD image support

apt-get install php5-gd
/etc/init.d/apache2 reload

• install imagemagick support for large images

apt-get install imagemagick
/etc/init.d/apache2 reload

• edit php setting to support large files

nano /etc/php5/apache2/php.ini
...
    upload_max_filesize = 16M  # from default of 2M
    memory_limit = 128M        # from default of 16M
...