## 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

- Referenzen:
  - AW: [ctsrvdev] AW: Kommunikation abgebrochen?
    - From: Niedermeier Günter

- Voriger (Datum): AW: [ctsrvdev] AW: Kommunikation abgebrochen?, Niedermeier Günter
- Nächster (Datum): [ctsrvdev] Kernel bauen, Jens Friedrich
- Voriger (Thread): AW: [ctsrvdev] AW: Kommunikation abgebrochen?, Niedermeier Günter
- Nächster (Thread): [ctsrvdev] Kernel bauen, Jens Friedrich
- Indizes:
  - Datum
  - Thread