Software-Pakete entstehen wenn Softwarebestandteile zusammengefasst werden und bestehen in einem einfachen Fall beispielsweise aus einer Archivdatei, welche ein Programm, Abh\u00e4ngigkeiten und Anweisungen wie das Programm installiert werden sollte, enth\u00e4lt. Pakete k\u00f6nnen aber auch aus Programmbibliotheken oder Dokumentation bestehen.<\/p>\n
Werden Softwarepakete automatisiert durch einen Package-Manager verwaltet, spricht man von Paketverwaltung, und diese erm\u00f6glicht im Optimalfall eine reibungslose und vollautomatische<\/p>\n
von Software.<\/p>\n
Werden Pakete nicht systematisch verwaltet, treten verschiedene Probleme auf. Softwarespezifische Installer sind im Allgemeinen nicht in der Lage Abh\u00e4ngigkeiten aufzul\u00f6sen und so wird bei fehlenden Abh\u00e4ngigkeiten 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\u00e4ngigkeiten f\u00fcr jede Software separat installiert, unabh\u00e4ngig davon wie oft diese schon von anderen Installern kopiert wurde.<\/p>\n
Diese Probleme resultieren in einem erh\u00f6hten Speicherverbrauch, zahllosen Update-Agenten, Chaos in der Startmen\u00fc-Struktur und bei Ordnern und Dateien, welches bei h\u00e4ufiger Installation und Deinstallation immer weiter zunimmt, da die softwarespezifischen Deinstaller im Zweifelsfall bestimmte Teile nicht l\u00f6schen, um die Funktionsf\u00e4higkeit des Systems nicht zu gef\u00e4hrden. Auch bei der Beschaffung von Software k\u00f6nnen Probleme entstehen. So wird dem Nutzer und dessen F\u00e4higkeit vertraut, die Qualit\u00e4t und Sicherheit der Software und seiner Quelle einzusch\u00e4tzen.<\/p>\n
Bei einer zentralen Paketverwaltung k\u00f6nnen Pakete im Voraus getestet werden, so dass Pakete in der Test-Phase, Beta-Phase und stabile Pakete unterschieden werden k\u00f6nnen. Ebenso werden die Pakete mit Signaturen versehen, womit viele Man-In-The-Middle-Angriffe unm\u00f6glich werden und sichergestellt werden kann dass das jeweilige Paket von der vertrauten Quelle stammt. Dadurch wird hohe Software-Sicherheit, Software-Qualit\u00e4t 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.<\/p>\n
Es gibt eine Vielzahl von Paketmanagern mit unterschiedlichen Ans\u00e4tzen und Einsatzbereichen, was durch die folgende Aufz\u00e4hlung einiger Paketverwaltungen verdeutlicht werden soll:<\/p>\n
Unter Linux ist die Wahl des Paketmanagers verkn\u00fcpft mit der Wahl der Linuxdistribution. Die zus\u00e4tzliche Verwendung von distributionsunabh\u00e4ngigen Paketverwaltungen ist kein Problem, muss aber eventuell durch einen erh\u00f6hten Speicherverbrauch erkauft werden, da diese eine eigene Sammlung von Abh\u00e4ngigkeiten pflegen.<\/p>\n
F\u00fcr das sp\u00e4ter folgende Beispiel zum Bauen und Hosten eines Paketes wird hier Debian verwendet, da dieses im betrieblichen Umfeld h\u00e4ufig eingesetzt wird und eine sehr gute Dokumentation vorliegt.<\/p>\n
Ein betriebsinternes Software Repository bietet folgende Vorteile:<\/p>\n
F\u00fcr das Erstellen eines Debian-Software-Pakets muss die Software selbst sowie Anweisungen f\u00fcr Anpassungen an das Makefile und weitere Metadaten in speziellen Dateien gespeichert werden. Vorlagen dieser Dateien k\u00f6nnen mit Werkzeugen wie 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\u00e4chst konventionsgem\u00e4\u00df umbenannt und entpackt. Dann wird ein Verzeichnis mit dem Namen Im Folgenden werden die vier notwendigen Dateien f\u00fcr das Bauen des Paketes beschrieben.<\/p>\n In * Initial release. (Closes: #XXXXXX)<\/p>\n — Peter Hornik <peter.hornik@stud.htwk-leipzig.de> Fri, 20 Nov 2020 10:36:34 +0100<\/p>\n Die changelog-Datei dient unter Anderem zur Dokumentation von Ver\u00e4nderungen am Paket. Sie gibt Nutzern Anhaltspunkte \u00fcber m\u00f6gliche Probleme die mit dem Paket bestehen. override_dh_auto_install: In Ein Debian-Repo besteht aus zwei grundlegenden Bausteinen: Einem Server, \u00fcber den die Pakete verteilt werden und einer Software ( Hier soll aber auf Repositories der zweiten Kategorie eingangen werden: Die Private Package Archives<\/em>. Diese werden verwendet, um Software \u00fcber die distributionseigenen Werkzeuge zu installieren, die nicht in den offiziellen Softwarequellen angeboten wird.<\/p>\n Ein solches Paket geht dabei \u00fcber drei Stationen: Zuerst vom Rechner des Entwicklers oder vom Build-Server aus auf den Repository-Server. Dort wird das Paket mithilfe von Ist auf dem Repo-Server bereits ein Webserver korrekt installiert und konfiguriert, steht das Paket jetzt zum Download bereit. Um die Software nun \u00fcber die gewohnten Werkzeuge auf dem Zielrechner zu installieren und aktualisieren sind noch einige Konfigurationsschritte n\u00f6tig: Der Paketmanager muss informiert werden, dass dem Schl\u00fcssel des Repos vertraut werden kann, au\u00dferdem m\u00fcssen der Name und die URL des Repos hinterlegt werden. Jetzt kann das Paket ganz einfach installiert werden.<\/p>\n Eine einfache Beispieleinrichtung kann im Hosting<\/a>-Ordner unseres GitLab-Verzeichnisses zu diesem Projekt gefunden werden. Diese ist \u00fcber Der Server ist nun \u00fcber http:\/\/localhost:8080<\/a> zu erreichen. Die genaue Konfiguration kann hier auch eingesehen werden. Auf dem Client, der nun das entsprechende Paket installiert werden soll, m\u00fcssen nun erst die Dateien key_pub.gpg<\/em> und example-repo.list<\/em> heruntergeladen werden, die auch auf dem Server zu finden sind. Debian Packaging Intro<\/a>dh_make<\/code> erstellt werden.<\/p>\ndebian<\/code> erstellt, in welches die zuvor erw\u00e4hnten Text-Dateien erstellt werden. hithere.1<\/code> stellt den man-Eintrag bereit.<\/p>\nbeispielpaket
\n\u251c\u2500\u2500 hithere-1.0
\n\u2502 \u251c\u2500\u2500 debian
\n\u2502 \u2502 \u251c\u2500\u2500 changelog
\n\u2502 \u2502 \u251c\u2500\u2500 control
\n\u2502 \u2502 \u251c\u2500\u2500 copyright
\n\u2502 \u2502 \u2514\u2500\u2500 rules
\n\u2502 \u251c\u2500\u2500 hithere.1
\n\u2502 \u251c\u2500\u2500 hithere.c
\n\u2502 \u2514\u2500\u2500 Makefile
\n\u2514\u2500\u2500 hithere_1.0.tar.gz<\/code><\/p>\ncopyright<\/h4>\n
copyright<\/code> k\u00f6nnen Software-Lizenzen des Paketes auf Datei und Ordner-Ebene vergeben werden.<\/p>\nchangelog<\/h4>\n
hithere (1.0-1) UNRELEASED; urgency=low<\/code><\/p>\nhithere<\/code> ist dabei der Paket-Name, gefolgt von Version und Distribution, hier UNRELEASED<\/code> was versehentliches Hochladen verhindert, f\u00fcr gew\u00f6hnlich w\u00fcrde man hier „unstable“ eintragen. Closes<\/code> bezieht sich auf einen Bug, der mit dem Release des Paketes gefixt wird.<\/p>\nrules<\/h4>\n
#!\/usr\/bin\/make -f
\n%:
\ndh $@<\/code><\/p>\n
\n$(MAKE) DESTDIR=$$(pwd)\/debian\/hithere prefix=\/usr install<\/p>\nrules<\/code> 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\u00fcglich des Installationsverzeichnisses gemacht wurde.<\/p>\ncontrol<\/h4>\n
control<\/code> werden Informationen wie die angezeigte Paketbeschreibung, Abh\u00e4ngigkeiten und weitere gespeichert, die von Werkzeugen wie apt-get<\/code> oder aptitude<\/code> ben\u00f6tigt werden.<\/p>\nHosting eines Debian-Repositorys<\/h2>\n
reprepro<\/code>), 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\u00dfen Organisationen dabei helfen, Bandbreite f\u00fcr Systemupdates zu sparen und den Updateprozess an sich besser zu kontrollieren.<\/p>\nreprepro<\/code> der Datenbank hinzugef\u00fcgt und dar\u00fcber hinaus \u00fcber gpg<\/code> signiert. Das sorgt daf\u00fcr, dass das Paket auf dem Weg zum Rechner, auf dem die Software installiert werden soll, nicht manipuliert werden kann, da sich sonst die Signatur \u00e4ndern w\u00fcrde. Au\u00dferdem kann der Nutzer oder die Nutzerin festlegen ausschlie\u00dflich Pakete zu erlauben, die von einem Schl\u00fcssel signiert wurden, dem auch vertraut wird.<\/p>\nBeispiel<\/h3>\n
docker-compose<\/code> mit zwei Containern realisiert. Zum Ausf\u00fchren des Servers m\u00fcssen die Container erst mit docker-compose build<\/code> gebaut werden und dann mit docker-compose up<\/code> gestartet werden.<\/p>\n
\nDie .list<\/em>-Datei muss jetzt in den Ordner \/etc\/apt\/sources.list.d\/<\/code> kopiert werden. Dadurch wei\u00df der Paketmanager, wo das Repo zu finden ist. Dann muss dem Schl\u00fcssel vertraut werden. Das erreicht man mit dem Befehl apt-key add key_pub.gpg<\/code>. Nachdem der Paketcache erneuert wurde (apt update<\/code>), kann das Paket jetzt mit apt install hithere<\/code> installiert und danach mit hithere<\/code> ausgef\u00fchrt werden.<\/p>\nQuellen<\/h2>\n
\nDebian Package Management<\/a>
\nGitLab-Projekt<\/a><\/p>\nPr\u00e4sentation<\/h2>\n