use $(LIBENSCVECTOR) instead of libensc_vector.a
[util-vserver.git] / util-vserver / README
index 0b24797..7e6caf1 100644 (file)
@@ -9,8 +9,8 @@ Some common notes/FAQs:
   'util-vserver' with packagemanagement, an appropriate initscript
   should be installed
 
-* the name of old-style vservers is not shown; the needed functionality
-  is not implemented
+* the name of old-style vservers is shown on 2.4 kernels only; the
+  needed functionality is not implemented for 2.6 kernels.
 
 
 
@@ -39,14 +39,17 @@ Red Hat 7.3, Red Hat 9, Fedora Core 1&2
   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' build-method. This
-  requires the 'apt' package e.g. from http://fedora.us. Before first
-  invocation, a near mirror should be activated in
+* 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)
+  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
 
@@ -59,8 +62,8 @@ Red Hat 7.3, Red Hat 9, Fedora Core 1&2
 
 * when having RH/FC guestsystems, it is *strongly* recommended to use
   a dietlibc linked version of 'rpm-fake-resolver'. Else, package
-  installation with 'vrpm' or 'vapt-get' can fail since users can not
-  be resolved.
+  installation with 'vrpm', 'vapt-get' or 'vyum' can fail since users
+  can not be resolved.
 
 
 
@@ -77,13 +80,12 @@ Debian Woody & Sarge
   | 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 put it with
+  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
 
-  into this file.
-
 * it is known, that warning messages will be created at startup and
   shutdown of guest servers. This is non fatal and can be ignored
 
@@ -115,4 +117,74 @@ Gentoo
 
 
 
+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$