c't

c't-Projekte - Mailinglisten


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

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

Absender: Jens Friedrich
Datum: Fr, 18.11.2005 17:58:07
In-reply-to: <Pine.LNX.4.21.0511181013450.3761-100000@xxxxxxxxxxxxxxxxxxxxx>


Wenn ich nicht innerhalb des IPCop update (Webinterface), gehen alle
installierten AddOns und Konfigurationen verloren, jedesmal wenn ein neues
IPCop Images zur Installation verwendet bzw. vorgegeben wird. Dass sollte
sich deshalb auf notwendige Ausnahmen beschränken lassen - wahlfrei.

Den Kernel in ein update.gpg zu packen, um ihn dann vom ipcop aus der UML
auf den Host zu bekommen, hmmm, da muss ich mal länger drüber nachdenken...
Weiss noch nicht, ob ich das als sinnvoll erachten soll... Der IPCop ist für
mich ein möglichst abgeschottetes Firewall-System, da will ich nicht
unbedingt rauskommen... Steht zur Diskussion.

Ich denke, vernünftige update-scripten auf dem host-server liegen eher in
meinem persönlichen Fokus. Möglichst Fehler-resistent müssen die halt
sein... Den kernel sehe ich nicht unbedingt innerhalb des uml-images als
notwendig/sinnvoll an, was soll er denn da? Der wird doch auf dem host
gestartet und ist in der uml selber nicht notwendig.

Bin jedenfalls gespannt, ob das images bei Euch auch stabil läuft, oder ob
es abstürzt...

Viele Grüsse
Jens

-----Ursprüngliche Nachricht-----
Von: ctsrvdev-bounces@xxxxxxxxxxxxxxxxx
[mailto:ctsrvdev-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von Peter Siering
Gesendet: Freitag, 18. November 2005 11:47
An: Entwicklung rund um den c't Server
Betreff: Re: [ctsrvdev] UML-IPCop - ctserver.org History

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


_______________________________________________
ctsrvdev Mailingliste
ctsrvdev@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ctsrvdev