README (6231B)
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$