Linux-VServer

errors, make sure, that 'vprocunhide' was executed. When installing 'util-vserver' with packagemanagement, an appropriate initscript should be installed flags are required for the 'rpmbuild' command. Builds on Red Hat 7.3 will require a guest systems can be created with the 'apt-rpm' or 'yum' build-methods. The first one requires the 'apt' package e.g. from and the configuration of a near mirror in The 'yum' method uses the repository configuration shipped by the fedora-release package. when having existing vservers with RH 9 or Fedora Core 1, the startup of the vserver will probably fail. You will have to add when having RH/FC guestsystems, it is strongly recommended to use a dietlibc linked version of 'rpm-fake-resolver'. Else, package installation with 'vrpm', 'vapt-get' or 'vyum' can fail since users can not be resolved. guest systems can be created with the 'debootstrap' method. When not already existing, the needed package will be downloaded automatically. Since it is updated very often, it can happen that a '404 Not found' error occurs; in this case look either for a newer util-vserver package, or configure the new URI e.g. with Gentoo guest systems are very complicated and are requiring lots of modifications in the initscripts. Currently, no step-by-step guide can be provided 'sysv' initstyle is probably not working for Gentoo guests (e.g. you will see messages about missing 'utmp' files); 'gentoo' should be used instead of: There exists a 'make install-distribution' target which installs files outside of the configured 'prefix'. In particular, these files are: As you probably know, two branches of 'util-vserver' are existing: the 'stable' one, and the 'alpha' one. This terms are to be understood as a level of the featureset stability but not of the software stability. E.g. 'stable' is not really stable: it has huge security problems and missing functionality. But you can expect that the current configuration will work in future versions also. This version is untested on author's side and it will be hard to bring patches/fixes in, since it must be proofed that they will not break anything. In the opposite, the 'alpha' branch does not have known security issues and works well (at least on author's system ;)). But it may happen that some behavior or configuration options change. With 'alpha' you should be still able to use vservers created with the 'stable' branch, but you may encounter some oddities -- especially on kernel 2.6 systems (e.g. 'vserver-stat' will not show the names of old vservers). when you have productive vservers running for some years already, stay at the 'stable' branch. A change to 'alpha' will need a completely rewritten configuration which must be perhaps changed again. when you are new at vservers, use the 'alpha' branch. You will have to learn the principles of vserver configuration for both branches but 'alpha' makes some things easier. when you have existing vservers and want all the new kernel 2.6 functionality, use the 'alpha' branch. A last note: the 'alpha' branch works both with the stable 2.4 and the development 2.6 kernel patch.