Verteiltes Paketsystem

* packet management

In this work i try to show the potential of different packet management systems and their different capabilities and features. A later and far more important step will be finding a way to get a synthesis of the systems resulting in a new system. A major issue with all these different systems is that they enforce duplicate/redundant work steps upon all it's users - a synthesis between these systems shall reduce this issue.

A main principle will be deployment and not creating "yet another linux distribution"!

The core problem

Packets are build per Distro(distribution) (ignoring inheritance as debian -> ubuntu here)
Patches on packets - made by the Distribution developer - are not noticed by upstream
assignment of distribution specific bugs and upstream bugs are complicated
no automation in building packets (as in gentoo) for most distros - a developer has to do that
no authentification (as in debian) for most distributions - was the packet modified?!

| developer team | ------------------ | distribution | ------------------ | user |
      |                                       |
   bug management                       bug management

   (upstream)

<graphviz border='frame' format='png'> digraph G {Hello->World!} </graphviz>

things i have to do before creating anything new

analyze capability of different systems and how much these systems already implement the concept of this work
analyze the 'work flow' of ppl doing releases and packing software (take this into account)
considering the new features (i have added at the end of this work) analyze how much work it will be to create a system of that scale and get it up and running
getting a minimal system running maybe with a modular approach so that components can be refined over time.

Introduction

The problem: Softwareverteilung und des automatisierten Softwarebaus. Was unter Linux wirklich aergerlich ist: man findet Software muss diese dann selbst uebersetzen. Natuerlich ist das kein Linux spezifisches Problem, man trifft es dort nur haeufiger an.

Hier versuche ich einen konzeptionellen Ansatz zu finden, der das Erstellen von Paketen und deren Pflege von Abhaenigkeiten vereinfacht.

Die Absichten sind:

- Abstraktionlayer zwischen upstream und distribution

ein zentrales Abstraktionslayer zwischen upstream (das sind die Entwickler von Software und dazu zaehlt OpenSource wie ClosedSource Software) und Distribution (z.b. Fedora/SuSE/Windows XP.. usw).

- automatisches Bauen von Paketen

(ein Paket ist eine Software z.b. die Qt library oder den firefox) fuer verschiedene distributionen

- verifikation der Paketerstellung:

das gesammte automatisierte Bauen muss jederzeit in jedem Teilschritt nachvollziehbar sein: z.b. via Emulator fuer verschiedene archs (i386/ppc/arm) oder unterschiedliche Tool-Chains (gcc 3.1 vs gcc 3.3). D.h. das entstandene Paket (kein Quellcode mehr) enthaellt zusaetzlich die Bauanleitung (aehnlich deb-src oder ebuild). Wenn nun das Paket nochmals gebaut wird, dann muss das selbe Paket 1:1 vorliegen.

- strukturierte stable/unstable Baeume

anders wie bei Gentoo wo es nur fortschreitende Versionierung gibt sollte auch ein stable/unstable/testing Baum vorhanden sein.

- sicherheit (patches von upstream software bei deployment)

patches welche Software von upstream modifizieren sollten auf lange Sicht von upstream integriert werden. Im derzeitigen Wildwuchs und Distributionsgepatche ist es fuer upstream eigentlich unmoeglich die Uebersicht zu behalten.

- sicherheit (reproduzierung des binary Paketes)

verifizierte Quellen und verfifizierte Toolchain.

- verfifizierte Toolchain

um ueber die Vertraulichkeit einer Software aussagen machen zu koennen reicht es nicht nur die Software selber zu validieren, wenn diese statisch oder auch dynamisch noch andere Software mit einbindet. Wichtig ist dabei aber auch die verwendete Toolchain (compiler, systemcalls usw) mit zu validieren. Wenn ein sicherheitsrelevanter Bug in der Toolchain festgestellt wird, dann muss das Paket ev. sogar neu gebaut werden (statische verlinkung) oder falls ABI kompatibel, dann reicht es aus die darunter liegende Library neu zu bauen.

guidelines for installing software

unix

Unter unixartigen systemen sowas wie in [13] oder [14]. BSD macht das anderst als Linux.

microsoft

microsoft has a certification program, check "the designed for windows" guidelines

Definition Paketmanagement

Es gibt verschiedene Stufen von Paketmanagement, hier eine Einfuehrung:

kein Management:
programme werden einfach reinkopiert (typisch: make; make install)
uninstaller:
programme werden in chroot umgebungen installiert, daraus die fileliste erstell fuers uninstall
uninstaller + updater:
gleich wie oben nur ist eine softwarekomponenten enthalten welche z.b. periodisch nach updates sucht
distribution specific hierarchical management(internal builds):
pro Distributionszweig (nicht zwingend Linux-distribution). Hier werden Pakete erstellt, das Management hat den ueberblick ueber installierte Pakete und kann feststellen ob Updates fuer einzelne Pakete vorhanden sind.
hier wird das neue paket innerhalb der distribution erstellt. dabei schleichen sich _sehr oft_ fehlende abhaenigkeiten mit katastrophalen folgen ein. beispiel: nach einem update versagt die software zur laufzeit !1!! da die noetigen abhaenigkeiten nicht erfuellt sind: z.b. eine library fehlt oder ist in der falschen version installiert.
bei weitem das verbreitetste model bei fast allen linux distributionen
distribution specific hierarchical management(external builds):
hier wird das neue paket nicht innerhalb der distribution erstellt, sondern mit einer angepassten minimalumgebung. das neue system haengt begrenzt von inneren abhaenigkeiten ab.
globaly centralized hierarchical packet management (von nun an GHM)
dieses system wird die naechste grosse evolution sein. warum? rekapitulieren wir ueber distributionen allg.: siehe "warum distributionen?"

warum distributionen?"

im prinzip wuerde eine reichen! ja? ... natuerlich nicht. die distribution ist die individuelle anpassung eines systems an eine spezialisierte umgebung wie z.b.:

usergemeinschaft
verwendete hardware (architektur)
verwendete hardware (leistung)
komplexitaet der komponenten (full featured desktop distro vs. embedded system)
sicherheitsaspekte
quallitaetsanforderungen
supportleistungen
uvm

zusammengefasst: eine distribution ist nur ein subset von programmen aus dem pool "aller programme" welche zusammengestellt wird um spezialisierten anforderungen zu genuegen.

technisch gesehen wuerde das GHM die entwicklung von distributionen nicht behindern sondern geradezu beschleunigen.

wichtig: GHM -> Distribution -> Endanwender. Genau so sollte die Abstraktion verstanden werden.

Das Problem

Was wir brauchen ist sowohl Aktualitaet als auch Stabilitaet und das Endproukt sollte via Mausclick installierbar sein.

