OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Shared webhosting

2006-09-29T09:13:39Z

Hvdkamer: /* Other applications */

{{roughstub}}

== The problem ==

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these.

== The solution ==

[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]

You can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you probably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method. One possible solution is dedicated webhosting, but most users don't have the experience to maintain a server or it is way to expensicve for them.

The main problem with shared webhosting is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting server is shown in the figure above.

[[Category:HOWTO]]

Processes scope and visibility

2006-09-04T09:19:03Z

Hvdkamer: /* "Poor man's vzps in bash" */

This [[:Category:HOWTO|HOWTO]] shows how OpenVZ [[hardware node]] administrator can see a processes belonging to the host system only, or to a particular [[VE]].

== Problem ==
From [[VE0]] one can see all the processes running on the system; that includes all the processes of all [[VE]]s and the processes of the [[host system]] itself. Sometimes you just want to see the processes from the host system only. Sometimes you just want to see the processes from a particular VE.

There are many ways to achieve it.

== Solutions ==

=== "Poor man's vzps in bash" ===
Use the following script by aistis, modified by kir.

First argument is VE ID (0 for the host system), all the remaining arguments are passed to <code>ps(1)</code> utility.

<pre>
#!/bin/bash
# Usage: ./ovzps VEID [ps flags ...]

function find_ve_pids(){
local pid
local myveid=$1
local vepids=

for pid in $ALLPIDS; do
[ -f /proc/$pid/status ] || continue
veid=`grep envID /proc/$pid/status | awk -F: '{print $2}'`
if [ ${veid} = ${myveid} ]; then
vepids="$vepids $pid"
fi
done
echo "$vepids"
}

ALLPIDS=`ps -A -o pid --no-headers`
VEPIDS=`find_ve_pids $1`
shift

if [ -n "${VEPIDS}" ]; then
ps $* -p $VEPIDS
else
exit 0
fi
</pre>

=== Use vzprocps tools ===
Take <code>vzprocps</code> tools from http://download.openvz.org/contrib/utils/.
These are usual <code>ps</code> and <code>top</code> utilities (named <code>vztop</code> and <code>vzps</code> to not conflict with the standard ones) with an <code>-E</code> option added. You can use <code>-E <i>VEID</i></code> option to limit the output to the selected VEID (use 0 for the host system), or just <code>-E</code> without an argument to just add VEID column to output.

== See also ==
* {{Forum|836}}

[[Category: HOWTO]]

UBC consistency check

2006-08-30T14:54:02Z

Hvdkamer:

{{UBC toc}}

System resource control parameters have certain interdependencies. Constraints on the parameter settings are listed below. Indexes <code>bar</code> and <code>lim</code> in the formulae below mean the barrier and the limit of the parameters, respectively.

