Goodie Domain Service - einst und jetzt

Der Goodie Domain Service (GDS), ein im österreichischen akademischen Raum mittlerweile etablierter und auch über die Landesgrenzen durchaus bekannter Service der Abteilung Standardsoftware des Zentralen Informatikdienstes (ZID) der TU Wien feierte im Herbst 2004 unspektakulärerweise sein 10-jähriges Bestandsjubiläum. Ein Anlass genug, eine kurze geschichtliche Retrospektive Revue passieren zu lassen.

Die dem GDS zu Grunde liegende Mission sei gleich vorweg genommen: Mit dem GDS wurde von allem Anfang an die Zielsetzung verfolgt, dem schulischen wie auch dem akademischen Bereich in Österreich einen problemlosen Zugang zu kostenfreier, ausgesuchter, möglichst plattformneutraler Software zu ermöglichen; zu einer Software, die sich durch Anwendungsfreundlichkeit, Robustheit, Qualität, Wartbarkeit sowie einen hohen Nutzungsgrad auszeichnet und in breiten Anwendungsbereichen eingesetzt werden kann.

Darüber hinaus - und das war für den Verfasser stets besonders motivierend - sollten diese Softwarebestände nach dem moralischen Fairness-Grundsatz des "Gebens und Nehmens" der breiten Kommunität wieder zur Verfü- gung gestellt werden. Wie wir wissen, wäre das Internet ohne die "collaborative work of the worldwide community", einer weltweit verstreuten, koordiniert zusammenarbeitenden Unzahl von Enthusiasten überhaupt kaum entstanden. Im Rahmen des GDS sollte durch Redistribution zur "collaborative work" ein bescheidener Beitrag geleistet werden.

Die Idee der Gründung eines Software-Repository Anfang der 90er-Jahre wurde aus der damaligen schwerpunktmäßigen Beschäftigung des Verfassers entwickelt, neue Software-Technologien hinsichtlich ihrer sinnvollen und nützlichen Anwendbarkeit im universitären Bereich für Zwecke der Forschung und Lehre zu untersuchen. Ein Metier des Verfassers, das sich als Folge des abgeschlossenen Informatikstudiums ergeben hatte. Im Brennpunkt des Interesses standen internet-basierte, zukunftsweisende Projekte, die sich durch einige besonders interessante Merkmale auszeichneten: Standardisierung, Nicht-Proprietät von Schnittstellen und Protokollen, Modularität, Netzfähigkeit, Client-Server-Architektur, Lizenz- und Kostenfreiheit, Source-Verfügbarkeit, Qualität, Stabilität und vor allem durch einen hohen Nutzungsgrad im breiten Anwendungsumfeld.

Der Begriff Open-Source Software (OSS), der all diese Merkmale - wie mittlerweile allgemein bekannt - enthält, wurde zu diesem Zeitpunkt jedoch eher vereinzelt erwähnt. Er hatte noch keine ausgeprägten Konturen angenommen und im Bewusstsein der Öffentlichkeit war er praktisch nicht verankert.

Die Motivation, sich am damaligen Rechenzentrum mit Neuen Technologien zu beschäftigen, lag auf der Hand:
a) es gehörte stets zur Aufgabe des Rechenzentrums, nach neuen Wegen und Alternativen zu suchen, Informationstechnologien im universitären Umfeld mit Vorteil einzusetzen,
b) die sprichwörtliche Finanzknappheit im universitären Bereich, die das Experimentieren mit kommerziellen Produkten beachtlich paralysierte.

Von der Beschäftigung mit Neuen Technologien zur Schaffung eines allgemein zugänglichen Repository von ausgewählten Projekten, Komponenten und Systemen, das einem breiteren Anwenderkreis dienen sollte, war dann nur ein kleiner Gedankensprung. Begünstigt wurde diese Entwicklung insbesondere durch das Wesen des Verfassers:
a) ein chronischer Hang zum Sammeln und
b) ein starker Hang zur "Wohltätigkeit".

