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