Paketverwaltung am Beispiel von Debian

Veröffentlicht am von

Was sind Software-Pakete?

Software-Pakete entstehen wenn Softwarebestandteile zusammengefasst werden und bestehen in einem einfachen Fall beispielsweise aus einer Archivdatei, welche ein Programm, Abhängigkeiten und Anweisungen wie das Programm installiert werden sollte, enthält. Pakete können aber auch aus Programmbibliotheken oder Dokumentation bestehen.

Was ist Paketverwaltung?

Werden Softwarepakete automatisiert durch einen Package-Manager verwaltet, spricht man von Paketverwaltung, und diese ermöglicht im Optimalfall eine reibungslose und vollautomatische

  • Installation
  • Vorkonfiguration
  • Aktualisierung
  • Deinstallation

von Software.

Vergleich zu manueller Vorgehensweise

Werden Pakete nicht systematisch verwaltet, treten verschiedene Probleme auf. Softwarespezifische Installer sind im Allgemeinen nicht in der Lage Abhängigkeiten aufzulösen und so wird bei fehlenden Abhängigkeiten wie z.B. der Java Runtime Environment die Installation mit der Aufforderung an den Benutzer diese manuell zu installieren, abgebrochen. Um dieses Problem weitestgehend zu umgehen werden die meisten Abhängigkeiten für jede Software separat installiert, unabhängig davon wie oft diese schon von anderen Installern kopiert wurde.

Diese Probleme resultieren in einem erhöhten Speicherverbrauch, zahllosen Update-Agenten, Chaos in der Startmenü-Struktur und bei Ordnern und Dateien, welches bei häufiger Installation und Deinstallation immer weiter zunimmt, da die softwarespezifischen Deinstaller im Zweifelsfall bestimmte Teile nicht löschen, um die Funktionsfähigkeit des Systems nicht zu gefährden. Auch bei der Beschaffung von Software können Probleme entstehen. So wird dem Nutzer und dessen Fähigkeit vertraut, die Qualität und Sicherheit der Software und seiner Quelle einzuschätzen.

Bei einer zentralen Paketverwaltung können Pakete im Voraus getestet werden, so dass Pakete in der Test-Phase, Beta-Phase und stabile Pakete unterschieden werden können. Ebenso werden die Pakete mit Signaturen versehen, womit viele Man-In-The-Middle-Angriffe unmöglich werden und sichergestellt werden kann dass das jeweilige Paket von der vertrauten Quelle stammt. Dadurch wird hohe Software-Sicherheit, Software-Qualität und Benutzerfreundlichkeit erreicht. Die vertraute Quelle ist meistens ein vom Paketmanager oder von der Distribution bereitgestelltes und voreingestelltes Repository aber viele Paketverwaltungen erlauben auch das Einbinden externer Repositories sowie das Erstellen eigener Repositories.

Wahl des Paketmanagers

Es gibt eine Vielzahl von Paketmanagern mit unterschiedlichen Ansätzen und Einsatzbereichen, was durch die folgende Aufzählung einiger Paketverwaltungen verdeutlicht werden soll:

  • dpkg ist der von der Linuxdistribution Debian verwendete Paketmanager. Auch weitere von Debian abstammende Distributionen wie Ubuntu, Linux Mint oder Raspbian verwenden diesen. Er stellt eine Sammlung von betriebsystemseitig unterstützter Software zur Verfügung.
  • RPM wird von den Linuxdistributionen RHEL, CentOS und Fedora verwendet. Auch Suse Linux verwendet RPM, ohne aber kompatibel zu den zuvor genannten Distributionen zu sein.
  • Snap ist eine distributionsunabhängige Paketverwaltung für Linux, welche in sich geschlossene Applikationen in einer teilweise abgeschotteten Umgebung ausführt. Das Repository ist closed source und wird von Canonical bereitgestellt.
  • Nix ist ein rein funktionaler, distributionsunabhängiger Paketmanager welcher über hierarchische Hashwertbildung der Abhängigkeiten Abhängigkeitskonflikte vollständig vermeidet und eine hohe Reproduzierbarkeit bei gleichzeitig geteilten Abhängigkeiten ermöglicht.
  • Google Play Store ist der vom Smartphone-Betriebssystem Android verwendete Appstore
  • npm ist ein Paketmanager nur für JavaScript Programme und Programmbibliotheken.
  • Steam verwaltet Pakete für Computerspiele und ist für die Betriebssysteme Windows, MacOS und Linux verfügbar.

