c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ctsrvdev] UML-IPCop - ctserver.org History

Absender: Peter Siering
Datum: Fr, 18.11.2005 11:47:07
In-reply-to: <E1EcnZs-0006sL-D1@xxxxxxxxxxxxxxxxxxxxxx>


On Thu, 17 Nov 2005, Jens Friedrich wrote:

> im Forum habe ich im FAQ beschrieben, wie der "UML-IPCop update"
> vorgenommen wird. Wie Du sehen kannst, sind wir mit unseren Kerneln im
> aktuellen IPCop-1.4.10 mit uml-kernel-2.4.31 angekommen :-)

Super.

> Wir haben bis dato keine Rückmeldungen über Instabilitäten mit dem
> Host-Kernel 2.6 erhalten. Die Downloads unserer Kernel liegen
> inzwischen weit über 250 in Summe - denke die gehen.
>
> Ich habe im Forum ein HowTo geschrieben, wie ich den uml-kernel für
> IPCop-1.4.9 gebaut habe, das liest sich soweit analog zu Deiner
> Beschreibung. Ich konnte allerdings nicht nachvollziehen, warum ich
> den IPCop-UML-Kernel letztlich nur ausserhalb der LFS-IPCop Umgebung
> kompilieren konnte :-(
>  
> Denke mein beschrittener Weg ist aber trotzdem sehr sauber.
>

Er ist im Unterschied zu unserem Ansatz halt ein Stück von dem Weg weg,
wie es die IPCop-Entwickler machen. Auf den ersten Blick (hatte bisher nur
Zeit die Anleitung zu überfliegen) sieht es so aus, als würdest Du den
unter Debian-installierten Compiler fürs Übersetzen des UML-Kernels
nutzen; unsser Ansatz nimmt den der IPCop-Build-Umgebung.

Ich setze oben auf meine todo-Liste das Experiment mit Deinen Patches,
unserer Bau-Umgebung und den alten Testsystemen, mit denen ich die
2.6er-Abstürze perfekt reproduzieren konnte. Das sollte Gewissheit
liefern, ob der Compiler womöglich auch Einfluss hat.

> Die Frage die sich mir aufdrängt ist, wie oft man ein neues
> uml-image-apt paket bauen sollte. Denke das macht man am besten nur
> bei Major-Version Changes des IPCop, ansonsten sollte der "normale
> update" des IPCop verwendet werden.
>  

Das sollten wir diskutieren - ich hole ein bisschen aus: Wir haben zwei
Paketarten geliefert, kleine und große. Die großen jeweils auf der CD
inklusive IPCop-ext3-Image-Datei (bz2 komprimiert), die kleinen als
Update-Pakete (nur online mit Version 1.1 für Kernel-Update des Pakets auf
der CD 1.0).

Um das Bauen eines neuen Debian-Pakets kommt man immer dann nicht herum,
wenn mit dem IPCop-Update eine Kernel-Aktualisierung einhergeht. Der
Kernel der UML-Variante liegt zur Zeit als Binary im Host-Dateisystem, das
heißt, aus dem IPCop selbst lässt sich die Datei nicht aktualisieren (es
sei denn, man verlegt sie auf eine trickreiche Weise dorthin). 

Dadurch ist aber das Aktualisieren des IPCop umständlich. Das
Debian-Update-Paket muss den IPCop beenden, im ext3-Dateisystem-Image die
Modul-Dateien einfügen und im Host-Dateisystem das Kernel-Binary ergänzen
und den Cop dann neu starten. Wenn der Vorgang schief geht oder beim
Updaten womöglich noch weitere Debian-Pakete nötig sind, kann es im
Extremfall passieren, dass der IPCop heruntergefahren ist, aber noch
Pakete zu holen wären ;-(

Auf den ersten Blick scheint deshalb die Idee gut, das Kernel-Binary ins
Image mit hinein zu packen, dann könnte man es bei einem IPCop-internen
Update mit austauschen. Man müsse es beim Starten des IPCop dort heraus
holen; das könnte man vielleicht durch ein separates Image-File mit dem
Kernel und md5sum optimieren. 

Aber: Ein Neustart aus dem IPCop heraus, lädt ja den Kernel nicht neu, das
heißt, man müsste womöglich das init-Skript des Server für den IPCop in
einer Schleife kreisen lassen, die schaut, ob sich das boot-image geändert
hat, den Kernel dort heraus holt und die UML mit dem neuen Kernel startet.
Wäre mir zu heftig ... aber vielleicht gibt es ja noch einen Weg?

Die pragmatische Strategie scheint mir deshalb: Bei Kernel-Updates ein
Debian-Paket zu bauen. 

Peter