Gentoo VdrEbuildDevelopmentUmgebung

Aktuelle Version vom 25. Oktober 2005, 13:18 Uhr

Das größste Problem bei der Einwicklung der Ebuilds ist die Unterschiede der verschiedenen Clientsysteme und natürlich die Angst sein eingenes System dabei zu zerschiessen. Diese kleine Anleitung soll zeigen wie beide Klippen umschifft werden können.

Um mit dem Ganze anzufangen brauchen wir einen Virtuellen VDR in einer CHROOT Umgebung. Die bekommen wir folgendermaßen:

stage3 Tarball besorgen (richtige CPU!)

Anlegen eines, sagen wir vserver Verzeichnisses. Je nach Anzahl und Installationsumfang sollten einige GIG frei sein.

mkdir /vservers/

Danach brauchen wir für jede Umgebung noch ein Unterverzeichnis.

mkdir /vservers/test1

In dieses Verzeichnis muss das Stage3 ausgepackt werden. Also fast wie eine normale Gentoo Installation. Damit die neue Umgebung so funktioniert wie die alte sollten einige Files in die test1 Struktur kopiert werden:

cp /etc/resolv.conf /vservers/test1/etc/
cp /etc/make.conf /vservers/test1/etc/
cp /etc/rc.conf /vservers/test1/etc/

Eine kleine Änderung in der /etc/profile hilft Verwechselungen zu verhindern:

--- /etc/profile        2004-01-18 21:01:49.000000000 +0100
+++ /vservers/vdrdev/etc/profile        2004-01-18 15:43:44.000000000 +0100
@@ -14,14 +14,14 @@
        # Do not set PS1 for dumb terminals
        if [ "$TERM" != 'dumb'  ] && [ -n "$BASH" ]
        then
-               export PS1='\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\]'
+               export PS1='vs \[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\]'
        fi
        export PATH="/bin:/sbin:/usr/bin:/usr/sbin:${ROOTPATH}"
 else
        # Do not set PS1 for dumb terminals
        if [ "$TERM" != 'dumb'  ] && [ -n "$BASH" ]
        then
-               export PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\W \$ \[\033[00m\]'
+               export PS1='vs \[\033[01;32m\]\u@\h \[\033[01;34m\]\W \$ \[\033[00m\]'
        fi
        export PATH="/bin:/usr/bin:${PATH}"
 fi

Der Prompt wir um ein Prefix vs erweitert so das man immer erkennt, daß man sich in der Vserver Umgebung befindet.

So, jetzt geht es endlich in die CHROOT Umgebung:

mount --bind /proc /vservers/test1/proc
mount --bind /dev /vservers/test1/dev
mount --bind  /var/lib/init.d /vservers/test1/var/lib/init.d/
chroot /vservers/test1 /bin/bash --login

Ab jetzt befindet man sich in der CHROOT Umgebung und sollte erstmal mit emerge world das System auf aktuellen Stand bringen. Wenn das Abgeschlossen ist, ist eine Sicherung des "test1" Verzeichnisses angesagt. Dann ist das Erzeugen neuer Testumgebungen auf ein cp beschränkt cp -a /vservers/test1 /vservers/sik.

Um das /video Verzeichnis in allen Testumgebungen benutzen zu können wird auch diese Verzeichnis in die neue Umgebung gemounted (bei nen Test des VDR Ebuilds besser nicht, da im Ebuild eine Logic für das /video Verzeichnis ist) :

mount --bind /video /vservers/test1/video

Durch das mounten des init.d Verzeichnisses gelten für die RC Scripte die gleichen Bedingungen wie für die Hostmaschine. Ebenso die gleichen Devices. Andere Kernel sind leider nicht möglich, also entweder das /usr/src + /lib/modules auch in die CHROOT Umgebung mounten oder einen Kernel emergen und eine ähnliche Konfig + Module erzeugen.

So, in dieser Umgebung könnt Ihr machen was Ihr wollt, wenns mal "kaputt" ist, einfach das Verzeichnis test1 löschen (Vorher evt. Konfigs sichern) und das Backup wieder einspielen. cp /vservers/sik /vservers/test2

Hier ein kleines VserverScript um die Mounterei zu vereinfachen.