Der Linux-Code ist ein offenes Buch, der Windows-Quelltext ein eifersüchtig bewachtes Geheimis. Doch was bedeutet das für den Alltag des Systemadministrators?

Von einem theoretischen Standpunkt aus lässt sich in Sachen Transparenz ein eindeutiges Urteil über Linux und Windows fällen: Hier das Open-Source-, dort das Closed-Source-Betriebssystem. Doch wie wirkt sich das in der Praxis des Systemadministrators aus?

Der Quelltext des Linux-Kernels ist frei lizenziert und unter vielen Adressen zum Download erhältlich. Die Diskussion über die Weiterentwicklung dieses Systemkerns findet auf der offenen Kernel-Mailingliste statt. Selbst was die Entwickler auf den eigentlich geschlossenen Kernel-Summit-Treffen besprechen, kann man in der Regel in Mail-Archiven und auf Websites nachlesen.

Theorie und Praxis

Allerdings überblickt nicht einmal ein Vollzeit-Kernelentwickler die Gesamtheit der Millionen Codezeilen, geschweige denn der durchschnittliche Sysadmin in seiner notorischen Zeitnot. Selbst den Kernel-Profis entgehen gelegentlich Schwächen des Linux-Kerns. Es lässt sich in fast jeder Ausgabe der Kernel-News im Linux-Magazin nachlesen: Immer wieder taucht vergessener, verwaister, veralteter oder defekter Code auf. So brachte etwa ein Fehler im Kernel zum Jahreswechsel 2008/2009 einzelne Server zum Absturz. Alter Code, der Schaltsekunden verwaltet, war die Ursache [1].

Quellen-Studium

Der Blick in den Quelltext mag die letzte Zuflucht bleiben, wenn unklar ist, was ein Programm im Detail an einer bestimmten Stelle macht. Doch im Alltag nimmt der Linux-Admin in der Regel auf andere Weise Einblick in Kernel und Software, nämlich über deren Schnittstellen und Protokolldateien.

Tools wie »lsmod«, »ps« und »top« liefern Informationen über Kernelmodule und Userspace-Prozesse, »lsof« ermittelt die letzte geöffnete Datei, die das Aushängen einer Partition verhindert. Wer dem Kernel noch näher kommen möchte, sieht sich im Pseudo-Dateisystem »/proc« um, das das Innere des Systemkerns nach außen kehrt. Wichtige Kernel-Meldungen sowie weitere Informationen von Daemons und Userspace-Programmen finden sich in verschiedenen Logfiles eines Linux-Systems.

Wie sieht das unter Windows aus? Stefanie Kühnast arbeitet im Kommunalen Rechenzentrum Niederrhein (KRZN) und betreut dort unter anderem Windows-Server. Sie meint: “So unterschiedlich sind die Konzepte gar nicht. Beide Systeme versuchen, alle wesentlichen Logs an einem Ort zu konzentrieren: unter Linux »/var/log/*« unter Windows das Eventlog, zu finden im Startmenü unter »Systemsteuerung | Verwaltung | Ereignisanzeige«. Unter beiden System kann ein Entwickler aber ungestraft die Vorgaben ignorieren und seine Logs hinlegen, wo er möchte, solange seine Software dort Schreibzugriff hat.”

Wichtige Nummern

Eine (Fehler-)meldung in der Windows-Ereignisanzeige hat in der Regel eine Kennziffer, die Event-ID. Kühnast: “Alle Windows-Admins kennen die Adresse [http://www.EventID.net] auswendig, denn dort kann man nachlesen, was die Nummern bedeuten. Aussagekräftige Meldungen im Klartext sind selten.”

Auch beim Durchsuchen der Protokolldaten hat Linux die Nase vorn, meint die Mitarbeiterin des Rechenzentrums: “Mit so mächtigen Suchfunktionen wie verketteten Grep- und Awk-Kommandos mit regulären Ausdrücken kann Windows nicht dienen.” Die Beta-Version von Windows Server 2008 R2 zeigt allerdings mit Kategorien und Filtern, dass Microsoft-sich bemüht, aufzuholen.

Wie die Ausgabe, so die Eingabe: Linux verlässt sich auch bei der Systemkonfiguration auf Plaintext-Dateien, die sich mit einfachsten Mitteln lesen, auswerten und bearbeiten lassen. Windows dagegen verwendet die Registry, eine datenbankähnliche Struktur im Binärformat.

Stefanie Kühnast findet, die Registry verwende teilweise “faszinierend kryptische Namen”. Sie schränkt ihre Kritik allerdings ein: “Microsofts ursprüngliches Konzept sah vor, das weder Admins noch User die Registry jemals nackt zu Gesicht bekommen sollten. Statt dessen sollten sie mit GUIs arbeiten, deren Backend die vorgenommenen Einstellungen in die Registry schreibt.”

Die KRZN-Mitarbeiterin findet die Fehlersuche im Windows-System ungleich aufwändiger als unter Linux, zudem neige die Registry zu “schleichender Verfettung” – sie werde immer umfangreicher, da manche Software alte Einträge hinterlässt.

Klaus Wiest, selbstständiger IT-Dienstleister aus München, fühlt sich in der Registry etwas mehr zu Hause. Er arbeitet seit 1995 mit Windows, seit 2002 auch mit Linux und meint: “Größenprobleme mit der Registry hatte ich seit Windows 2000 nicht mehr.” Wiest findet nur wenige Bezeichnungen dort kryptisch, es gäbe schließlich auch sprechende Namen. »HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParametersNtpServer« beispielsweise nimmt als Wert eine Liste von Zeitservern entgegen. Zur Arbeit an der Registry verwendet er den Editor »regedit.exe« und das etwas leistungsfähigere »regedt32.exe«, mit dem man auch Berechtigungen auf Registry-Schlüssel setzen kann. Beides liefert Windows mit.

Von Utilities, die versprechen, die Registry automatisch aufzuräumen, hält der erfahrene Windows-Admin gar nichts: “Wenn ich ein massives Windows-Problem zu hören bekomme, wenn gar nichts mehr geht, dann war meistens vorher so ein Programm am Werk.”

Prozess-Archäologie

Falls Anwendungen abstürzen, bevor sie eine Meldung ins Log schreiben können, analysiert er den Speicherdump mit Hilfe der Debugging-Tools for Windows [2]. Damit das funktioniert, muss er vorher die passenden Symbol-Dateien zur Software installieren. Sie stehen für Windows und viele Microsoft-Programme zur Verfügung, bei Software anderer Hersteller häufig nicht. Hier sind die Anwender von quelloffenen Programm ganz offensichtlich im Vorteil.

Daneben können die Freunde freier Betriebssysteme etwas tun, was Windows-Anwendern versagt bleiben wird: Das System mit allen Komponenten sowie die Anwendungen aus den Quellen selbst übersetzen und zusammenstellen, wie es das Projekt Linux From Scratch (siehe Kasten “Linux-System im Eigenbau”) vormacht [3].

Wer das Selbstbauprojekt absolviert hat, durchschaut das System besser denn je. Mehr Transparenz gibt es vermutlich nur beim selbst Programmieren. Ein Windows From Scratch dagegen gibt es nicht. Der normale Anwender oder Systemadministrator bekommt auch den Windows-Quelltext niemals zu Gesicht.