X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=README;h=e99e9997a1b9c942293fc6c3435e43b2501c5604;hb=5f167675beabb9f55df5fe8a579f87763764cb08;hp=86b6e1dbf6e8ae684d80e2e66847b69fbed3cc44;hpb=06e1018272502e1d15d6d8f32b80fa96420785b8;p=util-vserver.git diff --git a/README b/README index 86b6e1d..e99e999 100644 --- a/README +++ b/README @@ -1,10 +1,190 @@ -Build-Requirements: +Some common notes/FAQs: +====================== - * at least gcc-2.95 (C and C++ frontends) +* when vserver startup/shutdown fails, or when you get - * when using 2.6 kernel-headers, the 'e2fsprogs' headers are - required. RHL/Fedora Core ships them in the 'e2fsprogs-devel' - package, Mandrake in 'libext2fs2-devel'. + | Error: /proc must be mounted - Using these headers with kernel 2.4 will not hurt and can prevent - problems, so they are strongly recommended. + errors, make sure, that 'vprocunhide' was executed. When installing + 'util-vserver' with packagemanagement, an appropriate initscript + should be installed + +* the name of old-style vservers is shown on 2.4 kernels only; the + needed functionality is not implemented for 2.6 kernels. + + + +Some distribution specific notes: +================================= + +Red Hat 7.3, Red Hat 9, Fedora Core 1&2 +--------------------------------------- +* tested and running successfully as host and guest systems + +* it is *strongly* suggested to use the rpm packages which can be + created from the tarball with + + | $ rpmbuild -tb util-vserver-.tar.bz2 + + For distributions below Fedora Core 2, additional + + | --without dietlibc --without xalan + + flags are required for the 'rpmbuild' command. Builds on Red Hat 7.3 + will require a + + | --nodeps + + also, since 'vconfig' is not available there. Since it is required + for path-detection only and paths from RH systems will be assumed by + default, this should not be a big problem. + +* guest systems can be created with the 'apt-rpm' or 'yum' build-methods. + The first one requires the 'apt' package e.g. from http://fedora.us and + the configuration of a near mirror in + + | /etc/vservers/.distributions//apt/sources.list + + (To avoid slashdotting by the masses of util-vserver-users, there + does not exist a standard mirror). + + The 'yum' method uses the repository configuration shipped by the + fedora-release package. + +* RH/FC uses the 'sysv' initstyle which is assumed by default + +* when having existing vservers with RH 9 or Fedora Core 1, the startup + of the vserver will probably fail. You will have to add + + | true + + to etc/rc.d/rc (within the vserver root directory) + +* 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. + + + +Debian Woody & Sarge +-------------------- +* tested and running successfully as guest systems on FC1/FC2 hosts + +* 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 + + | echo 'http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap__i386.deb' \ + | >/etc/vservers/.defaults/apps/debootstrap/uri + + You can download a local copy of this tarball also, and register it + with + + | echo '/' \ + | >/etc/vservers/.defaults/apps/debootstrap/uri + +* it is known, that warning messages will be created at startup and + shutdown of guest servers. This is non fatal and can be ignored + +* Debian guest systems are running fine with the 'sysv' initstyle; + success with 'plain' was reported also + +* no packages for Debian hosts are known at time of writing (May 2004) + + + +Gentoo +------ +* 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: + + | echo 'gentoo' >/etc/vservers//apps/init/style + +* there does not exist a build-method for Gentoo guests; instead of, + create a skeleton with + + | # vserver build -m skeleton --initstyle gentoo * + + and fill the vserver directory at /etc/vservers//vdir/ manually. + + + +Notes for distributors: +======================= + +To generate FHS compliant paths, call configure with + +| ./configure --prefix=/usr --mandir=/usr/share/man \ +| --sysconfdir=/etc --localstatedir=/var \ +| --with-vrootdir= + +Except the '--with-vrootdir' option, rpm's '%configure' option will +expand to this. + + +There exists a 'make install-distribution' target which installs +files outside of the configured 'prefix'. In particular, these files are: + +* the /sbin/vshelper symlink +* the /vservers and related directories (or whatever you configured + with '--with-vrootdir') + +Without this rule, 'make distcheck' would fail. + + +It might be needed also, to call 'setattr --barrier /vservers' in an +after-installation script. + + + +Which version shall I use? +========================== + +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). + + +So let me summarize: + +* 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. + + + +## $Id: README 2283 2006-09-10 17:07:57Z hollow $