Configuration of resource control parameters for a Virtual Environment
is invalid if these constraints are not satisfied. The best way to ensure the
validity of the configuration is to use [http://openvz.org/documentation/man/vzcfgvalidate.8 vzcfgvalidate(8)] utility.

All the interdependencies discussed below and their importance are summarized in [[UBC interdependencies table]].

The configured limits can be checked through
* <code>/proc/user beancounters</code> interface;
* Virtual Environment configuration files in <code>/etc/vz/conf/</code> directory.

== kmemsize should be enough for the expected number of processes ==
<math>kmemsize_{bar} \ge 40KB \cdot avnumproc + dcachesize_{lim}</math>

(<code>avnumproc</code> here stands for the expected average number of processes).

This constraint is important for reliable work of applications in the
Virtual Environment.
If it is not satisfied, applications will start to fail at the middle of
operations instead of failing at the moment of spawning more processes,
and the application abilities to handle resource shortage will be very
limited.

== Memory allocation limits should not be less than the guarantee ==
<math> privvmpages_{bar} \ge vmguarpages_{bar}</math>

If this constraint is not satisfied, <code>vmguarpages</code> will not work.

== Send buffers should have enough space for all sockets ==
<math>tcpsndbuf_{lim} - tcpsndbuf_{bar} \ge 2.5KB \cdot numtcpsock</math>

<math>othersockbuf_{lim} - othersockbuf_{bar} \ge 2.5KB \cdot numothersock</math>

These constraints are also important.
If they are not satisfied, transmission of data over the sockets
may hang in some circumstances.

== Other TCP socket buffers should be big enough ==
<math>tcprcvbuf_{lim} - tcprcvbuf_{bar} \ge 2.5KB \cdot numtcpsock</math>

<math>tcprcvbuf_{bar} \ge 64KB</math>

<math>tcpsndbuf_{bar} \ge 64KB</math>

Selecting the left side equal to the right side in the inequalities
above ensures minimal performance of network communications.
Increasing the left side will increase performance to certain extent.

== UDP socket buffers should be big enough if the system is not tight on memory ==
<math>dgramrcvbuf_{bar} \ge 129KB</math>

<math>othersockbuf_{bar} \ge 129KB</math>

These constraints are desired, but not essential.
Big enough buffers for UDP sockets improve reliability of datagram delivery.
However, note that if the UDP traffic is so bursty that it needs larger
buffers, the datagrams will likely be lost not because of resource control
limits, but because of other memory and performance limitations.

== Number of file limit should be adequate for the expected number of processes ==
<math>numfile \ge avnumproc \cdot 32</math>

Note that each process after <code>execve(2)</code> system call
requires a file for each loaded shared library.
Too low <code>numfile</code> limit will increase the chances of failures
during <code>execve(2)</code> call with diagnostics not clear
for the users.

== The limit on the total size of <code>dentry</code> and <code>inode</code> structures locked in memory should be adequate for allowed number of files ==

<math>dcachesize_{bar} \ge numfile \cdot 384\ \rm(bytes)</math>

Too low <code>dcachesize</code> limit will increase the chances of
file operation refusals not expected by applications.

== Barrier should be less or equal than limit ==
In addition to the conditions listed above,

<math>barrier \le limit</math>

should be maintained for each parameter.

[[Category:Troubleshooting]]

Resource shortage

2006-08-17T11:04:35Z

Hvdkamer:

Sometimes you see a strange fails from some programs inside your [[VE|Virtual Environment]]. In some cases it means one of the resources controlled by OpenVZ hit the limit.

The first thing to do is to check the contents of /proc/user_beancounters file in your [[VE]]. The last column of output is fail counter. Each time a resource hit the limit, fail counter is increasing. So, if you see non-zero values in failcnt column that means something is wrong.

There are two ways to fix the situation: reconfigure (in some cases recompile) the application, or change the resource management settings.

== [[UBC]] parameters ==

Here is the example of current [[UBC]] values obtained from <code>/proc/user_beancounters</code> file in VE 123:
<pre>
# cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
123: kmemsize 836919 1005343 2752512 2936012 0
lockedpages 0 0 32 32 0
privvmpages 4587 7289 49152 53575 0
shmpages 39 39 8192 8192 0
dummy 0 0 0 0 0
numproc 20 26 65 65 0
physpages 2267 2399 0 2147483647 0
vmguarpages 0 0 6144 2147483647 0
oomguarpages 2267 2399 6144 2147483647 0
numtcpsock 3 3 80 80 0
numflock 3 4 100 110 0
numpty 1 1 16 16 0
numsiginfo 0 1 256 256 0
tcpsndbuf 0 0 319488 524288 0
tcprcvbuf 0 0 319488 524288 0
othersockbuf 6684 7888 132096 336896 0
dgramrcvbuf 0 8372 132096 132096 0
numothersock 8 10 80 80 0
dcachesize 87672 92168 1048576 1097728 0
numfile 238 306 2048 2048 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 16 128 128 0
</pre>

You can see if you hit the limits for some [[UBC]] parameters by analyzing the last column (named <code>failcnt</code>). It shows a number of fails for this counter, i.e. a number of times a parameter hit the limit. Usually what you need to do is to increase the parameter in question. But you need to do it carefully, and here is how.

<ol>
<li>Get the current values for the parameter's barrier and limit. For example, we want to increase kmemsize values from the example at . From <code>/proc/user_beancounters</code> we see that <code>kmemsize</code> barrier is 2752512, and its limit is 2936012.
</li>

<li>Increase the values. Say, we want to increase <code>kmemsize</code> by 2 times. This is how it can be done using built-in bash arithmetics:
<pre>
# vzctl set 123 --kmemsize $((2752512*2)):$((2936012*2)) --save
</pre>
By using <code>--save</code> flag, we denote we want to both apply the new settings to the running VE, and save them in the configuration file (from which they will be taken during next VE start).
</li>

<li>Check the new configuration. Issue the following command:
<pre>
# vzcfgvalidate /etc/vz/conf/123.conf
</pre>
If something is wrong, you need to fix it as suggested by the utility.
</li>
</ol>

For more in-depth explanation of different parameters, their meaning and how to set them properly, see [[setting UBC parameters]].

== Disk quota ==
To check if your [[VE]] ran out of its disk quota, use the following commands (inside a VE):
<pre>
# df
Filesystem 1K-blocks Used Available Use% Mounted on
simfs 1048576 327664 720912 32% /
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
simfs 200000 18857 181143 10% /
</pre>

First command shows disk space usage, and second command shows the inodes usage (you can roughly see inodes as a number of files/directories on your system).

If one of the commands give you usage of 100%, that means you hit one of the disk quota limit.

You can increase the limit from the host system ([[VE0]]) only. This is how:
<ol>
<li>Get the current values for disk quota:
<pre># vzquota stat 123
resource usage softlimit hardlimit grace
1k-blocks 327664 1048576 1153434
inodes 18857 200000 220000
</pre>
</li>

<li>To increase the disk space quota, use vzctl set --diskspace. For example, we want to increase it by a factor of 2:
<pre>
vzctl set 123 --diskspace $(( 1048576*2 )):$(( 1153434*2 )) --save
</pre>
</li>

<li>To increase the disk inodes quota, use <tt>vzctl set --diskinodes</tt>. For example, we want to increase it by a factor of 3:
<pre>
vzctl set 123 --diskinodes $(( 200000*3 )):$(( 220000*3 )) --save
</pre>
</li>
</ol>

{{Note|shell does not support floating-point arithmetics, i.e. you can not use expressions like <code>$(( 220000*1.5 ))</code>. To use floating point, try <code>bc</code> instead, something like this: <code><nowiki>$(echo 220000*1.5 | bc)</nowiki></code>.}}

[[Category:Troubleshooting]]
[[Category:HOWTO]]

UBC parameter units

2006-08-17T11:02:13Z

Hvdkamer: /* Overriding default units */

== UBC default units ==

# entries which name has word 'page' are measured in memory pages (4kb on x86 and x86-64, 16kb for IA64). These are privvmpages, oomguarpages and others.
# entries with names like 'num*' are measured in items. i.e. numproc - number of processes, numiptent - number of iptables entries.
# other entries like kmemsize, tcprcvbuf/tcpsndbuf are measured in bytes

== Overriding default units ==

You can set parameter units implicitly when appropriate, for example:

* Set kmemsize limit to 512 Kb
<pre>
# vzctl set --kmemsize 512k
</pre>

* Set privvmpages limit to 256 Mb
<pre>
# vzctl set --privvmpages 256m
</pre>

* Set tcprcvbuf limit to 1000 pages (totals to almost 4 Mb on x86)
<pre>
# vzctl set --tcprcvbuf 1000p
</pre>

Shared webhosting

2006-08-03T09:41:46Z

Hvdkamer: /* The problem */

'''Note: This article is not finished and at the moment a rough draft. Please modify :-)'''

== The problem ==

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these.

== The solution ==

[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]

You can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you probably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method. One possible solution is dedicated webhosting, but most users don't have the experience to maintain a server or it is way to expensicve for them.

The main problem with shared webhosting is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:40:10Z

Hvdkamer: /* The solution */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these.

== The solution ==

[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]

You can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you probably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method. One possible solution is dedicated webhosting, but most users don't have the experience to maintain a server or it is way to expensicve for them.

The main problem with shared webhosting is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:35:26Z

Hvdkamer: /* The problem */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these.

== The solution ==

[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]

As said, you can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method.

Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:32:05Z

Hvdkamer: /* The solution */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]

