devel.reinikainen.net

Table of contents

1. Introduction

1.1. Concepts

1.2. Revision history

1.3. Disclaimer

2. The host system

2.1. Starting point

2.2. Install a new Linux-Vserver container

2.3. Setup iptables

3. Vserver container

3.1. Install daemontools

3.2. Install openssh-server

3.3. Public key certificates

3.4. Install Denyhosts

3.5. Install cronolog

3.6. Install MySQL client

3.7. Install FSSOS

3.8. Compile Apache 2.2 from source

3.9. Compile PHP 5.3.3 from source

3.10. Install SSL certificates

4. Testing

1. Introduction

1.1. Concepts

Throughout this document, you will see either hash symbols (#) or dollar signs ($) in front of the commands. These indicate whether the command should be run as a regular user or with superuser privileges (i.e. root). Do not include these
in the commands! And by the way, copy-pasting commands is not such a great idea. I also provide my configuration files here for reference only. Please do not just copy them over to your server without fully understanding what they do. Additionally, please do not use the authors of this documents as a technical support, which we are most certainly not. Instead, you should
consult the respective softwares’ manual pages, documentations, forums and mailing lists.

For brevity’s sake, I will use “e.g.” as a shorthand for “for instance”, and “i.e.” as a shorthand for “that is” or “in other words” throughout this document. I have placed links to the respective softwares’ web sites, where you can download them and read more about them.

1.2. Revision history

11. 10. 2010 First revision.

1.3. Disclaimer

Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.

All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to make a backup of your system before major installation and should make backups at regular intervals.

2. Host system

2.1. Starting point

The platform used is a plain 32-bit version of Ubuntu 10.04 LTS (Long Term Support). Since this is a server computer, there is no X server (graphical interface) installed, so we’re installing eveything on the command line. The basic assumption here is that “everything is insecure by default”. One might say this is overly paranoid, but sometimes that’s a good thing. I will not cover the installation of the operating system itself, because it is fairly straigt-forward using Ubuntu’s installer.

The system uses a Linux-Vserver patched kernel version 2.6.22.19. By installing this patch to the Linux kernel, we are able to create vritualized containers, somewhat similar to chroots, but much more feature-rich. Each virtual container can have one or more IP addresses, and they can be restarted and upgraded individually. Linux-Vserver is very light-weight compared to, for example, Xen, and can also be seen as an alternative to KVM. It’s also a very similar concept than FreeBSD‘s jails.

I will refer to the base system running the Vserver containers as the “host system”. The Vserver containers are often also called “Virtual Private Servers” (VPS), because they allow you to have a separate environment from the host system, i.e. you can have root privileges in your own “sandbox” while not having any privileges on the host system.

I will be installing both packages and source code in this guide. The Ubuntu package search is a very handy way of searching for packages and even inside packages.

2.2. Install a new Linux-Vserver container

I find it most convenient to su to root at this point, because all of the vserver commands require root privileges. Ubuntu also provides utilities for the Linux-Vserver virtualization system in two optional packages. There are conveniently installed by running:

# apt-get install vserver-debiantools util-vserver

Next, we can proceed to create new Vserver containers. I decided to name my new container ‘www’, because it will be used for HTTP softwares. I also gave it the host name ‘www’. A new container with some basic programs is created in the following fashion:

# vserver www build -m debootstrap -n www –hostname www –interface eth0:192.168.1.3 — -d lucid -m http://fi.archive.ubuntu.com/ubuntu/ — –arch i386

This command also specified that the IP I want the container to bind to is 192.168.1.3 on the first network card (eth0). Since this is a testing environment only, it is created on a local network. The final argument ‘arch’ detonates that we wish to install a 32-bit container, because the host system is also 32-bit. Start the newly created container by running:

# vserver www start

You can verify that the Vserver container was indeed started by issuing:

# vserver-stat

This should output something similar if the container is running:

CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
40015 4 320.3M 511M 1d15h44 20h21m54 2d06h58 www

You can also check the directory /etc/vservers/www for the generated configuration files, which should have a directory structure similar to this:

$ tree /etc/vservers/www/
/etc/vservers/www/
|-- apps
| |-- init
| | `-- mark
| `-- pkgmgmt
| `-- internal
|-- context
|-- cpuset
|-- fstab
|-- interfaces
| |-- 0
| | |-- dev
| | |-- ip
| | `-- prefix
|-- name
|-- run -> /var/run/vservers/www
|-- uts
| `-- nodename
`-- vdir -> /etc/vservers/.defaults/vdirbase/www

Of couse, we’ll also want to automatically start the Vserver when we boot the computer. This is very simple to do:

# echo default > /etc/vservers/www/apps/init/mark

Now, we still need to enter the container before we can start installing software. Enter the newly created container by running:

# vserver www enter

You will automatically receive root priveleges in the Vserver also. Should you need to switch to another user inside the Vserver, you can simply use su or sudo -u .

There is a small caveat here. debootstrap, which we used earlier to build the container, does indeed get percisely the distribution you tell it to fetch, i.e. Lucid Lynx 10.04 in this case. If you wish to get the updates to Lucid, run apt in the following way inside the Vserver:

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

The “update” command will fetch the newest package lists from the Ubuntu servers and the “dist-upgrade” command will search and update any installed packages on the container which are older than in the package lists. This will make sure you have the newest updates before you start installing more software. I will install Vim, which is my preferred editor, because we are going to edit some configuration files later on.

# apt-get install wget vim

I will also install wget, which is my preferred way to download from the command line. wget is a feature-rich program, that is able to communicate over a myriad of protocols. The output of these commands will be similar to this:


Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
wget
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 242kB of archives.
After this operation, 12.3kB disk space will be freed.
Get:1 http://fi.archive.ubuntu.com lucid-updates/main wget 1.11.4-2ubuntu2.1 [242kB]
Fetched 242kB in 0s (1,371kB/s)
(Reading database ... 21764 files and directories currently installed.)
Preparing to replace wget 1.11.4-2ubuntu2 (using .../wget_1.11.4-2ubuntu2.1_i386.deb) ...
Unpacking replacement wget ...
Processing triggers for install-info ...
Setting up wget (1.11.4-2ubuntu2.1) ...

2.3. Setup iptables

Iptables will allow you to control what goes in and what goes out of the Vserver container, i.e. it works as a firewall. iptables needs to be installed on the host system. Currently, it is not possible to install iptables inside the Vserver container. I will block all traffic to the Vserver’s IP address (192.168.1.3), except for the ports that we need:

22 SSH
80 Apache HTTP (unencrypted)
443 Apache HTTPS (encrypted)
3306 MySQL

This can be achieved by running the following iptables commands on the host system:

iptables -i eth0 -P INPUT DROP
iptables -i eth0 -P OUTPUT DROP
iptables -i eth0 -P FORWARD DROP
iptables -i eth0 -A INPUT -p tcp -m multiport –dport 22,80,443,3306 -j ACCEPT
iptables -i eth0 -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -i eth0 -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

These settings will not allow any traffic in or our from the Vserver’s network interface (eth0), except for the four specified TCP ports, replies, and associated traffic. The first three rules with DROP specify the default action, after that, we allow only specific traffic.

However, these commands only set the iptables configuration for the current moment, you still need to save them if you wish them to be in effect after you reboot. Ubuntu provides a handy script for this called iptables-save. After a reboot, you can reset the firewall rules by running iptables-restore. To automate the process even further, you can just place the iptables-restore command in /etc/rc.local on the host system.

Vserver container

3.1. Install daemontools

Daemontools is a set of small helper programs by D. J. Bernstein that monitor your running daemons. If a deamon was to crash, Daemontools will automatically attempt to restart it. Installing Daemontools on Ubuntu is trivial, because there is a package for this also:

# apt-get install daemontools

Setting up daemontools will require a few directories:

# mkdir /etc/service

Also, you will need to make sure that daemontools is started when the Vserver container is started. You need to add the following line to /etc/rc.local:

/usr/bin/svscanboot &

Also make sure that the rc.local script itself is executable:

# chmod +x /etc/rc.local

/etc/rc.local will be executed automatically each time the Vserver container is “booted” i.e. when you issue “vserver www start” from the host system.

3.2. Install openssh-server

Installing the OpenSSH daemon is made really easy by apt. Simply run:

# apt-get install openssh-server libssl-dev

The libssl-dev package includes the necessary source files we’re going to need a bit later when compiling SSL support for the PHP scripting language. Apt-get is nice enough to start the daemon for you, but we want to run SSHd from Daemontools, so stop the daemon for now using:

# /etc/init.d/ssh stop

You can verify that ssh is not running by issuing:

# ps aux | grep ssh

This command should not return anything if SSH is not running. I usually deny root logins to the ssh server, because that way a user first has to login as a regular user and then use su or sudo. This way, a potential hacker needs to work harder to break the system. Simply change one line in /etc/ssh/sshd_config:

PermitRootLogin no

Next, create a small shell script so that daemontools knows to start sshd.

# mkdir -p /srv/sshd/
# vim /srv/sshd/run

Place the following contents in the run file:

#!/bin/sh
exec /usr/sbin/sshd -D 2>&1

The -D argument to sshd tells it not to fork into the background, i.e. it’s supposed to keep itself in the foreground, so that Daemontools can monitor it. The “2>&1″ is known as IO redirection, and directs STDERR to the same place as STDOUT. Daemontools also provies a logging tool, which also automatically rotates logs for you. Let’s setup that also:

# mkdir -p /srv/sshd/log/main/current
# vim /srv/sshd/log/run

The contents of that file should be as following:

$ cat /srv/sshd/log/run
#!/bin/sh
exec multilog ./main

Make sure the newly created run files are executable and start Daemontools (& tells svscanboot to go to the background, otherwise you will not get back your shell prompt):

# chmod 0700 /srv/sshd/run /srv/sshd/log/run
# svscanboot /etc/service &

Finally, make a symbolic link for Daemontools, after which it will try to bring up sshd. We will also disable the init.d startup script, because daemontools is now handling to start/stop of sshd.

# ln -s /srv/sshd /etc/service/sshd
# mv /etc/rc2.d/S16ssh /etc/rc2.d/K84ssh

Finally, you can verify that ssh is indeed running:

$ ps auxwwf
root 11959 0.0 0.0 32944 1820 ? S Sep17 0:00 /bin/sh /usr/bin/svscanboot
root 11963 0.0 0.0 3956 396 ? S Sep17 0:01 \_ svscan /etc/service
root 11965 0.0 0.0 3784 344 ? S Sep17 0:00 | \_ supervise sshd
root 11968 0.0 0.1 57796 2492 ? S Sep17 0:31 | \_ /usr/sbin/sshd -D
root 11964 0.0 0.0 3772 268 ? S Sep17 0:00 \_ readproctitle service errors: .............

You can also test that Daemontools brings up the SSH daemon if it crashes. Check using ps if sshd is running again after you issue this command:

# killall sshd

This will kill the SSHd process, but daemontools should bring it up again in a second or two.

3.3. Public key certificates

I want to be able to log into this ssh daemon from my workstation. I could just use a username and password to connect from my workstation, like this:

$ ssh jani@192.168.1.3
Using username “jani”.
jani@192.168.1.3′s password:

Now this is perfectly fine as such, but I want to automate this process. This is where SSH private key encryption comes into place. Because I have already installed ssh on my workstation, I can use the ssh-keygen tool to generate a private and public key for myself. Note that this will only work for SSH version 2, which is pretty much the standard, SSH version 1 is quite old and should not be used anymore.

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/jani/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jani/.ssh/id_dsa.
Your public key has been saved in /home/jani/.ssh/id_dsa.pub.
The key fingerprint is:
00:11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee jani@workstation

This is not my actual key fingerprint, but here for demonstration purposes only. I decided not to use a passphrase. id_dsa is the private part of the key, and should under no circumstances be distributed. The public part, on the other hand, needs to be compied to the server. I can now upload the generated public key from my workstation to the Vserver container by running the following command on my workstation:

$ scp ~/.ssh/id_dsa.pub jani@www:~

The scp command simply copies files and directories over SSH. We still need to install the newly copied key on the server. On the server we need to run:

$ echo ~/id_dsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_dsa.pub
$ chmod 0600 ~/.ssh/authorized_keys

Next time I connect from my workstation to the server, I’m not prompted for a password, but I’m still securely connected. Handy!

3.4. Install Denyhosts

Next, let’s install Denyhosts to further enchance the SSH daemon’s security. Denyhosts is an optional script designed to make brute-force attacks against the daemon harder, by automatically blocking suspicious IP addresses by adding them to /etc/hosts.deny.

# apt-get install denyhosts

Again, dpkg (the package manager behing apt-get) is nice enough to install the python scripting language interpreter (a dependancy of denyhosts) and start the denyhosts daemon for you. The configuration file is located at /etc/denyhosts.conf and offers very sensible defaults. However, we need to add the following like so that it knows to block suspicious connections to SSHd:

BLOCK_SERVICE = sshd

3.5. Install cronolog

Cronolog is a nifty small program that is able to split log files based on time and date. We will be using the to rotate Apache’s logs. Installation is really simple:

# apt-get install cronolog

There is no daemon to run here, we will later in this guide configure Apache to log to a pipe which points to cronolog.

3.6. Install MySQL client

Our newly installed system would be somewhat limited without a database backend. MySQL is a popular and free database. For example, also this WordPress blog uses MySQL as a backend. Here we will install the MySQL client and it’s libraries, so that we can use PHP to connect to a MySQL server.

# apt-get install mysql-client libmysqlclient16-dev

There is no need to install the mysql-server package, because you only need to client package to connect to an existing MySQL server. The libmysqlclient16-dev contains the necessary source files we need for compiling PHP with MySQL support. you can now test the connection to your MySQL server by running:

$ mysql -u username -p -h your.mysql.host.fi

Obviously, you need to replace the argument to switch -h with the IP address or host name of your MySQL database server. Of course, thanks to Ubuntu’s excellect package manager, it’s not much harder to install the full server in the Vserver container also, if you so desire. This is as simple as running:

# apt-get install mysql-server

3.7. Install FSSOS

Flexible Single Sign-on Solutions (FSSOS) is a new version of libnss-mysql by the same author. The purpose of this package is to replace the current /etc/passwd and /etc/group, i.e. the files that contain the user, group and password information for the user accounts defined in the Vserver container. The idea of this package is to allow you to store this information in a MySQL database. Compiling and installing this package follows the same pattern as usually:

$ tar xfvz nsvs-0.5.tar.gz
$ cd nsvs-0.5
$ ./configure
$ make
# make install

Next we need to edit /etc/nsvs.cfg, because it needs to know where to find our MySQL server. In /etc/nsvs.cfg, define:


host 192.168.1.4
database auth
username nsvsuser
password goodsecret


Save the file and exit the editor. Next, edit /etc/nsswitch.conf and add ‘mysql’ to passwd/group:


passwd: files mysql
group: files mysql


We still need to load the sample database from the nsvs package into the MySQL server:

$ mysql -u root -p -e “source sample_database.sql”

Next, give SELECT privilege (enough for successful authentication) to the nsvs user:

mysql> GRANT SELECT ON auth.* TO nsvsuser@192.168.1.3 IDENTIFIED BY ‘goodsecret’;

Log out of the MySQL server. Check that the user accounts still work by issuing:

$ id jani
uid=1001(jani) gid=5001(console) groups=5001(console)

Now you can simply add, modify and remove users and groups by editing the MySQL database instead of the traditional adduser route.

3.8. Compile Apache 2.2 from source

First we will use wget to obtain the Apache HTTP server 2.2 source code from the nearest mirror:

$ cd ~
$ wget http://www.nic.funet.fi/pub/mirrors/apache.org//httpd/httpd-2.2.16.tar.bz2
$ tar xfvj httpd-2.2.16.tar.bz2
$ cd httpd-2.2.16
$ ./configure –enable-deflate –enable-rewrite –with-ssl
$ make
# make install

Apache can be compiled with a number of modules, small parts that add functionality to the daemon. For example, the mod_deflate module (previously known as mod_gzip in Apache 1.3) enables compression of the data between the server and the client, thus saving bandwidth. mod_rewrite is a very powerful tool for doing all sorts of routing with URLs. –with-ssl enables support for the SSL encryption protocol, which is needed when we install the SSL certificates later on.

mod_perl

mod_perl is a module that enables the use of the Perl scripting language. This module is not included in the Apache distribution, so we need to install it separately:

$ cd ~
$ wget http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz
$ tar xfvz mod_perl-2.0-current.tar.gz
$ cd mod_perl-2.0.4
$ perl Makefile.PL MP_APXS=/usr/local/bin/apxs
$ make
$ make test
$ sudo make install

The APXS tool is installed along with Apache. It is a tool that “glues” Apache and third-party modules together.

mod_vhs

mod_vhs is a module which enables “mass virtual hosting”, i.e. it makes it easier to manage multiple web sites hosted on the same Apache web server. This module is also not included by default, so we need to download and install it now. The preferred version of mod_vhs is located in a Subversion repository (a source code repository), which can be obtained using the svn command.

$ cd ~
$ svn co https://svn.oav.net/openvisp/mod_vhs

However, after further investigation, it turns out that mod_vhs is too unstable for production use, at least on this system, so I will leave it out of the final software mix.

3.9. Compile PHP 5.3.3 from source

Again, I will change to my home directory and use wget to obtain the PHP source code from the closest mirror:

$ cd ~
$ wget http://fi.php.net/get/php-5.3.3.tar.bz2/from/this/mirror
$ tar xfvj php-5.3.3.tar.bz2

I will also install the Suhosin patch to enhance PHP’s security. I will only install the Suhosin Patch and not the full Extension, since I have found the patch to be sufficient. Depending on your level of paranoia, you could opt for the full Extension also.

$ wget http://download.suhosin.org/suhosin-patch-5.3.3-0.9.10.patch.gz
$ gunzip suhosin-patch-5.3.3-0.9.10.patch.gz
$ cd php-5.3.3
$ patch -p 1 -i ../suhosin-patch-5.3.3-0.9.10.patch

After patching PHP, we are finally ready to compile it. I have used several options to configure, because I have wanted to include some modules that provides extra functionality for my PHP scripts. For example, –enable-ftp will allow me to handle FTP connections from PHP, –with-zlib –with-bz2 allow me to handle compressed libraries, –with-gd enables image processing functions, –with-mcrypt will enable additional encryption functions and so on.

$ ./configure –enable-cgi –with-pear –with-openssl –with-zlib \
–with-bz2 –enable-ftp –with-gd –with-kerberos \
–with-mysqli=/usr/bin/mysql_config –enable-calendar –with-imap \
–with-imap-ssl –with-curl –with-jpeg-dir=/usr/local/lib/ –with-freetype-dir \
–enable-pdo=shared –with-pdo-mysql=shared –with-sqlite=shared \
–with-pdo-sqlite=shared –with-mysql –enable-zend-multibyte –with-snmp \
–enable-ucd-snmp-hack –with-gettext –with-xmlrpc –with-mcrypt \
–enable-mbstring –enable-pcntl –enable-posix –enable-fpm

All of the available arguments that can passed to configure can be viewed by issuing:

./configure –help

Assuming configure did not return any errors, you can proceed to the actual compilation:

$ make
$ make test
$ sudo make install

Xdebug

Xdebug is an excellent PHP extension for developers. It provides debugging information, such as stack straces, to ease your development tasks. Also, it’s reasonably simple to install because we compiled PHP with PEAR (by passing –with-pear to ./configure) and thus also the PECL command is included:

# pecl install xdebug
# vim /usr/local/lib/php.ini

After installation, we need to edit /usr/local/lib/php.ini and add a line for Xdebug, so that PHP knows to load the extension.

zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so

For security reasons, I have also decided to disable some of PHP’s functions, to procect the system. I disabled some commands by entering the following line in php.ini:

disable_functions = exec,escapeshellcmd,syslog,openlog,leak, disk_free_space,diskfreespace, disk_total_space,chroot, posix_mkfifo,link,symlink,popen,proc_open

Save and close the file (:wq in Vim) and verify that the PHP installation is successful by running:

$ php -v

This command should output something like the following:

PHP 5.3.3 with Suhosin-Patch (cli) (built: Oct 04 2010 11:11:13)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

Alternative PHP Cache

To enhance the performance of PHP, I will install Alternative PHP Cache (APC), which caches generated dynamic pages, also known as an opcode cache. Other popular opcode caches include Zend Optimizer. Installing APC is just as easy as installing Xdebug:

# pecl install apc

The output of this command starts by:

downloading APC-3.0.19.tgz …
Starting to download APC-3.0.19.tgz (115,735 bytes)
……………………done: 115,735 bytes
47 source files, building
running: phpize
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626

Again, we need to edit /usr/local/lib/php.ini and add a few lines for APC:

extension=apc.so
apc.enabled=1
apc.shm_size=30

PHP-FPM

PHP-FPM is a new exciting feature in PHP 5.3.3. It has been available before as a separate module, but has now been integrated into the main PHP distribution. Previosly, I have had good success with php-fastcgi and Apache 1.3. PHP-FPM and php-fastcgi are both designed to further enhance the performance of PHP by spwning some PHP processes and handling requests through them. We already compiled the FPM feature into PHP earlier by issuing –enable-fpm to the configure command for PHP. We still need to start the PHP-FPM daemon:

# php-fpm start

Should you encounter an problems, you can always check the log file for PHP-FPM:

$ tail -f /var/log/php-fpm.log

You can get your command prompt back by pressing Ctrl-C to terminate the tail program.

3.10. Install SSL certificates

As a final security measure, I wish to offer my users HTTPS access to the web server. This way all traffic between the client (browser) and the server (Apache) will be encrypted, as long as the user uses an URL that starts with https://…

I use RapidSSL certificates, because they offer good value for money. The SSL certificates are the only part of this guide that are not open source. Installing the certificates I have bought from RapidSSL only requires that you copy the certificate (.crt) and the key file to the server and place the following diretive in Apache’s configuration file /etc/apache2/httpd.conf

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/certs/server.key

I have decided to place the SSL files in /etc/ssl/certs, since that has been the preferred location in Debian. You will need to replace the files each time you renew your certificate.

4. Testing

It’s finally time to test the setup. Start the Apache web server by running:

# apachectl -k start

Again, you can use top or ps to check that the process is running. Point your browser to http://192.168.1.3/ to see if there is a reply. You should receive the generic Apache welcoming page. Next, try https://192.168.1.3/ to see if you get the same page, but over an encrypted connection. Good old telnet is also a handy tool for testing from the command line:

$ telnet localhost 80
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
GET /

This should output the default Apache welcoming page in raw HTML form. Now, we still need to test that PHP works with Apache. Just because it works from the command line does not necessarity mean that Apache plays nicely with it. Create a simple PHP file in the web root for Apache:

$ echo '<?php echo phpinfo(); ?>' > /var/www/info.php

When pointing your browser to http(s)://192.168.1.3/info.php you should get the PHP information page, which contains all of the configuration options for your PHP installation. If you get this page, PHP is working with Apache, congratulations! It not a good idea to leave this script open to the public if your server is reachable from the outside world and not just on the local network, because it exposes the inner workings of your server. You can remove the file or replace its contents with something else:

$ cat <<EOF > /var/www/info.php
> <?php
> while ($i<5) {
> echo 'Hello world!<br>';
> $i++;
> }
> ?>
> EOF


The setup is now all done. You can exit the Vserver container by pressing Ctrl-D to be returned to the host system. You can even test that all startup scripts inside the Vserver container are properly set up by restarting the container from the host system:

# vserver www restart

If everything is correctly set up, Daemontools, Denyhosts, SSHd, Apache and php-fpm should all be automatically started. While this is a suitable system for testing, before moving this setup to a production environment, you could to check the following things;

• Since it is a VPS, you can even remove the root user, because you will get a “virtual” root user each time you enter the Vserver.
• Make sure all file permissions are correct. World writeable/executable files in the web root are generally a bad idea.

This entry was posted on Monday, October 11th, 2010 at 23:09 and is filed under Linux/BSD Server Solutions. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.