Die anfängliche Namensgebung Public Domain Service für dieses Repository wurde vom Verfasser aus verschiedenen Gründen anschließend fallen gelassen und durch den ihm zutreffender erscheinenden, nicht belegten Begriff Goodie Domain Service ersetzt.

Die Realisierung des Goodie-Repository befand sich im Herbst des Jahres 1993 in der Konzeptionsphase. Die Realisierung nahm dann langsam konkrete Formen an und der Betrieb konnte schließlich zu Beginn des Jahres 1994 versuchsweise aufgenommen werden. Das Angebot erstreckte sich in erster Linie auf infrastrukturell wichtige Internet-Komponenten wie Server und Browser sowie das GNU-Angebot, die ausschließlich über das ftp-Protokoll bezogen werden konnten. Zur Verfügung stand eine bescheidene Bandbreite für den internationalen Traffic. Die anfängliche hardwaremäßige Ausstattung des Goodie Domain Service hielt sich recht in Grenzen. Es gelang, eine leistungsmäßig bescheidene Clone SPARC-Maschine Axil 235 zu organisieren, ein Äquivalent zum Vorgänger der Sun SPARC ultra 1 sowie eine Anzahl älterer Massenspeicher mit einer Gesamtkapazität von 20 Gb. Der Begriff Service-Security war zu diesem Zeitpunkt de-facto kein Thema, das einer besonderen Beachtung würdig gewesen wäre.

Ein besonderer Stellenwert wurde von allem Anfang an der Service-Akzeptanz seitens der Anwender eingeräumt. Eine hohe Service-Akzeptanz als zentrale Richtgröße war bereits in der Konzeptionsphase an bestimmte Qualitätsvorstellungen geknüpft, die den Verfasser schließlich zur Aufstellung einiger Grundmaximen führten. Diesen Service-Grundmaximen wurde während der ganzen Existenz von GDS stets die höchste Priorität eingeräumt. Die Verwirklichung erfolgte stufenweise im Laufe der Service-Expansion. Zu diesen - vor allem - qualitativen Grundmaximen gehören:

• Programmangebot: breites Angebotsspektrum, Aktualität, hoher Nutzungsgrad, hohe Qualität/Wartbarkeit,
• Zugang: Zugangsvielfalt, problemlose Orientierung/ Überschaubarkeit/Navigation,
• Service: hohe Verfügbarkeit/Stabilität/Ausfallssicherheit/ Integrität, legale Nutzung.

Nach der Einführungsphase setzte eine Entwicklung ein, die im Zeichen einer allmählichen Ausweitung aller den Service charakterisierenden operationalen Dimensionen stand - das Angebotsspektrum und Volumen, installierte Hardware, zugestandene Bandbreite, Zugangsarten, Service-Verwaltungsaufwand (Monitoring, System-, Datensicherung, Security etc.), generelle Einhaltung der qualitativen Grundmaximen.

Der Schlüssel zur stetigen Ausweitung des Services lag in einer behutsamen, aufeinander abgestimmten Steigerung aller Service-Dimensionen begründet. So wurde in erster Linie das Angebotsspektrum und Volumen in einer ausgewogenen Weise an die Gegebenheiten stets schrittweise angepasst, vor allem an die Leistungsfähigkeit der gerade installierten Hardware, vorhandene Massenspeicherkapazität sowie die verfügbare Bandbreite.

Das schlichte Fehlen einschlägiger Erfahrungen in der Betriebsführung eines Services derartiger Größenordnung zwang auch zu einer eher vorsichtigen Expansionsart, insbesondere hinsichtlich der mit vorrangiger Priorität zu berücksichtigenden Qualitäts- und Grundsatzmaximen. In der Anfangsphase war es für den Verfasser kaum vorstellbar, Jahre später immer noch als "One Man Service" aktuelle Datenbestände von mehreren Terabytes im Rahmen eines stabilen, abgesicherten Betriebes anzubieten.

Es soll aber nicht unerwähnt bleiben, dass jede sich ergebende oder angestrebte inkrementelle Steigerung der Leistung oder eine Kapazitätsaufstockung bzw. Bandbreitenvergrößerung Hand in Hand mit der Frage nach der Daseinsberechtigung von GDS und seiner Nützlichkeit diskutiert wurde.

