Linux läuft theoretisch seit 1999 auf IBMs Großrechnern – und wie sieht die Praxis aus? Unser Beispiel zeigt, was alles schief gehen kann und wie dabei eine Firewall auf den Dino kam.

Für IBM ist Linux auf dem oft als Dinosaurier verspotteten Mainframe zum unerwarteten Erfolg geworden und trägt derzeit, zusammen mit dem Trend zur Konsolidierung, zur Renaissance der S/390 bei, die jetzt im neuen Gewand als zSeries auftritt. Mainframes sind unter anderem im Finanzsektor stark verbreitet. Dort steht Sicherheit an erster Stellen, deshalb hier ein Erfahrungsbericht über eine Firewall-Portierung.

Nach den ersten erfolgreichen Gehversuchen im Jahr 1999 steht für Linux auf Großrechnern seit 2000 eine installierbare Distribution zur Verfügung. Inzwischen sind die schlimmsten Kinderkrankheiten überstanden – ein guter Zeitpunkt, um alle möglichen Anwendungen zu portieren.

Eine dieser Anwendungen ist eine Personal Firewall. Niemand wird auf die Idee kommen, den kompletten Mainframe als eine einzige Firewall zu verwenden, aber innerhalb des Großrechners erweisen sich Filter zum jeweiligen Netz als sehr nützlich. Ein Mainframe ist heute schließlich kein allein stehender Computer mehr, sondern die Basis für viele virtuelle Maschinen, die gleichzeitig laufen und einen ganzen Park an Servern ersetzen. In der Server-Farm sind Firewalls Stand der Technik, warum also nicht auch im Großrechner?

Die Welt der Mainframes dreht sich nicht nur um besondere Architekturen, sie hat auch ihre eigenen Begriffe und Abkürzungen. Der Kasten “S/390 und zSeries” erklärt einige davon, während der Kasten “Virtuelle Maschinen” näher auf das Konzept einer VM eingeht.

Konfiguration

Wie sieht die Konfiguration eines VM-Users als Linux-System konkret aus? Die Firewall-Portierungs-Maschine der Autoren dieses Artikels dient hier als Beispiel. Im CMS (Conversational Monitor System) gibt es eine Minidisk mit einem CMS-Dateisystem, auf der sich eine Skriptdatei befindet, die beim CMS-Start automatisch ausgeführt wird. Dort können beispielsweise über CP-Befehle virtuelle Netzwerkverbindungen definiert und aktiviert und auch das IPL (Initial Program Load) eines anderen Betriebssystem angestoßen werden.

Die Geräte einer VM werden über einen Device Identifier (0000 bis FFFF) angesprochen. Für einen VM-User spielt die Zuordnung der physischen Anschlüsse zu den Geräten keine Rolle, man hat also freie Hand bei der Auswahl. Es haben sich aber bestimmte Adressen eingebürgert. So hat die erste Minidisk für das CM-System in der Regel die Adresse 191 (Listing 1, Markierung 11); die Adressen für virtuelle Konsole (5), virtuellen Lochkartenleser (6) und -stanzer (7) und einen virtuellen Drucker (8) entsprechen in Listing 1 dem Standard.

Als Erstes sind der Username, das Passwort, eine initiale und eine maximale Hauptspeichergröße und die Sicherheitsklasse hinter dem »USER«-Statement definiert (1). Die zweite Zeile bewirkt, dass das System bei einem Neustart des VM mit hochgefahren wird (2). Als Nächstes wird der Prozessoranteil zugeordnet (3): Unser System erhält so viel CPU-Leistung wie möglich, jedoch mindestens drei Prozent der Gesamtleistung.

Die nächste Zeile bewirkt den Autostart des CM-Betriebssystems (4). Die vier »Link«-Statements (9) erlauben den Read-only-Zugriff (RR) auf benötigte Systembereiche von VM und VM-TCP/IP. So befindet sich auf der Minidisk 592 des Users »TCPMAINT« beispielsweise der FTP-Client des VM – ohne diese Zeile wäre unser User vom Rest der Welt abgeschnitten.

Die nächsten beiden Einträge (10) reichen zwei reale Adressen (1012 und 1013) der VM-LPAR direkt an unsere virtuelle Maschine weiter, jedoch unter den neuen virtuellen Adressen 112 und 113. Dahinter verbergen sich zwei Verbindungen zu dem OSA-Adapter, die eine virtuelle Netzwerkkarte ermöglichen (Read- und Write-Kanal).

