Das neue Paketmanagement in FreeBSD

© Konstantin Semenov, 123RF

Neubau

,
Seit Langem warten die FreeBSD-Anwender auf eine Runderneuerung der in die Jahre gekommenen Paketverwaltung. Im Oktober wurde in CURRENT mit PKG-NG ein radikaler Schnitt gemacht – bei den Binärpaketen wird vieles anders und manches besser.
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Anders als bei Windows und Mac OS X, bei denen jeder Softwarehersteller für die Installation und Deinstallation seiner Anwendung selbst verantwortlich ist, kümmern sich die Unix-artigen Betriebssysteme selbst um die verfügbaren Programme. Bei Linux sind die Distributoren, bei BSD die Projekte für die hier enthaltenen Daten zuständig. Der Linux-Anwender (außer er arbeitet mit Gentoo) wählt normalerweise die Binärdateien der Programme als RPM- oder Deb-Dateien in einem Frontend, und die Softwareverwaltung macht den Rest. Das alles geht schnell, ist aber wenig flexibel, weil alle Programme mit Voreinstellungen vorkompiliert sind.

Bei BSD ist das ganz anders. Der erfahrene Administrator installiert im Regelfall Programme exakt angepasst aus deren Quellen. Dieses Verfahren ist bei FreeBSD, NetBSD und OpenBSD fast identisch, auch wenn dies bei NetBSD Package Sources und bei den anderen beiden Betriebssystemen Ports heißt. Das Einspielen von Programmen auf diese Weise ist sehr langwierig. Wer zu schnelleren Ergebnissen kommen will, kann die Programme – dann nur mit den Standardvorgaben – mit den Kommandozeilenprogrammen »pkg_add« installieren, mit »pkg_delete« deinstallieren und sich weiterhin mit »pkg_info« Basisinformationen zu den installierten Paketen anzeigen lassen.

Es gibt noch einige weitere Hilfsprogramme, die aber für die meisten Anwender nicht von Bedeutung sind. Diese Programme gibt es bei allen BSD-Betriebssystemen, die das Paketsystem vor Jahren von FreeBSD übernommen hatten. Ausführliche Beschreibungen zum Aufbau des Systems und zum Umgang damit, auch mit Seitenblicken auf OpenBSD und NetBSD finden sich etwa [1].

Das Paketsystem aller drei BSD-Systeme legt zur Verwaltung einen Verzeichnisbaum in »/var/db/pkg/« an. Es ist eine rein verzeichnisbasierte Datenbank, in der jedes Softwarepaket ein Unterverzeichnis mit genau seinem Namen und der vollen Versionsnummer erhält. In diesem Verzeichnis befinden sich eine Reihe Text-Steuerdateien.

Überarbeitet

Im Oktober 2012 wurde diese Softwareverwaltung bei FreeBSD CURRENT durch einen PKG NG genannten Nachfolger abgelöst. Das Absonderliche ist nicht, dass endlich die Paketverwaltung modernisiert wird, sondern dass sich »pkg« gar nicht im Lieferumfang von FreeBSD befindet. Ruft man nach der Installation das Programm auf, wird nur die Meldung angezeigt, dass das Programm installiert werden sollte, es befindet sich nämlich in den Ports und muss erst gebootstrappt werden. Selbst wenn man ein Paket des Programms »pkg« vorliegen hat, nützt das aber nichts – »pkg« ist ja nicht installiert. Diesen Konflikt versucht FreeBSD über einen Download des Binaries zu lösen, was bei diversen Versuchen fehlschlug.

Da das Paket in den Ports vorhanden ist, reicht alternativ ein »cd /usr/ports/ports-mgmt/pkg ; make install clean« , um anschließend mit dem Programm arbeiten zu können. Vertrauenerweckend erscheint diese Einführung der neuen Paketverwaltung jedoch nicht. Immerhin weist sie bei der Installation darauf hin, dass der Aufruf von »pkg2ng« eine alte Paketdatenbank in das neue Format umzieht. Er ist aber nur dann nötig, wenn man »pkg-ng« bei einer älteren FreeBSD-Version nutzen möchte, bei der schon Programme installiert wurden, möglich ist das ab FreeBSD 8.

Zweiteilung

»pkg-ng« besteht aus zwei Programmen, die in »/usr/local/sbin« abgelegt werden und »pkg« und »pkg-static« heißen. Nach der Installation sollte man Letzteres an einen sicheren Ort wie beispielsweise »/usr/sbin« kopieren. Weiterhin elementar ist die Konfiguration »/usr/local/etc/pkg.conf« . Diese Datei gibt es nach der Installation aber nicht, das in »/usr/local/etc« abgelegte Template »pkg.conf.sample« muss erst wahlweise umbenannt oder umkopiert werden. Der auffälligste Unterschied zum alten Paketsystem ist aber, dass man nicht mehr einfach Namen und Version eines installierten Paketes durch ein »ls« nach »/var/db/pkg« ermitteln kann. Die Zeiten, in denen mit den Standardwerkzeugen des Betriebssystems nach Daten forschen und man über das Editieren einer Datei einen kleineren Tweak durchführen konnte, sind vorbei. Der Entwickler von »pkg« hat sich der auch schon anderweitig bei freien Unix-Systemen um sich greifende Unsitte angeschlossen und schreibt die Daten in eine SQLite-Datei.

Nach der Installation ändert sich aber sonst bei der Installation eines Paketes erst einmal nicht sehr viel. Liegt die Paketdatei lokal vor, ruft man anstelle von »pkg_add« jetzt nur »pkg add« ohne den Unterstrich auf. Möchte man Anwendungen aus dem Internet installieren, heißt es jetzt nicht mehr »pkg_add -r« , sondern »pkg install« . Gelöscht werden die Daten mit »pkg delete« . Tabula rasa mit »pkg delete -a« geht aber nicht, der Anwender muss jetzt mit »-af« das Löschen erzwingen. Hier zeigt sich auch die Tücke des Objekts und warum man »pkg-static« in Sicherheit bringen muss: Das Paketverwaltungsprogramm wird als Paket aus den Ports gleich mitgelöscht und muss vor der Installation neuer Pakete erst wieder installiert werden.

Abbildung 1: Die herkömmlichen Paketverwaltungsprogramme weisen bei FreeBSD CURRENT auf das neue Programm hin.
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019