Durch eine derart moderate Politik der Service-Expansion ist es gelungen, mit moderaten finanziellen Mitteln das Auslangen zu finden sowie das Downloadvolumen relativ gut skaliert im Griff zu halten. Die ungefähre Steigerungsrate des Downloadvolumens betrug 100% pro Jahr, siehe Grafik "GDS Downloads".

Im Laufe der Aufbaujahre wurden unterschiedliche Schwerpunkte gesetzt und verfolgt. Sie wurden zum Teil durch die Wunschvorstellung einer weiteren qualitativen Verbesserung des bestehenden Services motiviert, hatten sich aus betrieblicher Sicht infolge der fortschreitenden Expansion ergeben oder wurden zum Teil durch äußere unerwünschte, unerwartet eingetretene Einflüsse bzw. problematische Ereignisse erzwungen.

Es war ein stets großes Anliegen des Verfassers, ein breitgefächertes Angebot an unterschiedlichen Goodies im Angebot zu halten, um den disparaten Bedarfsvorstellungen einer möglichst breiten Anwenderschaft zu entsprechen. So wurden grundsätzlich nicht nur einzelne Softwarekomponenten, sondern auch ganze integrierte Systeme im Laufe der Zeit ins Programmangebot aufgenommen. Wie oben bereits angedeutet wurde, konzentrierte sich das GDS-Angebot auf den Bereich der Informationstechnologien sowie internet-orientierte Anwendungen.

Deshalb stellten Betriebssysteme, Informationssysteme, Mensch-Maschine-Schnittstellen, System-Hilfsprogramme jeder Art sowie PC-Anwendungen den größten Teil des Angebotes dar. Dabei wurde ein ganz großer Wert sowohl auf das begleitende Dokumentationsmaterial zwecks einer sinnvollen Nutzung und Wartung sowie auch auf Begleitmaterial jeder Art zur autodidaktischen Weiterbildung gelegt. Zum späteren Zeitpunkt wurden darüber hinaus wichtige Verweise bzw. ganze Server, die fokussierte Verweise zu einem bestimmten Thema anbieten, ins Programmangebot aufgenommen. GNU/Linux hatte bei den Anwendern im Laufe der Jahre beachtlich an Popularität zugelegt. Der gestiegenen Nachfrage - insbesondere nach unterschiedlichen Linuxdistributionen - wurde im Laufe der Jahre daher in angemessener Weise Rechnung getragen. Die Attraktivität der Linuxdistributionen ist infolge der bestehenden Rivalität einem ständigen Wandel unterzogen. Die gefragtesten Distributionen gehörten aber - in Abhängigkeit von den verfügbaren Ressourcen oft in mehreren Versionen - stets zum Bestandteil des GDS-Angebotes.

Die GDS-Bestände waren anfangs lediglich über das ftp-Protokoll beziehbar, einem Protokoll, das in den 90er- Jahren für File-Download mit Abstand am meisten benutzt wurde. Mit dem Aufkommen der Browser gewann das http-Protokoll zunehmend an Bedeutung. Die Möglichkeit eines Multiprotokoll-Zugangs zu den GDS-Beständen wurde relativ früh als relevant betrachtet. Dementsprechend war es erforderlich, Datenstrukturen so anzulegen und zu halten, dass mehrere unterschiedliche Server unter Beachtung einiger Randbedingungen (Security etc.) in einem harmonischen Environment koexistieren konnten. So wurde schrittweise der http-Zugang mit einer benutzerfreundlichen Schnittstelle implementiert, angereichert mit zusätzlicher Funktionalität wie etwa der Möglichkeit einer "fliegenden" Entpackung von gegebenen- falls komprimierten Dateien (rpm-, zip-, tar-Dateien etc.).