Die »MDISK«-Statements (11) definieren jeweils Minidisks mit den virtuellen Adressen gemäß der zweiten Spalte. In der dritten Spalte steht der Gerätetyp, danach der Startzylinder, die Zylinderanzahl und der Name des zugrunde liegenden DASD-Device. Die weiteren Parameter betreffen Zugriffsrechte anderer VM-Guests sowie Zugriffspasswörter.

Listing 1: Linux als VM-Guest

02658 ***********************************************************
02659 ***  L390VM07 *** FIREWALL PORTIERUNG *********************
02660 ***********************************************************
02661 USER L390VM07 PASSWORT 500M 512M G                   (1)
02662  AUTOLOG AUTOLOG1                                    (2)
02663  OPTION QUICKDSP
02664  SHARE ABS 3%                                        (3)
02665  IPL CMS                                             (4)
02666  CONSOLE 009 3270                                    (5)
02667  SPOOL 00C 2540 READER A                             (6)
02668  SPOOL 00D 2540 PUNCH  A                             (7)
02669  SPOOL 00E 1403 X                                    (8)
02670  LINK MAINT 190 190 RR                               (9)
02671  LINK MAINT 19D 19D RR
02672  LINK MAINT 19E 19E RR
02673  LINK TCPMAINT 592 592 RR
02674 * OSA TCP/IP
02675   DEDICATE 112 1012                                  (10)
02676   DEDICATE 113 1013
02677  MDISK 191 3390 6061 0600 LINUX3 MW ALL  WPAS  MPAS  (11)
02678  MDISK 291 3390 1451 0200 VMSPG2 MR ALL  WPAS  MPAS
02679  MDISK 192 3390 0925 0180 VMSWK9 MR ALL  WPAS  MPAS
02680 * 193 + 293 für Development + Frozen Releaselevel - wechselweise
02681  MDISK 193 3390 1105 1000 VMSWK9 MR ALL  WPAS  MPAS
02682  MDISK 293 3390 0001 1000 LINUX4 MR ALL  WPAS  MPAS

Wozu das Ganze?

Vor der Entwicklung eines neuen Produkts sollte immer die Frage stehen: Wer braucht es und warum? Die Argumentation ist – nach anfänglicher Verwunderung über die ungewöhnliche Kombination – relativ einfach. Die Großrechner sollen schließlich als große Web-, Mail-, News- und sonstige Server ihren Dienst verrichten und haben außer der Unternehmens-Firewall keinen Schutz.

Das ist in solchen Umgebungen nicht akzeptabel. Die Alternative zu einer Firewall auf dem Großrechner ist eine Firewall vor dem Großrechner, die natürlich auch so ausgelegt sein muss, dass sie 24 Stunden am Tag zur Verfügung steht. Diese Nebenbedingung katapultiert die Kosten sofort in mittlere fünfstellige Euro-Bereiche.

Bei einer Firewall auf dem Mainframe gibt es keine zusätzliche Hardware, die ausfallen könnte. Das Operating betreut die Firewall zusammen mit den übrigen virtuellen Rechnern und kann bei Störungen selbst aktiv werden. Klar ist, dass eine Firewall auf einem Großrechner nur den Mainframe und dessen virtuelle Maschinen schützen kann und keinesfalls als Ersatz für eine Firmen-Firewall zu sehen ist.

Der Schutz im Großrechner wirkt nicht nur gegen Angriffe aus dem Internet, auch Zugriffe aus dem Intranet lassen sich entsprechend filtern. Die Einzelsysteme können sich sogar voreinander schützen. Außerdem kann die Firewall als VPN-Gateway dienen – damit sind verschlüsselte Verbindungen auch zu Systemen möglich, die dies von sich aus nicht vorsehen. Beispielsweise lassen sich die 3270-Sitzungen (Telnet-Protokoll auf Zeilenbasis) verschlüsseln, um Benutzernamen und Passwörter abgesichert zu übertragen.

Abbildung 1: Bereits die Größe eines eServers der zSeries von IBM ist beeindruckend. Im Bild: Cyril Price und Kyle Vankleeck neben einer z900.

Im Großrechner ist vieles anders

Wer zum ersten Mal mit Großrechnern arbeitet, dem wird schnell klar, dass diese Architektur wenig mit einem PC zu tun hat. Bei einem PC trennt Betriebssystem und Hardware nicht gerade besonders viel, der Firewall-Spezialist kann den Rechner also gleich mitbetreuen. Bei einem Mainframe liegt zwischen der Firewall und ihrem Betriebssystem auf der einen und der Hardware auf der anderen Seite noch ein komplettes Softwaresystem, das man nicht mal schnell nebenher booten kann.

