http://linux-vserver.org/api.php?action=feedcontributions&user=DanielghSHy3&feedformat=atomLinux-VServer - User contributions [en]2024-03-28T08:07:46ZUser contributionsMediaWiki 1.20.2http://linux-vserver.org/Building_Guest_SystemsBuilding Guest Systems2011-02-24T08:52:51Z<p>DanielghSHy3: newvserver worked without any problems for me</p>
<hr />
<div>== Building a guest ==<br />
<br />
There are three parts to the <code>vserver ... build</code> command. Each part is separated by <code>--</code>. The first part are generic vserver options, such as hostname, available IP-addresses, and context id. The second part is specific to the chosen build method (by <code>-m <method></code> in the first part). The third part is completely optional and only implemented for a few build methods. These are options passed directly to whatever application is used to build guest.<br />
<br />
There are a lot of options not covered here (yet). Use <code>vserver - build --help</code> to see them all.<br />
<br />
=== Building guests using the debootstrap build method ===<br />
'''''(applies to Debian, Ubuntu,...)'''''<br />
* Build a Debian lenny guest using the ftp.de.debian.org mirror.<br />
vserver vserver1 build \<br />
-m debootstrap --[[context]] 42 \<br />
--hostname vserver1.mydomain.com \<br />
--interface eth0:192.168.1.10/24 \<br />
-- -d lenny -m http://ftp.de.debian.org/debian<br />
lenny can be replaced by e.g. etch for Debian etch, edgy for Ubuntu edgy, or sid for Debian sid. Anything your debootstrap version can handle will be fine.<br />
<br />
If you want to build a 32-bit guest on a 64-bit host, append <code>-- --arch i386</code> to the above command line. The same applies to other additional debootstrap options: place them after a second <code>--</code>. Likewise, in case your host architecture does not match one available in Debian by default, add your architecture in the same way. E.g. you might need to add <code>-- --arch amd64</code> to create a 64-bit Debian guest on a Gentoo host.<br />
<br />
Please note that <code>vserver...pkgmgmt</code> has has no use on Debian guests: package management is internalized by default and cannot be externalized. To externalize package management on Debian vserver guests, you have to create the guest using the <code>newvserver</code> command from the <code>vserver-debiantools</code> Debian package (see the <code>--pkgcache</code> option).<br />
Note that newvserver is considered obsolete and only suited for those who want to shoot themselves in the foot.<br />
<br />
newvserver worked without any problems for me on etch,lenny and squeeze:<br />
- ip a add 10.0.0.2/24 dev eth0 (and make nat if needed)<br />
- add to /etc/network/interfaces, after "iface eth0 inet static" and "dns-search":<br />
post-up /bin/ip a add dev eth0 10.0.0.2/24<br />
pre-down /bin/ip a del dev eth0 10.0.0.2/24<br />
- newvserver --vsroot /myvserversdir --hostname myvserver --domain mydomain --ip 10.0.0.2/24 --dist squeeze --mirror http://ftp.de.debian.org/debian/ --interface eth0<br />
- amd64 host with i386 guest: aptitude install util-linux && newvserver --arch i386 --vsroot /myvserversdir --hostname myvserver --domain mydomain --ip 10.0.0.2/24 --dist squeeze --mirror http://ftp.de.debian.org/debian/ --interface eth0<br />
- mv /etc/vservers/myvserver/interfaces/0/dev /etc/vservers/myvserver/interfaces/0/nodev<br />
- edit /etc/vservers/myvserver/fstab and increase "size=16m" or comment the line:<br />
#none /tmp tmpfs size=16m,mode=1777 0 0<br />
- again: ip a add 10.0.0.2/24 dev eth0<br />
- vserver myvserver start<br />
- vserver myvserver enter<br />
<br />
<br />
<br />
=== Building guests using the yum build method ===<br />
'''''(applies to Fedora, Centos, RHEL,...)'''''<br />
* Make sure that your host system already has yum installed, preferably one that has been patched to work better with chroots.<br />
<br />
* Build a CentOS 5-based guest using a minimal set of packages.<br />
vserver vserver2 build -m yum --[[context]] 42 \<br />
--hostname vserver2.mydomain.com \<br />
--interface eth0:192.168.1.11/24 -- -d centos5<br />
centos5 can be replaced by e.g. f8 for Fedora 8, or fc6 for Fedora 6.<br />
<br />
If you want to build a 32-bit guest on a 64-bit, prepend <code>linux32</code> to this and subsequent yum commands.<br />
<br />
* If you want to manage the packages inside the guest, you will have to install some package management program(s) as well as internalize the RPM database. This can be achieved by<br />
vyum vserver2 -- install yum<br />
vserver vserver2 pkgmgmt internalize<br />
Internal package management means that commands such as rpm, yum and rpmbuild can be used from inside the guest, as opposed to requiring the host administrator to run vrpm or vyum. If you use rpmbuild, you'll need internal package management, or use --nodeps (but that's ''strongly'' discouraged).<br />
<br />
* Depending on your host's/guest's distribution, you may also need to do<br />
vserver vserver2 exec bash -c "rm -f /var/lib/rpm/__db*; rpm --rebuilddb"<br />
This is required if every rpm operation, for example ''rpm -qa'', complains about a database version mismatch.<br />
<br />
=== Building guests using the template build method ===<br />
'''''(applies to Gentoo,...)'''''<br />
<br />
A template is a file containing a complete guest filesystem. This can be a tar(1)ball, a cpio(1)-archive, or a dump(8). It can be compressed using either gzip or bzip2. Multiple templates can be used, to do e.g. guest-specific modifications.<br />
<br />
* Build a guest using a single template named stage4-i686-20070905.tar.bz2 located in /vservers/.templates.<br />
vserver vserver3 build -m template \<br />
--[[context]] 42 --hostname vserver3.mydomain.com \<br />
--interface eth0:192.168.1.12/24 \<br />
--initstyle gentoo -- -d gentoo \<br />
-t /vservers/.templates/stage4-i686-20070905.tar.bz2<br />
<br />
'''OR'''<br />
<br />
* Build a guest using multiple templates, one named stage4-i686-20070905.tar.bz2 and one named httpd.tar.bz2.<br />
vserver vserver3 build -m template \<br />
--[[context]] 42 --hostname vserver3.mydomain.com \<br />
--interface eth0:192.168.1.12/24 \<br />
--initstyle gentoo -- -d gentoo \<br />
-t /vservers/.templates/stage4-i686-20070905.tar.bz2 \<br />
-t /vservers/.templates/httpd.tar.bz2<br />
<br />
=== Building guests using the rsync build method ===<br />
<br />
The rsync build method can be used to move a guest from one system to another. It is preferable for most guest distributions if the source guest is stopped when you create a one based on it, but it's not strictly required.<br />
<br />
* Build a guest by rsync'ing from vserver3 on host1.<br />
RSYNC_RSH=ssh<br />
vserver vserver4 build -m rsync --[[context]] 42 \<br />
--hostname vserver4.mydomain.com \<br />
--interface eth0:192.168.1.13/24 \<br />
-- --source root@host1:/vservers/vserver3<br />
<br />
'''OR'''<br />
<br />
* Build a guest by rsync'ing from vserver1 on the same host.<br />
vserver vserver4 build -m rsync --[[context]] 42 --hostname vserver4.mydomain.com --interface eth0:192.168.1.13/24 -- --source vserver1<br />
<br />
=== Building guests using the clone build method ===<br />
<br />
The clone build method copies the filesystem from one guest to another, much like the rsync build method, but the thing that separates it is that it knows about unified/hashified files. This means that it only creates new links for such files, and copies the rest, which can lead to significantly speedier builds.<br />
<br />
* Build a guest by using vserver4 as a reference.<br />
vserver vserver5 build -m clone --hostname vserver5.mydomain.com --interface eth0:192.168.1.14/24 -- --source /vservers/vserver4<br />
<br />
== Post-build customization ==<br />
<br />
== Verifying guest functionality ==<br />
<br />
* Once the guest is built, it's time to start it.<br />
vserver vserverX start<br />
<br />
* At this point, you can use both<br />
vserver vserverX enter<br />
and<br />
vserver vserverX exec ...<br />
to do things inside the guest.<br />
<br />
* To stop it, simply use<br />
vserver vserverX stop<br />
<br />
== How to remove a screwed up vserver ==<br />
<br />
* To to remove a screwed up vserver<br />
vserver vserverX delete<br />
<br />
== See also ==<br />
* [[Installing Ubuntu on Debian]]<br />
* [[Installing 32-bit Fedora on 64-bit Debian]]</div>DanielghSHy3http://linux-vserver.org/Installation_on_DebianInstallation on Debian2009-07-13T11:14:24Z<p>DanielghSHy3: </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 install-distribution</pre><br />
<br />
Running ''vserver-info'' will show you that the proper util-vserver is installed. :)<br />
<br />
== Versions ==<br />
Debian already contains vservers kernels, so no manual patching and compiling is needed. <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 />
== 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 />
== References ==<br />
* Linux-VServer HOWTO by Daniel15: http://howtoforge.com/linux_vserver_debian_etch</div>DanielghSHy3