http://linux-vserver.org/api.php?action=feedcontributions&user=Trs&feedformat=atomLinux-VServer - User contributions [en]2024-03-29T07:54:15ZUser contributionsMediaWiki 1.20.2http://linux-vserver.org/Installation_on_GentooInstallation on Gentoo2021-08-17T11:09:17Z<p>Trs: /* Manually install a Linux-Vserver kernel */</p>
<hr />
<div>== Host configuration ==<br />
<br />
=== Manually installing a Linux-Vserver kernel ===<br />
<br />
IF your portage tree contains a pre-patched linux-vserver kernel, then that one could be fine to use: Skip to the next chapter.<br />
<br />
As of april 2016 there is no current maintainer for linux-vserver kernels on Gentoo. The Gentoo maintainers seem to have adapted a more "aggressive" approach related to removing "unmaintained" Gentoo packages, so they have deleted all "old" vserver pre-patched kernels from portage. This means that one has to install the vserver patch manually. However, this is a fairly simple process, slightly depending on whether you find a kernel source in portage that also has an available linux-vserver kernel patch. <br />
<br />
This is what you need to do:<br />
<br />
Have a look at Bertl's kernel patches. These are found on http://vserver.13thfloor.at/Experimental/ and named "patch-" + the kernel version the patch applies for. ("Experimental" is slightly misleading...)<br />
<br />
You'll then have to find kernel sources for which there is a patch available. Take a look into /var/db/repos/gentoo/sys-kernel/vanilla-sources . (On older Gentoo installations, this is rather /usr/portage/sys-kernel/vanilla-sources/ ). This is what you might see:<br />
<br />
<pre><br />
amd64 ~ # ls -l /var/db/repos/gentoo/sys-kernel/vanilla-sources<br />
totalt 228<br />
-rw-r--r-- 1 portage portage 23681 april 6 17:34 ChangeLog<br />
-rw-r--r-- 1 portage portage 104895 nov. 9 04:28 ChangeLog-2013<br />
-rw-r--r-- 1 portage portage 43787 nov. 9 05:11 ChangeLog-2015<br />
-rw-r--r-- 1 portage portage 11396 april 6 17:34 Manifest<br />
-rw-r--r-- 1 portage portage 642 jan. 25 00:06 metadata.xml<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-3.10.101.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 18 23:03 vanilla-sources-3.12.57.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-3.14.65.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 6 12:49 vanilla-sources-3.18.30.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 1 12:31 vanilla-sources-3.2.79.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 22 14:42 vanilla-sources-3.4.111.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 6 12:49 vanilla-sources-4.1.21.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-4.4.6.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-4.5.0.ebuild<br />
</pre><br />
<br />
Unfortunately, at this time of writing no patch exists for any of the most recent kernels from that list. If it did, then install that version and skip the next step and use the chosen kernel as the kernel to install and patch later in this short writeup.<br />
<br />
There is also a "gentoo-sources" kernel source alternative. These kernel are slightly patched with Gentoo updates. However, assumingly that these kernels are not so heavily patched by Gentoo that they couldn't accept the linux-vserver patch also. <br />
<br />
Here is a sample Gentoo-sources list:<br />
<br />
<pre><br />
amd64 ~ # ls -l /var/db/repos/gentoo/sys-kernel/gentoo-sources<br />
totalt 500<br />
-rw-r--r-- 1 portage portage 36798 april 6 17:34 ChangeLog<br />
-rw-r--r-- 1 portage portage 91971 nov. 9 04:28 ChangeLog-2007<br />
-rw-r--r-- 1 portage portage 101665 nov. 9 04:28 ChangeLog-2012<br />
-rw-r--r-- 1 portage portage 119486 nov. 9 05:11 ChangeLog-2015<br />
-rw-r--r-- 1 portage portage 766 mars 17 00:18 gentoo-sources-3.10.101.ebuild<br />
-rw-r--r-- 1 portage portage 757 jan. 24 12:50 gentoo-sources-3.10.95.ebuild<br />
[...several kernels deleted to save space...]<br />
-rw-r--r-- 1 portage portage 770 okt. 26 13:05 gentoo-sources-4.0.9.ebuild<br />
-rw-r--r-- 1 portage portage 787 jan. 10 11:32 gentoo-sources-4.1.12.ebuild<br />
-rw-r--r-- 1 portage portage 786 mars 21 12:45 gentoo-sources-4.1.15-r1.ebuild<br />
-rw-r--r-- 1 portage portage 794 mars 18 19:57 gentoo-sources-4.1.20.ebuild<br />
-rw-r--r-- 1 portage portage 794 april 6 15:49 gentoo-sources-4.1.21.ebuild<br />
-rw-r--r-- 1 portage portage 793 mars 17 00:56 gentoo-sources-4.4.6.ebuild<br />
-rw-r--r-- 1 portage portage 793 mars 29 14:53 gentoo-sources-4.5.0-r1.ebuild<br />
-rw-r--r-- 1 portage portage 40428 april 6 17:34 Manifest<br />
-rw-r--r-- 1 portage portage 705 jan. 25 00:06 metadata.xml<br />
</pre><br />
<br />
There is a match. http://vserver.13thfloor.at/Experimental/ has a patch for 4.1.12, so let's install the 4.1.12 gentoo-sources and try the linux-vserver patch on it.<br />
<br />
<pre><br />
amd64 ~ # emerge -v =sys-kernel/gentoo-sources-4.1.12<br />
</pre><br />
<br />
Then download the corresponding patch from 13thfloor and save it into the same directory as the emerged kernel source, which is /usr/src/gentoo-sources-4.1.12 .<br />
<br />
cd into that source directory and install the linux-vserver kernel patch:<br />
<br />
<pre><br />
amd64 ~ # cd /usr/src/linux-4.1.12-gentoo/<br />
amd64 linux-4.1.12-gentoo # patch -p1 < patch-4.1.12-vs2.3.8.3.diff <br />
patching file Documentation/vserver/debug.txt<br />
patching file Makefile<br />
Hunk #1 FAILED at 1.<br />
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej<br />
patching file arch/alpha/Kconfig<br />
patching file arch/alpha/kernel/systbls.S<br />
patching file arch/alpha/kernel/traps.c<br />
patching file arch/arm/Kconfig<br />
[...further output deleted...]<br />
</pre><br />
<br />
Hopefully there shouldn't be any serious rejects. The only reject I got was the makefile itself. By looking at the .rej file just the EXTRAVERSIONat failed since EXTRAVERSION is already set to "-gentoo" by gentoo-sources. So you can rather just edit EXTRAVERSION line the makefile manually to whatever you like or keep it as it is.<br />
<br />
Makefile.rej:<br />
<br />
<pre><br />
--- Makefile 2015-10-29 09:20:01.000000000 +0000<br />
+++ Makefile 2015-10-30 14:51:48.000000000 +0000<br />
@@ -1,7 +1,7 @@<br />
VERSION = 4<br />
PATCHLEVEL = 1<br />
SUBLEVEL = 12<br />
-EXTRAVERSION =<br />
+EXTRAVERSION = -vs2.3.8.3<br />
NAME = Series 4800<br />
<br />
# *DOCUMENTATION*<br />
</pre><br />
<br />
Then configure the kernel as you like, and as descripted in later chapters.<br />
<br />
=== Install a Linux-VServer kernel ===<br />
<br />
Installing a prepatched kernel is as easy as:<br />
<br />
<pre><br />
# emerge vserver-sources<br />
</pre><br />
<br />
After the vserver-sources are installed it's time to configure them using make menuconfig. Below is a common configuration for 2.1.1 and above. If you are using 2.0.x some configuration options may not be present.<br />
<br />
<pre><br />
# cd /usr/src/linux-<KERNELVERSION>-vserver-<VSERVERVERSION><br />
# make menuconfig<br />
<br />
Linux VServer ---><br />
[ ] Enable Legacy Kernel API<br />
[ ] Enable Legacy Networking Kernel API<br />
[ ] Remap Source IP Address<br />
[*] Enable COW Immutable Link Breaking<br />
[*] Enable Virtualized Guest Time<br />
[*] Enable Proc Security<br />
[*] Enable Hard CPU Limits<br />
[*] Avoid idle CPUs by skipping Time<br />
[*] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation<br />
[*] Honor Privacy Aspects of Guests<br />
[ ] VServer Debugging Code<br />
</pre><br />
<br />
'''Note''': If you are using reiserfs as file system on the partition where guest images are stored, you will need to enable extended attributes for reiserfs in your kernel configuration and additionally add the attrs option in /etc/fstab.<br />
<br />
<pre><br />
File systems ---><br />
<*> Reiserfs support<br />
[*] ReiserFS extended attributes<br />
</pre><br />
<br />
<pre><br />
/dev/hdb1 /vservers reiserfs noatime,attrs 0 0<br />
</pre><br />
<br />
After you've built and installed the kernel, update your boot loader and finally reboot to see if the kernel boots correctly.<br />
<br />
<pre><br />
(Building the kernel)<br />
# make<br />
(Installing)<br />
# make modules_install<br />
# cp arch/<arch>/boot/bzImage /boot/kernel-<KERNELVERSION>-vserver-<VSERVERVERSION><br />
(Edit bootloader config file as required and)<br />
# reboot<br />
</pre><br />
<br />
=== Setup host environment ===<br />
<br />
To maintain your virtual servers you need the util-vserver package which contains all necessary programs and many useful features.<br />
<br />
<pre><br />
# emerge >=sys-cluster/util-vserver-0.30.212<br />
</pre><br />
<br />
You have to run the vprocunhide command after every reboot in order to setup /proc permissions correctly for vserver use. An init script has been installed by util-vserver. To use it you should add it to a runlevel: <br />
<br />
<pre><br />
# rc-update add vprocunhide default<br />
# /etc/init.d/vprocunhide start<br />
# rc-update add util-vserver default<br />
# /etc/init.d/util-vserver start<br />
</pre><br />
<br />
== Guest creation ==<br />
<br />
=== Download a precompiled stage3 ===<br />
<br />
Since many hardware related commands are not available inside a virtual server,<br />
there has been a patched version of baselayout known as baselayout-vserver.<br />
However, since baselayout-2/openrc, all required changes have been integrated,<br />
eliminating the need for separate vserver stages, profiles and baselayout. The<br />
only (temporary) drawback is that baselayout-2/openrc is still in testing<br />
(~arch) and there are no stages with baselayout-2/openrc available on the<br />
mirrors yet.<br />
<br />
As soon as baselayout-2/openrc is stable you can use a precompiled stage3 from<br />
one of the [http://www.gentoo.org/main/en/mirrors.xml Gentoo mirrors]. In the meantime<br />
please download a stage3 or gentoo-vserver stage from<br />
[http://bb.xnull.de/projects/gentoo/stages/ here]. Since a<br />
stage3 contains a complete root file system you can use the template build<br />
method of util-vserver. However, this method only works reliable since<br />
util-vserver-0.30.213_rc5, so make sure you have the right version installed.<br />
<br />
You have to choose a context ID for your vserver (dynamic context IDs are discouraged) as well as the necessary network device information (In this example eth0 is configured with 192.168.1.253/24 and the context ID is equivalent to the last two parts of the virtual servers IP).<br />
<br />
=== Using the template build method ===<br />
<br />
For a long time now, plain init style was the only init style available for<br />
gentoo, i.e. a normal init process will be started inside the guest, just like<br />
on any common Unix system. However this approach has some drawbacks:<br />
<br />
* No possibility to see output of init/rc scripts<br />
* Wasted resources for idle init processes in each guest<br />
* Annoying conflicts for /etc/inittab<br />
<br />
Therefore, many users have requested the gentoo init style to be reimplemented,<br />
which has been abandoned since it was a very hacky implementation and more<br />
or less worked by accident due to other modifications done to baselayout back<br />
then. However, as of util-vserver-0.30.212 the gentoo init style has been<br />
reimplemented in a concise manner and will become the default in the future.<br />
<br />
<pre><br />
# vserver myguest build \<br />
--context 1253 \<br />
--hostname myguest \<br />
--interface eth0:192.168.1.253/24 \<br />
--initstyle gentoo \<br />
-m template -- \<br />
-t /path/to/gentoo-vserver-<arch>-<version>.tar.bz2 \<br />
-d gentoo<br />
</pre><br />
<br />
You should be able to start and enter the vserver by using the commands below.<br />
<br />
<pre><br />
# vserver myguest start<br />
<br />
OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]<br />
<br />
Press I to enter interactive boot mode<br />
<br />
* /proc is already mounted, skipping<br />
* Setting hostname to myguest... [ ok ]<br />
* Creating user login records... [ ok ]<br />
* Cleaning /var/run... [ ok ]<br />
* Wiping /tmp directory... [ ok ]<br />
* Updating /etc/mtab... [ ok ]<br />
* Initializing random number generator... [ ok ]<br />
* Starting syslog-ng... [ ok ]<br />
* Starting fcron... [ ok ]<br />
* Starting Name Service Cache Daemon... [ ok ]<br />
* Starting local... [ ok ]<br />
# vserver-stat<br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 90 1.4G 153.4K 14m00s11 6m45s17 2h59m59 root server<br />
1253 2 3M 286 0m00s45 0m00s42 0m02s91 myguest<br />
# vserver myguest enter<br />
# ps ax<br />
PID TTY STAT TIME COMMAND<br />
1 ? Ss 0:04 init [3]<br />
27637 ? Ss 0:00 /usr/sbin/syslog-ng<br />
27656 ? Ss 0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf<br />
27676 ? Ssl 0:00 /usr/sbin/nscd<br />
27713 ? S+ 0:00 login<br />
27737 pts/15 Ss 0:00 /bin/bash<br />
27832 pts/15 R+ 0:00 ps ax<br />
# logout<br />
</pre><br />
<br />
== Maintenance made easy ==<br />
<br />
=== Start guests on boot ===<br />
<br />
You can start certain guests during boot. Each guest can be assigned a MARK. Now everything you have to do is configure these MARKs in the guests configuration and tell the init script to run all MARKed guests.<br />
<br />
<pre><br />
(Do this for every guest you want to start)<br />
# mkdir -p /etc/vservers/myguest/apps/init<br />
# echo "default" > /etc/vservers/myguest/apps/init/mark<br />
</pre><br />
<br />
'''Note''': Since all guests marked with "default" are started by default, nothing more has to be done. If you have different marks you should also update /etc/conf.d/vservers.<br />
<br />
=== Keep portage in sync ===<br />
<br />
The script vesync will help you to keep the metadata cache and overlays in sync. vemerge is a simple wrapper for emerge in guests.<br />
<br />
<pre><br />
(Sync metadata for 'myguest')<br />
# vesync myguest<br />
(Sync metadata for all guests)<br />
# vesync -a<br />
(Sync metadata for all guests except 'myguest')<br />
# vesync -a -e myguest<br />
(Sync 'myoverlay' for all guests)<br />
# vesync -a \<br />
--overlay /usr/local/overlays/myoverlay \<br />
--overlay-host rsync://rsync.myhost.com/myoverlay \<br />
--overlay-only<br />
(emerge app-editors/vim in 'myguest')<br />
# vemerge myguest -- app-editors/vim -va<br />
</pre><br />
<br />
=== Update guests ===<br />
<br />
Gentoo guests can share packages to save compilation time. In order to use shared packages, you have to create a central directory for packages on the host. We will use /var/cache/vpackages on the host and mount it to /usr/portage/packages in every guest.<br />
<br />
<pre><br />
# mkdir -p /var/cache/vpackages<br />
# $EDITOR /etc/vservers/myguest/fstab<br />
(Add this line at the end)<br />
/var/cache/vpackages /usr/portage/packages none bind,rw 0 0<br />
</pre><br />
<br />
Now you can use vupdateworld to update every guest. The command is equivalent to something like emerge --deep --update --newuse world depending on command line options.<br />
<br />
<pre><br />
(Pretend update for 'myguest')<br />
# vupdateworld -p myguest<br />
(Update 'myguest' using binary packages)<br />
# vupdateworld -k myguest<br />
(Update all guests using binary packages)<br />
# vupdateworld -ka<br />
</pre><br />
<br />
'''Note''': In order to get binary packages you can either use PORTAGE_BINHOST (see man make.conf) or set FEATURES="buildpkg" in one or more guests.<br />
<br />
After a successful update you can easily update all configuration files with vdispatch-conf. It is a simple wrapper for dispatch-conf and behaves exactly the same.<br />
<br />
<pre><br />
(Update configuration files for 'myguest')<br />
# vdispatch-conf myguest<br />
(Update configuration files for all guests)<br />
# vdispatch-conf -a<br />
</pre><br />
<br />
=== Bash scripts ===<br />
<br />
These scripts will hopefully help some of you out with some basic tasks. Review each script carefully, so you know what it is doing.<br />
<br />
The scripts here were outdated and the original contributor removed them.<br />
<br />
== External Resources ==<br />
<br />
Please take a look at the [http://www.gentoo.org/proj/en/vps/vserver-howto.xml Gentoo Linux-VServer Howto] for more information. In general we try to keep the wiki in sync, nevertheless it might help :)<br />
<br />
[[Category:Installation]]</div>Trshttp://linux-vserver.org/Installation_on_GentooInstallation on Gentoo2016-04-09T13:13:53Z<p>Trs: /* Host configuration */</p>
<hr />
<div>== Host configuration ==<br />
<br />
=== Manually install a Linux-Vserver kernel ===<br />
<br />
IF your portage tree contains a pre-patched linux-vserver kernel, then use that one and skip to the next chapter.<br />
<br />
As of april 2016 there is no current maintainer for linux-vserver kernels on Gentoo. The Gentoo maintainers seem to have adapted a more "aggressive" approach related to removing unmaintained Gentoo packages, so they have deleted all "old" vserver pre-patched kernels from portage. This means that one has to install the vserver patch manually.<br />
However, this is a fairly simple process, depending on whether you find a kernel source in portage that has an available linux-vserver kernel patch also. <br />
This is what you need to do:<br />
<br />
Have a look at Bertl's kernel patches. These are found on http://vserver.13thfloor.at/Experimental/ and named "patch-" + the kernel version the patch applies for. ("Experimental" is slightly misleading...)<br />
<br />
You'll then have to find kernel sources for which there is a patch available. Take a look into /usr/portage/sys-kernel/vanilla-sources/. This is what you might see:<br />
<br />
<pre><br />
amd64 ~ # ls -l /usr/portage/sys-kernel/vanilla-sources/<br />
totalt 228<br />
-rw-r--r-- 1 portage portage 23681 april 6 17:34 ChangeLog<br />
-rw-r--r-- 1 portage portage 104895 nov. 9 04:28 ChangeLog-2013<br />
-rw-r--r-- 1 portage portage 43787 nov. 9 05:11 ChangeLog-2015<br />
-rw-r--r-- 1 portage portage 11396 april 6 17:34 Manifest<br />
-rw-r--r-- 1 portage portage 642 jan. 25 00:06 metadata.xml<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-3.10.101.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 18 23:03 vanilla-sources-3.12.57.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-3.14.65.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 6 12:49 vanilla-sources-3.18.30.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 1 12:31 vanilla-sources-3.2.79.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 22 14:42 vanilla-sources-3.4.111.ebuild<br />
-rw-r--r-- 1 portage portage 456 april 6 12:49 vanilla-sources-4.1.21.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-4.4.6.ebuild<br />
-rw-r--r-- 1 portage portage 456 mars 17 10:58 vanilla-sources-4.5.0.ebuild<br />
</pre><br />
<br />
Unfortunately, at this time of writing no patch exists for any of the most recent kernels from that list. If it did, then install that version and skip the next step and use the chosen kernel as the kernel to install and patch later in this short writeup.<br />
<br />
There is also a "gentoo-sources" kernel source alternative. These kernel are slightly patched with Gentoo updates. However, assumingly that these kernels are not so heavily patched by Gentoo that they couldn't accept the linux-vserver patch also. <br />
<br />
Here is a sample Gentoo-sources list:<br />
<br />
<pre><br />
amd64 ~ # ls -l /usr/portage/sys-kernel/gentoo-sources/<br />
totalt 500<br />
-rw-r--r-- 1 portage portage 36798 april 6 17:34 ChangeLog<br />
-rw-r--r-- 1 portage portage 91971 nov. 9 04:28 ChangeLog-2007<br />
-rw-r--r-- 1 portage portage 101665 nov. 9 04:28 ChangeLog-2012<br />
-rw-r--r-- 1 portage portage 119486 nov. 9 05:11 ChangeLog-2015<br />
-rw-r--r-- 1 portage portage 766 mars 17 00:18 gentoo-sources-3.10.101.ebuild<br />
-rw-r--r-- 1 portage portage 757 jan. 24 12:50 gentoo-sources-3.10.95.ebuild<br />
[...several kernels deleted to save space...]<br />
-rw-r--r-- 1 portage portage 770 okt. 26 13:05 gentoo-sources-4.0.9.ebuild<br />
-rw-r--r-- 1 portage portage 787 jan. 10 11:32 gentoo-sources-4.1.12.ebuild<br />
-rw-r--r-- 1 portage portage 786 mars 21 12:45 gentoo-sources-4.1.15-r1.ebuild<br />
-rw-r--r-- 1 portage portage 794 mars 18 19:57 gentoo-sources-4.1.20.ebuild<br />
-rw-r--r-- 1 portage portage 794 april 6 15:49 gentoo-sources-4.1.21.ebuild<br />
-rw-r--r-- 1 portage portage 793 mars 17 00:56 gentoo-sources-4.4.6.ebuild<br />
-rw-r--r-- 1 portage portage 793 mars 29 14:53 gentoo-sources-4.5.0-r1.ebuild<br />
-rw-r--r-- 1 portage portage 40428 april 6 17:34 Manifest<br />
-rw-r--r-- 1 portage portage 705 jan. 25 00:06 metadata.xml<br />
</pre><br />
<br />
There is a match. http://vserver.13thfloor.at/Experimental/ has a patch for 4.1.12, so let's install the 4.1.12 gentoo-sources and try the linux-vserver patch on it.<br />
<br />
<pre><br />
amd64 ~ # emerge -v =sys-kernel/gentoo-sources-4.1.12<br />
</pre><br />
<br />
Then download the corresponding patch from 13thfloor and save it into the same directory as the emerged kernel sources which in this case is /usr/src/gentoo-sources-4.1.12 .<br />
<br />
cd into that source directory and install the linux-vserver kernel patch:<br />
<br />
<pre><br />
amd64 ~ # cd /usr/src/linux-4.1.12-gentoo/<br />
amd64 linux-4.1.12-gentoo # patch -p1 < patch-4.1.12-vs2.3.8.3.diff <br />
patching file Documentation/vserver/debug.txt<br />
patching file Makefile<br />
Hunk #1 FAILED at 1.<br />
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej<br />
patching file arch/alpha/Kconfig<br />
patching file arch/alpha/kernel/systbls.S<br />
patching file arch/alpha/kernel/traps.c<br />
patching file arch/arm/Kconfig<br />
[...further output deleted...]<br />
</pre><br />
<br />
Hopefully there shouldn't be any serious rejects. The only reject I got was the makefile itself. By looking at the .rej file, it is just the EXTRAVERSION that failed since EXTRAVERSION is already set to "-gentoo" by gentoo-sources. So you can rather just edit EXTRAVERSION line the makefile manually to whatever you like or keep it as it is.<br />
<br />
Makefile.rej:<br />
<br />
<pre><br />
--- Makefile 2015-10-29 09:20:01.000000000 +0000<br />
+++ Makefile 2015-10-30 14:51:48.000000000 +0000<br />
@@ -1,7 +1,7 @@<br />
VERSION = 4<br />
PATCHLEVEL = 1<br />
SUBLEVEL = 12<br />
-EXTRAVERSION =<br />
+EXTRAVERSION = -vs2.3.8.3<br />
NAME = Series 4800<br />
<br />
# *DOCUMENTATION*<br />
</pre><br />
<br />
Then configure the kernel as you like, and as descripted in later chapters.<br />
<br />
=== Install a Linux-VServer kernel ===<br />
<br />
Installing a prepatched kernel is as easy as:<br />
<br />
<pre><br />
# emerge vserver-sources<br />
</pre><br />
<br />
After the vserver-sources are installed it's time to configure them using make menuconfig. Below is a common configuration for 2.1.1 and above. If you are using 2.0.x some configuration options may not be present.<br />
<br />
<pre><br />
# cd /usr/src/linux-<KERNELVERSION>-vserver-<VSERVERVERSION><br />
# make menuconfig<br />
<br />
Linux VServer ---><br />
[ ] Enable Legacy Kernel API<br />
[ ] Enable Legacy Networking Kernel API<br />
[ ] Remap Source IP Address<br />
[*] Enable COW Immutable Link Breaking<br />
[*] Enable Virtualized Guest Time<br />
[*] Enable Proc Security<br />
[*] Enable Hard CPU Limits<br />
[*] Avoid idle CPUs by skipping Time<br />
[*] Limit the IDLE task<br />
Persistent Inode Tagging (UID24/GID24) ---><br />
[ ] Tag NFSD User Auth and Files<br />
[ ] Enable Inode Tag Propagation<br />
[*] Honor Privacy Aspects of Guests<br />
[ ] VServer Debugging Code<br />
</pre><br />
<br />
'''Note''': If you are using reiserfs as file system on the partition where guest images are stored, you will need to enable extended attributes for reiserfs in your kernel configuration and additionally add the attrs option in /etc/fstab.<br />
<br />
<pre><br />
File systems ---><br />
<*> Reiserfs support<br />
[*] ReiserFS extended attributes<br />
</pre><br />
<br />
<pre><br />
/dev/hdb1 /vservers reiserfs noatime,attrs 0 0<br />
</pre><br />
<br />
After you've built and installed the kernel, update your boot loader and finally reboot to see if the kernel boots correctly.<br />
<br />
<pre><br />
(Building the kernel)<br />
# make<br />
(Installing)<br />
# make modules_install<br />
# cp arch/<arch>/boot/bzImage /boot/kernel-<KERNELVERSION>-vserver-<VSERVERVERSION><br />
(Edit bootloader config file as required and)<br />
# reboot<br />
</pre><br />
<br />
=== Setup host environment ===<br />
<br />
To maintain your virtual servers you need the util-vserver package which contains all necessary programs and many useful features.<br />
<br />
<pre><br />
# emerge >=sys-cluster/util-vserver-0.30.212<br />
</pre><br />
<br />
You have to run the vprocunhide command after every reboot in order to setup /proc permissions correctly for vserver use. An init script has been installed by util-vserver. To use it you should add it to a runlevel: <br />
<br />
<pre><br />
# rc-update add vprocunhide default<br />
# /etc/init.d/vprocunhide start<br />
# rc-update add util-vserver default<br />
# /etc/init.d/util-vserver start<br />
</pre><br />
<br />
== Guest creation ==<br />
<br />
=== Download a precompiled stage3 ===<br />
<br />
Since many hardware related commands are not available inside a virtual server,<br />
there has been a patched version of baselayout known as baselayout-vserver.<br />
However, since baselayout-2/openrc, all required changes have been integrated,<br />
eliminating the need for separate vserver stages, profiles and baselayout. The<br />
only (temporary) drawback is that baselayout-2/openrc is still in testing<br />
(~arch) and there are no stages with baselayout-2/openrc available on the<br />
mirrors yet.<br />
<br />
As soon as baselayout-2/openrc is stable you can use a precompiled stage3 from<br />
one of the [http://www.gentoo.org/main/en/mirrors.xml Gentoo mirrors]. In the meantime<br />
please download a stage3 or gentoo-vserver stage from<br />
[http://bb.xnull.de/projects/gentoo/stages/ here]. Since a<br />
stage3 contains a complete root file system you can use the template build<br />
method of util-vserver. However, this method only works reliable since<br />
util-vserver-0.30.213_rc5, so make sure you have the right version installed.<br />
<br />
You have to choose a context ID for your vserver (dynamic context IDs are discouraged) as well as the necessary network device information (In this example eth0 is configured with 192.168.1.253/24 and the context ID is equivalent to the last two parts of the virtual servers IP).<br />
<br />
=== Using the template build method ===<br />
<br />
For a long time now, plain init style was the only init style available for<br />
gentoo, i.e. a normal init process will be started inside the guest, just like<br />
on any common Unix system. However this approach has some drawbacks:<br />
<br />
* No possibility to see output of init/rc scripts<br />
* Wasted resources for idle init processes in each guest<br />
* Annoying conflicts for /etc/inittab<br />
<br />
Therefore, many users have requested the gentoo init style to be reimplemented,<br />
which has been abandoned since it was a very hacky implementation and more<br />
or less worked by accident due to other modifications done to baselayout back<br />
then. However, as of util-vserver-0.30.212 the gentoo init style has been<br />
reimplemented in a concise manner and will become the default in the future.<br />
<br />
<pre><br />
# vserver myguest build \<br />
--context 1253 \<br />
--hostname myguest \<br />
--interface eth0:192.168.1.253/24 \<br />
--initstyle gentoo \<br />
-m template -- \<br />
-t /path/to/gentoo-vserver-<arch>-<version>.tar.bz2 \<br />
-d gentoo<br />
</pre><br />
<br />
You should be able to start and enter the vserver by using the commands below.<br />
<br />
<pre><br />
# vserver myguest start<br />
<br />
OpenRC 0.4.3 is starting up Gentoo Linux (x86_64) [VSERVER]<br />
<br />
Press I to enter interactive boot mode<br />
<br />
* /proc is already mounted, skipping<br />
* Setting hostname to myguest... [ ok ]<br />
* Creating user login records... [ ok ]<br />
* Cleaning /var/run... [ ok ]<br />
* Wiping /tmp directory... [ ok ]<br />
* Updating /etc/mtab... [ ok ]<br />
* Initializing random number generator... [ ok ]<br />
* Starting syslog-ng... [ ok ]<br />
* Starting fcron... [ ok ]<br />
* Starting Name Service Cache Daemon... [ ok ]<br />
* Starting local... [ ok ]<br />
# vserver-stat<br />
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME<br />
0 90 1.4G 153.4K 14m00s11 6m45s17 2h59m59 root server<br />
1253 2 3M 286 0m00s45 0m00s42 0m02s91 myguest<br />
# vserver myguest enter<br />
# ps ax<br />
PID TTY STAT TIME COMMAND<br />
1 ? Ss 0:04 init [3]<br />
27637 ? Ss 0:00 /usr/sbin/syslog-ng<br />
27656 ? Ss 0:00 /usr/sbin/fcron -c /etc/fcron/fcron.conf<br />
27676 ? Ssl 0:00 /usr/sbin/nscd<br />
27713 ? S+ 0:00 login<br />
27737 pts/15 Ss 0:00 /bin/bash<br />
27832 pts/15 R+ 0:00 ps ax<br />
# logout<br />
</pre><br />
<br />
== Maintenance made easy ==<br />
<br />
=== Start guests on boot ===<br />
<br />
You can start certain guests during boot. Each guest can be assigned a MARK. Now everything you have to do is configure these MARKs in the guests configuration and tell the init script to run all MARKed guests.<br />
<br />
<pre><br />
(Do this for every guest you want to start)<br />
# mkdir -p /etc/vservers/myguest/apps/init<br />
# echo "default" > /etc/vservers/myguest/apps/init/mark<br />
</pre><br />
<br />
'''Note''': Since all guests marked with "default" are started by default, nothing more has to be done. If you have different marks you should also update /etc/conf.d/vservers.<br />
<br />
=== Keep portage in sync ===<br />
<br />
The script vesync will help you to keep the metadata cache and overlays in sync. vemerge is a simple wrapper for emerge in guests.<br />
<br />
<pre><br />
(Sync metadata for 'myguest')<br />
# vesync myguest<br />
(Sync metadata for all guests)<br />
# vesync -a<br />
(Sync metadata for all guests except 'myguest')<br />
# vesync -a -e myguest<br />
(Sync 'myoverlay' for all guests)<br />
# vesync -a \<br />
--overlay /usr/local/overlays/myoverlay \<br />
--overlay-host rsync://rsync.myhost.com/myoverlay \<br />
--overlay-only<br />
(emerge app-editors/vim in 'myguest')<br />
# vemerge myguest -- app-editors/vim -va<br />
</pre><br />
<br />
=== Update guests ===<br />
<br />
Gentoo guests can share packages to save compilation time. In order to use shared packages, you have to create a central directory for packages on the host. We will use /var/cache/vpackages on the host and mount it to /usr/portage/packages in every guest.<br />
<br />
<pre><br />
# mkdir -p /var/cache/vpackages<br />
# $EDITOR /etc/vservers/myguest/fstab<br />
(Add this line at the end)<br />
/var/cache/vpackages /usr/portage/packages none bind,rw 0 0<br />
</pre><br />
<br />
Now you can use vupdateworld to update every guest. The command is equivalent to something like emerge --deep --update --newuse world depending on command line options.<br />
<br />
<pre><br />
(Pretend update for 'myguest')<br />
# vupdateworld -p myguest<br />
(Update 'myguest' using binary packages)<br />
# vupdateworld -k myguest<br />
(Update all guests using binary packages)<br />
# vupdateworld -ka<br />
</pre><br />
<br />
'''Note''': In order to get binary packages you can either use PORTAGE_BINHOST (see man make.conf) or set FEATURES="buildpkg" in one or more guests.<br />
<br />
After a successful update you can easily update all configuration files with vdispatch-conf. It is a simple wrapper for dispatch-conf and behaves exactly the same.<br />
<br />
<pre><br />
(Update configuration files for 'myguest')<br />
# vdispatch-conf myguest<br />
(Update configuration files for all guests)<br />
# vdispatch-conf -a<br />
</pre><br />
<br />
=== Bash scripts ===<br />
<br />
These scripts will hopefully help some of you out with some basic tasks. Review each script carefully, so you know what it is doing.<br />
<br />
The scripts here were outdated and the original contributor removed them.<br />
<br />
== External Resources ==<br />
<br />
Please take a look at the [http://www.gentoo.org/proj/en/vps/vserver-howto.xml Gentoo Linux-VServer Howto] for more information. In general we try to keep the wiki in sync, nevertheless it might help :)<br />
<br />
[[Category:Installation]]</div>Trshttp://linux-vserver.org/Building_Guest_SystemsBuilding Guest Systems2010-05-18T12:42:13Z<p>Trs: </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). Note that newvserver is considered obsolete and only suited for those who want to foot themselves in shoot.<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>Trs