Simple Security Policy Editor
Der Unterschied zwischen Information und Desinformation ist nicht virtuell.
Professioneller Support
Der Rote Hut ließ sich einfach installieren; meine Idee vom universellen, monolithischen Kernel für alle Maschinen erwies sich jedoch als Falle. Ein auf den Roten Hut neu aufgebrachter, ansonsten fehlerfrei funktionierender Kernel zeigte mit LILO keinerlei Probleme, bootete jedoch nicht. Der vorherige Kernel aus dem Hut zeigte munter weiter sein /proc. Die Ursache für dieses Verhalten war nicht festzustellen. Daher wurde eine passende Frage mit den Daten zu unserem selbstgebackenen Kernel an den bis dahin unbekannten Support des Roten Hutes geschickt. Da unsere Angaben wahrheitsgemäß den Hinweis auf den FreeSwan-Patch enthielten, war man dort sehr einfach die Sache los: man verwies uns an den Hersteller des FreeSwan-Patches und war schon fertig. Diesem in unseren Augen abwegigen Ansinnen folgten wir nicht. Von Seiten des Controller-Herstellers war kein Support zu erwarten, da dieser seinen Angaben zufolge ausschließlich Systeme aus Redmond unterstützte.
Am Ende wurde entschieden, auf die RAID-Controller zu verzichten. Betrachtet im Schatten dreier Betriebsjahre, war dies die einzig richtige Vorgehensweise. Ohne Hochverfügbarkeitsanforderungen sind einfache IDE-Platten ausreichend.
Datei hostnet
################################################################ # File: hostnet # Demonstration of CIDR-notatation #name address # comment ################################################################ any 0.0.0.0/0 # all the net many 0.0.0.0/1 # lower half many 128.0.0.0/1 # upper half # admin 192.168.1.195/32 # sspe host alice 192.168.1.11/32 # admin alice # gw-cgn-s 192.168.1.222/32 # server-LAN gw-cgn-u 192.168.1.126/32 # user-LAN gw-cgn-e 194.120.12.96/32 # extern cgn-user 192.168.1.0/25 # dhcp here cgn-leased 192.168.1.128/26 # cgn-server 192.168.1.192/27 # cgn-rfu 192.168.1.224/27 # cgn-net 192.168.1.0/24 # cgn complete ptb1 192.52.103.103/32 # NTP-Source ################################################################
Datei rules.admin
# File: rules.admin # Demonstration of sspe-rules ################################################################ #src dst dir proto port action options ################################################################ alice admin 1 tcp ssh accept many admin 1 ip all drop LOG gw-cgn-e ptb1 1 udp ntp accept NTP cgn-user gw-cgn-u 1 udp 135:139 drop NETBIOS ################################################################
Ignoriere Fehler
Während des Apply können die verschiedensten Fehler auf jeder der beteiligten Maschinen geschehen. Trotzdem muß der Mechanismus für alle anderen weiterlaufen, ein Anhalten, um dem Administrator eine Eingriffsmöglichkeit zu geben, ist nicht vorgesehen. Da jedoch an fast allen Stellen Fehler geschehen können, werden diese bei Auftreten erst gesammelt, um am Ende des Apply dem Administrator in Summe gezeigt zu werden.
Er hat sodann die Pflicht, geeignet für Abhilfe im Sinne des handelnden Unternehmens zu sorgen. Seiner Kompetenz obliegt es, die Maßnahmen wenig betriebsunterbrechend oder besser gleitend so zu gestalten, daß der Geschäftsablauf wenig bis gar nicht gestört wird. Bei Betriebsbeginn war den jeweiligen SSH-Sessions noch ein ping vorgeschaltet, der die Erreichbarkeit der Zielsysteme aktuell überprüft, dieses Prüfung wurde zugunsten schnellerer Abläufe alsbald gestrichen.
Infolge wird bei Fehlschlagen der SSH-Session durch die TCP-Retries eine erhebliche Verzögerung auftreten. Da der Administrator jedoch den Apply manuell initiiert, wird er auch den Bildschirm beobachten und eingreifen können.
Zeige Fortschritt
Bei LPFC wurde das Aktivieren der Regeln durch echo-Kommandos begleitet, die Punkte als Fortschrittsanzeige aufs Display des Administrators ausgaben. Dies diente der Kontrolle, ob das Gerät ordnungsgemäß arbeitet oder zum Telefon gegriffen werden musste. Da nun aber viele Maschinen gleichzeitig zu überwachen waren, konnte dieses nur anderweitig realisiert werden. Eine der letzten Änderungen (Version 0.2.5) ergab eine zufriedenstellende Darstellung des Fortschritts. Es werden nun pro Maschine in je einer Zeile der aktuelle Status (sleeping, waiting, generating, diff, transferring, executing) sekundengenau dargestellt. Die Werte sleeping und waiting werden gezielt über die Datei apply-options im jeweiligen Verzeichnis gesetzt. Als Konsequenz muß evtl. das darstellende Fenster in ausreichender Höhe in Abhängigkeit zur Maschinenanzahl eingestellt werden.
Ernste Umsetzung
Ab Dezember 2001 waren dann einige Überstunden fällig, die Sechstagewoche war für etwa ein halbes Jahr angesagt. Da der normale Wahnsinn des alltäglichen Lebens weiterging, kam nur die Zeit nach Büroschluß oder das Wochenende für eine ruhige, besinnliche Art der Entwicklung in Frage. Alle 5, spätestens 10 Minuten per Telefonklingel aus den notwendigen Gedanken gerissen zu werden, macht keine Freude und auch keinen Fortschritt bei der Arbeit.
Als Entwicklungsumgebung für die neue Administrationszentrale diente ein Intel-PC mit 1 GHz Takt, 512 KByte Speicher und ausreichend SCSI-Plattenplatz. Hierauf wurde die Geschmacksrichtung Debian Stable installiert, um keinerlei Risiken bzgl. der unbekannten Variante einzugehen. Zur bequemen Arbeit diente ein normaler Arbeitsplatz-PC mit Rotem Hut, auch um eben dieses kennenzulernen. Die KDE-Oberfläche erwies sich als angenehm, zuvor hatte ich nur von Systemen aus Redmond per telnet und putty, sowie von Debian (80x25 ASCII) aus mit ssh meine Systeme administriert. Die in der Grafik möglichen breiten Fenster überzeugten mich schnell, meinen Code nur so eingeben zu wollen. Per Dialog ein Hauptmenü darzustellen und anschließend mit Skripten zur ersten Funktion zu erwecken, dauerte dann nur wenige Tage. Die ersten Übungen mit iptables sollten bald danach die Hürden der Geschichte zeigen.