As said, you can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method.

Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:31:22Z

Hvdkamer: /* The solution */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

[[Image:Shared hosting1.png|360px|right|The OpenVZ way of shared webhosting]]

As said, you can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method.

Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:29:53Z

Hvdkamer: /* The solution */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

[[Image:Shared hosting1.png|300px|right|The OpenVZ way of shared webhosting]]

As said, you can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method.

Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Category:HOWTO]]

Shared webhosting

2006-08-03T09:26:09Z

Hvdkamer: /* The solution */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

As said, you can waste hours of time in securing all the possible things you don't want in your shared webhosting environment. And unless you are very familiar with all the things modern scripting languages can do, you pronbably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselve victims of a comprimised host. Learning the hard way is by far the most effective method.

Instead of the above route, we take a different approach. The main problem is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read alle files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely seperate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Talk:Shared webhosting

2006-08-02T15:42:47Z

Hvdkamer: /* Rename? */

--[[User:Hvdkamer|Hvdkamer]] 08:23, 2 August 2006 (EDT)
I probably did something stupid, but how can I link from the HOWTO's to this page?
: If you want to link to the Category:HOWTO, you put it like this
: <code><nowiki>[[:Category:HOWTO HOWTOs (i.e. this is link text)]]</nowiki></code>
: If you want your article to be included into HOWTO category, you put it like this (in any part of the article, usually at the end):
: <code><nowiki>[[Category:HOWTO]]</nowiki></code>
: --[[User:Kir|Kir]] 09:51, 2 August 2006 (EDT)

