1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
Some common notes/FAQs:
======================
* when vserver startup/shutdown fails, or when you get
| Error: /proc must be mounted
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$
|
