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.