Für die Installation sind daher zwei Experten nötig, einmal für den Rechner einmal für die Firewall. Auch der geforderte Support ist bei Großrechnern typischerweise anders; eine 24-Stunden-Betreuung mit kurzen Reaktionszeiten unterscheidet sich doch sehr stark von der Mo-Fr/9-17-Mentalität.

Als nach langer und reiflicher Überlegung (eine Nacht) die Entscheidung für eine Entwicklung gefallen und die Dauer für die Portierung auch beschlossen war (zwei bis fünf Tage – ist ja Linux), vereinbarten wir einen Termin zu einem ersten Versuch.

Ein Erlebnisbericht: Die Portierung

Wie entwickelt man eine Firewall für einen Großrechner, wenn man gerade keinen Mainframe übrig hat und die Entwicklung zentral für alle Plattformen auf einem Entwicklungsrechner laufen soll? Man nimmt einen Cross-Compiler, schließlich gibt es ja den Gcc. Eine IBM-Entwicklerseite[1] stellt dazu jede Menge Tipps und Patches bereit. Also sucht man in den verschiedenen Archiven nach den Grundversionen (Debian) für die Patches und holt sie, dann geht alles nach Anleitung: Binutils auspacken, patchen, übersetzen und installieren, Gcc 2.95.3 (nicht 3.0) ebenso, den Kernel cross-kompilieren, dann die Glibc und so weiter.

Soweit die Theorie. Die Praxis sieht anders aus: Abbrüche, Trial-and-Error-Durchläufe, nach der Übersetzung ein verkonfiguriertes Entwicklungssystem, Neuinstallation und Neubeginn. Und natürlich gibt es Patches, die erst erscheinen, sobald die Cross-Entwicklungsumgebung fertig ist. Die ändern schon mal den Ziel-Assembler, so dass alles von vorn losgeht.

Nicht zu vergessen ist auch, dass die für Cross-Kompilierungen wichtigen Optionen »–build=«, »–host=« und »–target=« umso wüster durcheinander gewürfelt sind, je weiter man sich vom Kernel entfernt. Viele Pakete sind offensichtlich nicht für die Cross-Kompilierung gemacht.

Jeder, der einmal eine komplexe Aufgabe gelöst hat, wird unser Gefühl des Stolzes verstehen können, als nach gut einer Woche (also der vorgesehenen Portierungszeit) der Kernel und “Hello World” übersetzt waren. Nun konnte es ja nicht mehr lange dauern, denn das Schlimmste lag hinter uns. Jetzt nur schnell mal den Kernel auf dem vorgesehenen System booten, um die Kernel-Meldungen zu sehen – die Panic-Meldung wegen des fehlenden Dateisystems ist schon in Ordnung -, und als zweiten Test das “Hello World” in einer Linux-Maschine auf dem Großrechner laufen lassen, das funktioniert sowieso. Also weg damit per Mail und auf das Feedback gewartet.

Abbildung 2: Im Unterschied zu einer klassischen Firewall läuft diese Linux-Firewall in dem Großrechner und nicht auf einer eigenen Maschine vor dem Mainframe.

Plug & Pray

Nichts funktionierte. Meldungen beim Booten: Fehlanzeige, auch das “Hello World” konnte nicht ausgeführt werden. Für den Portierungstermin vor Ort sah es nicht gut aus. Übertragungsfehler in den Mails konnten wir von vornherein ausschließen, wir hatten sogar die MD5-Summen verglichen.

Für die Portierung waren zwei Tage vereinbart. Danach sollte das Grundsystem laufen und nach und nach der Rest der Software portiert werden. Stattdessen verglichen wir die Assembler-Ausgaben von “Hello World” zwischen Cross-Compiler auf dem PC und Native-Compiler auf dem Großrechner. Wir assemblierten und disassemblierten, verglichen Binaries und linkten auch noch über Kreuz. Die Binaries unterschieden sich tatsächlich an einer Stelle im Header, nicht aber im Code. Änderten wir dieses Byte, lief der cross-kompilierte Code auf dem Linux-Zielsystem.

