Das Fedora Projekt
quo vadis Red Hat
Enrico Scholz
Unix-Stammtisch 28. Oktober 2003 Inhalt
Begriffe Red Hat Linux fedora.us Paketfluss Der Zusammenschluss Das Fedora Project Core + Extras + ... Paketmanagement Zeitplan Mitwirkungsmöglichkeiten Begriffe (1)
Red Hat (RH) Unternehmensbezeichnung
Red Hat Linux (RHL) Linuxdistribution abgelöst durch Produkte des Fedora Projects
Red Hat Enterprise Linux (RHEL) Linuxdistribution für Unternehmenseinsatz Ausprägungen für unterschiedliche Zielgruppen: WS, Professional WS, ES, AS
Fedora Kopfbedeckung Verwendet in RH Logo ("shadow man") Begriffe (2)
Fedora Linux (fedora.us) von Red Hat unabhängiger Anbieter von RPMS Ziel: hochqualitative und aktuelle Pakete
Fedora Project von Red Hat gesponsert, von der "Community" unterstützt Ziele: freies Betriebssystem Übernahme entwickelter Technologien in RHEL Produkte
Fedora Core, Fedora Legacy, Fedora Extras... Produkte des Fedora Projects Begriffe (3)
Paketqualität Maßstab, inwieweit die Zielsetzung nach minimalen, aber umfassenden Abhängigkeiten funktionierenden Updatepfaden gutmütigem Verhalten in abweichenden Umgebungen Standardkonformität (FHS, LSB, freedesktop) leichter Konfigurierbarkeit der installierten Daten guter Wartbarkeit des .spec-Files/der Patches vom Paket erfüllt wird
Paket/RPM Verpackungseinheit für Software gebaut aus src.rpm, bestehend aus .spec-Datei Quellen Patches Red Hat Linux (1)
Erstveröffentlichung: 31.Oktober 1994, v0.9 "Halloween" Version 1.0 "Mother’s Day" im Mai 1995 Details: http://fedora.redhat.com/about/history/ relativ offen (ISOs, öffentlicher Bugzilla, rawhide) vollständig GPL mp3-Player: nur gegen Lizenzgebühr ($60.000) auslieferbar -> Verlust des GPL Status von RHL ca. 6 monatliche Releasezyklen ausgedehnte Betatests
Probleme: stetig wachsende Anzahl potentieller Pakete begrenzte Ressourcen (Entwickler) Sitz von Red Hat in USA: Softwarepatente und DMCA Red Hat ist AG -> keine Experimente mit Legalität Boxen-Verkauf lohnt sich wirtschaftlich nicht Red Hat Linux (2)
Auswege aus Paketarmut: Red Hat "contrib" oft bescheidene Qualität Pakete nicht vertrauenswürdig keine Infrastruktur: einfach nur Upload
Powertools loose, nicht besonders gepflegte Extra-CD zu rufschädigend und ressourcenbindend -> Wegfall mit RHL 7.2
rhcontrib.bero.org Mitte 2001 vom damaligen RH Entwickler Bernhard Rosenkränzer ins Leben gerufen Ziel: besseres Red Hat "contrib" Aber: kein Sicherheitskonzept, keine offizielle Unterstützung seitens RH Anfang 2002 aufgegeben Red Hat Linux (3)
Auswege aus Paketarmut: 3rd Party Repositories freshrpms.net (Matthias Saou), atrpms.physik.fu-berlin.de (Axel Thimm), dag.wieers.com (Dag Wieers) wegen DMCA meist in der freien Welt Ein-Mann-Paketfabriken nicht offen für andere Anbieter schnell & flexibel, aber nur inoffizielle Standards und interne QA fedora.us (1) gegründet im November/Dezember 2002 von Warren Togami (Informatikstudent an Universität von Hawaii)
Ziel: 3rd party repository mit Fokus auf Qualität und Sicherheit offizielle Richtlinien offen für jedermann erste vier Monate: Diskussion über Regeln für Paket-Namen: Koexistenz mit RHL Paketen -> RHL Paket hat stets Vorrang Updatepfad unter Vermeidung von Epoch-Erhöhung Spezialfall alphanumerische/CVS Versionierung kurz und einfach Ergebnis: %name-%version-0.fdr.0.%alphatag.%releasetag z.B. "aalib-1.4.0-0.fdr.0.8.rc5.rh90" für aalib-1.4.0rc5 Details: http://www.fedora.us/wiki/PackageNamingGuidelines fedora.us (2) unbequeme Entscheidungen Explizites "Epoch: 0" und Epoch-Tag in versionierten Abhängigkeiten z.B. "Requires: gtk2 >= 0:2.2" Abschreckung von Autoren anderer Repositories
Probleme: Hawaii ist US Bundesstaat Theoretisch: separate und eigenständige "freeworld" Server mit minimalen Paketsets Erfüllung von Abhängigkeiten durch Dummy-Libraries im Hauptrepository (z.B. libdvdcss fake) Praktisch: Ignorieren des Problems (bis zum Zusammenschluß mit RH) Versuche für Logo gescheitert:
http://people.auc.ca/tack/files/fedora-logo.png ;) fedora.us (3)
Kommunikation Bugzilla (https://bugzilla.fedora.us) Mailinglisten IRC (#fedora auf freenode.net) Wiki (http://www.fedora.us/wiki/) fedora.us Paketfluss (1)
Erstveröf− fentlichung
Annonciert durch Bugzilla Fehlerreport GPG signiertes Paket Bereitstellung im WWW-/FTP-Space des Autors fedora.us Paketfluss (2)
Erstveröf− fentlichung QA
Sicherheitschecks: Vergleich mit Upstream-Quellen Überprüfung eventueller Patches GPG-Signatur des Paketes Allgemeine Überprüfung des .spec-Files Funktionalitätstest rpmlint Details: http://www.fedora.us/wiki/QAChecklist fedora.us Paketfluss (3)
Erstveröf− fentlichung
Korrektur QA
Wieder: GPG signiertes Paket Bereitstellung in Web-/FTP-Space des Autors fedora.us Paketfluss (4)
Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur)
GPG-signiertes OK von zwei QA-Testern Ziel: automatisierter Build anvisiertes Werkzeug: "mach" (http://thomas.apestaart.org/projects/mach) in vserver-Umgebung (http://linux-vserver.org) tatsächlich: nur manueller Build in vserver fedora.us Paketfluss (5)
Verifikation durch Autor
Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (6)
Repository Verifikation durch Autor
Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (7)
Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) fedora.us Paketfluss (8)
Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) Vorteile: nur "gute" Pakete werden veröffentlicht paranoide Sicherheitsvorkehrungen fedora.us Paketfluss (9)
Repository Verifikation durch Autor Update Erstveröf− fentlichung 2x Build QA Korrektur (inkl. Signatur) Nachteile: sehr langsam, da wenig Tester (QA) keine Tester bei komplexen Paketen nur weiteres 3rd party repository -> nicht besonders attraktiv für weitere Freiwillige fehlende Infrastruktur Bugzilla nicht wirklich geeignet für Abbildung des QA-Vorgangs Status des Paketes in Bugzilla nicht ersichtlich -> Abschreckung potentieller Tester Build manuell ausgeführt -> hoher Zeitaufwand für Buildmaster RH + fedora.us Zusammenschluss (1)
Red Hat: RHL wirtschaftlich nicht rentabel limitierte Ressourcen, viel Potential wegen hoher Bekanntheit Aufgabe von RHL im Juli 2003 Ziel: stärkere Einbeziehung der "Community" (Debian Modell) Aber: nur unklares Konzept über das "Wie" fedora.us: limitierte Ressourcen funktionierender Prozess & Policies RH + fedora.us Zusammenschluss (2)
Zusammenschluss am 22.September 2003 durch Warren Togami initiiert "fedora" nun Warenzeichen von Red Hat http://fedora.us für Übergangszeit weiterhin aktiv Entfernung rechtlich kritischer Pakete: betroffen: 70 von 287 z.B. MPEG Software, CSS, Spiele-Nachbauten, valgrind
Fedora-Freeworld momentan http://rpm.livna.org (Damien Nade, "Anvil") Ziel: Nachbau der alten Infrastruktur & Verwendung neuer Elemente noch kein Name, "fedora XXX" nicht verwendbar eventuell Zusammenschluss mit Penguin Liberation Front (http://plf.zarb.org)?? Das Fedora Project
viele Details unklar Red Hat bietet Infrastruktur (CVS, Build-Maschinen, Bugzilla, Bandbreite, Mailinglisten, ...) und Entwickler Resultate fließen in RHEL Produkte keine Geheimnisse
Steuerungskomitee http://fedora.redhat.com/about/leadership.html hauptsächlich RH Mitarbeiter
Aufteilung der Pakete in Fedora Core Fedora Extras Fedora Alternatives Fedora Legacy Fedora Core
Nachfolger von Red Hat Linux ISO Images von Fremdanbietern unter diesem Namen kommerziell verwertbar -> deshalb eigenständiger "Fedora(tm)" Name blee^Wleading edge 4-6 monatige Releaseintervalle Updates 2-3 Monate nach nächstem Release keinerlei Support keinerlei Hardwarezertifikate RHEL-Abgrenzung: http://fedora.redhat.com/about/rhel.html Fedora Extras + Alternatives
Fedora Extras Ergänzung von Fedora Core Aufteilung in themenbezogene Repositories, z.B. "Fedora Extras HPC" für High-Performance Computing
Fedora Alternatives Ersatz von Fedora Core Paketen
Details: http://fedora.redhat.com/participate/terminology.html Fedora Legacy
Basis Idee + Organisation: Jesse Keating ("ender") Pflege existierender Red Hat Linux (7.3 & 9) und bestimmter Fedora Core Versionen sowohl Sicherheits-, als auch (begrenzte) Feature-Updates sehr breite Unterstützung Nutzung existierender fedora.us Verfahren (Build-System) Details: http://www.fedora.us/wiki/FedoraLegacy
Probleme: zögerliche Akzeptanz seitens RH passt nicht in gegenwärtigen Bugzilla (Eigentümer von Komponenten sind global) vendorsec Paketmanagement
Ziele: Fedora Extras + Alternatives keine ISOs -> Installation übers Netz automatisches Auflösen von Abhängigkeiten (automatisches) Einspielen von (Sicherheits)updates
Verfahren: blanke RPM Kommandozeile Skriptlösungen (autorpm, GRAB, ...) up2date/Red Hat Network (RHN) apt yum up2date entwickelt von Red Hat wesentlicher Bestandteil des Red Hat Networks authentifizierte Klienten, Übergang Paket- zu Systemmanagement ermöglicht Bezahlfunktionalität Server-Software nur Red Hat intern; keine bzw. nur wenig verbreitete freie Lösungen APT
basierend auf Debian’s "apt" portiert von Conectiva (Alfredo Kojima (Version 0.3), Gustavo Niemeyer (Version 0.5+)) rpm-Port wahrscheinlich in offizielles "apt" Details: http://moin.conectiva.com.br/AptRpm
Vorteile: sehr gut konfigurierbar "Synaptic" Frontend (http://www.nongnu.org/synaptic/)
Nachteile: keine direkte Nutzung der RPM-Funktionen: Nacheinander-Ausführen von "rpm -e" und "rpm -U" Nutzung des "--nodeps" Parameters Re-Implementierung von "rpm" Funktionen YUM
"Yellow dog Updater, Modified" Autor: Seth Vidal, Duke University geschrieben in Python direkte Nutzung der rpmlib Nachbau der Verfahren von Red Hats "anaconda" Zeitplan
Fedora Core 1 "Cambridge" (FC1) Mo, 3.November 2003 2.4er Kernel + NPTL + exec-shield + randomized VM mapping UTF-8 Standardzeichensatz Details: http://fedora.redhat.com/docs/release-notes Gnome 2.4, KDE 3.1.4, Mozilla 1.4.1 Details: http://fedora.redhat.com/projects/package-list
Fedora Core 2 "Cambridge+" (FC2) Zeitliche Orientierung am 2.6er Kernel Mitwirkungsmöglichkeiten (1) bugzilla.redhat.com sinnvolle Fehlerreports: Recherche nach ähnlichen Bugs genaue Beschreibung fedora.us für Übergangszeit weiterhin aktiv QA (http://www.fedora.us/QA) Bereitstellung von Paketen Mitwirkungsmöglichkeiten (2)
Mailinglisten Nachfolger der rhl-* Listen: [email protected] ... Nutzer von Fedora Core [email protected] ... Tester [email protected] ... Entwickler [email protected] ... Dokumentation [email protected] Fedora Legacy https://lists.dulug.duke.edu/mailman/listinfo/fedora-legacy-list
IRC freenode Netzwerk #fedora, #fedora-devel, #fedora-legacy Fröhliches Testen