LSB, die zweite
Anfang September hat die Free Standards Group Version 2.0 der Linux Standard Base veröffentlicht, die einen weiteren Meilenstein für die Entwicklung von Linux als Plattform für Enterprise-Anwendungen darstellt.
- Matthias Kranz
Die LSB ist eine Arbeitsgruppe der Free Standards Group (FSG). Letztere wiederum ist eine unabhängige, gemeinnützige Organisation, welche sich der Entwicklung und Vermarktung offener Standards verschrieben hat mit dem Ziel, den Einsatz und die Akzeptanz von Open-Source-Software (OSS) zu fördern. Zu den bekanntesten Mitgliedern zählen Hewlett-Packard, IBM, Intel, Dell, Sun und die Distributionshersteller Red Hat, Suse, Mandrake, Turbolinux und Debian. Die FSG unterstützt die Bemühungen der LSB durch die Organisation und Durchführung eines Zertifizierungsprozesses, der Distributionen und Applikationen als LSB-konform identifiziert.
Hauptziel der Linux Standard Base ist es, unter Linux einen Rahmen für Anwendungen zu definieren. Dieser soll garantieren, dass diese Anwendungen auf allen Distributionen, die sich standardkonform verhalten, ohne Rekompilierung lauffähig sind. Über diese Kompatibilität der Application Binary Interfaces hinaus definiert sie aber weitere Schnittstellen, die es insbesondere Independent Software Vendors (ISV) erleichtern soll, ihre Applikatio-nen plattformübergreifend zur Verfügung stellen zu können. Die Strategie der LSB ist grundsätzlich, neben der Erarbeitung einer eher theoretischen Spezifikation auch Testwerkzeuge und Beispielimplementierungen zur Verfügung zu stellen. Die Intention der LSB ist also ganz klar, eine Plattform weniger durch die Aufzählung bestimmter Pakete und deren exakten Versionen als viel mehr durch die Beschreibung ihres Funktionsumfangs zu definieren.
OSS und bestehende Standards
Entscheidend dabei ist, dass die LSB als Open-Source-Projekt agiert, das heißt, dass auf der einen Seite sämtliche Spezifikationen unter der GNU Free Documentation License und beigesteuerter Code als Open Source veröffentlicht werden und auf der anderen Seite jeder Interessierte seine Ideen, Kritik und Korrekturen einbringen kann. Die Arbeit erfolgt im Wesentlichen über Mailinglisten, und wie in vielen Community-Projekten gilt auch hier, dass man sich einlesen und die laufenden Diskussionen eine Weile verfolgen sollte, ehe man sich beteiligt.
Von Anfang an hat die LSB versucht, sich als Erweiterung beziehungsweise Ergänzung bestehender und seit langer Zeit etablierter Standards zu sehen. Neben der Referenzierung des System V Application Binary Interface, dessen leicht gewandelte Version unter Linux als ELF-Objektformat existiert, bezog man die so genannte Single Unix Specification (SUS) als stabilisierenden Unterbau ein. Es ging und geht also bei der LSB nicht darum, das Unix-Rad neu zu erfinden. Überhaupt weist die FSG immer wieder an unterschiedlichen Stellen darauf hin, dass die LSB nicht dazu bestimmt ist, Funktionen, Regeln und andere Vorgaben neu zu erfinden, sondern stattdessen bestehende, praxiserprobte Vorgehensweisen und die dazugehörigen Werkzeuge einheitlich zu definieren. Eine Anfang des Jahres verliehene Auszeichnung der ISO/IEC (International Organization for Standardization/ International Electrotechnical Commission) bestätigt die Qualität der Arbeit, die FSG gilt seitdem als anerkannter Linux-Spezifizierer.
LSB-konform entwickeln
Um die Arbeit von Entwicklern zu unterstützen, stellt das LSB-Projekt diverse Werkzeuge bereit. Unter anderem existiert eine Build-Umgebung in zwei unterschiedlichen Ausführungen, die beide LSB-Header-Dateien verwenden und gegen spezielle Bibliotheken linken. Der eine Ansatz richtet eine chroot-Umgebung (lsbdev-chroot) ein, der andere verwendet einen Wrapper für den Compileraufruf (lsbcc). Letztere Methode ist die einfacher und schneller anwendbare, da sie sich relativ einfach beispielsweise in configure-Skripte einbauen lässt: Ein CC=lsbcc ./configure reicht vielfach aus. In komplexeren Build-Umgebungen treten allerdings auch häufiger Probleme auf, weil die durch lsbcc erfolgten Transformationen wieder überschrieben oder umgangen werden.
In einer lsbdev-chroot-Umgebung hingegen ist es das Ziel, alle nicht konformen Elemente von vornherein auszuschließen. Braucht der Entwicklungsprozess trotzdem Funktionen des Restsystems, lässt sich diese seit Kernel 2.4 durch bind-Mounts zur Verfügung stellen. Dabei stehen dann Dateien in beiden Welten zur Verfügung. Die Einrichtung einer passenden chroot-Umgebung bedeutet sicherlich mehr initialen Aufwand als die Verwendung des oben genannten lsbcc. Allerdings muss man diesen in aller Regel nur einmal betreiben.
Für Entwickler wichtig ist, dass die LSB nur wenige Shared Libraries als vorhanden vorschreibt (siehe Kasten „Bibliotheksvorgaben“). Weitere benötigte Bibliotheken muss die Anwendung LSB-konform selbst, durch ein anderes Paket oder durch statisches Linken bereitstellen.
Bibliotheksvoraussetzungen
generisch: libdl, libcrypt, libz, libncurses, libutil, libpthread, libpam, libgcc_s
architekturspezifisch:
libm, libc, proginterp
Kommandos und Werkzeuge
Nicht nur für Entwickler von Anwendungssoftware, sondern für jeden Anwender und Administrator interessant ist natürlich, welche Werkzeuge man auf einem konformen System als LSB-gegeben voraussetzen darf. Die LSB stellt dazu eine recht ansehnliche Liste von Kommandos bereit, beschreibt aber das jeweilige Verhalten lediglich als Differenz zur referenzierten Single Unix Specification. Mit install_initd und remove_initd stehen zwei zusätzliche Befehle zum Management der init-Skripte zur Verfügung. Einige Kommandos (wie ar) oder aber Optionen werden wie in anderen Standards auch üblich als Deprecated markiert, um darauf hinzuweisen, dass sie in einer nächsten Version nicht mehr unbedingt unterstützt werden. Die Unterschiede in diesem Bereich zur SUSV3 beschränken sich auf minimale Abweichungen im Bereich der Anforderungen an Werkzeuge, die reguläre Ausdrücke verarbeiten oder mit dem so genannten Filename Globbing operieren.
Ganz wichtig ist das Kommando lsb_release als Ergänzung zum klassischen uname, mit dessen Hilfe sich beispielsweise herausfinden lässt, zu welcher LSB-Version die Distribution konform ist:
example% lsb_release -v
LSB Version: core-2.0-ia32:graphics-2.0-ia32 LSB-Konformität testen
LSB stellt eine Reihe von Testwerkzeugen bereit, die sowohl für Distributions- als auch für Applikationsentwickler bestimmt sind. lsbappchk eignet sich beispielsweise gut, um vor einer anstehenden Portierung eines Binaries eine erste Überprüfung durchzuführen. lsblibchk testet, ob die auf einem System vorhandenen Bibliotheken die korrekten Schnittstellen in der richtigen Versionen aufweisen. Mit cxxabichk lassen sich speziell C++-Implementierungen überprüfen. Neben den Testwerkzeugen erfolgte, auch mangels externer Aktivitäten in diesem Bereich, im Teilprojekt Application Battery die Überprüfung eines guten Dutzend Standardapplikationen wie Apache, um zum einen deren Standardtreue, aber zum anderen insbesondere auch die Anwendbarkeit und Stabilität der entwickelten LSB-Tools zu verifizieren. In diesem Bereich finden Interessierte auch komplexere Beispiele für LSB-konforme Anwendungen.
File System Hierarchy Standard
Bekannter als die LSB selbst ist der File System Hierarchy Standard (FHS), der definiert, an welcher Stelle im Dateisystem welche Komponenten eines Linux-Systems zu speichern sind. Wer sich den FHS genau ansieht, stellt dabei aber auch fest, dass er relativ wenige Elemente fest definiert und voraussetzt - viele andere Komponenten beschreibt er dagegen einfach als optional. Deshalb gibt die LSB vor, dass eine Anwendung diese zusätzlichen Abhängigkeiten stets selbst auf Erfüllung beziehungsweise Vorhandensein überprüfen und gegebenenfalls reagieren muss.
Bei der Verwendung des vom FHS definierten Orts zur Installation der Applikation respektive zur Speicherung von Daten kann es natürlich leicht zu Konflikten im Namensraum kommen. Unter Linux wurde deshalb die Linux Assigned Names and Numbers Authority (LANANA) etabliert, die sich um die Reservierung der zugehörigen Schlüsselwörter kümmert. So lässt sich beispielsweise in der Liste der registrierten Init-Skripte lesen, dass mysql für die gleichnamige Datenbank der Firma MySQL AB reserviert ist. Klassische Dienstnamen wie dhcpcd oder fetchmail und viele andere hat die LSB bereits reserviert. Weitere Namensräume existieren für Cron-Skripte und Pakete.
Paketierung der Anwendungen
LSB beschreibt lediglich das Red Hat Package Management (RPM) als Paketstandard, schließt alternative Paketformate allerdings nicht grundsätzlich aus. Sie definiert in diesem Fall lediglich, dass die Plattform in der Lage sein sollte, RPMs korrekt bearbeiten zu können und dass der alternative Mechanismus zum Management der Pakete zumindest LSB-Kommandos und Werkzeuge aufrufen sollte. Gerade im Bereich der Einrichtung von Systemdiensten mit ihren Konfigurationsdateien und vor allem Start- und Stoppskripten decken dedizierte Regeln daher relativ viel ab. So schreibt eine zum Beispiel vor, welche Argumente ein Init-Skript auf jeden Fall verarbeiten muss und welche Statuswerte bei entsprechender Abfrage erlaubt sind. Sehr wichtig in diesem Zusammenhang sind die spezifizierten Kommentare im Header eines Init-Skripts, die install_initd während der Installation auswertet, um mögliche Abhängigkeiten zu anderen Diensten erkennen und das Skript korrekt einbinden zu können.
Die Tatsache, dass die LSB das Verhalten und die Funktionen eines Systems beschreibt und spezifiziert, hat gewisse Vorteile gegenüber anderen Standardisierungsverfahren. Unabhängige Softwarehersteller sind damit weiterhin in der Lage, zusätzliche Funktionen auf Basis einer beschriebenen Plattform zu entwickeln und als Mehrwert anzubieten.
Neuerungen in LSB 2.0
Neben dem schon länger geforderten Application Binary Interface für C++ unterstützt LSB 2.0 nun neben Intels IA64 auch die 64-Bit-Architekturen von AMD und PowerPC. Gegenüber LSB 1.3, die auf Version 2 der Single Unix Specification (SUS) aufsetzt, bildet nun SUSV3 die Basis. Um der ständig wachsenden Informationsmenge im Standard zu genügen und sich auch für die Zukunft zu wappnen, überarbeitete man außerdem die Dokumentenstruktur. Statt einem einzigen monolithischen Dokument besteht der Standard nun aus einer Vielzahl von Einzeldokumenten, die für den Leser zusammengefasst aufbereitet wurden. Den Interessierten aber bietet die neue Struktur die Möglichkeit, bestimmte Funktionen eben nur gegen Teile der Gesamtspezifikation zu entwickeln.
Außerdem wurde diese Aufteilung auch deshalb notwendig, weil es innerhalb der LSB zu einer schwierigen Diskussion bezüglich der C++-ABI-Spezifikation kam, die auch den Zeitplan erheblich durcheinander brachte. Letztendlich fand man den Kompromiss, LSB 2.0 im jetzigen Status zu veröffentlichen und ohne die Teilspezifikation zu C++ an die ISO/IEC zu übergeben.
Innerhalb der LSB existiert ein spezielles Teilprojekt LSB Futures, das sich mit der Zukunft und der Erweiterung der jetzigen Spezifikation beschäftigt. Dazu gehört im Speziellen die Analyse bestehender Implementierungen, sowohl kommerzieller Applikationen, deren Abhängigkeiten zu bislang nicht erfassten Funktionen, als auch von Distributionen. Erweiterungsvorschläge können dort über eine Mailingliste eingebracht und diskutiert werden. Erscheint eine Standardisierung sinnvoll, stuft das Projekt das Thema als Kandidat ein. So gehören beispielsweise OpenLDAP und SSL zu den Kandidaten und könnten eventuell schon in der nächsten LSB-Version, die aller Voraussicht nach 3.0 heißen wird, enthalten sein.
Fazit
Im Bereich der Distributionen hat sich die LSB inzwischen als De-facto-Standard etabliert, weil auch die großen Distributionshersteller erkannt haben, dass es nicht reicht, eine Version zur Enterprise-Version zu deklarieren und statt alle zwei Monate nur noch einmal im Jahr zu veröffentlichen. Stattdessen brauchen die ISVs eine Laufzeitumgebung mit spezifiziertem Verhalten, die ihren Kunden einen wesentlichen Vorzug der Linux-Welt, die freie Wahl der Distributionsplattform, garantiert. Jetzt muss eigentlich nur noch der nächste Schritt vollzogen werden und die zentralen, gerade auch kommerziellen Applikationen ihrerseits den Zertifikationsprozess erfolgreich durchlaufen. Außerdem erinnert ja nicht nur Microsoft durch geschicktes Marketing daran, dass gerade die zerklüftete Welt der Unix-Derivate ein warnendes Beispiel sein sollte - auch die Kunden und Interessenten drängen auf übersichtliche und vor allem praxisorientierte Standards.
Matthias Kranz
arbeitet als Senior Consultant und Leiter Presales für die ASDIS Software AG in Berlin und beschäftigt seit 1993 mit Gnu/Linux und Open-Source-Software.
Literatur
[1] Mats Wichmann, Stuart Anderson: The LSB: The Road to Linux Compatibility in Proceedings of the Linux-Kongress 2003
iX-TRACT
- Bei der Linux Standard Base (LSB) handelt es sich um eine Arbeitsgruppe der Free Standard Group, die sich der Entwicklung und Propagierung offener Standards verschrieben hat.
- LSB will einen Rahmen für Anwendungen definieren, der es ISVs erleichtert, ihre Applikation auf das freie Betriebssystem zu portieren.
- Ziel ist, Linux eine Diversifizierung trotz offener Standards zu ersparen, wie sie in der Vergangenheit den Unix-Derivaten den Weg auf den Desktop verbaute.
- Neben den Festlegungen unterstützt eine Reihe von Werkzeugen die Entwickler bei der Erstellung LSB-konformer Programme.
(avr)
