Infrastruktur. Dr.-Ing. Matthias Sand und Dipl.-Inf. Stefan Potyra

Transkript

1 Infrastruktur Dr.-Ing. Matthias Sand und Dipl.-Inf. Stefan Potyra Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg SS 2009 Infrastruktur 1/

2 Motivation Situation In der Regel entwickeln viele Entwickler eine Linux-Distribution gemeinsam. Ihre Arbeit muss koordiniert werden. Ebenso verwenden viele Benutzer eine Distribution. Ihr Feedback muss die richtigen Entwickler erreichen. Folge Eine Infrastruktur, die dies ermöglicht, wird benötigt. Infrastruktur 2/

3 Überblick Infrastrukturaspekte Organisationsstrukturen Archivverwaltung ( Vom Quellpaket bis zum Mirror ) Releasezyklus Qualitätssicherung Koordination vieler Entwickler Community -Aspekte Infrastruktur 3/

4 Organisationsstrukturen Relevante Fragestellungen Wer darf welches Paket modifizieren? Wer betreut welche Infrastrukturdienste? Wer koordiniert welchen Bereich und stellt Zielvorgaben? Wie bekommt jemand eine Rolle übertragen? Wie werden Konflikte gelöst? Kurz: Wer hat welche Rolle und wer hat wo das Sagen?!? Infrastruktur 4/

5 Organisationsstrukturen (2) Beispiel Debian Constitution legt Struktur und Rechte fest, Unterscheidung nach Entwickler, DPL (Debian Project Leader), Technical Comittee, Delegierte Gremien, sagt implizit, dass Entwickler für ihre Pakete (alleine) verantwortlich sind Paket gehört einem Entwickler, generell demokratische Struktur (Abstimmungen, Wahlen),... und in der Praxis? Infrastruktur 5/

6 Organisationsstrukturen (3) Delegierte Gremien Beispiel Debian (1/2) DSA Serververwaltung, Accounts, Keyring, FTP-Master New-Queue, Archivkonsistenz NBS (Not built from Source), Source-, Binary-New, Wartung der Archivmanagement-Software, (direkter) Zugang zum Haupt-Archiv. Infrastruktur 6/

7 Organisationsstrukturen (4) Delegierte Gremien Beispiel Debian (2/2) Debian... -Release Release-Management, binnmus (Rebuilds für Bibliotheksänderungen), -Frontdesk Bewerbungen neuer Entwickler, Debian-Maintainer, -QA Betreuen verwaiste Pakete, Buildd Maintainers Betreuung der Buildds, Signieren von Binärpaketen, Infrastruktur 7/

8 Organisationsstrukturen (5) Beispiel Ubuntu (1/2) Diktatur, Mark Shuttleworth als sabdfl, keine bindende Verfassung oder Ähnliches, keine feste Zuordnung zwischen Paket und Maintainer, aber Aufteilung in main wichtige Pakete, Hauptentwickler, universe Community-betreute Pakete ( MOTU ), restricted wichtige unfreie Pakete, Hauptentwickler, multiverse unfreie Pakete, Community-betreut. Infrastruktur 8/

9 Organisationsstrukturen (6) Beispiel Ubuntu (2/2) Firma Canonical im Hintergrund treibt hauptsächlich Ubuntu-Entwicklung voran, beschäftigt die meisten Hauptentwickler, entwickelt und wartet Launchpad -Infrastruktur. Technical Board hat letztes Wort bei technischen Fragen, kann neue Entwickler aufnehmen. Community Council klärt Differenzen bei Streitfragen in der Community, kann Ubuntu Mitgliedschaft vergeben. Infrastruktur 9/

10 Organisationsstrukturen (7) Delegierte Gremien Beispiel Ubuntu Ubuntu-Archive: analog zu FTP-Master, {Ubuntu,MOTU}-Release: Release-Management, Buildd-Maintainer: Wartung der Buildds, MOTU-Council: Ernennen Community-Entwickler, empfehlen Hauptentwickler, Ubuntu-Security, MOTU-Swat: Security Updates,... Infrastruktur 10/

