http://linux-vserver.org/api.php?action=feedcontributions&user=Theocrite&feedformat=atomLinux-VServer - User contributions [en]2024-03-28T21:55:14ZUser contributionsMediaWiki 1.20.2http://linux-vserver.org/Related_ProjectsRelated Projects2010-03-15T09:54:25Z<p>Theocrite: Qemu website moved.</p>
<hr />
<div>{{NeedCompletion}}<br />
<br />
== Emulation ==<br />
<br />
* [http://wiki.qemu.org/Index.html Qemu] - QEMU CPU Emulator<br />
* [http://bochs.sourceforge.net/ Bochs] - highly portable open source IA-32 (x86) PC emulator written in C++<br />
* [http://pearpc.sourceforge.net/ PearPC] - architecture-independent PowerPC platform emulator<br />
<br />
== Paravirtualization ==<br />
<br />
* [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Xen] - Xen virtual machine monitor<br />
<br />
== Native Virtualization ==<br />
<br />
* [http://kvm.qumranet.com/kvmwiki KVM] - Kernel Based Virtual Machine<br />
* [http://www.vmware.com VMware] - desktop virtualization software for software developers/testers<br />
* [http://www.virtualbox.org/ VirtualBox] - GPL Virtual Computer<br />
* [http://user-mode-linux.sourceforge.net/ UML] - User-mode Linux<br />
<br />
== Operating System-level Virtualization ==<br />
<br />
* [http://www.freevps.com FreeVPS] - early Linux-VServer fork<br />
* [http://openvz.org OpenVZ] - Open Source version of the commercial Parallels Virtuozzo Containers product from Parallels<br />
* [http://docs.freebsd.org/44doc/papers/jail/jail.html FreeBSD jails] - the closest equivalent standard feature in FreeBSD<br />
* [http://sysjail.bsd.lv/ Sysjail] - systrace userland virtualisation<br />
* [http://www.sun.com/bigadmin/content/zones/ Solaris Zones] - the closest equivalent standard feature in Solaris 10<br />
* [http://lxc.sourceforge.net/ Linux Containers] - Linux implementation based on control groups and namespaces<br />
<br />
== Cluster Virtualization / Cloud Computing ==<br />
<br />
* [http://trac.enomalism.com Enomalism] - AGPL licensed multi-hypervisor web based virtualization framework<br />
* [http://www.openqrm.com openQRM] - openQRM is the next generation, open-source Data-center management platform.</div>Theocritehttp://linux-vserver.org/Networking_vserver_guestsNetworking vserver guests2010-01-03T15:29:17Z<p>Theocrite: Undo revision 3984 by TTimo (Talk) (Don't need to enable IP forwarding)</p>
<hr />
<div>Setting up network access to and from your vserver guests.<br />
__TOC__<br />
==Introduction==<br />
<br />
Lets imagine, you have only one external IP -- <code>$EXTIP</code>.<br />
<br />
You want to have several vservers running without worrying about port overlapping.<br />
<br />
Example:<br />
<br />
Two vservers run a default webserver, running on port 80. If each "guest" vserver shares an IP with the host, then the two webservers will conflict.<br />
<br />
One solution is:<br />
<br />
* All vservers are contained in a "virtual lan", say 192.168.1.x<br />
* Each vserver has its own IP<br />
* Control port forwarding on "parent" host. That is, run a router.<br />
<br />
==Configuration==<br />
===Host===<br />
First you need to load the dummy interface driver<br />
# modprobe dummy<br />
<br />
To have it automatically loaded on startup, add<br />
"loopback" to /etc/modules<br />
<br />
Set up <code>dummy0</code> interface on the parent host<br />
# /etc/network/interfaces on a Debian box, <br />
# configure on other distros with your preferred way<br />
auto dummy0<br />
iface dummy0 inet static<br />
address 192.168.1.250<br />
netmask 255.255.255.0<br />
<br />
===Guests===<br />
Set up each guest vserver:<br />
cd /etc/vservers/$VSERVER/interfaces/0<br />
echo dummy0 > dev<br />
echo 192.168.1.1 > ip<br />
echo 1 > name<br />
echo 24 > prefix<br />
Consider using a value of <code>name</code> equal to the last digit of the IP for easy separation.<br />
<br />
===Host as router===<br />
Configure the host to act as a router.<br />
<br />
For internal packets going outside, pretend each packet came from our external IP (put it in one line without backslash):<br />
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \ <br />
-d ! 192.168.1.0/24 -j SNAT --to-source $EXTIP<br />
For each service that runs on a vserver, map it to an external port. Vserver local address <code>$VHOST</code> and port <code>$INTPORT</code> you select one external port <code>$EXTPORT</code> and run the following (put it in one line without backslash):<br />
# iptables -t nat -A PREROUTING -s ! 192.168.1.0/24 \<br />
-m tcp -p tcp --dport $EXTPORT <br />
-j DNAT --to-destination $VHOST:$INTPORT<br />
That's all!<br />
<br />
==Verifying==<br />
Try <code>ping pool.ntp.org</code> from your vserver -- it should ping fine.<br />
<br />
Try to connect to your <code>$EXTIP:$EXTPORT</code> (from another external host) -- you will successfully connect to service running on a guest vserver.<br />
==See also==<br />
* [[Frequently_Asked_Questions#If_my_host_has_only_one_a_single_public_IP.2C_can_I_use_RFC1918_IP_.28e.g._192.168.foo.bar.29_for_the_guest_vservers.3F |FAQ on private networking]]<br />
* [[Frequently_Asked_Questions#When_I_try_to_ssh_to_the_guest.2C_I_log_into_the_host.2C_even_if_I_installed_sshd_on_the_guest._What.27s_wrong_here.3F |Permit guest sshd to bind to its IP address's port 22]]<br />
* [[Networking_vserver_guests_RHEL|Networking_vserver_guests_RHEL]]<br />
<br />
[[Category:HowTo]]<br />
[[Category:Network]]</div>Theocritehttp://linux-vserver.org/Installation_on_DebianInstallation on Debian2009-11-14T17:07:20Z<p>Theocrite: /* Issues with the current 2.6.26 Kernel */</p>
<hr />
<div>This guide is written against Debian Etch (4.0) and works on Lenny (5.0) as well. Both releases include kernel '''linux-image-vserver-686''', so no manual patching is needed. Hence, Installation on Debian Etch/Lenny is pretty easy and straightforward.<br />
<br />
If you need to compile your own kernel, you need to apply the vserver-version.patch. [http://www.kwu.hu/vserver.txt Details at 2007/May/04]<br />
<br />
<br />
== Packages installation ==<br />
The packages required by Linux-VServer are:<br />
* '''linux-image-vserver-686''' - This is the current kernel, use '''linux-image-vserver-amd64''' on 64-bit systems, you can still create 32-bit guests<br />
* '''util-vserver''' - These are the utilities used to administer the guests<br />
* '''ssh''' - This is probably already installed, but just in case it isn't<br />
<br />
All the packages you need can be obtained via<br />
<pre>aptitude install linux-image-vserver-686 util-vserver ssh</pre><br />
so run this as ''root'' and reboot.<br />
To check out wherever everything went fine you may run<br />
<pre>uname -r</pre><br />
and check that kernel version contains '''vserver''', e.g. '''2.6.18-4-vserver-686'''. That's it.<br />
<br />
Now that the host system is ready, you can proceed with [[Building Guest Systems|building guests]].<br />
<br />
=== Install util-vserver by source ===<br />
Occasionally, Debian's util-vserver package can be too old. So, we'll need to compile from [http://people.linux-vserver.org/~dhozac/t/uv-testing/ source].<br />
<br />
First, install the required packages for util-vserver to compile.<br />
<pre>apt-get install vlan dietlibc-dev pkg-config libnss3-dev</pre><br />
<br />
Then, we configure util-vserver<br />
<pre>./configure --prefix=/usr --enable-release --mandir=/usr/share/man \<br />
--infodir=/usr/share/info --sysconfdir=/etc --enable-dietlibc \<br />
--localstatedir=/var --with-vrootdir=/home</pre><br />
Note: You should change ''--with-vrootdir'' accordingly<br />
<br />
Finally, we run make to finalise the installation<br />
<pre>make && make install debian && make install install-distribution</pre><br />
<br />
Running ''vserver-info'' will show you that the proper util-vserver is installed. :)<br />
<br />
Debian likes to be funny, so we need to enable the following,<br />
* echo /usr/lib/util-vserver/vshelper >| /proc/sys/kernel/vshelper<br />
* echo kernel.vshelper = /usr/lib/util-vserver/vshelper >> /etc/sysctl.conf<br />
* update-rc.d vprocunhide defaults<br />
* update-rc.d vservers-default defaults <br />
<br />
== Versions ==<br />
<br />
Debian already contains vservers kernels, so no manual patching and compiling is needed. <br />
<br />
{|class="wikitablenowrap"<br />
!Debian release <br />
!Kernel version<br />
!VServer version<br />
|-<br />
| Etch<br />
| 2.6.18+6<br />
| 2.0.2.2-rc9<br />
|-<br />
| Lenny<br />
| 2.6.26+17<br />
| 2.3.0.35<br />
|-<br />
|}<br />
<br />
Unofficial debian vserver packages : http://zbla.net/debian/<br />
<br />
<pre><br />
apt source line: deb http://zbla.net/debian/ ./<br />
</pre><br />
<br />
== Issues with the current 2.6.26 Kernel ==<br />
<br />
=== Hard CPU scheduling ===<br />
<br />
This will not work in the Debian 'Lenny' Kernel, the patch used simply does not contain any of this functionality.<br />
<br />
=== Problems due to Xattrs ===<br />
<br />
There are two sets of issues within the Lenny kernel caused by the change in value of the Xattrs (extended attributes) applied to file in Vserver setups. The patch used in Debian Lenny uses Xattr flags which are set in positions which differ from the flags set by Debian kernels as well as most of the mainline Vserver patches. This result is that Xattrs of files in a non lenny system appear to have completely different flags in Lenny and vice versa. Since these flags are crucial to vserver hashification and chroot security, they can have devastating effects on Vserver guests and on host system security. If you have recently moved to or away from the stock Lenny Vserver kernel, have look at the symptoms below to see if any match your experiences, and apply the fixes/use another kernel as you see fit.<br />
<br />
As of writing these issue has not been corrected within the Debian archive. These fixes must be applied whenever moving vserver guest '''from''' or '''to''' the Debian 'Lenny's vserver kernel. For more details and a more concise explanation see [http://irc.13thfloor.at/LOG/2009-05/LOG_2009-05-12.txt Bertls IRC explanation ].<br />
<br />
==== Chroot Security Problems ====<br />
<br />
Linux-Vserver uses file Xattrs to protect guest superusers from being able to view files above their root, preventing access to host file. This creates issues for anyone who:<br />
<br />
* has created a guest with a Debian 2.6.26-*-vserver kernel and wishes to use it with another kernel.<br />
* has created a guest with a different kernel and wishes to use it on a Debian 2.6.26-*-vserver kernel based host.<br />
<br />
In effect, the barrier normally in place for guest servers is not recognised by the kernel (the chroot problem) in the situation above and/or immutable links will not function correctly (the unification problem)failing to break when overwritten) in a unified guest setup. Symptoms suffered may include:<br />
<br />
* the possibility of vserver guest processes escaping their chroots and accessing other parts of the filesystem<br />
* guest not starting<br />
<br />
To fix the barrier flags for a current kernel, see [[Secure_chroot_Barrier#Solution:_Secure_Barrier | these instructions]]. Note that on some setups a barrier flags will appear on all directories under the guest hierarchy, and need to be unset in order to allow the servers to run. Use showattr to reveal the state of play for your guests and fix appropriately.<br />
<br />
==== Unification Problems ====<br />
<br />
There is a discrepancy between the immutable-unlink flag used for file unification, the process used in vhashify. This creates considerable issues for anyone who:<br />
<br />
* has unified guests with a Debian 2.6.26-*-vserver kernel and wishes to use them with another kernel.<br />
* has unified guests with a different kernel and wishes to then it on a Debian 2.6.26-*-vserver kernel based host.<br />
<br />
Symptoms suffered may include:<br />
<br />
* file that cannot be deleted<br />
* any process involving the writing of files in guests not working<br />
* files not being unlinked on write<br />
<br />
To fix the problem each file must be unlinked then the unification re-applied, or one could try this script submitted to [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508523 bugs.debian.org].<br />
<br />
<br />
=== /proc/mounts issue ===<br />
<br />
The vserver's /proc/mounts let appear the vserver path on the host. lsof (for example) is able to print it.<br />
<br />
=== "Ghosts" guests ===<br />
<br />
==== Issue ====<br />
Sometimes a guests loose it's name in vserver-stats and is acting like a zombie. It's impossible to restart or kill it. Stopping all the guests with the util-vserver init.d script doesn't solve the issue. vkill --xid $CTX doesn't either.<br />
<br />
==== Fix ====<br />
echo 50 > /var/run/vservers/$vserver<br />
<br />
Seems to fix the issue<br />
<br />
== References ==<br />
* Linux-VServer HOWTO by Daniel15: http://howtoforge.com/linux_vserver_debian_etch</div>Theocrite