OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Talk:Debian template creation

2007-04-10T06:29:53Z

Dusty: /* Update document for Debian Etch */

== edit/symlink /etc/mtab, /proc/mounts ==
Does anybody have valuable information why this would make sense and if this is needed?
http://wiki.openvz.org/Debian_template_creation#Fix_.2Fetc.2Fmtab {{unsigned|Juggler|20:41, 13 February 2007}}

: Linking /etc/mtab -> /proc/mounts is needed since VE's root filesystem is actually mounted from the [[Hardware Node]]. Thus, there is no appropriate record in /etc/mtab, so utilities like df fail to work (since they get a list of mounts from the /etc/mtab). After linking /etc/mtab to /proc/mounts, /etc/mtab shows all the mounts, including the one for root filesystem, so df works fine. --[[User:Kir|Kir]] 10:25, 14 February 2007 (EST)

== problem with path ==
Hi all,
This is my first trial with openVZ and a wiki. Please give me some hints, if anything is wrong. Don't hesitate to correct my poor english.

I just installed openVZ on a rather old test box with Debian. Installation failed at first and I suppose there is a wrong path statement used for the debian packages.

When I came to
<code>vzctl start 777</code>
I received the message
<code>Starting VE ...
VE private area /var/lib/vz/private/777 does not exist</code>

Moving the directory 777 from /vz/private to /var/lib/vz/private solves this problem.

Now I could start and enter the new VE. --(unsigned)

This isn't a very good place to ask for help. You should use the forum instead. See the link for the forum in the sidebar on the left. --[[User:Dusty|Dusty]] 19:00, 9 April 2007 (EDT)

== Debian template creation ==

For backward compablity to main OpenVZ:

Create a symlink from /var/lib/vz to /vz
<pre>
# ln -s /var/lib/vz /vz
</pre>

== Update document for Debian Etch ==
Updated.

I'm not sure how to fit it in, but if your hardware node is Debian Etch, you don't have to make a temporary VE to create a template. You can just chroot into it instead, which probably saves some hassle. It's probably not worth making a whole new page for it and it'd probably cause confusion to add it to this document. If someone knows what to do with that information, feel free to do something. I always just use a chroot because it's so much easier for me. But when I tried it on a RedHat box, it didn't quite work out for some interesting locale reason when installing the SSH package.

Debian template creation

2007-04-10T06:19:25Z

Dusty: /* Bootstrapping Debian */ Reword a sentence so the user doesn't think Debian is going to take over their computer's OS.

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
This will download Debian Etch to a temporary location on your server. Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>. We use VE ID of 777 for this example; surely it can be any other unused ID.
sudo debootstrap --arch i386 etch /vz/private/777 http://debian.osuosl.org/debian/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Note|'''Warning!''' Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]

Debian template creation

2007-04-10T05:15:31Z

Dusty: /* Bootstrapping Debian */

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
This will download Debian Etch to your server. Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>. We use VE ID of 777 for this example; surely it can be any other unused ID.
sudo debootstrap --arch i386 etch /vz/private/777 http://debian.osuosl.org/debian/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Note|'''Warning!''' Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]

User talk:Dusty/Debian template creation

2007-04-10T05:14:30Z

Dusty: Delete me, please.

User:Dusty/Debian template creation

2007-04-10T05:14:12Z

Dusty: Delete me, please.

Debian template creation

2007-04-10T05:13:46Z

Dusty: Updated for Debian Etch release

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Download Debian Etch to a directory called "etch-temp". Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>. We use VE ID of 777 for this example; surely it can be any other unused ID.
sudo debootstrap --arch i386 etch /vz/private/777 http://debian.osuosl.org/debian/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Note|'''Warning!''' Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]

User:Dusty/Debian template creation

2007-04-10T04:41:32Z

Dusty:

'''This is just a working area to make sure I've got my facts straight.''' It works great on a Debian hardware node, but not so great on RedHat. We might really have to create a temporary VE instead of using the chroot. Pitty.

---

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp". Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>.
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .
cd ..

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 123456 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

User:Dusty/Debian template creation

2007-04-10T04:27:02Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp". Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>.
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .
cd ..

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 123456 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