== Rename? ==

I suggest renaming the article to something like "Application separation" or "Services separation" since this is what you actually describe :) --[[User:Kir|Kir]] 10:22, 2 August 2006 (EDT)

Go ahead if you think it describes the content better. I started to investigate OpenVZ because I had serious problems with shared hosting. The minimal servers (it is only a rough draft at this moment) are the solution to that. You could see this as application seperation, but for the end-user it is a "normal" webhosting account. Only he/she can do much more and can not break his/her prison :-)
--[[User:Hvdkamer|Hvdkamer]] 10:28, 2 August 2006 (EDT)

May be to explain better my choice. After some serious problems with PHP (users who knew where an include with passwords lived, could see the content) I started to investigate the option of Apache threads with its own user credentials. That was the abonded project perchild. So there is not an easy technical solution. Also users hate safe_mode and open_basedir because it breaks there applications. They also want obscure CGI-scripts and all the things we administrators hate. I already used chrooted OpenSSH shell accounts. With the minimal servers I take that one step further. Now every user has total control (he/she can even be root) over his/her space.

If I had to do my research again, I think I would still start with "shared webhosting". Not "application seperation". I think that my term, although not exactly correct, will draw more people to this site. I think of it as "user seperation", but that is the whole point of OpenVZ? As said, its your Wiki, so change it if you think it is better :-)
--[[User:Hvdkamer|Hvdkamer]] 10:40, 2 August 2006 (EDT)

I changed the introduction to give some examples of the problems shared webhosting is facing. I think that you now could see were it is going? I'm still in the process of setting up this server. So I thought to start this page while I'm working on it. Because if you do it weeks later, most subtle points are lost :-)
--[[User:Hvdkamer|Hvdkamer]] 11:42, 2 August 2006 (EDT)

Talk:Shared webhosting

2006-08-02T15:42:28Z

Hvdkamer:

Shared webhosting

2006-08-02T15:37:10Z

Hvdkamer: /* The problem */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

Instead of wasting time to secure all the possible things you don't want as a webhoster and in the process frustrate your clients, it is far better, easier and more flexible to give every account its own environment. OpenVZ is ideal for this. In this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Shared webhosting

2006-08-02T15:36:10Z

