c't

c't-Projekte - Mailinglisten


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

Re: AW: [ctsrvdev] AW: Kommunikation abgebrochen?

Absender: Peter Siering
Datum: Di, 21.02.2006 22:45:07
In-reply-to: <AEECJPLNPPMKFDNOANPIMEAHMJAA.ipcop@xxxxxxxxxxxxx>
References: <AEECJPLNPPMKFDNOANPIMEAHMJAA.ipcop@xxxxxxxxxxxxx>



Am 21.02.2006 um 21:19 schrieb Niedermeier Günter:

Hallo Freunde,

Da musste Peter doch nix extra machen - glaube ich. Da (und nur da)
gings noch mit den vorhandenen Sourcen... Oder?


Genau, aber es waren Anfang 2005 noch andere UML-Patches in den Gast-
Kerneln, die haben sich hinsichtlich der
Integrationsfähigkeit in die
UML-Buildumgebung verschlechtert ;-)

...nachdem ich hier anscheinend der Einzige bin, dem das nicht klar ist,
da ich ja zu dem Zeitpunkt noch keinerlei Änderungen an den Patches
durchgeführt hatte, darf ich um Aufklärung bitten:


Ich kann nicht zu jeder Kombination was sagen, zunächst Normalnull:

2.4.27-1um - erste Fassung des IPCop-Kernels (IPCop 1.4.2/c't-Server 1.0) - im Januar/Februar basiert auf den damals verfügbaren UML- Patches (offizielle, keine Blaisorblade-Fassung); skas aktiv, tt nicht. D.h. auch IPCop läuft nicht im chroot. Auf 2.6er-Host (2.6.10- ct-1) läuft der IPCop lausig, auf 2.4.27-ct-1 prima.

2.4.29-1um - zweite Fassung (Kernel als Update IPCop 1.4.4(a)/c't- Server 1.1 mit IPCop 1.4.6) - Juni/Juli basiert auf den in dieser Zeit von Blaisorblade veröffentlichten Patches - noch nicht die Patches, mit denen Ihr experimentiert habt. Läuft auf Kernel 2.6 (2.6.12-ct-1), bricht aber unter Last zusammen. Kernel 2.4.31-ct-1 hingegen geht als Host. IPCop läuft chrooted, skas und tt aktiv (tt wg. statischem Linken).

Nur mal für die Größenordnung: 2.4.29-1um-IPCop läuft bei mir auf 2.4.27-ct-1-Host seit 126 Tagen mit zwei weiteren UMLs (für Mail und Audiostreaming) auf einem 600 MHz C3 mit 256 MByte RAM.

1. org. ct-2.4.27-1um läuft mit jedem Kernel24 und dem ct-2.6.8
Hostkernel

2. org. ct-2.4.27-1um läuft mit keinem anderen Kernel26

3. Sourcen vom ct-2.4.27-1um neu unter SL90 gebaut, ohne Änderung der
.config
läuft mit jedem Kernel24 aber mit keinem Kernel26, auch nicht mit dem
   org. ct-2.6.8 Hostkernel

4. Sourcen vom ct-2.4.27-1um neu unter SL90 gebaut incl. TT, läuft mit
   allen Kernel24 und Kernel26, auch mit dem org. ct-2.6.8 Hostkernel


Alle neueren Erfahrungen meinerseits beziehen sich jetzt auf 2.4.31: Der läuft mit den letzten Blaisorblade-Patches für 2.4er-Guests dann perfekt, wenn ich ihn außerhalb der LFS-Buildumgebung baue (mit dem Standard gcc von Sarge). Perfekt heißt mit provozierter Last > 24 Stunden sowohl auf Kernel 2.4.31 als auch 2.6.12 (und .15); die Patches im Host sind die mit c't-Server 1.1 (2.6.12-ct-1/2.4.31-ct-1) gelieferten sowie die aktuellen von Blaisorblade für 2.6.15-ct-1.

Vll bin ich ja etwas begriffstutzig, aber jetzt möchte ich doch mit
einfachen
Worten lesen, was hier nun unterschiedlich ist. ;-)

Ist mein Erfahrungshorizont jetzt sichtbar ;-?


Welche Vorteile bietet XEN30 gegenüber XEN20, solange es kein
HW-mapping gibt?

- Multiprozessorfähigkeit in VMs (xen2 weist eine CPU zu, falls
mehrere physische da sind)

damit kann ich leben!

Hab ich die moderneren Kernel erwähnt? Erst 2.6.15 kann SMART bei SATA-Platten - Xen2 geht aber nur mit 2.6.12 ;-(


- xen3 ändert viele Details in der Systemkonfiguration (Netz, udev/
hotplug); die Arbeit für xen2 ist also "für die Tonne" ;-(

für Xen3 warte ich jetzt erst mal den releasten ipcop 1.5x ab,
und beschäftige mich dann wieder mit dem Thema.

Daher favorisiere doch eher meinen 2.4.31er XEN Kernel im COP.

Ich auch wegen HW-Mapping trotz o.g. Gründe. BTW: Mein VDR läuft mit
zwei DVB-Karten und einem SATA-Controller seit mehreren Monaten in
einer Xen-Instanz. Stabil ist es. Es gibt aber wohl
"Sicherheitsprobleme" mit dem direkten HW-Zugriff; ein Prozess in
einer VM, der weiß, dass er in einer DriverDomain (VM mit
eingeblendeter HW) läuft, kann diese HW wohl direkt manipulieren ...

Welche Probleme können aus dieser "Sicherheitslücke" erwachsen?


Eine Diskussion vor allem - bzw. der erste Virus mit Treibern für die Hardware - Denial of Service. Ich wollte es nicht verschweigen ;-)


Ist es definitiv, dass Xen3 kein HW-mapping unterstützen wird???
(soweit absehbar)


Die Entwickler scheinen es nicht mit Priorität voranzutreiben. Einen verbindlichen Zeitplan gibt es leider nicht.

Peter