Leider widersprechen sich diese im Wesentlichen zwei Anforderungen teilweise. Nehmen wir z.B. die Debian Distribution, fuer welche hunderte von Paketen uebersetzt sind (also deb's), sieht man sehr schnell wie komplex die Sache ist.

Die Idee, des verteilten Paketerstellen ist einfach, jedoch sind einige Erfordernisse vorhanden. Dabei brauchen wir genau ein solches System, wie es unter Debian schon sehr gut implementiert ist.

Stable
Testing (hier sind Pakete enthalten, welche dann nach validierung stable werden)
Unstable (oder unuseable?, sicherlich manachmal)

Warum? Die meisten Benutzer wollen nicht den ganzen Tag updates via "apt-get update; apt-get upgrade" durchlaufen lassen. Dazu kommt, dass dies auch nicht jeder kann, da es mindestens eine Flatrate erfordert oder die Preise koennen astronomisch hoch werden. Mal ganz von den hiermit verbunden Problemen der Verteilung abgesehen ist ein solches Konzept eines "Fertigsystems" nicht verkehrt, da wiederum viele Benutzer eine einmalige Installation wuenschen, die oftmals nicht haeufig upgedatet wird.

Aber: Welche Vorteile ein Releasesystem noch hat ist hinsichtlich des Paketekonzepts nebensaechlich, da wir uns auf den nun wesentlichen Aspekt konzentrieren werden - der Paketebau.

Ob nun rpm oder deb Paketformat ist im Prinzip egal, da sich beide sehr aehnlich sind, im Wesentlichen haben beide die selben Probleme:

erstellen eines Paketes erfordert Kentnisse ueber dessen Abhaenigkeiten
erstellen kann problematisch sein, da man ev. zu aktuelle libraries installiert hat und ein downdate nicht in Frage kommt
erstellen eines Paketes erfordert Vertrauen, ich vertraue am liebsten dem Debian Project, aber viele wichtige Pakete sind nur in contrib zu finden.
Paketersteller ist nicht gleichzeitig der Projektmaintainer

bypassing packet management

hier gibt es mehrere problemfelder, ich greif mal ein paar auf:

pakete welche man selber installiert da sie nicht im paket management enthalten sind z.b. exotische programme die von randgruppen verwendet werden
open office extensions wie z.b. [3]
firefox plugins (grosses sicherheitsproblem): flash aber auch addons
php scripte zusammen mit mysql
perl z.b. die perl library und die user programme darin
spiele: installation von zusatzsoftware wie 'karten' bei ut2004 oder bei taspring
kartenmateriel wie z.b. OSM - karten bei marble

einzustufen ist das so:

bypassing ist bei ausfuehrbarem code bedenklich.
bypassing ist bei content aergerlich, da z.b. mehrere user gleichen content im ~ lagern muessen, also platzverschwendung.

im allg. ist solche software schwer 'sauber' zu entfernen

Die Abhaenigkeiten

Wir schauen uns diese Probleme nun mal im Einzelfall an:

Zu aktuelle Libraries der Entwickler

Ich illustriere das an einem Beispiel. Im MusE Project, wo ich selbst taetig bin, wird fast immer mit den aktuellsten Versionen entwickelt, also sind auch diese Libraries meist von den Entwicklern selbst uebersetzt worden. So kommt im Program selbst Qt3.2 zum Einsatz, aber die Entwickler haben Qt3.3 installiert.

Wenn man nun "qt3-develop" der Qt3.3 Serie verwendet, speichert der die erstellten widgets gleich wie die Qt3.2 serie ab, aber aus eventueller Inkompatibilitaet setzt er einen Verweis:
File generated with too recent version of Qt Designer (3.3 vs. 3.2.3)

Diese Problem laesst sich zwar nicht umgehen, wenn nun die Entwickler ein Release ihrer Software planen, jedoch kann der Paketebauer auf eine Umgebung zurueckgreifen, welche eben die Qt Version installiert hat, die auf dem System als aktuell gilt. Beim compilieren der Software stoesst er nun auf die Fehler, welche beim compilieren auf seinem Rechner verborgen waren.

-Stable
 |-libjack             \
 |-libsnd               |> MusE 0.7.1
 |-qt       3.2.3      /
-UnStable
 |-libjack             \
 |-libsnd               |> MusE 0.7.1
 |-qt       3.3        /

Vertrauen in den Paketersteller

Dies ist ein ganz wichtiger Punkt fuer Unternehmen wie Privatnutzer. Dieses System koennte mit einem pgp-key die Software, also das deb oder rpm file signieren und es somit zumindest als vom Entwickler erzeugt und signiert ausweisen. Solche ansaetze sind im Wesentlichen schon in den gaenigen Debian releases enthalten.

Paketersteller != Projektleiter

Meist sind Projekteleiter nur am Anfang der Entwicklung des Projektes mit der Verteilung der Software betraut. Sobald das Projekt komplexer wird, uebernehmen diese Aufgabe andere Leute. Bei den meisten Programmen werden die Pakete von den Debian Package Maintainern betreut, welche oft nicht viel mit dem Projekt zu tun haben.

weitere probleme

das paketbauen muss so einfach sein, dass eine software von extern z.b. abhaenigkeiten im tree referenziert und damit integrierbar ist. so kann man sicherstellen, dass software von extern leicht integrierbar ist.
im sinne eines overlays sollten allerdings nicht nur pakete sondern auch abhaenigkeiten integrierbar sein. ziel: bei einem groesseren paket-merge wie z.b. kde und alle kde programme kann man dann z.b. exklusiv von extern via overlay verwenden und kann die im system liegenden abhaenigkeiten entweder erweitern oder auch komplett ueberschatten

load balancing issue

packets should be specified, not their origin. this means it MUST NOT matter if a packet was downloaded from:

p2p network
client/server downloads
a friend via local share
or in general any media a packet could be 'accessed' from

Platformen die obige Konzepte teilweise implementieren

launchpad
sourceforge
codeplex [17]
google code
savannah
freshmeat
autopackage
suse build service [7]

siehe auch [2]

beispiel zu heutigem deployment

programm wird entweder statisch oder dynamisch gelinkt. z.b.:

hauptprogramm selbst
- qt lib
- libX
- libY
- libZ

im statischen fall ist man recht schnell fertig. im dynamischen wird dann z.b. das programm und die dll files in ein verzeichnis geschoben und der loader (also wenn man das hauptprogramm.exe anclickt) laed dann die *.dll files welche libX.dll, libY.dll und libZ.dll usw nach.

vorteil:

einfach zu machen, deployment geht schnell
entweder mit installier/uninstaller
hersteller proprietaerer software koennen user zum update zwingen wegen sicherheits-loechern in alten ;-)
oder alternativ mit exe packer als ein grosses exe file welches via resource files usw alle daten entheallt

nachteil:

fehler in einer lib erzwingen auch ein neues release des programmes (das klingt fuer windows nutzer vielleicht normal, aber linuxnutzer kennen sowas eigentlich nicht da dort immer nur die libs upgedatet werden (da meist die ABI kompatibel zur security-gepatchten lib ist).
man hat keine uebersicht welche libs das programm nun braucht
man hat ev. zwei mal die gleichen libs rumliegen (das native qt und das im deployten paket)
auf lange sicht gesehen ist sowas ekelig zu supporten, da man alles doppelt machen muss:
- updates in der lib muss man selber machen und neu deployen
man kann libs nicht mehr anfassen (ich glaube hier ist ein beispiel noetig)
- spiel: ut2004 hat die openal.so (das ist eine dll unter linux) und ich hab fuer openal-soft ja das pulseaudio backend programmiert. mein problem war nun wie bekomme ich ut2004 dazu meine .so zu verwenden und nicht die wo im /opt/ut2004 dir rumlag. man kann das entweder via LD_LIBRARY_PATH machen oder man loescht einfach die im /opt/ut2004 verzeichnis und dann sucht der linker autoamtisch unter /lib und /usr/lib nach der .so und nimmt die. so koennte man natuerlich auch cheaten und das spiel veraendern darum ist das teilweise hier nicht gewollt in diesem fall ist das allerdings offensichtlich nicht so.