Unter Linux ist die Wahl des Paketmanagers verknüpft mit der Wahl der Linuxdistribution. Die zusätzliche Verwendung von distributionsunabhängigen Paketverwaltungen ist kein Problem, muss aber eventuell durch einen erhöhten Speicherverbrauch erkauft werden, da diese eine eigene Sammlung von Abhängigkeiten pflegen.

Für das später folgende Beispiel zum Bauen und Hosten eines Paketes wird hier Debian verwendet, da dieses im betrieblichen Umfeld häufig eingesetzt wird und eine sehr gute Dokumentation vorliegt.

Vorteile eines eigenen Repositories

Ein betriebsinternes Software Repository bietet folgende Vorteile:

  • Caching von Paketen aus externen Repositories: Durch Mirroring von externen Paketquellen kann Internet-Bandbreite und Zeit bei Installation und Update von Paketen gespart werden.
  • Unternehmensweite Bereitstellung von eigenen Software-Paketen: Die Paketierung eigener Software beispielsweise für die Serverinfrastruktur im Unternehmen kann durch die vollautomatische Installation und Updates im Nachhinein viel Zeit sparen
  • Staging der eigenen Software für Entwicklung, Pilotphase, Live-Betrieb: Eine Paketverwaltung ermöglicht kontrollierte Test und Entwicklungs-Umgebungen

Bauen eines Paketes am Beispiel Debian

Für das Erstellen eines Debian-Software-Pakets muss die Software selbst sowie Anweisungen für Anpassungen an das Makefile und weitere Metadaten in speziellen Dateien gespeichert werden. Vorlagen dieser Dateien können mit Werkzeugen wie dh_make erstellt werden.

Als Beispiel wird hier ein in C geschriebenes Hello-World Programm mit Hilfe einer Debian VM paketiert. Das Programm liegt als tar Datei vor und wird zunächst konventionsgemäß umbenannt und entpackt. Dann wird ein Verzeichnis mit dem Namen debian erstellt, in welches die zuvor erwähnten Text-Dateien erstellt werden. hithere.1 stellt den man-Eintrag bereit.

beispielpaket
├── hithere-1.0
│ ├── debian
│ │ ├── changelog
│ │ ├── control
│ │ ├── copyright
│ │ └── rules
│ ├── hithere.1
│ ├── hithere.c
│ └── Makefile
└── hithere_1.0.tar.gz

Im Folgenden werden die vier notwendigen Dateien für das Bauen des Paketes beschrieben.

copyright

In copyright können Software-Lizenzen des Paketes auf Datei und Ordner-Ebene vergeben werden.

changelog

hithere (1.0-1) UNRELEASED; urgency=low