Hvdkamer: /* The problem */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python or Perl are to powerfull. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. Another example is [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Again there is a solution in the form of safe_mode, but lots of PHP scripts break if you enable this. For Python, Perl or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these. Most users don't want to hear about security (unless you show them how easy it is) and just want there scripts to work. Some do care, but his/her own server is much to expensive. And finally we didn't talk about hidden bugs in almost every security measure we mentioned. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

Instead of wasting time to secure all the possible things you don't want as a webhoster and in the process frustrate your clients, it is far better, easier and more flexible to give every account its own environment. OpenVZ is ideal for this. In this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Shared webhosting

2006-08-02T15:20:32Z

Hvdkamer:

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages as PHP, Python or Perl are to powerfull. They can read almost every file on the system. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. And with Python, Perl or CGI-scripts there is no easy way. Plus that users don't care if it is about security (unless you show them how easy it is), so there is a big dillema. And we didn't even talk about hidden bugs in almost every security measure we take. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer.

== The solution ==

Instead of wasting time to secure all the possible things you don't want as a webhoster and in the process frustrate your clients, it is far better, easier and more flexible to give every account its own environment. OpenVZ is ideal for this. In this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Shared webhosting

2006-08-02T15:19:04Z

Hvdkamer: /* Shared webhosting */

== The problem ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting (i.e. different people with each his/her own webpages) is that modern script languages as PHP, Python or Perl are to powerfull. They can read almost every file on the system. For example take the following PHP script:

<pre>
<?php

function get_content($filename) {
$handle = fopen($filename, 'r');
echo fread($handle, filesize($filename));
fclose($handle);
}

get_content('/home/ppuk34/www/forum/config.inc.php');

?>
</pre>

With PHP you could use open_basedir to prevent this, but there are more ways. And with Python, Perl or CGI-scripts there is no easy way. Plus that users don't care if it is about security (unless you show them how easy it is), so there is a big dillema. And we didn't even talk about hidden bugs in almost every security measure we take. A knowledgeable person can almost certain find backdoors because of the vast amount of possibilities these scripting languages offer. Instead of wasting time to secure all the possible things you don't want as a webhoster and in the process frustrate your clients, it is far better, easier and more flexible to give every account its own environment. OpenVZ is ideal for this. In this article we describe how shared webhosting with OpenVZ could be implemented.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Talk:Shared webhosting

2006-08-02T15:02:59Z

Hvdkamer: /* Rename? */

Talk:Shared webhosting

2006-08-02T14:40:19Z

Hvdkamer: /* Rename? */

--[[User:Hvdkamer|Hvdkamer]] 08:23, 2 August 2006 (EDT)
I probably did something stupid, but how can I link from the HOWTO's to this page?
: If you want to link to the Category:HOWTO, you put it like this
: <code><nowiki>[[:Category:HOWTO HOWTOs (i.e. this is link text)]]</nowiki></code>
: If you want your article to be included into HOWTO category, you put it like this (in any part of the article, usually at the end):
: <code><nowiki>[[Category:HOWTO]]</nowiki></code>
: --[[User:Kir|Kir]] 09:51, 2 August 2006 (EDT)

== Rename? ==

I suggest renaming the article to something like "Application separation" or "Services separation" since this is what you actually describe :) --[[User:Kir|Kir]] 10:22, 2 August 2006 (EDT)

Go ahead if you think it describes the content better. I started to investigate OpenVZ because I had serious problems with shared hosting. The minimal servers (it is only a rough draft at this moment) are the solution to that. You could see this as application seperation, but for the end-user it is a "normal" webhosting account. Only he/she can do much more and can not break his/her prison :-)
--[[User:Hvdkamer|Hvdkamer]] 10:28, 2 August 2006 (EDT)

May be to explain better my choice. After some serious problems with PHP (users who knew where an include with passwords lived, could see the content) I started to investigate the option of Apache threads with its own user credentials. That was the abonded project perchild. So there is not an easy technical solution. Also users hate safe_mode and open_basedir because it breaks there applications. They also want obscure CGI-scripts and all the things we administrators hate. I already used chrooted OpenSSH shell accounts. With the minimal servers I take that one step further. Now every user has total control (he/she can even be root) over his/her space.