11 Vom Quellpaket bis zum Mirror Ausgangspunkt Upstream entwickelt Software, Paketverwalter paketiert/aktualisiert Software. Was passiert nun? Infrastruktur 11/

12 Vom Quellpaket bis zum Mirror (2) Beispiel Debian Paketverwalter... erstellt Quellpaket, erzeugt Binärpaket für eine Architektur, signiert.changes-datei (Ticket), lädt Paketdateien und.changes-file auf dedizierten Server incoming (mittels anyomem FTP). Infrastruktur 12/

13 Vom Quellpaket bis zum Mirror (3) Quellpaket liegt auf Server Debian Archive Kit (dak) übernimmt die Steuerung. Cron-Job überprüft Signaturen mit Keyring a, Cron-Job überprüft, ob diese Version aktueller als eine im Archiv vorhandene, Cron-Job überprüft, ob passende Quellen vorhanden sind (entweder im Archiv oder als Teil des Uploads), Quellpaket oder ein Binary neu New-Queue, Bearbeitung von Hand, andernfalls Kopieren des Quellpakets ins Zentralarchiv, Installation mitgelieferter Binärpakete ins Zentralarchiv, Aktualisieren der Buildd-Datenbank. a eine Kopie des Keyrings ist in dem Paket debian-keyring bzw. debian-maintainers zu finden. Infrastruktur 13/

14 Exkurs: Buildds Automatisches Bauen Probleme Mehrere Architekturen werden unterstützt, aber Entwickler hat in der Regel nicht für jede Architektur einen passenden Rechner. Ein nachvollziehbarer Weg, wie Pakete gebaut werden sollen, wird benötigt. Lösung Infrastruktur für automatisierten Bauvorgang auf den Buildds. Infrastruktur 14/

15 Exkurs: Buildds Automatisches Bauen (2) Problemstellungen Wer darf den Dienst nutzen? (Authentifizierurng) Was passiert, wenn das Bauen fehlschlägt? Welche Daten werden benötigt? (Datenbank) Buildd-Datenbank wanna-build Enthält Build-Status, Logs, Ist das Paket baubar? (= Bau-Abhängigkeiten in korrekter Version vorhanden), Priorität, welche Buildds mit welchen Architekturen gibt es, Overrides, Packages-Arch-Specific. Infrastruktur 15/

16 Vom Quellpaket bis zum Mirror (4) Quellpaket ist im Archiv... Kann das Paket für eine Architektur gebaut werden, reiht wanna-build es in eine Warteschlange ein, Binärpakete für Architektur werden auf Buildd gebaut, Buildd-Maintainer signiert.changes-file der Binaries und lädt die Paketdateien nach incoming, dak erkennt, dass zu den Binaries ein passendes Quellpaket existiert, und akzeptiert die Binaries, dak installiert die Binaries ins Zentralarchiv. Infrastruktur 16/

17 Vom Quellpaket bis zum Mirror (5) Letzte Schritte Bisher: Cronjob hat Quell- und Binärpakete ins Zentralarchiv installiert. Cron-Job versendet daraufhin Mirror-Pulse, Haupt-Mirrors synchronisieren sich mit Zentral-Archiv, weitere Spiegelserver können sich mit Haupt-Mirrors synchronisieren,... Benutzer installieren/aktualisieren Paket. Infrastruktur 17/

18 Release Anforderung Eine Distribution sollte... leicht durch die Benutzer installierbar sein, aktuelle Software enthalten, möglichst fehlerfrei sein, aufeinander abgestimmt sein. Infrastruktur 18/

19 Release (2) Idealvorstellung Eine Distribution kann jederzeit veröffentlicht werden. Hauptproblem Inkonsistenzen im Softwarearchiv. Beispiel: Neue Version einer Software macht Abhängigkeiten kaputt. Infrastruktur 19/

20 Release (3) (Triviale) Erkenntnis Release-Management ist erforderlich! Unterschiedliche Strategien Release when Ready, also wenn alle wichtigen Fehler behoben wurden (Debian), Release zu einem bestimmten Zeitpunkt (Ubuntu), Releases von Teilen nach einer der obigen Strategien, Mischformen. Infrastruktur 20/

