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 secuserv 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 -v --vsroot /vservers --hostname base --domain --ip 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 root@base:/# 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 "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/ chmod 000 /vservers//.. 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 cp /etc/vservers/base.conf /etc/vservers/.conf Anpassen im Child: /etc/hostname /etc/hosts /etc/motd Anpassen auf dem Hostsystem: /etc/vservers/.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