In einer versteckten Mail und später im Kernel fanden wir endlich die Erklärung: Zwischen der Kernelversion 2.4.3 (Linux-Zielsystem) und 2.4.5 (Linux-Entwicklungssystem) war die Magic-Nummer für S/390-Binaries geändert worden. Der neue Kernel verstand beide Magics, aber der alte Kernel selbstverständlich nur das alte.

Es blieb uns also nichts anderes übrig, als die neue Kernelversion zum Laufen zu bringen. Am Ende des zweiten Portierungstags kam der Kernel zumindest bis zum Start der Ramdisk und zum Bash-Prompt, wenn auch ohne Plattentreiber (die hatten beim Übersetzen einen Fehler gemeldet). Die Bash des alten Kernels hatten wir auf das neue System kopiert, unerklärlicherweise lief unsere neu übersetzte Shell nicht.

Abbildung 3: Durch das Netzwerk-API ist es leicht, den Virenschutz auf einen anderen Rechner zu verlegen. Selbst innerhalb des Großrechners wird über dasselbe API kommuniziert.

Hercules

Zum Ausgleich funktionierte etwas anderes: Hercules[3], ein Hardware-Emulator, der einen Großrechner auf einem normalen PC emuliert. Er simuliert einen oder mehrere Prozessoren, Netzwerkkarten und Platten, also ein komplettes System (siehe Listing 2). Das geht zwar manchmal etwas langsam, aber es funktioniert weitgehend. Unser bisheriges Portierungsergebnis konnten wir auf Hercules-Basis immerhin zum Laufen überreden und waren damit im Großen und Ganzen unabhängig von einem realen Großrechner.

Aber kein einziges cross-kompiliertes Programm lief. Weder unter Hercules, noch auf dem Zielsystem. Auch die Versuche mit den Vorversionen von Glibc 2.2.4 scheiterten. Da ein IBM-Mitarbeiter sich als Glibc-Tester geoutet hatte, wurde er kurzerhand angemailt und ohne große Hoffnung mit dem Problem konfrontiert. Am nächsten Morgen kam eine Mail (von hier aus noch mal ein Dank an Martin Schwidefsky, wir säßen heute noch ratlos da) mit einem Ein-Zeilen-Patch für die Binutils.

Listing 2: Hercules-Konfiguration

01 CPUSERIAL 002623    # CPU serial number
02 CPUMODEL  3090      # CPU model number
03 MAINSIZE  280       # Main storage size in megabytes
04 XPNDSIZE  0
05 CNSLPORT  3270      # TCP port number to which consoles connect
06 NUMCPU    1         # Number of CPUs
07 LOADPARM  0582      # IPL parameter
08 OSTAILOR LINUX
09 PANRATE FAST
10 ARCHMODE ESA/390
11 CFCCIMAGE cfcc_level8
12 
13 # .-------------------Device number
14 # |   .---------------Device type
15 # |   |     .---------File name and parameters
16 # |   |     |
17 # V   V     V
18 #---  ----  --------------------
19 000D  3525  punch00d.txt  ascii
20 000E  1403  print00e.txt  crlf
21 001F  3215
22 0020  1052
23 0194  3370  tapes/zguard.0194
24 018f  3420  linux.aws
25 0200  3270
26 0201  3270
27 0582  3420  /root/hercules/hercules-package/ tapes/fwb.tdf
28 0E00  3088  CTCI  /dev/net/tun 1500 192.168.253.14 192.168.253.13 255.255.255.0
29 0E01  3088  CTCI  /dev/net/tun 1500 192.168.253.14 192.168.253.13 255.255.255.

Alles wird gut

Die Neu-Übersetzung des Entwicklungssystems dauerte zwei Stunden, das Übersetzen von “Hello World” weitere zwei Sekunden. Das Hochfahren von Hercules dann noch mal fünf Minuten. Wir können jetzt das Glücksgefühl von Linus Torvalds beim Anblick von AABBAAB… verstehen. Um es kurz zu machen: Jedes Programm lief nach der Neu-Übersetzung so, als hätte es nie etwas anderes getan.

Gemessen an diesen fundamentalen Dingen war das weitere Verfahren relativ einfach. Alle Softwarepakete, ob selbst entwickelt oder Open Source, wurden mit mehr oder weniger Aufwand dazu gebracht, sich cross-kompilieren zu lassen, und in den Ziel-Baum eingepflegt.

Abbildung 4: Innerhalb des Großrechners lassen sich auch mehrere Linux-Firewalls einsetzen. Hintereinander geschaltet sichern sie den hoch sicheren Bereich doppelt ab.

