Es gibt mehrere Probleme, die sich aus diesen Ansätzen ergeben und in zukünftigen Versionen vermieden werden sollten:

Transkript

1 Arbeitspapier zur Basisdistribution (zweite überarbeitete Version vom ) von Alexander Dubielczyk 1. Die bisherige Situation Die Programme der bisherigen Arktur-Distributionen entstammen mehrern unterschiedlichen Quellen. Dazu zählen neben (von SuSE und Slackware stammenden) Paketen individuell übersetzte Bestandteil. Diese sind in Form von tgz-archiven organisiert, die zum Installationszeitpunkt auf dem System entpackt werden. Ein Paketmanagementsystem wie z.b. rpm oder dpkg wird nicht verwendet. Teilweise sind spezielle Anpassungen für Arktur in die Basispakete eingeflossen. Es gibt mehrere Probleme, die sich aus diesen Ansätzen ergeben und in zukünftigen Versionen vermieden werden sollten: 1. Paketmanager: Es existiert keine Verwaltung für Abhängigkeiten von Programmpaketen und deren unterschiedlichen Versionen. U.a. werden speziell automatisierte Update- und Installations-Prozesse dadurch erheblich erschwert. 2. Aufwand bei der Paketpflege und Aktualisierbarkeit: Die Pakete des Basis-Systems müssen speziell und einzeln für Arktur angepasst werden. Es können (meist) keine fertigen Pakete problemlos aus anderen Distributionen übernommen werden. Jedes einzelne Programm muss durch die Arktur-Entwicklergemeinschaft gepflegt und vor allem auf Sicherheitslöcher hin überwacht werden. 3. Erweiterbarkeit des Systems: Arktur lässt sich nur umständlich um zusätzliche Funktionen erweitern, die über den vorbestimmten Umfang hinausgehen. Zusätzliche Programme und Tools müssen meist manuell auf dem System übersetzt und angepasst werden. Das wird wiederum erschwert durch veraltete oder inkompatible Komponenten (z.b. Libraries). 2. Anforderungen an zukünftige Versionen Zukünftige Arktur-Versionen sollten die oben dargestellten Probleme von vorne herein und möglichst konsequent vermeiden. Um den Aufwand für die Arktur-Entwicklung in einem überschaubaren Rahmen zu halten, sollten diejenigen Bestandteile der Arktur-Distribution, die auch in Standard-Distributionen enthalten sind, möglichst ohne Änderungen (und damit Arbeitsaufwand) übernommen werden. Arktur-spezifische Anpassungen sollten genau wie speziell angepasste Programmpakete im Paketformat der verwendeten Basisdistribution bereitgestellt werden. Um die Rate der Neuinstallationen klein zu halten, sollte auf lange Release-Zyklen und flexible Updatemechanismen bei Wahl der Basisdistribution Wert gelegt werden. Neben den technischen Anforderungen an die Basisdistribution sollte außerdem noch die lizenzrechtliche Situation beachtet werden. Es erscheint sinnvoll sich nicht in direkte oder möglicherweise zukünftige lizenzrechtliche Abhängigkeiten von Herstellern zu begeben. Da der Trend bei den meisten laufenden Schulserver-Projekten dahin geht, auch direkt Linux als Client-Plattform zu integrieren oder in Form eines Linux Terminalservers bereitzustellen,