Das rsync-Protokoll gewann im Laufe der Zeit wegen seiner besonderen Traffic-Effizienz beim Abgleich großer Datenmengen zunehmend an Bedeutung. Am GDS wurde dieses Protokoll daher primär für Anwender implementiert, die selbst größere Datenbestände lokal halten und aktualisieren. Die http-orientierten Downloads haben massiv zugenommen und scheinen laut Downloadstatistik zunehmend die klassische, ftp-orientierte Downloadvariante zu überflügeln.

Die anfängliche Sicherung vorhandener Datenbestände war zumindest aus zwei Gründen sinnvoll:
a) die Aktualisierungsfrequenz der Originaldaten hielt sich in vernünftigen Zeitperioden;
b) infolge des gesamten, relativ kleinen GDS-Datenvolumens konnte eine Datensicherung mit den vorhandenen, bescheidenen Backup-Geräten auch in einem akzeptablen Zeitrahmen erfolgen.

Mit der stetigen Zunahme des Datenvolumens einerseits sowie der immer kürzeren Updatefrequenz der vorhandenen Datenbestände andererseits drängte sich zunehmend die Frage nach dem Aufwand/Nutzen einer derartigen Backup-Durchführung in den Vordergrund. Die Situation war, wie sich bald herausstellte, ohne massive finanzielle Zuwendung nicht zu bewältigen.

Der Betrieb wurde daher einige Jahre gezwungenermaßen ohne Daten-Backups geführt. Eine erhebliche Entspannung in dieser Hinsicht konnte erst später erzielt werden und zwar durch die Schaffung eines abteilungsweiten Hitachi Backstore im Jahre 2003, das eine extrem hohe Ausfallssicherheit garantiert (siehe auch: GDS in der Gegenwart).

Der umfassende Begriff "Betriebssicherheit" erfuhr eine substanzielle Inhaltsverschiebung im Laufe der Jahre, im Zuge dessen sich auch im gleichen Maß die Beschäftigungsschwerpunkte verschoben haben.

Anfänglich stand die Thematik der Sicherstellung der Funktionstüchtigkeit, Ausfallssicherheit verfügbarer Hard- wareausstattung sowie die Aktualisierung und Sicherung der Betriebssoftware im Mittelpunkt, übers Internet kommende Angriffe wurden noch in der Mitte der 90er-Jahre kaum beobachtet. Die Security-Thematik wurde daher aus Anlassmangel kaum beachtet.

Gegen Ende der 90er-Jahre begannen sich allerdings auftretende Portscans sowie unterschiedliche Hackerpenetrationen zu häufen, was den Verfasser rasch zu Überlegungen nach geeigneter Abwehr auf den Plan riefen. Es wurden alle kommunikationsorientierten Applikationen von den bestehenden Systemen entfernt, die - wie es bis zu dem Zeitpunkt im Unix-Environment üblich war - "offenen", nicht verschlüsselten und daher leicht abhörbaren Text austauschten. Nach der Einführung dieser Maßnahme, als sich der Verfasser in Sicherheit wiegte, kam es aber zu einem "geringen" Übersehen mit dramatischen Folgen. Eine einzige, defaultmäßig vorhandene Variable auf der Shell-Ebene bewirkte, dass die Netzkommunikation zwischen der Root-Konsole und dem GD-System doch weiterhin im "Klartext" lief. Fazit dieses Übersehens: ein Lauschangriff war erfolgreich und der Goodie Domain Service zur Gänze - mehrere Hundert Gigabytes an Datenbeständen - systematisch und restlos eliminiert. Es gelang nicht zu eruieren, wodurch der Angriff motiviert war und von wem er tatsächlich ausgeführt wurde. Die Rekonstruktionsarbeit war eine Lehre neuer Dimension. Mit einem Schlag trat hinsichtlich der umfangreichen Securitymaßnahmen eine Ernüchterung sondergleichen ein.