Netzwerk

Eine besondere Herausforderung für Linuxer ist die Lektüre des IBM-Manuals “Linux for S/390 Device Drivers and Installation Commands”. Ohne einen richtigen Großrechner sagen den meisten solche Bezeichnungen wie CTC, ESCON, IUCV, LCS, QETH QDIO und OSA nicht gerade besonders viel, man weiß eigentlich nur, dass alles richtig teuer und richtig schnell ist.

Viele Erklärungen werden erst verständlich, wenn man selbst ausprobiert. Wegen der Hochverfügbarkeit gibt es auch die Möglichkeit eines Hotplug, also des An- und Abschaltens von realen und virtuellen Netzwerkkarten im laufenden Betrieb. Unter Hercules steht aber nur der CTC-Treiber für Tests zur Verfügung, die übrigen Treiber sind mangels Hardware nicht zu benutzen.

Der am meisten verwendete Netzwerkkartentreiber ist zugleich der einfachste: CTC (Channel to Channel). Er ist nur eine virtuelle Netzwerkkarte und stellt eine Punkt-zu-Punkt-Verbindung zwischen zwei virtuellen Maschinen (etwa zwischen Firewall und geschützter Maschine) her, die eine Netzwerkkarte simuliert. Unter Hercules dient CTC dazu, über den TUN-Treiber eine Verbindung zwischen Gast- und Wirtssystem aufzubauen. CTC-Verbindungen stellen unter VM das virtuelle Pendant zu ESCON-Verbindungen zwischen LPARs dar, der CTC-Treiber ist für beide geeignet.

IUCV steht nur unter VM zur Verfügung und bietet ebenfalls Punkt-zu-Punkt-Verbindungen zwischen VM-Guests. IUCV-Verbindungen sind jedoch schneller als CTC, da bei der Implementierung keine Rücksicht auf Kompatibilität zu einem realen Äquivalent genommen wurde.

Firewall im Rechner

In einer Firewall-Umgebung auf dem Großrechner hat nur die Firewall selbst einen Zugang zu den realen Netzwerkschnittstellen, die Verbindung zwischen der Firewall und geschützten Systemen führt ausschließlich über CTC- oder IUCV-Verbindungen.

LCS, QETH und QDIO sind Treiber für die unterschiedlichen OSA-Netzwerk-Adapter. Wird für den OSA2 und OSA Express Fast Ethernet noch der LCS-Treiber benutzt, benötigt Gigabit Ethernet sowohl QETH als auch QDIO. Ältere OSA-Adapter mussten jeweils mit den in den Gastsystemen verwendeten IP-Adressen und den zugehörigen Device-IDs vorkonfiguriert werden. Neuere übernehmen die Interface-Einstellungen der Gastsysteme dynamisch und vereinfachen die Administration erheblich.

Im Prinzip unterscheiden sich reale und virtuelle Netzwerkschnittstellen nicht voneinander, sobald sie im System angemeldet sind. Sie lassen sich wie gewohnt benutzen, allerdings haben sie ein paar Eigenheiten, die berücksichtigt sein wollen. Der LCS-Treiber hat beispielsweise nur einen Modulnamen (»lcs.o«), kann aber den Devicenamen »tr X« (für Token Ring) oder »eth X« (für Ethernet) belegen, je nachdem, was konkret angeschlossen ist. Die Gerätenummer » X« lässt sich aber beschränkt zuweisen. Ein Modul kann durchaus mehrere Devices enthalten, bis zu 256.

IBM empfiehlt das Device-Filesystem und das dynamische Laden der Module. Dadurch können über die Datei »/proc /chandev« die Netzwerkgeräte und Platten dynamisch zugeordnet werden. Die Lade- und Entladeprozedur ist alles andere als einfach, aber vermutlich sehr mächtig. Hier hat IBM einige Bug-Fixes veröffentlicht, die uns davor zurückschrecken lassen, zu früh “Jugend forscht” zu spielen. Immer wenn es im Manual interessant wird, fehlen leider aussagekräftige Beispiele.

Device-Filesystem

