-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-<version>.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/<id>/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_<version>_i386.deb' \
+ | >/etc/vservers/.defaults/apps/debootstrap/uri
+
+ You can download a local copy of this tarball also, and register it
+ with
+
+ | echo '/<path-to-the-tarball>' \
+ | >/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/<id>/apps/init/style
+
+* there does not exist a build-method for Gentoo guests; instead of,
+ create a skeleton with
+
+ | # vserver <id> build -m skeleton --initstyle gentoo <other-opts>*
+
+ and fill the vserver directory at /etc/vservers/<id>/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=<an FHS compliant path for /vservers>
+
+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 $
git://git.onelab.eu / util-vserver.git / blobdiff