README

   1 Some common notes/FAQs:
   2 ======================
   3
   4 * when vserver startup/shutdown fails, or when you get
   5
   6   | Error: /proc must be mounted
   7
   8   errors, make sure, that 'vprocunhide' was executed. When installing
   9   'util-vserver' with packagemanagement, an appropriate initscript
  10   should be installed
  11
  12 * the name of old-style vservers is shown on 2.4 kernels only; the
  13   needed functionality is not implemented for 2.6 kernels.
  14
  15
  16
  17 Some distribution specific notes:
  18 =================================
  19
  20 Red Hat 7.3, Red Hat 9, Fedora Core 1&2
  21 ---------------------------------------
  22 * tested and running successfully as host and guest systems
  23
  24 * it is *strongly* suggested to use the rpm packages which can be
  25   created from the tarball with
  26
  27   | $ rpmbuild -tb util-vserver-<version>.tar.bz2
  28
  29   For distributions below Fedora Core 2, additional
  30
  31   | --without dietlibc --without xalan
  32
  33   flags are required for the 'rpmbuild' command. Builds on Red Hat 7.3
  34   will require a
  35
  36   | --nodeps
  37
  38   also, since 'vconfig' is not available there. Since it is required
  39   for path-detection only and paths from RH systems will be assumed by
  40   default, this should not be a big problem.
  41
  42 * guest systems can be created with the 'apt-rpm' or 'yum' build-methods.
  43   The first one requires the 'apt' package e.g. from http://fedora.us and
  44   the configuration of a near mirror in
  45
  46   | /etc/vservers/.distributions/<id>/apt/sources.list
  47
  48   (To avoid slashdotting by the masses of util-vserver-users, there
  49   does not exist a standard mirror).
  50
  51   The 'yum' method uses the repository configuration shipped by the
  52   fedora-release package.
  53
  54 * RH/FC uses the 'sysv' initstyle which is assumed by default
  55
  56 * when having existing vservers with RH 9 or Fedora Core 1, the startup
  57   of the vserver will probably fail. You will have to add
  58
  59   | true
  60
  61   to etc/rc.d/rc (within the vserver root directory)
  62
  63 * when having RH/FC guestsystems, it is *strongly* recommended to use
  64   a dietlibc linked version of 'rpm-fake-resolver'. Else, package
  65   installation with 'vrpm', 'vapt-get' or 'vyum' can fail since users
  66   can not be resolved.
  67
  68
  69
  70 Debian Woody & Sarge
  71 --------------------
  72 * tested and running successfully as guest systems on FC1/FC2 hosts
  73
  74 * guest systems can be created with the 'debootstrap' method. When
  75   not already existing, the needed package will be downloaded
  76   automatically.  Since it is updated very often, it can happen
  77   that a '404 Not found' error occurs; in this case look either
  78   for a newer util-vserver package, or configure the new URI e.g. with
  79
  80   | echo 'http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap_<version>_i386.deb' \
  81   |    >/etc/vservers/.defaults/apps/debootstrap/uri
  82
  83   You can download a local copy of this tarball also, and register it
  84   with
  85
  86   | echo '/<path-to-the-tarball>' \
  87   |    >/etc/vservers/.defaults/apps/debootstrap/uri
  88
  89 * it is known, that warning messages will be created at startup and
  90   shutdown of guest servers. This is non fatal and can be ignored
  91
  92 * Debian guest systems are running fine with the 'sysv' initstyle;
  93   success with 'plain' was reported also
  94
  95 * no packages for Debian hosts are known at time of writing (May 2004)
  96
  97
  98
  99 Gentoo
 100 ------
 101 * Gentoo guest systems are very complicated and are requiring lots of
 102   modifications in the initscripts. Currently, no step-by-step guide
 103   can be provided
 104
 105 * 'sysv' initstyle is probably not working for Gentoo guests (e.g. you
 106   will see messages about missing 'utmp' files); 'gentoo' should be
 107   used instead of:
 108
 109   | echo 'gentoo' >/etc/vservers/<id>/apps/init/style
 110
 111 * there does not exist a build-method for Gentoo guests; instead of,
 112   create a skeleton with
 113
 114   | # vserver <id> build -m skeleton --initstyle gentoo <other-opts>*
 115
 116   and fill the vserver directory at /etc/vservers/<id>/vdir/ manually.
 117
 118
 119
 120 Notes for distributors:
 121 =======================
 122
 123 To generate FHS compliant paths, call configure with
 124
 125 | ./configure --prefix=/usr --mandir=/usr/share/man \
 126 |             --sysconfdir=/etc --localstatedir=/var \
 127 |             --with-vrootdir=<an FHS compliant path for /vservers>
 128
 129 Except the '--with-vrootdir' option, rpm's '%configure' option will
 130 expand to this.
 131
 132
 133 There exists a 'make install-distribution' target which installs
 134 files outside of the configured 'prefix'. In particular, these files are:
 135
 136 * the /sbin/vshelper symlink
 137 * the /vservers and related directories (or whatever you configured
 138   with '--with-vrootdir')
 139
 140 Without this rule, 'make distcheck' would fail.
 141
 142
 143 It might be needed also, to call 'setattr --barrier /vservers' in an
 144 after-installation script.
 145
 146
 147
 148 Which version shall I use?
 149 ==========================
 150
 151 As you probably know, two branches of 'util-vserver' are existing: the
 152 'stable' one, and the 'alpha' one. This terms are to be understood as
 153 a level of the featureset stability but not of the software stability.
 154
 155 E.g. 'stable' is not really stable: it has huge security problems and
 156 missing functionality. But you can expect that the current configuration
 157 will work in future versions also. This version is untested on author's
 158 side and it will be hard to bring patches/fixes in, since it must be
 159 proofed that they will not break anything.
 160
 161 In the opposite, the 'alpha' branch does not have known security issues
 162 and works well (at least on author's system ;)).  But it may happen
 163 that some behavior or configuration options change.
 164
 165 With 'alpha' you should be still able to use vservers created with the
 166 'stable' branch, but you may encounter some oddities -- especially on
 167 kernel 2.6 systems (e.g. 'vserver-stat' will not show the names of old
 168 vservers).
 169
 170
 171 So let me summarize:
 172
 173 * when you have productive vservers running for some years already, stay
 174   at the 'stable' branch. A change to 'alpha' will need a completely
 175   rewritten configuration which must be perhaps changed again.
 176
 177 * when you are new at vservers, use the 'alpha' branch. You will have
 178   to learn the principles of vserver configuration for both branches
 179   but 'alpha' makes some things easier.
 180
 181 * when you have existing vservers and want all the new kernel 2.6
 182   functionality, use the 'alpha' branch.
 183
 184
 185 A last note: the 'alpha' branch works both with the stable 2.4 and the
 186 development 2.6 kernel patch.
 187
 188
 189
 190 ## $Id$