In einer ersten Phase wurden an allen Systemen des mittlerweile geschaffenen GD-Intranetzes IP-Filter mit genau definierten Kommunikationsprofilen installiert. In einer zweiten Phase wurden relativ einfache Zusatzprozeduren implementiert, die das automatische Scannen von Logs und das Aussperren von Hosts besorgten. Damit wurden innerhalb einer definierten Zeitspanne Hosts erfasst und in die "Dead-List" eingetragen, die außerhalb der definierten Services herumprobierten, die Ports nach möglichen Vulnerabilitäten absuchten bzw. irgendwelche Schwachstellen in der eingesetzten Servicesoftware oder Protokollen selbst für Einbruchszwecke auszunutzen suchten. Diese eingeführte Maßnahme hatte sich als sehr erfolgreich erwiesen. Dadurch wurden Hackerversuche unterschiedlichen Grades in der Größenordnung von mehreren Hundert, tageweise Tausend, nach einem Jahr auf 5 - 15 reduziert. Die Dead-List wird quartalsmäßig ausgewertet, die Top 15 hartnäckigen Hacker dürfen dann in die Dead-List fürs nächste Quartal aufsteigen.

Die zugestandene, relativ geringe Bandbreite machte sich als knappes Gut immer deutlicher bemerkbar. Durch einen fortschreitenden Ausbau der lokalen bzw. quasilokalen Netz-Infrastruktur sowie geeignete netz-topologische Anpassungen in den Folgejahren wurde der Zugang zu GDS für den österreichischen akademischen Bereich wesentlich verbessert. Mit der steigenden internationalen Popularität des Services, die sich in der stetigen Zunahme unterschiedlicher Hostbesucher manifestierte, drängte sich aber die Frage nach einer geeigneten Politik der Zugangspriorität auf. Es wurden unterschiedliche Zugangsmodelle implementiert und ausprobiert, die sich allesamt bei der vorhandenen, geringen Bandbreite nur mäßig positiv auswirkten.

Im Laufe der Jahre wurde die Bandbreite angehoben, eine spürbare Entspannung trat jedoch erst im Jahre 2005 mit einer weiteren Bandbreitenanhebung auf 60 Mbps ein. Daraufhin wurden einschlägige, den Zugang nach Ländern regulierende Prozeduren fallen gelassen. Aktiv wurde nur die Regelung nach der maximalen Anzahl simultaner Zugriffe per Host bei allen Services beibehalten (in Abhängigkeit der Protokollart).

Die kontinuierliche Ausweitung des Servicebetriebes brachte es schließlich mit sich, dass insbesondere zwei Themenkreise - die Frage nach der Service-Ausfallssicherheit sowie die nach der angemessenen Service-Antwortzeit - enorm in den Vordergrund gerückt sind und nach einer angemessenen Lösung verlangten. Es sei nur kurz erwähnt, dass während der Ausbauphase kaum finanzielle Mittel zur Verfügung standen, die nötig gewesen wären, um die Thematik der Ausfallssicherheit zufrieden stellend zu lösen. Es wurde daher zu Beginn des Jahres 2002 nach Alternativen der Beschaffung von finanziellen Mitteln zum nötigen infrastrukturellen Ausbau gesucht. Durch den relativ hohen Bekanntheitsgrad, dessen sich der GD-Service in breiteren Kreisen bereits erfreuen durfte, gelang es dem Verfasser, einige Sponsoren dazu zu bewegen, den nötigen finanziellen Aufwand für den infrastrukturellen Ausbau zu tragen. Im Zuge dieser Sponsoring-Aktivitäten konnten substantielle Systemkomponenten beschafft werden, mit deren Hilfe sich nun ein Service mit hoher Ausfallssicherheit einerseits sowie einer entsprechend kurzen Service-Antwortzeit realisieren ließ. So wurde zu der vorhandenen Maschine eine zweite SunSPARC Enterprise 450 angeschafft, beide Systeme wurden sowohl CPU- als auch arbeitsspeichermäßig auf ihre volle Kapazität von je 4 CPUs und je 4 Gb ausgebaut, High-Speed-Fibre-Channel Gigabit-Interfaces für die Anbindung an das inzwischen installierte, abteilungsweite SAN Hitachi-Backstore sowie Gigabit-Interfaces zwischen beiden Maschinen installiert. Darüber hinaus wurden Massenspeicher, TFT-Display, ein PC mit 1 Tb Speicherkapazität zur Realisierung des Sourceforge-Spiegels sowie ein PC zum Testen von Linuxdistributionen und Software angeschafft. Durch den weiteren Ausbau des Hitachi-Backstore im Monat Mai stehen dem GD-Service jetzt insgesamt etwa 2,5 Tb zur Verfügung, unter Zunahme aller anderen angeschlossenen und benutzten Speicher werden vom GD-Service gegenwärtig alles in allem ungefähr 4 Tb an Software angeboten. Durch die Nutzung des extrem ausfallssicheren Hitachi-Backstore wurde auch die relativ problembehaftete Thematik nach geeigneter Backup-Philosophie definitiv ad-acta gelegt.