* Initial release. (Closes: #XXXXXX)

— Peter Hornik <peter.hornik@stud.htwk-leipzig.de> Fri, 20 Nov 2020 10:36:34 +0100

Die changelog-Datei dient unter Anderem zur Dokumentation von Veränderungen am Paket. Sie gibt Nutzern Anhaltspunkte über mögliche Probleme die mit dem Paket bestehen. hithere ist dabei der Paket-Name, gefolgt von Version und Distribution, hier UNRELEASED was versehentliches Hochladen verhindert, für gewöhnlich würde man hier „unstable“ eintragen. Closes bezieht sich auf einen Bug, der mit dem Release des Paketes gefixt wird.

rules

#!/usr/bin/make -f
%:
dh $@

override_dh_auto_install:
$(MAKE) DESTDIR=$$(pwd)/debian/hithere prefix=/usr install

rules ist ein Makefile, welches als Vorlage automatisch erstellt werden kann und alle Targets an debian helper scripts weiterleitet. Hier kann die Installationsprozedur aus dem Makefile der zu paketierenden Software angepasst werden, was hier bezüglich des Installationsverzeichnisses gemacht wurde.

control

In control werden Informationen wie die angezeigte Paketbeschreibung, Abhängigkeiten und weitere gespeichert, die von Werkzeugen wie apt-get oder aptitude benötigt werden.

Hosting eines Debian-Repositorys

Ein Debian-Repo besteht aus zwei grundlegenden Bausteinen: Einem Server, über den die Pakete verteilt werden und einer Software (reprepro), die eine Paketdatenbank und eine entsprechende Dateisystemstruktur statisch generiert. Ein solches Repository kann einer von zwei Kategorien zugeordnet werden. Entweder ist es ein Spiegelserver des offiziellen, distributionseigenen Repos. Das kann etwa großen Organisationen dabei helfen, Bandbreite für Systemupdates zu sparen und den Updateprozess an sich besser zu kontrollieren.

Hier soll aber auf Repositories der zweiten Kategorie eingangen werden: Die Private Package Archives. Diese werden verwendet, um Software über die distributionseigenen Werkzeuge zu installieren, die nicht in den offiziellen Softwarequellen angeboten wird.

Ein solches Paket geht dabei über drei Stationen: Zuerst vom Rechner des Entwicklers oder vom Build-Server aus auf den Repository-Server. Dort wird das Paket mithilfe von reprepro der Datenbank hinzugefügt und darüber hinaus über gpg signiert. Das sorgt dafür, dass das Paket auf dem Weg zum Rechner, auf dem die Software installiert werden soll, nicht manipuliert werden kann, da sich sonst die Signatur ändern würde. Außerdem kann der Nutzer oder die Nutzerin festlegen ausschließlich Pakete zu erlauben, die von einem Schlüssel signiert wurden, dem auch vertraut wird.

Ist auf dem Repo-Server bereits ein Webserver korrekt installiert und konfiguriert, steht das Paket jetzt zum Download bereit. Um die Software nun über die gewohnten Werkzeuge auf dem Zielrechner zu installieren und aktualisieren sind noch einige Konfigurationsschritte nötig: Der Paketmanager muss informiert werden, dass dem Schlüssel des Repos vertraut werden kann, außerdem müssen der Name und die URL des Repos hinterlegt werden. Jetzt kann das Paket ganz einfach installiert werden.

Beispiel

Eine einfache Beispieleinrichtung kann im Hosting-Ordner unseres GitLab-Verzeichnisses zu diesem Projekt gefunden werden. Diese ist über docker-compose mit zwei Containern realisiert. Zum Ausführen des Servers müssen die Container erst mit docker-compose build gebaut werden und dann mit docker-compose up gestartet werden.

Der Server ist nun über http://localhost:8080 zu erreichen. Die genaue Konfiguration kann hier auch eingesehen werden. Auf dem Client, der nun das entsprechende Paket installiert werden soll, müssen nun erst die Dateien key_pub.gpg und example-repo.list heruntergeladen werden, die auch auf dem Server zu finden sind.
Die .list-Datei muss jetzt in den Ordner /etc/apt/sources.list.d/ kopiert werden. Dadurch weiß der Paketmanager, wo das Repo zu finden ist. Dann muss dem Schlüssel vertraut werden. Das erreicht man mit dem Befehl apt-key add key_pub.gpg. Nachdem der Paketcache erneuert wurde (apt update), kann das Paket jetzt mit apt install hithere installiert und danach mit hithere ausgeführt werden.

Quellen

Debian Packaging Intro
Debian Package Management
GitLab-Projekt

Präsentation

Folien