21 Release-Management Beispiel Debian (1/2) Aufteilung des Archivs in unstable: Einstiegspunkt für neue Versionen, testing: (hoffentlich) in sich konsistente Variante von unstable, Version migriert automatisch von unstable nach testing, sofern... mindestens 14 Tage verstrichen sind, keine aktuellere Version in unstable vorliegt, keine Inkonsistenzen auftreten (reverse dependencies!), keine schwerwiegenden Fehlerberichte vorliegen (RC-Bugs). Infrastruktur 21/

22 Release-Management (2) Beispiel Debian (2/2) Version wird aus Testing gelöscht, wenn... Inkonsistenzen auftreten, RC-Bugs vorliegen. Release-Team koordiniert, wenn mehrere Pakete zusammen migrieren müssen (Transitions), kann manuell eingreifen. Infrastruktur 22/

23 Release-Management (3) Problematik Änderung an wichtigen Paketen kann Inkonsistenzen bei vielen Paketen hervorrufen (Beispiel libc5 libc6), geänderte API an wichtigen Paketen erfordert Anpassungen an vielen abhängigen Paketen, bestimmte Pakete müssen für Release funktionsfähig und Teil der Distribution sein: essentiell notwendige Pakete (Shell, Kern, Compiler,... ), Pakete zum Erstellen von Installationsmedien, Installer, populäre Pakete. Infrastruktur 23/

24 Release-Management (4) Lösung: Beispiel Debian Freezes: Migration von Paketgruppen von unstable nach testing wird unterbunden, Release-Team kann Ausnahmen (z.b. Bug-Fixes) bestätigen, Entwickler sind angehalten, keine neuen Versionen nach unstable zu bringen. Reihenfolge Freezes 1 essentielle Toolchain (build-essential), 2 sonstige Toolchain (debhelper, cdbs,...), 3 Bibliotheken, 4 Installer, 5 restliches Archiv. Infrastruktur 24/

25 Qualitätssicherung Ziele Ist alles in Ordnung? Probleme feststellen. Wer ist Schuld? Probleme zuordnen. Wie kaputt ist ein Paket? Probleme klassifizieren. Wie kann ein Fehler behoben werden? Entwickler muss Fehler reproduzieren können. Es ging doch schon mal! Regressionen vermeiden. Infrastruktur 25/

26 Qualitätssicherung (2) Qualitätssicherung in Debian Package Tracking System Zustand der Pakete, Build Logs, Version in Testing,... Bug Tracking System Bug Reports durch Benutzer und Entwickler, Zuordnung zu Paketen und Versionen, Klassifikation der Bug Reports, Umgebung (rdepends, Architektur, Kernelversion,... ), Fehlerbeschreibungen,... Infrastruktur 26/

27 Qualitätssicherung (3) QS-Tools für in Debian Paketierung pbuilder, sbuild, lintian, piuparts,... Bug-Reports reportbug, reportbug-ng, bts,... Infrastruktur 27/

28 Qualitätssicherung (4) QS-Maßnahmen Rebuild-Tests des gesamten Archivs, Archivweite piuparts-tests, Mass-Bug-Filings nach speziellen, automatisierten Tests, Installationsberichte, Tools zur Konsistenzprüfung des Archivs (Teil von dak), Bug-Squashing-Parties, Popularity Contest,... Infrastruktur 28/

29 Koordination von Entwicklern Koordinationshilfen Mailinglisten, IRC, Wikis, Konferenzen, Teams für bestimmte Pakete, Versionsverwaltung, Bug Reports,... Infrastruktur 29/

30 Community Problem In der Free- und Open-Source Software-Welt verwischen die Grenzen zwischen Entwicklern und Benutzern! Infrastruktur 30/

31 Community (2) Community-Aspekte Bug Reports, Patches, Möglichkeit Entwickler zu werden, Sponsoring, Übersetzungen, Öffentlichkeitsarbeit, Dokumentation, Ortsvereine, Installationsparties, Benutzer helfen anderen Benutzern,... Infrastruktur 31/