User:Dusty/Debian template creation

2007-04-10T04:23:04Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.osuosl.org/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .
cd ..

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 123456 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

User:Dusty/Debian template creation

2007-04-10T04:20:28Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.osuosl.org/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .
cd ..

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 12345 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 12345
sudo vzctl exec 12345 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 12345
sudo vzctl destroy 12345

User:Dusty/Debian template creation

2007-04-10T04:12:09Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.osuosl.org/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 12345 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 12345
sudo vzctl exec 12345 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 12345
sudo vzctl destroy 12345

User:Dusty/Debian template creation

2007-04-10T04:11:51Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. Even though it's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.osuosl.org/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.osuosl.org/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 12345 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 12345
sudo vzctl exec 12345 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 12345
sudo vzctl destroy 12345

User:Dusty/Debian template creation

2007-04-10T04:08:08Z

Dusty:

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. Even though it's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.oregonstate.edu/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

cd /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.oregonstate.edu/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.oregonstate.edu/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.oregonstate.edu/debian etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 12345 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 12345
sudo vzctl exec 12345 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 12345
sudo vzctl destroy 12345

User:Dusty/Debian template creation

2007-04-10T04:00:45Z

Dusty: New page: (this is just a working area to make sure I've got my facts straight) These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to c...

(this is just a working area to make sure I've got my facts straight)

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. Even though it's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.oregonstate.edu/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available from [http://forum.openvz.org/index.php?t=tree&th=142&mid=584].

== Bootstrapping Debian ==
Change to a directory where you'll have about 200MB of usable space and the ability to run executables. Depending on your configuration, <tt>/tmp</tt> might be set <tt>noexec</tt> which would mean you'd have to use some other location. I'm going to use <tt>/vz/private</tt> for this.

chdir /vz/private

Download Debian Etch to a directory called "etch-temp":
sudo debootstrap etch etch-temp http://debian.oregonstate.edu/debian/

''Or'' you can (but probably shouldn't need to) specify the architecture manually using one of these commands instead:

To specify i386/x86 architecture:
sudo debootstrap --arch i386 etch etch-temp http://debian.oregonstate.edu/debian/

For AMD64/x86_64, use <tt>amd64</tt> instead of <tt>i386</tt>. For ia64, use <tt>ia64</tt>.

== Inside the template ==
The following actions are all performed inside the template. To get inside, run this:
sudo chroot etch-temp

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.oregonstate.edu/debian etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Update and upgrade packages ===
This will update the available packages list, upgrade installed packages with security updates, and install the new packages that are listed below. Feel free to add your own.
apt-get update
apt-get upgrade

=== Install more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Put sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge fortune-mod fortunes-min

=== Disable services ===
If there are any services you'd like to disable, do that now. Here's an example:
update-rc.d -f klogd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys

=== Clean packages cache ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

=== Get out of the template ===
Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==
Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).

cd etch-temp
sudo tar -zcf /vz/template/cache/debian-4.0-i386-basic.tar.gz .

Check to make sure the filesize of the resulting tarball is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-basic.tar.gz

== Dispose of the temporary template directory ==
You're done with the template directory. Remove it.
sudo rm -Rf etch-temp

== Use your new template ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.

sudo vzctl create 12345 --ostemplate debian-4.0-i386-basic

Now make sure that it works:
sudo vzctl start 12345
sudo vzctl exec 12345 ps ax

You should see that a few processes are running as expected.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 12345
sudo vzctl destroy 12345

User talk:Dusty/Debian template creation

2007-04-10T03:14:59Z

Dusty: Raw commands

<pre>
apt-get install debootstrap
cd /var/lib/vz/private
debootstrap etch etch-temp http://debian.oregonstate.edu/debian/
chroot etch-temp
cat <<EOF > /etc/apt/sources.list
deb http://debian.oregonstate.edu/debian etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF
apt-get update
apt-get upgrade
apt-get install ssh quota
chmod 700 /root
usermod -L root
sed -i -e '/getty/d' /etc/inittab
sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab
update-rc.d -f klogd remove
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys
apt-get clean
exit
cd etch-temp
tar -zcf ../../template/cache/debian-4.0-i386-basic.tar.gz *
cd ..
rm -Rf etch-temp
cd /root
vzctl create 12345 --ostemplate=debian-4.0-i386-basic
</pre>

Talk:Zimbra on OpenVZ on Debian

2007-04-09T23:27:03Z

Dusty: /* Debian Etch has been released */

== Debian Etch has been released ==

Update this document for the new version of Debian which has gone stable. It might be as simple as changing the version number and reference to "sarge", but maybe not?

--[[User:Dusty|Dusty]] 19:27, 9 April 2007 (EDT)

Talk:Installation on Debian/old

2007-04-09T23:26:40Z

Dusty:

info about needed modules in kernel-config

info about "Yet Another mkInitRD" yaid tools creating initrd-files

== ip_forward setup ==

If you want network access for the virtual server then you need to enable IP forwarding.
Set "ip_forward" to yes in /etc/network option.
# editor /etc/network/options

: /etc/network/options is deprecated. ip_forward may be enabled in /etc/sysctl.conf by adding the line "net.ipv4.ip_forward=1"

== Debian Etch has been released ==

Sarge is no longer stable and has been replaced by Etch. This document needs to be updated for Etch

* References to Sarge need to be updated to use Etch instead.
* Lenny is the new Debian testing. If you wish to continue to have a testing section listed, update it for Lenny. Otherwise remove the testing section.
* Use the official Debian mirrors to get the OpenVZ packages.

--[[User:Dusty|Dusty]] 19:26, 9 April 2007 (EDT)

Talk:Installation on Debian/old

2007-04-09T23:26:17Z

Dusty: /* Debian Etch has been released */

Talk:Installation on Debian/old

2007-04-09T23:24:14Z

Dusty: Debian Etch has been released

info about needed modules in kernel-config

info about "Yet Another mkInitRD" yaid tools creating initrd-files

== ip_forward setup ==

If you want network access for the virtual server then you need to enable IP forwarding.
Set "ip_forward" to yes in /etc/network option.
# editor /etc/network/options

: /etc/network/options is deprecated. ip_forward may be enabled in /etc/sysctl.conf by adding the line "net.ipv4.ip_forward=1"

== Debian Etch has been released ==

Sarge is no longer stable and has been replaced by Etch. This document needs to be updated for Etch and references to Sarge need to be updated to use Etch instead. Lenny is the new Debian testing.

Talk:Zimbra on OpenVZ on Debian

2007-04-09T23:22:23Z

Dusty: Debian Etch has been released

User:Dusty

2007-04-09T23:18:38Z

Dusty: New page: I'm an OpenVZ user. I couldn't live without it. I use OpenVZ on quite a few servers for both business and personal use. I use Debian Etch GNU/Linux for all of my hardware nodes except f...

I'm an OpenVZ user. I couldn't live without it.

I use OpenVZ on quite a few servers for both business and personal use.

I use Debian Etch GNU/Linux for all of my hardware nodes except for one server where I am forced to use RHEL3. I thank Ola Lundqvist for providing and maintaining Debian packages for OpenVZ utilities and going through the effort to make sure they are provided through the official Debian repositories.

Except for a couple special servers, I always custom-compile my kernel and disable kernel module support. It is important for me that OpenVZ works with kernel module support disabled. Right now, it it requires major tweaking of the /etc/init.d/vz script for that to work.

I always use a custom-created Debian VPS template for my VPSes. For that, debootstrap is very important and useful.

I tend to do some advanced things with my VPS configurations and sometimes require custom scripts to make certain things happen correctly. For example, I have stored in my individual VPS .conf files the necessary settings for port forwarding through the hardware node to the VPS for certain tasks as well as defining the SNAT IP address if necessary. I then have scripts that read the individual VPS and global .conf files that perform specific tasks like port forwarding, firewall settings, and disk mounting.

I don't use .mount and .umount scripts because they don't quite do the job as needed. Sometimes the command needs to be run on a global level (re-setting the global firewall) or on a frequent basis (checking mounts for status and/or availability). Also, having all the settings in a single .conf file per VPS and a single .conf for hardware node global is very useful for portability between servers.

I wish OpenVZ was in the mainstream kernel. It'd make deploying new servers and upgrading existing kernels a much simpler task, especially when I try to stay as Debian-standard as possible.

Talk:Debian template creation

2007-04-09T23:00:24Z

Dusty: /* problem with path */

== edit/symlink /etc/mtab, /proc/mounts ==
Does anybody have valuable information why this would make sense and if this is needed?
http://wiki.openvz.org/Debian_template_creation#Fix_.2Fetc.2Fmtab {{unsigned|Juggler|20:41, 13 February 2007}}

: Linking /etc/mtab -> /proc/mounts is needed since VE's root filesystem is actually mounted from the [[Hardware Node]]. Thus, there is no appropriate record in /etc/mtab, so utilities like df fail to work (since they get a list of mounts from the /etc/mtab). After linking /etc/mtab to /proc/mounts, /etc/mtab shows all the mounts, including the one for root filesystem, so df works fine. --[[User:Kir|Kir]] 10:25, 14 February 2007 (EST)

== problem with path ==
Hi all,
This is my first trial with openVZ and a wiki. Please give me some hints, if anything is wrong. Don't hesitate to correct my poor english.

I just installed openVZ on a rather old test box with Debian. Installation failed at first and I suppose there is a wrong path statement used for the debian packages.

When I came to
<code>vzctl start 777</code>
I received the message
<code>Starting VE ...
VE private area /var/lib/vz/private/777 does not exist</code>

Moving the directory 777 from /vz/private to /var/lib/vz/private solves this problem.

Now I could start and enter the new VE. --(unsigned)

This isn't a very good place to ask for help. You should use the forum instead. See the link for the forum in the sidebar on the left. --[[User:Dusty|Dusty]] 19:00, 9 April 2007 (EDT)

== Debian template creation ==

For backward compablity to main OpenVZ:

Create a symlink from /var/lib/vz to /vz
<pre>
# ln -s /var/lib/vz /vz
</pre>

== Update document for Debian Etch ==

Debian Etch has been released and this document needs updated for the new version.

* Etch does have proper AMD64 support now
* Use "etch" instead of "sarge" everywhere.
* Update for any Etch-specific cases (I don't know of any yet)
* Update/remove any Sarge-specific cases that no longer apply (I don't know of any yet)
* Instead of recommending that people use the .de mirror, link to a list of mirrors maybe?

If someone gets to it before I do, great! If not, I'm hoping that I'll update the document after I've done this task a few times in production, which I'm doing quite a bit this week. Thanks!

--[[User:Dusty|Dusty]] 18:58, 9 April 2007 (EDT)

Talk:Debian template creation

2007-04-09T22:58:30Z

Dusty: Update document for Debian Etch

== edit/symlink /etc/mtab, /proc/mounts ==
Does anybody have valuable information why this would make sense and if this is needed?
http://wiki.openvz.org/Debian_template_creation#Fix_.2Fetc.2Fmtab {{unsigned|Juggler|20:41, 13 February 2007}}

: Linking /etc/mtab -> /proc/mounts is needed since VE's root filesystem is actually mounted from the [[Hardware Node]]. Thus, there is no appropriate record in /etc/mtab, so utilities like df fail to work (since they get a list of mounts from the /etc/mtab). After linking /etc/mtab to /proc/mounts, /etc/mtab shows all the mounts, including the one for root filesystem, so df works fine. --[[User:Kir|Kir]] 10:25, 14 February 2007 (EST)

== problem with path ==
Hi all,
This is my first trial with openVZ and a wiki. Please give me some hints, if anything is wrong. Don't hesitate to correct my poor english.

I just installed openVZ on a rather old test box with Debian. Installation failed at first and I suppose there is a wrong path statement used for the debian packages.

When I came to
<code>vzctl start 777</code>
I received the message
<code>Starting VE ...
VE private area /var/lib/vz/private/777 does not exist</code>

Moving the directory 777 from /vz/private to /var/lib/vz/private solves this problem.

Now I could start and enter the new VE.

== Debian template creation ==

For backward compablity to main OpenVZ:

Create a symlink from /var/lib/vz to /vz
<pre>
# ln -s /var/lib/vz /vz
</pre>

== Update document for Debian Etch ==

Debian Etch has been released and this document needs updated for the new version.

* Etch does have proper AMD64 support now
* Use "etch" instead of "sarge" everywhere.
* Update for any Etch-specific cases (I don't know of any yet)
* Update/remove any Sarge-specific cases that no longer apply (I don't know of any yet)
* Instead of recommending that people use the .de mirror, link to a list of mirrors maybe?

If someone gets to it before I do, great! If not, I'm hoping that I'll update the document after I've done this task a few times in production, which I'm doing quite a bit this week. Thanks!

--[[User:Dusty|Dusty]] 18:58, 9 April 2007 (EDT)

Virtual Ethernet device

2006-11-18T06:26:44Z

Dusty: /* Examples */

'''Virtual ethernet device''' is an ethernet-like device which can be used inside a [[VE]]. Unlike
[[venet]] network device, veth device has a MAC address. Due to this, it can be used in configurations, when veth is bridged to ethX or other device and VE user fully sets up his networking himself,
including IPs, gateways etc.

Virtual ethernet device consist of two ethernet devices - one in [[VE0]] and another one
in VE. These devices are connected to each other, so if a packet goes to one
device it will come out from the other device.

== Virtual ethernet device usage ==

=== Kernel module ===
First of all, make sure the <code>vzethdev</code> module is loaded:
<pre>
# lsmod | grep vzeth
vzethdev 8224 0
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota
</pre>

In case it is not loaded, load it:
<pre>
# modprobe vzethdev
</pre>

You might want to add the module to <code>/etc/init.d/vz script</code>, so it will be loaded during startup.

=== Adding veth to a VE ===
<pre>
vzctl set <VEID> --veth_add <dev_name>,<dev_addr>,<ve_dev_name>,<ve_dev_addr>
</pre>
Here
* <tt>dev_name</tt> is ethernet device name in the [[VE0|host system]]
* <tt>dev_addr</tt> is its MAC address
* <tt>ve_dev_name</tt> is an ethernet device name in the VE
* <tt>ve_dev_addr</tt> is its MAC address

MAC addresses must be entered in XX:XX:XX:XX:XX:XX format. Note that this option
is incremental, so devices are added to already existing ones.

==== Examples ====
<pre>
vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save
</pre>
After executing this command <tt>veth</tt> device will be created for VE 101 and veth configuration will be saved to a VE configuration file.
Host-side ethernet device will have <tt>veth101.0</tt> name and <tt>00:12:34:56:78:9A</tt> MAC address.
VE-side ethernet device will have <tt>eth0</tt> name and <tt>00:12:34:56:78:9B</tt> MAC address.
{{Note|Use random MAC addresses. Do not use MAC addresses of real eth devices, because this can lead to collisions.}}

=== Removing veth from a VE ===
<pre>
vzctl set <VEID> --veth_del <dev_name>
</pre>
Here <tt>dev_name</tt> is the ethernet device name in the [[VE0|host system]].

==== Example ====
<pre>
vzctl set 101 --veth_del veth101.0 --save
</pre>
After executing this command veth device with host-side ethernet name veth101.0 will be removed from VE 101 and veth configuration will be updated in VE config file.

== Common configurations with virtual ethernet devices ==
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.

=== Simple configuration with virtual ethernet device ===

==== Start a VE ====
<pre>
[host-node]# vzctl start 101
</pre>

==== Add veth device to VE ====
<pre>
[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save
</pre>

==== Configure devices in VE0 ====
<pre>
[host-node]# ifconfig veth101.0 0
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
</pre>

==== Configure device in VE ====
<pre>
[host-node]# vzctl enter 101
[ve-101]# /sbin/ifconfig eth0 0
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0
[ve-101]# /sbin/ip route add default dev eth0
</pre>

==== Add route in [[VE0]] ====
<pre>
[host-node]# ip route add 192.168.0.101 dev veth101.0
</pre>

=== Virtual ethernet device with IPv6 ===

==== Start [[VE]] ====
<pre>
[host-node]# vzctl start 101
</pre>

==== Add veth device to [[VE]] ====
<pre>
[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save
</pre>

==== Configure devices in [[VE0]] ====
<pre>
[host-node]# ifconfig veth101.0 0
[host-node]# echo 1 > /proc/sys/net/ipv6/conf/veth101.0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
</pre>

==== Configure device in [[VE]] ====
<pre>
[host-node]# vzctl enter 101
[ve-101]# /sbin/ifconfig eth0 0
</pre>

==== Start router advertisement daemon (radvd) for IPv6 in VE0 ====
First you need to edit radvd configuration file. Here is a simple example of <tt>/etc/radv.conf</tt>:
<pre>
interface veth101.0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvHomeAgentFlag off;

prefix 3ffe:2400:0:0::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

interface eth0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvHomeAgentFlag off;

prefix 3ffe:0302:0011:0002::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
</pre>

Then, start radvd:
<pre>
[host-node]# /etc/init.d/radvd start
</pre>

==== Add IPv6 addresses to devices in [[VE0]] ====
<pre>
[host-node]# ip addr add dev veth101.0 3ffe:2400::212:34ff:fe56:789a/64
[host-node]# ip addr add dev eth0 3ffe:0302:0011:0002:211:22ff:fe33:4455/64
</pre>

=== Virtual ethernet devices can be joined in one bridge ===
Perform steps 1 - 4 from Simple configuration chapter for several VEs and/or veth devices

==== Create bridge device ====
<pre>
[host-node]# brctl addbr vzbr0
</pre>

==== Add veth devices to bridge ====
<pre>
[host-node]# brctl addif vzbr0 veth101.0
...
[host-node]# brctl addif vzbr0 veth101.n
[host-node]# brctl addif vzbr0 veth102.0
...
...
[host-node]# brctl addif vzbr0 vethXXX.N
</pre>

==== Configure bridge device ====
<pre>
[host-node]# ifconfig vzbr0 0
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/vzbr0/forwarding
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/vzbr0/proxy_arp
</pre>

==== Add routes in [[VE0]] ====
<pre>
[host-node]# ip route add 192.168.101.1 dev vzbr0
...
[host-node]# ip route add 192.168.101.n dev vzbr0
[host-node]# ip route add 192.168.102.1 dev vzbr0
...
...
[host-node]# ip route add 192.168.XXX.N dev vzbr0
</pre>

Thus you'll have more convinient configuration, i.e. all routes to VEs will be through this bridge and VEs can communicate with each other even without these routes.

=== Virtual ethernet devices + VLAN ===
This configuration can be done by adding vlan device to the previous configuration.

== See also ==
* [[Virtual network device]]
* [[Differences between venet and veth]]

== External links ==
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]

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

Quick installation (legacy)

2006-11-13T08:20:27Z

Dusty:

This document briefly describes the steps needed to install OpenVZ on your machine.

This document is also available in the following languages: [http://forum.openvz.org/index.php?t=tree&goto=35&#msg_35 French], [http://forum.openvz.org/index.php?t=tree&goto=1805&#msg_1805 German].

OpenVZ consists of a kernel, user-level tools, and VE templates. This guide tells how to install the kernel and the tools.

== Requirements ==
This guide assumes you are running recent release of Fedora Core (like FC5) or RHEL/CentOS 4. Currently, OpenVZ kernel tries to support the same hardware that Red Hat kernels support. For full hardware compatibility list, see [http://www.virtuozzo.com/en/products/virtuozzo/hcl/ Virtuozzo HCL].

=== Filesystems ===
It is recommended to use a separate partition for VEs private directories (by default /vz/private/<veid>). The reason why you should do so is that if you wish to use OpenVZ per-VE disk quota, you won't be able to use usual Linux disk quotas on the same partition. Bear in mind, that per-VE quota in this context includes not only pure per-VE quota, but also usual Linux disk quota used in VE, not on HN.

At least try to avoid using root partition for VEs, because the root user of VE will be able to overcome 5% disk space barrier in some situations. This way HN root partition can be completely filled and it will break the system.

OpenVZ per-VE disk quota is supported only for ext2/ext3 filesystems. So use one of these filesystems (ext3 is recommended) if you need per-VE disk quota.

=== rpm or yum? ===

In case you have yum utility available on your system, you may want to use it effectively to install and update OpenVZ packages. In case you don't have yum, or don't want to use it, you can use plain old rpm. Instructions for both rpm and yum are provided below.

=== yum pre-setup ===
If you want to use yum, you should set up OpenVZ yum repository first.

Download [http://download.openvz.org/openvz.repo openvz.repo] file and put it to your <code>/etc/yum.repos.d/</code> repository. This can be achieved by the following commands, as root:
<pre>
# cd /etc/yum.repos.d
# wget http://download.openvz.org/openvz.repo
</pre>

In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old. In that case, just stick to rpm installation method.

== Kernel installation ==

{{Note|In case you want to recompile the kernel yourself rather than use the one provided by OpenVZ, see [[kernel build]].}}

First, you need to choose what “flavor” of the kernel you want to install. Please refer to [[Kernel flavors]] for more information.

=== Using yum ===
Run the following command
<pre>
# yum install ovzkernel[-flavor]
</pre>

Here <code>[-flavor]</code> is optional, and can be <code>-smp</code> or <code>-enterprise</code>. Refer to [[kernel flavors]] for more info.

=== Using rpm ===
Get the kernel binary RPM from the [http://openvz.org/download/kernel/ Download » Kernel] page, or directly from [http://download.openvz.org/kernel/ download.openvz.org/kernel], or from one of its [[Download mirrors|mirrors]]. You need only one kernel RPM so please [[Kernel flavors|choose the appropriate one]] depending on your hardware.

Next, install the kernel RPM you chose:

<pre>
# rpm -ihv ovzkernel[-flavor]*.rpm
</pre>

Here <code>[-flavor]</code> is optional, and can be <code>-smp</code> or <code>-enterprise</code>. Refer to [[kernel flavors]] for more info.

{{Note|<tt>rpm -U</tt> (where <tt>-U</tt> stands for ''upgrade'') should '''not''' be used, otherwise all currently installed kernels will be uninstalled.}}

== Configuring the bootloader ==

In case GRUB is used as the boot loader, it will be configured automatically: lines similar to these will be added to the <tt>/boot/grub/grub.conf</tt> file:

<pre>
title Fedora Core (2.6.8-022stab029.1)
root (hd0,0)
kernel /vmlinuz-2.6.8-022stab029.1 ro root=/dev/sda5 quiet rhgb vga=0x31B
initrd /initrd-2.6.8-022stab029.1.img
</pre>
Change <tt>Fedora Core</tt> to <tt>OpenVZ</tt> (just for clarity reasons, so the OpenVZ kernels will not be mixed up with non-OpenVZ ones). Remove extra arguments from the kernel line, leaving only the <tt>root=...</tt> parameter. The modifed portion of <tt>/etc/grub.conf</tt> should look like this:

<pre>
title OpenVZ (2.6.8-022stab029.1)
root (hd0,0)
kernel /vmlinuz-2.6.8-022stab029.1 ro root=/dev/sda5
initrd /initrd-2.6.8-022stab029.1.img
</pre>

== Configuring ==

Please make sure the following steps are performed before rebooting into OpenVZ kernel.

=== sysctl ===

There is a number of kernel parameters that should be set for OpenVZ to work correctly. These parameters are stored in <tt>/etc/sysctl.conf</tt> file. Here is the relevant part of the file; please edit it accordingly.

<pre>
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0
# Enables source route verification
net.ipv4.conf.all.rp_filter = 1
# Enables the magic-sysrq key
kernel.sysrq = 1
# TCP Explict Congestion Notification
#net.ipv4.tcp_ecn = 0
# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
</pre>

=== SELinux ===

SELinux should be disabled. To that effect, put the following line to <code>/etc/sysconfig/selinux</code>:
<pre>
SELINUX=disabled
</pre>

=== Conntracks ===

In the stable OpenVZ kernels (those that are 2.6.8-based) netfilter connection tracking for [[VE0]] is disabled by default. If you have a stateful firewall enabled on the host node (it is there by default) you should either disable it, or enable connection tracking for [[VE0]].

To enable conntracks for VE0, add the following line to <code>/etc/modprobe.conf</code> file:
<pre>
options ip_conntrack ip_conntrack_enable_ve0=1
</pre>

{{Note|In kernels later than 2.6.8, connection tracking is enabled by default.}}

== Rebooting into OpenVZ kernel ==

Now reboot the machine and choose "OpenVZ" on the boot loader menu. If the OpenVZ kernel has been booted successfully, proceed to installing the user-level tools for OpenVZ.

== Installing the utilities ==

OpenVZ needs some user-level tools installed. Those are:

; vzctl
: A utility to control OpenVZ VPSs (create, destroy, start, stop, set parameters etc.)
; vzquota
: A utility to manage quotas for VPSs. Mostly used indirectly (by vzctl).

=== Using yum ===

<pre>
# yum install vzctl vzquota
</pre>

=== Using rpm ===

Download the binary RPMs of these utilities from [http://openvz.org/download/utils/ Download » Utils], or directly from [http://download.openvz.org/utils/ download.openvz.org/utils], or from one of its [[Download mirrors|mirrors]]. Install them:

<pre>
# rpm -Uhv vzctl*.rpm vzquota*.rpm
</pre>

If rpm complains about unresolved dependencies, you'll have to satisfy them first, then repeat the installation.

When all the tools are installed, start the OpenVZ subsystem.

== Starting OpenVZ ==

As root, execute the following command:

<pre>
# /sbin/service vz start
</pre>

This will load all the needed OpenVZ kernel modules. This script should also start all the VPSs marked to be auto-started on machine boot (there aren't any yet).

During the next reboot, this script should be executed automatically.

== Next steps ==

OpenVZ is now set up on your machine. To load OpenVZ kernel by default, edit the default line in the /boot/grub/grub.conf file to point to the OpenVZ kernel. For example, if the OpenVZ kernel is the first kernel mentioned in the file, put it as default 0. See man grub.conf for more details.

The next step is to prepare the [[OS template]]: please continue to [[OS template cache preparation]] document.

[[Category: Installation]]
[[Category: HOWTO]]

Talk:Using NAT for container with private IPs

2006-11-13T03:26:04Z

Dusty:

Using NAT for container with private IPs

2006-11-13T03:25:40Z

Dusty:

Usually you supply public IP addresses to your VEs. Sometimes you don't want to do it (lack of IPs, etc.). This article describes how to use private IP addresses for VEs.

== Prerequisites ==

IP forwarding should be turned on on hardware node in order for VE networking to work. Make sure it is turned on.

== 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>

{{Note|in kernels later than 2.6.8, connection tracking is enabled by default}}

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 are loaded! Also remember that if this module is loaded without the option, unloading and reloading doesn't work! You need to reboot the computer.

{{Note|in kernels later than 2.6.8, connection tracking is enabled by default}}

== 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 --dport 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]]

Shared webhosting

2006-11-13T02:45:17Z

Dusty: /* The problem */ Grammar fixes

{{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 too powerful. 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 themselves victims of a compromised 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 expensive 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 all 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 separate 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 unnecessary 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]]

Shared webhosting

2006-11-13T02:44:20Z

Dusty: Spelling fixes

{{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 powerful. 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 themselves victims of a compromised 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 expensive 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 all 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 separate 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 unnecessary 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]]

Shared webhosting

2006-11-13T02:43:26Z

Dusty: /* The solution */ Spelling fixes

{{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 themselves victims of a compromised 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 expensive 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 all 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 separate 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 unnecessary 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]]

Talk:Using NAT for container with private IPs

2006-11-13T02:38:12Z

Dusty:

There is a mention of "ip_conntrack_enable_ve0" here. I know the new kernels (>= 2.6.15) are using "ip_conntrack_disable_ve0" instead and having it connnection tracking enabled by default. This document should probably be updated to state whatever necessary instructions differences for those new kernel versions. I'd do it, but I'm not confident in my precise knowledge of the issue. Thanks! --[[User:Dusty|Dusty]] 21:38, 12 November 2006 (EST)