Sehr erfreulich verlief der empfohlene Umstieg auf das Device-Filesystem (»devfs«). Die Programme und Prozeduren liefen überwiegend ohne jede Änderung. Das Device-Filesystem hängt sich in »/dev« ein und muss als Option bei der Kernelübersetzung angegeben werden. Der große Vorteil ist, dass mit ihm nur die Device-Nodes im »/dev«-Baum angelegt sind, deren Treiber und Geräte sich auch tatsächlich registriert haben. Wenn eine Datei namens »/dev/dasd /0192/device« vorhanden ist, ist der DASD-Treiber auch geladen und die Platte 0192 steht zur Verfügung. Die sonst übliche Müllhalde im »/dev«-Verzeichnis ist einer übersichtlichen und kleinen Struktur gewichen.

Darauf aufbauend ist die Installation auf Platte oder die Konfiguration der Netzwerkschnittstellen einfach zu automatisieren. Wir haben davon intensiv Gebrauch gemacht.

Installation

Wie kann man ein System installieren, wenn in der Regel weder ein CD-ROM-Laufwerk zur Verfügung steht, mit dem man die Software laden kann, noch eine Diskette mit den Konfigurationsdateien? Für die Installation benutzt man eine 120 MByte große Ramdisk, verwandelt sie samt Kernel und Parameterdatei in virtuelle Lochkarten, lädt sie in den VM-Reader (einen virtueller Lochkartenleser) und bootet von dort (siehe Kasten “Virtuelle Maschinen”). Die drei Dateien kommen per FTP über das LAN, man muss nur darauf achten, dass sie schon im 80-stelligen Lochkartenformat auf der CMS-Minidisk landen.

Der Kernel startet beim IPL, erkennt die Ramdisk und bootet von ihr. Statt das System weiter in der Ramdisk zu betreiben, kann man es auch auf Platte installieren. Diese Installation beginnt mit dem Formatieren (»dasdfmt«), Initialisieren und Partitionieren (»fdasd«) der Platte. Danach erhält sie ein Filesystem (»mke2fs«) und wird gemountet, die Dateien werden kopiert und der Bootsektor (»zipl«) aufgespielt. Wenn das abgeschlossen ist, kann man auch den IPL direkt von Platte starten. Alles ist fast so, wie man es kennt.

Eins fehlt noch zu unserem Glück: die spezifische Konfiguration. Wir haben uns in diesem Projekt dazu entschlossen, sie über das Netz per SCP-, SFTP-, HTTP- oder FTP-Server zu holen, wobei die Daten der ersten Netzwerkkarte und des Servers einzugeben sind. Zugute kommt uns hier die geringe Typenzahl der Netzwerkschnittstellen, statt Hunderter verschiedener Netzwerkkarten und -treiber gibt es nur fünf. Mit der Kernelversion 2.4.16 wäre es auch noch möglich, Dateien direkt von einer Minidisk zu lesen – wir können diese Version aber nicht einsetzen, da IBM bislang die Netzwerkkarten-Treiber nur für Version 2.4.7 als Binärmodule zur Verfügung stellt.

Zusammenfassung und Ausblick

Die Portierung hat viel länger gedauert, als wir zunächst dachten. Trotz der Wochenendarbeit und zeitweise fehlenden Schlafs hat sie viel Freude gemacht, gerade weil man sich auf neuem Terrain befindet und keine ausgetretenen Wege beschreiten muss. Die Cross-Entwicklung hat sich als der richtige Weg herausgestellt, plattformübergreifende Entwicklung zu betreiben und in alle Linien dieselben Erfahrungen einzubringen.

Es hat sich in den vergangenen Monaten sehr viel im S/390-Teil des Kernels getan. Die Bugfixes für die Version 2.4.7 sind insgesamt stabil, in den neuen Kernelversionen bis 2.4.16 sind zusätzlich aber viele interessante Dinge passiert, die wir in den nächsten Wochen nutzen werden, sobald die Netzwerk-Binärmodule verfügbar sind.

Wir werden dann im Laufe der Zeit endlich auch solche Eigenschaften von Linux testen und nutzen, die wir bislang nicht benötigt haben, aber dennoch gerne einmal ausprobiert hätten, zum Beispiel den Datendurchsatz von mehreren GByte/s, hundert Netzwerkschnittstellen und mehr, Traffic Shaping (Bandbreitenbegrenzung), Virenscan mit 50 GByte pro Tag, Routing mit Iproute 2, VPN direkt mit dem Großrechner und virtuelle DMZ.

Mit der Anforderung an Hochverfügbarkeit wird die Firewall dynamisch rekonfigurierbar werden müssen, inklusive Routing und Regeln. Wir sind sicher, dass Linux das alles bewältigen kann, und möchten seine Leistung jenseits des PCs kennen lernen. (fjl/uwo)