If I had to do my research again, I still start with "shared webhosting". Not "application seperation". I think that my term, although not exactly correct, will drwa more people to this site. Bu as said, if its your Wiki. If you want to change it, go ahead.
--[[User:Hvdkamer|Hvdkamer]] 10:40, 2 August 2006 (EDT)

Talk:Shared webhosting

2006-08-02T14:39:46Z

Hvdkamer:

--[[User:Hvdkamer|Hvdkamer]] 08:23, 2 August 2006 (EDT)
I probably did something stupid, but how can I link from the HOWTO's to this page?
: If you want to link to the Category:HOWTO, you put it like this
: <code><nowiki>[[:Category:HOWTO HOWTOs (i.e. this is link text)]]</nowiki></code>
: If you want your article to be included into HOWTO category, you put it like this (in any part of the article, usually at the end):
: <code><nowiki>[[Category:HOWTO]]</nowiki></code>
: --[[User:Kir|Kir]] 09:51, 2 August 2006 (EDT)

== Rename? ==

I suggest renaming the article to something like "Application separation" or "Services separation" since this is what you actually describe :) --[[User:Kir|Kir]] 10:22, 2 August 2006 (EDT)

Go ahead if you think it describes the content better. I started to investigate OpenVZ because I had serious problems with shared hosting. The minimal servers (it is only a rough draft at this moment) are the solution to that. You could see this as application seperation, but for the end-user it is a "normal" webhosting account. Only he/she can do much more and can not break his/her prison :-)
--[[User:Hvdkamer|Hvdkamer]] 10:28, 2 August 2006 (EDT)

May be to explain better my choice. After some serious problems with PHP (users who knew where an include with passwords lived, could see the content) I started to investigate the option of Apache threads with its own user credentials. That was the abonded project perchild. So there is not an easy technical solution. Also users hate safe_mode and open_basedir because it breaks there applications. They also want obscure CGI-scripts and all the things we administrators hate. I already used chrooted OpenSSH shell accounts. With the minimal servers I take that one step further. Now every user has total control (he/she can even be root) over his/her space.

If I had to do my research again, I still start with "shared webhosting". Not "application seperation". I think that my term, although not exactly correct, will drwa more people to this site. Bu as said, if its your Wiki. If you want to change it, go ahead.

Shared webhosting

2006-08-02T14:29:58Z

Hvdkamer: /* Shared webhosting */

== Shared webhosting ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting is that modern script languages as PHP, Python or Perl are to powerfull. They can read almost every file on the system. There are some tricks to prevent some of this, but it is not an easy task. All to often a knowledgeable person can find backdoors because of the vast amount of possibilities these scripting languages offer. The ultimate solution is to lock all the webhosting accounts in there own environment. OpenVZ is ideal for this.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need to set up [[Using NAT for VE with private IPs|destination NAT on VE0]] from high numbered ports to port 22 on the given private IP address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Talk:Shared webhosting

2006-08-02T14:28:45Z

Hvdkamer: /* Rename? */

Talk:Shared webhosting

2006-08-02T14:28:16Z

Hvdkamer:

Shared webhosting

2006-08-02T14:17:13Z

Hvdkamer: /* Minimal server */