2 sollte die verwendete Basisdistribution auch vor dem Hintergrund ausgewählt werden, dass langfristig auf dieser Basis eine automatisierte Client- bzw. Terminalserver-Installation ein Teil von Arktur werden könnte. Eine einheitliche Basisdistribution für Clients und Server wäre sicher wünschenswert, eine bekannte Distribution hätte den Vorteil eines höheren Bekanntheitsgrades bei den Benutzern. Ein weiteres zu beachtendes Auswahlkriterium betrifft die Kooperation mit anderen Schulserverprojekten. Um eventuell Lösungsansätze einfach aus anderen Projekten in Arktur integrieren zu können (und umgekehrt), wären möglicherweise Absprachen bezüglich der Basisdistribution mit anderen interessierten Projekten sinnvoll. Ob solch ein Interesse besteht müsste zunächst ausgelotet werden. 3. Auswahl der Distribution Die oben genannten Punkte sind mehr als einmal Thema in den Mailinglisten schandeveloper und arktur-team gewesen. Insgesamt wurden meist 3 Lösungsansätze für die Wahl der Basis-Distribution diskutiert. Hinzu kommen weitere Möglichkeiten, die erst im Verlauf der Diskussion im Vorfeld des 2. Arktur-Treffens in Bonn vorgetragen wurden. 1. Arktur wird als Add-On unabhängig von der zugrundeliegenden Distribution entwickelt 2. SuSE-basierte Basisdistribution ( consumer -SuSE) 3. Debian- bzw. Knoppix-basierte Basisdistribution 4. Eisfair 5. Gentoo Arktur als Add-On Obwohl dieser Ansatz eine gewisse Flexibiltät und Unabhängigkeit gegenüber der verwendeten Basisdistribution bietet, bringt er doch einige Nachteile mit sich. Leider sieht es in der Praxis so aus, dass sich selbst die großen Distributionen in mehreren Details unterscheiden. Für die Arktur-Entwicklung würde die Anpassung eines Add-On-Systems an verschiedene Distributionen einen deutlich höheren Arbeitsaufwand bedeuten. Auf der anderen Seite sollte der Kontakt des typischen Anwenders zum darunterliegenden Linux- System möglichst gering sein. Daher fallen auch die Vor- und Nachteile der einen oder anderen Distribution, die sich für den Administrator bieten würden, weniger ins Gewicht. Die Gewinne eines solchen Ansatzes rechtfertigen den nötigen Aufwand für die Entwicklung und Pflege wahrscheinlich nicht. SuSE Für ein SuSE-basiertes System spricht die Tatsache, dass es vielen Leuten aus dem Arktur- Umfeld bereits als Distribution bekannt ist und an einer größeren Anzahl an Schulen auch eingesetzt wird. Genau wie bei Punkt 1 ist jedoch zu sagen, dass die Basisdistribution für den Endanwender (im Gegensatz zu den Entwicklern!) in der Regel - was den Server betrifft - eine untergeordnete Rolle spielen sollte. Die Bedienung des Servers muss im Regelfall ohne Kenntnisse über das darunterliegende System möglich sein. Anders stellt sich die Situation

3 bei gleichzeitigem Einsatz als Client dar. Der hohe Bekanntheitsgrad und die große Verbreitung der SuSE-Produkte würde bei Verwendung der grafischen Oberflächen und deren Standard-Einstellungen dieser Distribution sicherlich zu geringeren Einstiegsproblemen als bei anderen Lösungen führen. Bei Verwendung von SuSE müssen jedoch einige Dinge beachtet werden: Die consumer -Versionen dieser Distribution haben mit ca. 4 Releases pro Jahr sehr kurze Release-Zyklen. Erschwerend kommt hinzu, dass oft größere Änderungen zwischen den Releases erfolgen, die mehr oder weniger umfangreiche Änderungen an den Schulerserver spezifischen Bestandteilen nötig machen würden. Die harten Übergänge zwischen den Releases führen außerdem dazu, dass meist keine fertigen Programmpakete aus neueren Versionen in ältere Systeme übernommen werden können. Auf der anderen Seite werden für ältere Releases kaum neue Versionen von einzelnen Programmen bereitgestellt. Bei Sicherheitslöchern werden häufig statt aktualisierter Programmversionen nur rückportierte Patches angeboten. Der Support-Zeitraum (Stichwort: Sicherheitsupdates) für eine Version wäre zwar vermutlich lang genug, aber dennoch zeitlich begrenzt. Die lizenzrechtliche Situation des SuSE-eigenen Administrations- und Installationssystem YaST ist entgegen der Darstellung in älteren Versionen dieses Dokumentes unkritisch. YaST steht mitlerweile unter der GPL, könnte also theoretisch für Arktur genutzt werden. Entsprechende Entwicklerdokumentationen sollen sich in Vorbereitung befinden. Überlegenswert im Zusammenhang mit einer SuSE-Basis könnten Kooperationen mit dem SLSS Projekt sein, welches eine recht offene Entwicklungspolitik anstrebt. Der SLSS ist dabei ein sauber getrennter Aufsatz auf die Enterprise-Server-Serie (SLES) der Firma SuSE. Debian/Knoppix Eine Debian-basierte Lösung könnte eine weitere gute Ausgangsbasis für eine neue Arktur- Version sein. Neben langen Release-Zyklen, einem mächtigen Paketmanager und extrem komfortablen Update-Mechanismen bietet das System lizenzrechtlich einen großen Spielraum für Änderungen und Weiterverwendung. Problematisch stellt sich die Situation des stable -Zweiges der Distribution dar, der aufgrund der langen Release-Zyklen technisch inzwischen stark veraltet ist und alleine keine Grundlage für ein aktuelles System darstellen kann. Auffrischung des Systems mit Paketen des unstable -Zweiges ist zwar nicht völlig gefahrlos, sollte aber möglich sein. Gute Vorarbeit wird hierbei zum Beispiel durch Knoppix geleistet. In Anlehnung an die Paket- Zusammenstellung von Knoppix (oder direkt aufbauend auf Knoppix) ließe sich ein aktuelles System zusammenstellen, welches sowohl server- als auch clientseitig stabil und auch extrem erweiterbar wäre. Ein Nachteil gegenüber SuSE dürfte sich im Bereich des Installationssystems finden. Während SuSE einen ausgereiften Installer mit guter Hardware-Erkennung liefert, steckt der Installer der kommenden Debian-Release noch in tief in der Entwicklung. Die Arbeit in diesem Bereich wird maßgeblich von den Entwicklern des norwegischen Skolelinux-Projekts vorangetrieben und lässt gute Ideen und flexible Ansätze erkennen. Möglicherweise könnte hier eine Kooperation mit dem Skolelinux-Projekt von beiderseitgem Interesse sein. Einfacher könnte man die zukünftige Installationsroutine auch auf Basis eines angepassten Knoppix-Systems aufsetzen. Zu diesem gibt es inzwischen sehr umfangreiche

