root/trunk/README

Revision 2283, 6.1 KB (checked in by hollow, 4 years ago)

skip duplicate util-vserver dir

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
Line 
1Some 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
17Some distribution specific notes:
18=================================
19
20Red 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
70Debian 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
99Gentoo
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
120Notes for distributors:
121=======================
122
123To 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
129Except the '--with-vrootdir' option, rpm's '%configure' option will
130expand to this.
131
132
133There exists a 'make install-distribution' target which installs
134files 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
140Without this rule, 'make distcheck' would fail.
141
142
143It might be needed also, to call 'setattr --barrier /vservers' in an
144after-installation script.
145
146
147
148Which version shall I use?
149==========================
150
151As 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
153a level of the featureset stability but not of the software stability.
154
155E.g. 'stable' is not really stable: it has huge security problems and
156missing functionality. But you can expect that the current configuration
157will work in future versions also. This version is untested on author's
158side and it will be hard to bring patches/fixes in, since it must be
159proofed that they will not break anything.
160
161In the opposite, the 'alpha' branch does not have known security issues
162and works well (at least on author's system ;)).  But it may happen
163that some behavior or configuration options change.
164
165With 'alpha' you should be still able to use vservers created with the
166'stable' branch, but you may encounter some oddities -- especially on
167kernel 2.6 systems (e.g. 'vserver-stat' will not show the names of old
168vservers).
169
170
171So 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
185A last note: the 'alpha' branch works both with the stable 2.4 and the
186development 2.6 kernel patch.
187
188
189
190## $Id$
Note: See TracBrowser for help on using the browser.