Die Anbindung vom Backstore-Speicher ist so ausgeführt, dass im Ausfallsfall einer der beiden zentralen Maschinen die andere funktionsfähige Maschine durch eine einfache Rekonfiguration jeweils die volle Last übernehmen kann. Die GD.tuwien.ac.at wird im internationalen Umfeld propagiert, ist daher in erster Linie für den nicht lokalen Bedarf gedacht. GD4.tuwien.ac.at (alias GD4ME.tuwien.ac.at) wird hingegen im internationalen Umfeld nicht erwähnt. Diese möge primär von der lokalen sowie quasilokalen Klientel in Anspruch genommen werden. Beide Maschinen offerieren aber uneingeschränkt das selbe Programmspektrum und sind über die gleichen Protokolle sowohl lokal als auch remote erreichbar. Der Anwender kann je nach seiner Präferenz zwischen den Zugangsarten ftp, http bzw. rsync wählen.

Das Handling der täglichen Betriebsführung eines Service dieser Größenordnung lässt sich nicht nach dem Do-it-Schema "Erstens, Zweitens, Drittens" beschreiben. In der Regel sind vielfältige Aktionen nötig, die einander überlagern, die aus dem laufendem Monitoring der Ressourcennutzung, des Hostverhaltens, der Überwachung einer Fülle von zum Teil speziell zugeschnittenen Download-Skripts sowie der Auswertung von mehreren Logs bestehen.

Auf die Gestaltung des Angebotsprogramms, insbesondere seiner Auswahl, sei hier noch in Umrissen eingegangen. Das Programmangebot des GDS unterliegt einer ständigen Gestaltung sowie Anpassung an manifestierte Anwenderbedürfnisse, die sich zum erheblichen Teil aus ständigen Beobachtungen sowie Auswertungen des Downloadprofils ergeben. Das Downloadprofil ermöglicht klarerweise einen deutlichen Aufschluss über die Anwenderattraktivität der jeweiligen Goodies. Außerdem werden vom Verfasser bzgl. des weltweiten Internet-Angebotes ständig Neuankündigungen sowie Diskussionen über unterschiedliche Informationskanäle verfolgt, um neue Entwicklungen oder Komponenten, die für die Anwender möglicherweise von potenziellem Interesse sein könnten, zeitgerecht in das bestehende Programmspektrum aufzunehmen, am Anfang zur Beobachtung, sozusagen testweise. Nicht zuletzt werden auch konkrete Wünsche bzw. besondere Präferenzen sowie angebotsspezifische Hinweise seitens der Anwender gerne entgegengenommen und verfolgt. Bei der Ressourcenzuteilung wird insbesondere bei voluminösen Objekten auf ihre Attraktivität bedacht genommen. Sehr gefragte Objekte werden darüber hinaus auf schnelle Massenspeicher verlegt, weniger gefragte gegebenenfalls in ihrem Umfang auf ein sinnvolles Minimum reduziert (etwa ältere Versionen fallen gelassen).

Der GDS Service wird auch am Wochenende, außerhalb der Dienstzeit, vom Verfasser - oft von unterschiedlichen remote Orten - ständig im Auge behalten. Dadurch konnte eine sehr hohe Serviceverfügbarkeit sowie Aktualität der Datenbestände über längere Zeiträume immer garantiert werden. Der Verfasser weiß aus zahlreichen Zusprüchen, die ihm zuteil wurden, dass die Anwender das auch zu schätzen wissen.