4 Praxiserfahrungen. Speziell die vielen positiven Berichte zur Hardware-Erkennung, die im Netz zu finden sind, sprechen für sich. Eisfair Im Gegensatz zu den großen Distributionen handelt es sich bei Eisfair um eine gewollt schlanke und übersichtliche Distribution. Die großen Pluspunkte liegen laut Aussagen der Entwickler in der einheitlichen Konfigurationsschicht, die eine konsequent einheitliche Administration der einzelnen Pakete ermöglicht. Ein selbst entwickelter Paketmanager ist in Form eines Shell-Skriptes vorhanden, wobei ein Vergleich zu den Fähigkeiten von z.b. rpm oder dpkg noch durchgeführt werden müsste. Die Diskussion in der Liste schan-developer lässt erkennen, dass die Initiatoren des Eisfair-Projekts großes Interesse an einer Kooperation hätten. Der Vorteil für das Arktur-Projekt läge in dem sehr kurzem Draht zu den Distributions-Betreuern und der Möglichkeit, Eigenschaften und Entwicklungsziele der Projekte aufeinander abzustimmen. Die Zahl der Projektbeteiligten wächst stetig und der Erfolg des von denselben Entwicklern stammenden FLI4L-Projektes stellt eine bemerkenswerte Referenz dar. Schwierigkeiten ergeben sich wahrscheinlich durch die bisher nicht integrierte automatische Hardware-Erkennung in Eisfair, die für einen modernen Schulserver sehr wichtig sein wird. Ebenso ist fraglich, ob sich der zwar wachsende aber bisher begrenzte Paketumfang des Projektes negativ auf Flexibilität und Ausbaufähigkeit des Systems auswirken würde. Individuelle Erweiterungen des Systems durch dessen Benutzer müssten sich auf die verfügbaren Pakete des Projektes beschränken. Trotz überaus positiven Zukunftseinschätzungen seitens der Eisfair-Entwickler, muss die Frage gestellt werden, ob die (derzeit noch?) begrenzten Kapazitäten des Projekts in der Lage wären die Verfügbarkeit von Updates (vor allem Sicherheitsupdates) und benötigten Softwarepaketen sicherzustellen. Gentoo Die Einschätzung der Eignung von Gentoo erscheint an dieser Stelle mangels Erfahrung des Schreibers mit diesem System und der etwas unübersichtlichen Diskussion über das Thema nur eingeschränkt möglich. Ergänzende oder verbessernde Kritiken zu diesem Punkt sind besonders erwünscht! Der eigentliche Vorteil der Gentoo liegt in ihrer Eigenschaft als Source-Distribution. Statt fertiger Binär-Pakete werden primär Source-Pakete zur Verfügung gestellt, die ihrerseits erst auf dem Zielsystem übersetzt und dadurch optimal an das Zielsystem angepasst werden. Dieser Weg ist natürlich für einen Schulserver zunächst ausgeschlossen, da schon der Zeitbedarf für die Übersetzung aller zu installierender Software extrem hoch wäre. Auf der anderen Seite besteht die Möglichkeit Gentoo-Binärpakete zu generieren und diese für Arktur auf einem zentralen FTP-Server zur Verfügung zu stellen. Damit ergäbe sich die Möglichkeit die Software-Pakete optimal für den Einsatz mit Arktur zu konfigurieren und sehr schnell Software-Neuerungen einzelner Softwarepakete zu übernehmen, ohne lange auf den Paket-Maintainer einer Distribution warten zu müssen. Andererseits liegt damit die Betreung aller Pakete wieder in Händen des Arktur-Projekts und stellt damit besondere Anforderungen an Entwicklungs- und Betreuungsresourcen. 3. Danke :-) Dieser Text entstand als Zusammenfassung der Diskussionen von Teilnehmern der schan-

5 developer und arktur-team Mailinglisten. Ich danke an dieser Stelle allen Beteiligten für konstruktive Diskussionsbeiträge und Vorschläge zur Verbesserung dieses Dokuments!