Wohooo ;), there seems to be a need for a howto.. ok.. I've received also
2 "private" EMails but I think it's the best I post the stuff here.
It _should_ be a complete installation instruction for vserver with some
tips
for the basic-debian installation and 2 ways to install a
"reference"-system.
I would be very happy for constructive feedback since it's my first HOWTO
I wrote and even worse, it's the first version of it too ;).
Attached to this mail you'll find a stabledebian+vserver-HOWTO.txt which
is written in german (I'm sure it gets translated soon by me or someone
else)
and a smart-upgrade.sh script for the dpkg-upgrading of the vservers. It's
well documented in english (it's kinda small, almost more comments than code
;)).
FYI: smart-upgrade.sh must be edited first. Because I now have one vserver
switched to a "testing"-Debian it will only update the servers defined in a
variable
in the script.
Greets & waiting for feedback..
Joel Wiesmann
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte l�cheln! Fotogalerie online mit GMX ohne eigene Homepage!
#!/bin/bash
# Done by Joel Wiesmann, June 2003 as a part of the stable Debian + vserver HOWTO
# License is GPL, of course ;)
# USE:
# Use this script to manage the distributed upgrades of the base
# vserver to all vserver childs. Just do your settings in this
# script and run it!
# ATTENTION:
# This script is a part of the vserver + debian HOWTO. So if
# you like to use this script in a useful way, you should have
# set up the server with the HOWTO instructions.
VSERVERS=/vservers
TMPDIR=/tmp
REFERENCE=base
# This is done manually because we could have testing/unstable servers we don't want to upgrade
# this way
UPGRADESERVERS="base pizzaman trader slave"
# First time you test this script choose LOGGING=no to see output, afterwards if
# you do a cronjob with it, choose LOGGING=yes to log in the files below
# Don't be iritated by the ERROR(FILE), it also records what Packages were updated.
LOGGING=no
ERRORFILE=/var/log/vserversoftdistr.err
function main
{
# Delete old, archived .deb files
rm $VSERVERS/$REFERENCE/var/cache/apt/archives/*.deb 2>> $ERRORFILE
# Update the reference-system-db and download the packages
vserver $REFERENCE exec apt-get update 2>> $ERRORFILE
vserver $REFERENCE exec apt-get -yd upgrade 2>> $ERRORFILE
# Now we have all up2date .deb's in $VSERVERS/$REFERENCE/var/cache/apt/archives
# let's install them into the child-vservers. The reference-server
# get's upgraded in this procedure too!
for i in `ls $VSERVERS/$REFERENCE/var/cache/apt/archives/*.deb`
do
echo "Upgrading Package $i" >> $ERRORFILE
installpkg $i
done
}
function installpkg
{
PACKAGEPATH=$1
PACKAGE=`basename $PACKAGEPATH`
for i in `UPGRADESERVERS`
do
SERVER=$i
# Check if noone tries to do something nasty
if [ -e "$VSERVERS/$SERVER/$TMPDIR/$PACKAGE" ]
then
echo "$PACKAGE is already in tmp-directory of vserver $SERVER. I won't install it." >> $ERRORFILE
else
cp $PACKAGEPATH $VSERVERS/$SERVER/$TMPDIR 2>> $ERRORFILE
vserver $SERVER exec dpkg --install /tmp/$PACKAGE 2>> $ERRORFILE
rm $VSERVERS/$SERVER/$TMPDIR/$PACKAGE 2>> $ERRORFILE
fi
done
}
if [ "$LOGGING" == "no" ]
then
ERRORFILE=/dev/stderr
fi
main
Debian VServer HOWTO:
---------------------
History:
--------
Version 1.0 (Sprachen: Deutsch):
Version 1.0 3.6.03 - vserver 0.22, linux 2.4.20, debian 3.0
by Joel Wiesmann: vserver <at> secuserv <dot> ch
Leadin:
-------
Dies soll ein kleines HOWTO in die Welt der VServer auf stable-Debian basis geben.
Ich versuche dabei Probleme mit der DPKG-DB und des Packagemanagements zu erklaeren und
eine Zwischenloesung zu finden.
Das HOWTO richtet sich an erfahrene Debian User welche schon mehrmals ein Debian
System installiert haben und nicht Beistand brauchen den Kernel zu entpacken und
kompilieren (und wenn noetig ncurses-dev nachinstallieren). Natuerlich koennen
auch weniger erfahrene versuchen dem HOWTO zu folgen, Links zu Informationsressourcen
an kritischen Stellen sind gegeben.
Wie vielleicht einigen Lesern bekannt sein wird, gibt es bereits ein
"debian-newvserver.sh"[5]
welches via Netz und debootstrap ein Debian-System in einem vserver installiert.
Dieses und
eine haendische Methode wird erlaeutert. Die Funktionalitaet des Systemes wird zwar
bei beiden
vorgehensweisen (HOWTO / Script) erreicht, aber natuerlich ist der Lerneffekt beim
haendischen
anlegen und installieren weitaus hoeher.
Die Informationen zum Anlegen von VServern unter Debian wurden u.a. aus dem originalen
newvserver Shellscript, dem debian-newvserver.sh[5], der VServer FAQ und durch meine
Tests & Erfahrungen zusammengetragen.
Auch ich bin nicht perfekt und bitte euch alle mich bei Problemen, alternativen
Loesungsvorschlaegen, success-stories und Fehlern mich unter der in der History
genannten EMail zu kontaktieren. Ich spreche Deutsch und Englisch, auch schlechtes ;).
Viel spass...
Joel Wiesmann, secuserv.ch
(P.S. ich suche Uebersetzer!)
1. Begrifferklaerung:
---------------------
Hostsystem:
System welches die VServer hostet.
Referenzsystem:
Ein Referenz-VServer. Wird bei jedem Erstellen eines weiteren vserver's kopiert.
Child:
Ein produktiver VServer.
2. Package-Management Problem:
------------------------------
Wir gehen hier davon aus, dass auf dem Hostsystem genug Festplattenkapazitaet ist
und wir fuer jedes Child etwa 250mb an Platz hergeben koennen (ohne Datenhaltung).
VServer bietet zwar das Feature, Systeme zu kopieren und mit speziellen Hardlinks
an Platz zu gewinnen, allerdings geraet so das Packagemanagementsystem DPKG
durcheinander. Leider besteht von VServer-Seiten nur eine Loesung fuer RPM-Packete
(bisher), moeglicherweise wird sich das noch aendern.
Das Problem besteht darin, dass Software welche auf dem Hostsystem upgedatet wird,
zwar durch die vorhandenen Hardlinks auch auf den Childsystemen aktuell ist,
allerdings die apt-Datenbank der Child-Systeme auf altem Stand bleibt. Will man
nun die Child-Systeme mit neuer Software bestuecken oder Upgraden, wird die DB
inkonsistent da teilweise bereits neuere Software auf dem Hostsystem eingespielt
wurde (und via Hardlinks erreichbar ist) oder bei Upgrades die bereits aktuellen
Software-Hardlinks durch neu heruntergeladene, eigentlich bereits installierte
Software (nicht mehr Hardlinks!) ersetzt wird und somit auch das Feature der
Hardlinks und des eingesparten Festplattenplatz zunichte macht.
Das Kopieren der DPKG-DB nach jedem Software-Upgrade auf dem Hostsystem in die
Childsysteme ist auch keine Loesung da so keine zusaetzliche, nur auf dem Child
verwaltete Softwarepackete gewartet werden koennen welche auf dem Hostsystem
nicht eingespielt wurden.
Die hier erklaerte Loesung basiert auf einem schmalen Debian-Hostsystem von welchem
ein 1:1 Referenz-Child gemacht wird mit einer eigenen Datenbank. Von dem Referenz-
child werden anschliessend alle weiteren Childs 1:1 kopiert (man hat also immer ein
leeres Debian-System nach dem Erstellen einer neuen Instanz) welche durch einen
Script immer dem Upgrade-Verhalten des Referenzsystemes folgen.
Somit wird per apt-get nur das Hostsystem und das Referenzsystem auf dem laufenden
gehalten, waehrend die Childs dieselben upgrade-Packete des Referenzsystems einspielen.
3. Debian Hostsystem Installationstips:
---------------------------------------
Zuerst muss das Hostsystem installiert werden, dazu wendet man sich am besten an
die Debian Installationsanweisungen[1]. Zu beachten ist bei der Festplatten-
partitionierung, dass die VServer moeglichst eine eigene Partition kriegen sollten
und Quotas in den VServern nicht korrekt funktionieren wird (dafuer soll es Patches
geben, bei Zeit werde ich das HOWTO damit vervollstaendigen)! Die einfachste Loesung
ist, jedem VServer eine eigene Partition zu geben.
In meinem Falle benutze ich einen Athlon XP 1.7ghz, 512mb DDRRam mit 2 Harddisks,
eine fuer VServer & Daten, die andere fuer Backup der wichtigsten Daten und
Hostsystem. Die Hostsystem-Installation erfolgt mit Disketten, Basissystem
ist bereits auf 2ter HD als tgz bereit. Der Rest wird per Internet gesaugt.
Es ist von Vorteil beim tasksel keine, bzw. gerademal die Packete fuer C und
C++ Development anzuwaehlen. dselect kann uebersprungen werden. Ich habe im
nachhinein dselect aufgerufen, gecheckt welche Software mir noch untergejubelt
werden soll und diese nochmals durchgeforscht und die unnoetigen Packages entfernt.
Fazit: Schmales Hostsystem - 200mb!
4. Kernel patchen
-----------------
Nun geht es darum vserver zu installieren. Da wir das ganze fuer den Serverbetrieb
vorsehen ist ein stable-Debian vorzuziehen, allerdings sind die VServer Packages
erst im Unstable-Tree (1.6.03) und werden in naechster Zeit wohl auch nicht stable
gehen.
Wir laden also die Source fuer den 2.4.20er Kernel[2] und vserver utilities 0.22[3]
mit dem Kernel-Patch fuer 2.4.20 runter.
Leider gibt es (noch?) kein CVS Repository, somit wird die aktuelle Version 0.22 mit
dem 2.4.20 Kernel verwendet.
Also, Kernel nach /usr/src verschieben, entpacken (wenn noetig bzip2 installieren),
den Patch ebenfalls entpacken und in das root der Sourcen verschieben und mit
patch -p1 < patch-2.4.20ctx-*
installieren. Anschliessend Kernel konfigurieren, kompilieren, installieren, lilo
(grub, whatever du benutzt) laufen lassen und beten dass die Maschine nach dem
Reboot wieder hochkommt.
5. VServer Utilities installieren
---------------------------------
Soweit so gut? Ok.. nun gehts daran die vserver-utilities zu kompilieren (Gnade
deren die ins /tmp runtergeladen haben und sich nun nach dem Reboot aufregen).
Also, auspacken, ins Verzeichnis wechseln und einfach nur "make && make install"
laufen lassen.
Anschliessend finden sich folgende neuen Dateien unter /usr/sbin:
vtop (?)
vserver-stat (Informationen ueber aktive VServer Instanzen)
vserver (VServer Kontrollscript -> stop, start etc.)
vrpm (unbenutzt)
vpstree (?)
vps (ps mit zusaetzlicher "CONTEXT"-Spalte)
vkill (?)
vfiles (?)
vdu (unbenutzt)
reducecap (Reduzieren der Capabilities)
rebootmgr (Reboot-Daemon fuer Childs)
newvserver (unbenutzt)
chcontext (Context change)
chbind (Bindet Prozesse an spezifische IP)
Startscripte in /etc/init.d:
vservers (Startet alle vserver welche ON_BOOT=yes haben in Config)
v_xinetd (Startet xinetd gebunden an IP)
v_sshd (Selbe mit SSHD)
v_smb (Selbe mit Samba)
v_sendmail (Selbe mit Sendmail)
v_portmap (Selbe mit Portmap)
v_named (Selbe mit named)
v_httpd (Selbe mit httpd)
rebootmgr (Reboot-Manager fuer Childs und vreboot)
Ausserdem unter /usr/lib/vserver:
capchroot (?)
fakerunlevel (?)
filetime (?)
ifspec (?)
install-<...> (unbenutzt)
listdevip (?)
readlink (?)
sample.conf (Beispiel Child-Config)
sample.sh (unbenutzt)
save_s_context (?)
showattr (unbenutzt, nur bei Hardlinks -> spezielles Attribut)
showperm (Permission Bits fuer Dateien Ausgabe)
vbuild (unbenutzt)
vcheck (unbenutzt)
vreboot (fuer reboots in VServern)
vserverkillall (Killall in VServern)
vservers.grabinfo.sh (VServer infos und Status in XML)
vsysvwrapper (?)
vunify (unbenutzt)
Einige dieser Tools wie vrpm und vunify sind allerdings leider fuer
uns nicht von interesse, da sie leider fuer den RPM gedacht sind.
6. VServer Referenzsystem erstellen
-----------------------------------
Es gibt 2 Wege ein VServer Referenzsystem zu installieren, der eine ist
mit dem im leadin angesprochenen debian-newvserver.sh[5], der andere ist
haendisch und mit einem schmalen Hostsystem zu machen. Ich werde beide
erklaeren. Den haendischen Weg empfehle ich jedoch nur den hartgesottenen
ich-will-alles-mal-gemacht-haben da der debian-newvserver.sh[5] Script
sehr ausgereift, komplett und sauberer ist.
6.1 Referenzsystem mit debian-newvserver.sh
-------------------------------------------
Zuerst sollten wir uns im klaren sein wohin wir die VServer wollen. Per
"default" wird ueberall in der Dokumentation /vservers angegeben. Also
machen wir es auf dieselbe art:
mkdir /vservers
debian-newvserver.sh --copy-vreboot --dist woody --fakeinit --mirror <mirror>
-v --vsroot /vservers --hostname base --domain <domain>
--ip <ip des vhost>
Dies erstellt den Referenz-VServer. Wenn debootstrap nicht installiert ist
muss vorher noch ein:
apt-get install debootstrap
gemacht werden. Anschliessend faengt er an vom ausgesuchten Debian-mirror[6]
runterzuladen und zu installieren.
Dieser Weg ist eindeutig zu bevorzugen. Er ist ausgereifter als das Kopieren
des Hauptsystemes und das haendische konfigurieren. Der Script ist auch schlau
und hat unter /vservers/ARCHIVE die runtergeladenen deb-Packete bereit fuer
das Erstellen neuer VServer-Childs. Allerdings wird bei dem Design das wir
anstreben nur das Referenzsystem ("base") via Script erstellt da sonst das
spaeter besprochene Upgrade-Script nicht funktionieren wird und die Basis-
packete interaktiven Input benoetigen. Also kann /vservers/ARCHIVE nach der
Referenzsystem-Installation geloescht werden.
Es ist von Vorteil bei tasksel nur die C/C++ Development Packete anzuwaehlen
und den rest dediziert auf die vserver zu laden.
Das System schluckt so etwa 250mb, nach dem d(e)selecten 10mb weniger (bei
mir).
Es schadet nicht trotz dem installieren per Script einen Blick in Kapitel 7
zu werfen da dieses auch noch einige Fragen abdeckt.
6.2 Referenzsystem haendisch
----------------------------
Per default wird ueberall /vservers (achtung, Plural!) angegeben, also:
mkdir -p /vservers/base
chmod 000 /vservers/base/..
Das ganze braucht nun auch noch Konfigurationsdateien welche unter /etc/vservers
abgespeichert werden. Also:
mkdir /etc/vservers
cp /usr/lib/vserver/sample.conf /etc/vservers/base.conf
Unser Basissystem ist also der "base"-VServer mit der Konfigurationsdatei
/etc/vservers/base.conf und dem root-Verzeichnis /vservers/base.
Nun geht es um die Konfiguration, also bitte die selbsterklaerende
/etc/vservers/base.conf editieren. Dort lassen sich u.a. ulimit-Werte (man ulimit)
setzen um die verfuegbaren Ressourcen eines VServers zu kontrollieren, oder
die verfuegbaren Capabilities veraendern.
Dann wollen wir doch mal versuchen unsere virtuellen Server hochzukriegen:
vserver base start
Nun, hat nicht geklappt? Nicht enttaeuscht sein! Wir haben doch noch gar nichts
in /vservers/base ;). Also hop, erstellen wir mal eine Kopie unseres Hostsystemes:
cp -rp /tmp /usr /bin /etc /lib /opt /sbin /var /root /vservers/base
cp -ax /dev /vservers/base
rp = Rekursiv und Permissions beibehalten. /boot und den Kernel brauchen wir nicht
da der Kernel nicht neu geladen wird bei dem start eines VServers (nicht so wie in
usermode linux).
ACHTUNG:
Wenn ihr die Maschine schon seit ner weile anhabt solltet ihr das tmp Verzeichnis
manuell anlegen:
mkdir /vservers/base/tmp
chmod 1777 /vservers/base/tmp
Nun ist es Zeit einen Kaffee zu trinken, mal wieder Mami anzurufen oder Tuxracer
zu spielen.
Ok, fertig? Na also, dann probieren wir doch nochmals:
fortess:/vservers# vserver base enter
ipv4root is now 192.168.1.3
New security context is 4
[EMAIL PROTECTED]:/#
Die Einschraenkung der Capabilities seht ihr bereits wenn ihr die IP eines Inter-
faces veraendern wollt:
base:/# id
uid=0(root) gid=0(root) groups=0(root)
base:/# ifconfig eth0 192.168.1.5
SIOCSIFADDR: Permission denied
SIOCSIFFLAGS: Permission denied
7. Detailkonfigurationen
------------------------
Nun sind wir immer nur local eingeloggt. Wenn wir nun per ssh versuchen auf die
zugewiesene IP einzuloggen kommen wir aber noch immer auf das Hostsystem. Um dies
zu vermeiden muessen wir auf dem Hostsystem in der Datei /etc/ssh/sshd_config
in der Zeile "ListenAddress 0.0.0.0" die 0.0.0.0 zu der IP des Hostsystemes aendern.
Danach ein:
/etc/init.d/ssh stop && /etc/init.d/ssh start
und:
vserver base stop && vserver base start
Nun sollte es funktionieren.
Jetzt sollten wir von unserer Installationsorgie noch ein paar Leichen auf dem
Child (!!!) aufraeumen (_NICHT_ Hostsystem!):
cp /usr/lib/vserver/vreboot /sbin/reboot # Mehr dazu spaeter
cp /sbin/reboot /sbin/halt
cp /sbin/halt /sbin/shutdown
rm -r /usr/src/linux* /usr/lib/vserver /etc/vservers # VServer und Linux-Sourcen
brauchen wir nicht
cd /usr/sbin
rm vtop vserver vserver-stat vrpm vpstree vps vkill vfiles vdu reducecap rebootmgr
newvserver chcontext chbind
Noch ein bisschen Konfiguration:
echo "base" > /etc/hostname
vi /etc/network/interfaces # Netzwerk anpassen
vi /etc/fstab /etc/mtab # Alle mountpoints loeschen
passwd root # default root-Passwort setzen (changeme z.B.)
mkdir /var/lock/subsys # RH-Style fuer Lockfiles von rebootmgr (...)
vi /etc/motd # Motive of the day - waehl was huebsches
vi /etc/hosts # VServer Eintrag vervollstaendigen bzw. korrigieren
Natuerlich sollten auch unsere User ein Home-Verzeichnis haben:
mkdir /home
ACHTUNG:
Wenn ihr bei der Installation bereits einen "normalen" User angelegt habt, dessen
Informationen
in /etc/shadow und /etc/passwd rausloeschen (bzw. userdel).
ACHTUNG:
War das System bereits im Einsatz koennten wichtige Informationen im
root-Homeverzeichniss
sein (ssh-Keys etc.). Diese muessen von Hand bereinigt werden!
8. Pause
--------
Ok, soweit so gut. Wir versuchen mal rasch den Ueberblick zu kriegen:
Wir haben nun ein "base"-System welches seperat mit eigener IP in einer eigenen
Umgebung
laeuft. Wir haben das System leicht modifiziert und von "Unreinheiten" des Hostsystems
gesaeubert. Wir koennen mit VServer den Server stoppen und starten.
Was gibt es nun noch zu tun?
- Automatischer VServer Aufstart beim Booten
- Rebootmoeglichkeit innerhalb des VServers
- Smartes Softwareupgrade aller Server (moeglichst Bandbreitenschonend)
- Neues Child erstellen
9. VServer rebooten & VServer start bei Bootup
----------------------------------------------
Wie soll man nun einen VServer wenn man denn mal eingeloggt ist rebooten? Dazu brauchen
wir die Tools vreboot (welches wir zu /sbin/reboot, /sbin/halt und /sbin/shutdown
in dem Referenzsystem kopiert haben) und auf dem Hostsystem den rebootmgr-Daemon.
Um den rebootmgr zu starten koennen wir den bereits vorhandenen Startscript
/etc/init.d/rebootmgr in rc2 linken.
ln -s /etc/init.d/rebootmgr /etc/rc2.d/S90rebootmgr
ln -s /etc/init.d/rebootmgr /etc/rc2.d/K90rebootmgr
Um alle VServer automatisch zu starten welche in der Configurationsdatei ONBOOT=yes
haben,
linken wir die bereits existierende /etc/init.d/vservers ebenfalls nach rc2 aber vor
den
rebootmgr:
ln -s /etc/init.d/vservers /etc/rc2.d/S89vservers
ln -s /etc/init.d/vservers /etc/rc2.d/K89vservers
Wer jetzt mutig ist, darf nun das Hauptsystem rebooten und checken ob der Base-VServer
wieder oben ist und rebootmgr laeuft.
Anschliessend loggen wir uns auf dem base ein und probieren gleich mal zu rebooten:
base:~# reboot
base:~# Connection to 192.168.1.3 closed by remote host.
Connection to 192.168.1.3 closed.
Falls ihr via "vserver base enter" rebootet, habt ihr moeglicherweise wenn es euch auf
euer Hauptsystem rausschmeisst ein defektes Terminal (ihr sehr nicht mehr was ihr
schreibt).
Um dies zu beheben einfach "reset" eingeben.
10. Smartes Softwareupgrade
---------------------------
Nun sind wir an dem Punkt angelangt wo wir ueber DPKG nachdenken muessen. DPKG
funktioniert
ohne Probleme auf unserem Referenz-VServer. Aber wenn wir nun noch 10 weitere Childs
aus dem
base Referenzsystem machen wirds langsam ein bisschen viel wenn alle Childsysteme ein
"apt-get update && apt-get upgrade" fahren.
Die Loesung ist eigentlich einfach: Wir wissen unser Referenzsystem "base" ist die
Grundlage
aller Childs. Wenn wir also das base-System upgraden (was wir sowieso muessen um die
Childs
die daraus noch entstehen aktuell zu halten), muessen wir dieselben Patches auch auf
den bereits existierenden Childs installieren. Zusaetzlich kommen bei den Childs noch
eigene,
auf den VServer dedizierte Software hinzu, um welchen sich aber der VServer selbst
kuemmern sollte.
Wir lassen das Referenzsystem also ein "apt-get update" fahren und anschliessend statt
einem
"apt-get upgrade" ein "apt-get -dy upgrade". Dies laedt die Packages nur runter welche
upzugraden sind. Diese koennen nun mittels einem Script und Cronjob vom Hostsystem aus
kontrolliert werden.
Wieso vom Hostsystem aus? Ganz einfach: Per default sollten wir den Referenzserver
deaktiviert
halten (vserver base stop - sonst koennte man mit default-Passwort einloggen) - somit
ist Cron
nicht aktiv.
Ein weiterer Grund ist, dass wir vom Hostsystem auf alle VServer zugreifen koennen und
mit
vserver base exec <kommando>
"remote" vom Hostsystem auf den VServern Befehle ausfuehren koennen und ebenso die
herunter
geladenen Packages so einfach verteilen.
Das fertige Script kann von der secuserv.ch[4] Homepage bezogen werden!
11. Neues Child erstellen
-------------------------
Um nun ein neues Child zu kreieren und es mit dem [4]-Script zu benutzen muss man eine
Kopie des
Referenzsystemes erstellen. Das Referenzsystem selbst darf somit nicht produktiv
genutzt werden
und sollte _immer_ deaktiviert sein.
mkdir /vservers/<child>
chmod 000 /vservers/<child>/..
cp -Rpv /vservers/base/bin /vservers/base/dev /vservers/base/etc /vservers/base/home
/vservers/base/initrd
/vservers/base/lib /vservers/base/mnt /vservers/base/opt /vservers/base/root
/vservers/base/sbin
/vservers/base/tmp /vservers/base/usr /vservers/base/var <child>
cp /etc/vservers/base.conf /etc/vservers/<child>.conf
Anpassen im Child:
/etc/hostname
/etc/hosts
/etc/motd
Anpassen auf dem Hostsystem:
/etc/vservers/<child>.conf
Et voila, das neue Child-system ist bereit! Nun kann man mit apt-get Software
installieren und es durch
das Hostsystem upgraden lassen. Was man nicht machen sollte ist das Child-System auf
unstable oder
testing zu stellen, somit wuerde es mit dem Upgrade-Script kollidieren! Man muesste
also das Upgrade-
script vervollstaendigen um stable, testing und unstable - Childs zu separieren.
Bitte um Feedback!
Joel Wiesmann
[1] Debian Installation: http://www.debian.org/releases/stable/installmanual
[2] Linux Kernel Sourcen http://www.kernel.org
[3] VServer Homepage: http://www.solucorp.qc.ca/miscprj/s_context.hc
[4] SecuServ Homepage: http://www.secuserv.ch
[5] debian-newvserver.sh: http://www.paul.sladen.org/vserver/debian/
[6] Debian Mirrors: http://www.debian.org/mirror/list
