c't

c't-Projekte - Mailinglisten


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

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

Absender: Jens Friedrich
Datum: Di, 22.11.2005 19:27:43
In-reply-to: <ACB76940-ABB9-4E43-B399-143F96ECE7AA@xxxxxxxxxxx>


Siehe unten...

Viele Grüsse
Jens
 

> -----Ursprüngliche Nachricht-----
> Von: ctsrvdev-bounces@xxxxxxxxxxxxxxxxx 
> [mailto:ctsrvdev-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von 
> Peter Siering
> Gesendet: Dienstag, 22. November 2005 17:18
> An: Entwicklung rund um den c't Server
> Betreff: Re: AW: [ctsrvdev] UML-IPCop - ctserver.org History
> 
> 
> Am 18.11.2005 um 17:58 schrieb Jens Friedrich:
> 
> > 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.
> 
> Auf http://www.heise.de/ct/ftp/projekte/srv/updates1505.shtml 
> ist ein IPCop-Update beschrieben, das als Debian-Paket 
> daherkommt, das Kernel- Update von IPCop 1.4.2 auf 1.4.4 
> erledigt und bei allen Tests, die ich gemacht habe, nichts an 
> den ansonsten konfigurierten Dingen kaputt gemacht hat. (In 
> meiner vorherigen Mail als "kleines Paket"  
> beschrieben.) Gibt es hiermit andere Erfahrungen?

Ich habe keine negativen Erfahrungen gemacht, allerdings hatte ich zu diesem
Zeitpunkt auch keine Addons installiert. Aber wenn ich das richtig sehe,
installierst Du hier den Kernel und die Module genauso, wie wir es im Forum
beschreiben. Als IPCop update auf V1.4.4 wirst Du wohl die original
ipcop-update-files verwenden, oder?

> 
> >
> > 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.
> >
> 
> Das wäre dann super einfach, wenn die UML-Ergänzungen 
> Bestandteil von IPCop selbst würden - aber da scheint keiner 
> der Entwickler Interesse dran zu haben. Das Update soll auch 
> keinesfalls etwas im Server anstoßen, sondern lediglich ein 
> Reboot der UML-Umgebung.

Im IPCop-Forum werden jegliche IPCops in virt. Maschinen als UN-IPCops
verschmäht. Steht eine Stellungnahme direkt im Forum auf den Haupt-Seiten.
Argumentativ könnte man das IMHO zumindest in bestimmten Anwendungsfällen
Aushebeln - einen argumentativen Ansatz habe ich mal in unserem Forum
gepostet.

> 
> > 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.
> >
> 
> Das loop-Mounten eines ext3-Dateisystemimages, auf das 
> womöglich noch ein laufender UML-Prozess zugreift, kann nie 
> vernünftig sein ;-)
> 

Dann hatte ich Dich wohl leicht "fehlinterpretiert".

> > Bin jedenfalls gespannt, ob das images bei Euch auch stabil läuft, 
> > oder ob es abstürzt...
> >
> 
> Bin leider noch nicht dazu gekommen. Rückmeldung dazu kommt separat.
> 
> Peter
> _______________________________________________
> ctsrvdev Mailingliste
> ctsrvdev@xxxxxxxxxxxxxxxxx
> http://www.heise.de/bin/newsletter/listinfo/ctsrvdev
>