== Shared webhosting ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting is that modern script languages as PHP, Python or Perl are to powerful. They can read almost every file on the system. There are some tricks to prevent some of this, but it is not an easy task. All to often a knowledgeable person can find backdoors because of the vast amount of possibilities these scripting languages offer. The ultimate solution is to lock all the webhosting accounts in there own environment. OpenVZ is ideal for this.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need [[http://wiki.openvz.org/Using_NAT_for_VE_with_private_IPs destination NAT on VE0]] from high numbered ports to port 22 on the given private IP-address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Shared webhosting

2006-08-02T14:12:29Z

Hvdkamer: /* Other applications */

== Shared webhosting ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting is that modern script languages as PHP, Python or Perl are to powerful. They can read almost every file on the system. There are some tricks to prevent some of this, but it is not an easy task. All to often a knowledgeable person can find backdoors because of the vast amount of possibilities these scripting languages offer. The ultimate solution is to lock all the webhosting accounts in there own environment. OpenVZ is ideal for this.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need destination NAT on VE0 from high numbered ports to port 22 on the given private IP-address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

[[Category:HOWTO]]

Talk:Shared webhosting

2006-08-02T12:23:50Z

Hvdkamer:

--[[User:Hvdkamer|Hvdkamer]] 08:23, 2 August 2006 (EDT)
I probably did something stupid, but how can I link from the HOWTO's to this page?

Shared webhosting

2006-08-02T12:21:23Z

Hvdkamer: /* Proxy webserver */

== Shared webhosting ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting is that modern script languages as PHP, Python or Perl are to powerful. They can read almost every file on the system. There are some tricks to prevent some of this, but it is not an easy task. All to often a knowledgeable person can find backdoors because of the vast amount of possibilities these scripting languages offer. The ultimate solution is to lock all the webhosting accounts in there own environment. OpenVZ is ideal for this.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need destination NAT on VE0 from high numbered ports to port 22 on the given private IP-address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.11:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

Shared webhosting

2006-08-02T12:17:11Z

Hvdkamer:

== Shared webhosting ==

'''Note: this is my first try to create an Wiki article. Please modify :-)'''

One of the problems with shared webhosting is that modern script languages as PHP, Python or Perl are to powerful. They can read almost every file on the system. There are some tricks to prevent some of this, but it is not an easy task. All to often a knowledgeable person can find backdoors because of the vast amount of possibilities these scripting languages offer. The ultimate solution is to lock all the webhosting accounts in there own environment. OpenVZ is ideal for this.

=== Minimal server ===

Create an VEx with your favorite distro. Give it an internal IP-address in one of the ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. Then strip away all unessary init.d scripts so only the bare minimum is started. That means as a minimum syslogd and ssh so the account holder can upload his/her files through SCP/SFTP in his/her own minimal server. For this to work you need destination NAT on VE0 from high numbered ports to port 22 on the given private IP-address:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

The other thing you want for webhosting is of course a webserver as well. To minimize the amount of needed memory, we choose [http://www.lighttpd.net/ Lighttpd] instead of the common Apache. Then configure the scripting language of your choice to run under this webserver. It is possible to use different languages/setups for different accounts as well. Also problematic CGI-scripts are not problematic anymore...

=== MySQL server ===

Most webhosting accounts use MySQL, but if you prefer another database server, go ahead. Create a new VEx with a lot more resources and again an internal IP-address. Now configure the accounts. As an extra security measure you can use the internal IP-address as well.

=== Proxy webserver ===

Because we have only one public IP-address, we need an trick to access every minimal server based on the hostname in the HTTP request. For SSH we used different ports, but that is not an option for websites. Again we create an VEx with an internal IP-address. On this server we install Lighttpd as well, because the proxying is very simple. If someone has an working example with Apache, please add. First we must forward port 80 to this server:

<pre>
dnat="-j DNAT --to-destination"

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -A PREROUTING -p TCP -d <external IP-address> --dport 80 $dnat 192.168.13.32:80
iptables -t nat -A PREROUTING -p TCP --dport 10122 $dnat 192.168.13.101:22
iptables -t nat -A PREROUTING -p TCP --dport 10222 $dnat 192.168.13.102:22
...
</pre>

Then we create for every website an section in /etc/lighttpd/lighttpd.conf as follows:

<pre>
$HTTP["host"] == "ve101.armorica.tk" {
proxy.server = ( "" => ( ( "host" => "192.168.13.101" ) ) )
}
</pre>

You can map more names to the same IP-address if needed. The last step is to add mod_proxy to the server.modules section.

=== Other applications ===

Create for other applications as mail, make sure that the minimal servers use this one for sending mail from webpages, DNS etc. VEx as needed. The resulting sever looks something lik this:

[[Image:Shared hosting1.png]]

File:Shared hosting1.png

2006-08-02T12:12:22Z

Hvdkamer: VE0 is the yellow block, supporting servers are in pink and the minimal servers are in mintgreen.

VE0 is the yellow block, supporting servers are in pink and the minimal servers are in mintgreen.

Using NAT for container with private IPs

2006-08-02T10:56:14Z

Hvdkamer: /* How to provide access for VE to Internet */

== How to provide access for VE to Internet ==

To enable the [[VE]]s, which have only internal IP addresses, to access the Internet, SNAT (Source Network Address Translation, also known as IP masquerading) should be configured on the [[Hardware Node]]. This is ensured by the standard Linux <tt>iptables</tt> utility. To perform a simple SNAT setup, execute the following command on the [[Hardware Node]]:
<pre>
# iptables -t nat -A POSTROUTING -s src_net -o eth0 -j SNAT --to ip_address
</pre>

where <tt>src_net</tt> is a range of IP addresses of VEs to be translated by SNAT, and <tt>ip_address</tt> is the external IP address of your [[Hardware Node]]. Multiple rules are allowed, for example, in case you wish to specify several ranges of IP addresses. If you are using a number of physical network interfaces on the [[Hardware Node|Node]], you may need to specify a different interface for outgoing connections, e.g. <tt>-o eth2</tt>.

To make all IP addresses to be translated by SNAT (not only the ones of [[VE]]s with private addresses), you should type the following string:
<pre>
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to ip_address
</pre>

{{Note|If the above is not working then check if one of the following solutions does the trick.}}
1. If you are using stable (currently 2.6.8-based) kernel, then to enable SNAT for the VEs on your local network you need to explicitly enable connection tracking in [[VE0]]. Make sure that the following string is present in the <tt>/etc/modprobe.conf</tt> file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

In case it is not, add this string to the file by means of any text editor (for example, vi). This setting is not needed for kernels more recent than 2.6.8, since connection tracking for [[VE0]] is enabled by default in those kernels.

2. For unknown reasons the above didn't work on a Debian host. The solution is to do it in an init.d script as follows:
<pre>
modprobe ip_conntrack ip_conntrack_enable_ve0=1
</pre>
Make sure that this module is loaded before any of the other iptables-modules ar loaded! Also remember that if this module is loaded without the option, unloading and reloading doesn't work! You need to reboot the computer.

== How to provide access from Internet to a VE ==

In addition, to make some services in VE with private IP address be accessible from the Internet, DNAT (Destination Network Address Translation) should be configured on the [[Hardware Node]]. To perform a simple DNAT setup, execute the following command on the [[Hardware Node]]:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --port port_num \
-i eth0 -j DNAT --to-destination ve_address:dst_port_num
</pre>

where <tt>ve_address</tt> is an IP address of the VE, <tt>dst_port_num</tt> is a tcp port which requires service use, <tt>ip_address</tt> is the external (public) IP address of your [[Hardware Node]], and <tt>port_num</tt> is a tcp port of [[Hardware Node]], which will be used for Internet connections to private VE service. Note that this setup makes the service which is using <tt>port_num</tt> on the [[Hardware Node]] be unaccessible from the Internet. Also note that SNAT translation is required too.

For example, if you need a web server in a VE to be accessible from outside and, at the same time, keep a web server on the [[Hardware Node]] be accessible, use the following config:
<pre>
# iptables -t nat -A PREROUTING -p tcp -d ip_address --dport 8080 \
-i eth0 -j DNAT --to-destination ve_address:80
# iptables -t nat -A POSTROUTING -s ve_address -o eth0 -j SNAT --to ip_address
</pre>

After applying this, you'll see VE' web server at <code><nowiki>http://ip_address:8080/</nowiki></code>.

The <tt>iptables</tt> utility allows to set up more complex rules for Network Address Translation, involving various protocols and ports. If you wish to get more information on this, consult the numerous Internet sites (e.g. [http://www.netfilter.org netfilter.org]) and tutorials devoted to this issue.

== External Links ==
* [http://www.netfilter.org netfilter.org]

[[Category: HOWTO]]
[[Category: Networking]]