![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 14 - Festplattenkonfiguration]
Es gibt viele Applikationen von Drittanbietern, die du eventuell auf einem OpenBSD-System einsetzen möchtest. Um die Installation und Verwaltung dieser Software einfacher zu machen (und um es mit OpenBSDs Richtlinien und Zielen in Einklang zu bringen), wird die Software der Drittanbieter in OpenBSD portiert. Diese Portierungsbemühung kann viele verschiedene Dinge beinhalten. Beispiele sind: dafür sorgen, dass die Software sich an die standardmäßige OpenBSD-Verzeichnisstruktur hält (z. B. sollten Konfigurationsdateien in /etc abgelegt werden), die Software sich an OpenBSDs Spezifikation für Shared Librarys hält, die Software sicherer machen, wenn das möglich ist etc.
Das Endergebnis dieser Portierungsbemühung ist ein Binärpaket, das direkt installiert werden kann. Das Ziel des Paketsystems ist es, die Installation der Software zu vermerken, sodass es auf einfache Art und Weise später aktualisiert oder entfernt werden kann. Auf diese Weise werden keine unnötigen Dateien auf dem System vergessen, wodurch Benutzer ihr System in einem sauberen Zustand halten können. Das Paketsystem stellt ebenfalls sicher, dass nichts aus Versehen gelöscht wird, was zur Folge hätte, dass Software nicht mehr ordnungsgemäß ausgeführt werden könnte. Ein weiterer Vorteil ist, dass Benutzer nur sehr selten Software aus dem Quelltext übersetzen müssen, da Pakete bereits kompiliert wurden und nun bereitstehen, um auf einem OpenBSD-System eingesetzt werden zu können. Innerhalb von Minuten kann eine große Anzahl Pakete heruntergeladen und installiert werden - und alles landet an der richtigen Stelle.
Die Paket- und Portierungs-Kollektionen unterliegen NICHT der gründlichen Sicherheitsüberprüfung, die für das OpenBSD-Basissystem gilt. Obwohl wir danach streben, die Qualität der Paketkollektion auf hohem Niveau zu halten, stehen zu wenig Entwickler bereit, um die gleiche Robustheit und Sicherheit zu gewährleisten. Selbstverständlich werden Sicherheitsaktualisierungen für vielerlei Anwendungen so schnell wie möglich in den Portierungsbaum eingebaut, und entsprechende Paket-Sicherheitsupdates als Schnappschuss in -current zur Verfügung gestellt.
Pakete sind die vorkompilierten Binärdateien von einigen der am meist genutzten Software von Drittanbietern. Pakete können mit Hilfe einiger Werkzeuge auf sehr einfache Art und Weise verwaltet werden - diese werden auch als pkg*-Werkzeuge bezeichnet:
Damit eine Applikation X ordnungsgemäß ausgeführt werden kann, kann es notwendig sein, dass die Applikationen Y und Z installiert sind. Applikation X ist somit abhängig von diesen anderen Applikationen. Das ist der Grund, warum Y und Z Abhängigkeiten von X genannt werden. Genauso gut könnte Y die anderen Applikationen P und Q, Z wiederum die Applikation R benötigen, um funktionieren zu können. Auf diese Weise wird ein gesamter Abhängigkeitsbaum modelliert.
Pakete wirken wie einfache .tgz-Bündel. Im Grunde genommen sind sie es auch doch gibt es einen wichtigen Unterschied: Sie enthalten zusätzliche Paketinformationen. Diese Informationen werden von pkg_add(1) für einige Zwecke genutzt:
Du kannst dir das Leben wirklich einfach machen, indem du die Umgebungsvariable PKG_PATH verwendest. Lass sie einfach auf dein bevorzugtes Verzeichnis zeigen und pkg_add(1) wird dort automatisch nach den von dir angegebenen Pakets suchen und ebenfalls alle notwendigen Abhängigkeiten des Pakets automatisch herunterladen und installieren.
Eine Liste möglicher Orte, von wo aus Pakete heruntergeladen werden können, befindet sich in folgender Sektion.
1. Beispiel: Installation von deiner CD-ROM; unter der Annahme, dass sie unter /mnt/cdrom gemountet wurde
$ export PKG_PATH=/mnt/cdrom/5.2/packages/`machine -a`/
2. Beispiel: Installation von einem nahe gelegenen FTP-Spiegelserver
$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/5.2/packages/`machine -a`/
Es ist grundsätzlich eine gute Idee, eine zusätzliche Zeile in deine ~/.profile zu schreiben, die den vorherigen Beispielen ähnlich ist. So wie mit der klassischen PATH-Variable kannst du mehrere Verzeichnisse angeben (mit Doppelpunkten getrennt). Vor OpenBSD 4.4 MUSSTE jedoch jedes Verzeichnis in der PKG_PATH-Variable mit einem Schrägstrich (/) enden. Auf diese Weise kann pkg_add(1) den Pfad richtig aufteilen selbst wenn URL-Schemas angegeben werden, die Doppelpunkte beinhalten. Wenn der erste Eintrag in PKG_PATH nicht zum Erfolg führt, wird der nächste ausprobiert; so lange, bis das Paket gefunden wurde. Wenn das Paket in keinem der Einträge gefunden werden kann, wird eine Fehlermeldung ausgegeben.
Beachte die Verwendung von machine(1) in den vorherigen Kommandozeilen. Hiermit wird automatisch deine installierte OpenBSD-Applikationsarchitektur eingefügt, die normalerweise - aber nicht zwangsläufig - dein Plattformname ist. Wenn du natürlich Schnappschüsse verwendest, so musst du »5.2« durch »snapshots« ersetzen.
Wenn du den Portierungsbaum auf deinem System hast, dann kannst du das Paket sehr schnell aufspüren, indem du nach ihm suchst wie es in »Den Portierungsbaum durchsuchen« beschrieben steht. Solltest du das Paket pkglocatedb installiert haben, so kannst du mit Hilfe des Kommandos pkglocate nach Dateinamen suchen, die sich in dem Paket befinden.
Es wird dir auffallen, dass bestimmte Pakete in verschiedenen Variationen vorliegen; formal Aromata (»flavors«) genannt. Andere sind Teile der gleichen Applikation, die separat installiert werden könnten; diese werden Unterpakete genannt. Das ganze wird in der Sektion Aromata und Unterpakete verwenden genauer erläutert, doch bedeutet Aroma im Grunde nichts anderes, als dass sie mit anderen Optionen konfiguriert wurden. Momentan haben viele Pakete Aromata; beispielsweise Datenbankunterstützung, Unterstützung für Systeme ohne X oder weitere Netzwerkfunktionalitäten wie SSL und IPv6 bereitstellen. Jedes Aromata eines Pakets hat einen anderen Suffix im Paketnamen. Detailliertere Informationen über Paketnamen können in packages-specs(7) gefunden werden.
Hinweis: Nicht alle möglichen Pakete müssen zwangsläufig auf den FTP-Servern liegen! Es gibt Applikationen, die einfach nicht auf allen Architekturen laufen. Weitere Applikationen können aus Lizenzgründen nicht über FTP (oder CD-ROM) weitergegeben werden. Es kann auch einfach nur eine schier unendliche Kombination aus Aromata für eine Portierung geben; das OpenBSD-Projekt hat jedoch einfach nicht die Ressourcen, um sie alle zu kompilieren. Wenn du eine Kombination brauchst, die nicht bereitgestellt wird, musst du die Portierung aus dem Quelltext übersetzen. Weitere Informationen darüber, wie du das machst, kannst du im Kapitel Aromata und Unterpakete verwenden der Portierungssektion dieses Dokumentes nachlesen.
$ sudo pkg_add -v screen-4.0.3p1 parsing screen-4.0.3p1 installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71% screen-4.0.3p1: complete
In diesem Beispiel wird die Option -v verwendet, um eine informativere Ausgabe zu erhalten. Diese Option ist nicht notwendig, doch ist sie hilfreich, um Fehler zu finden, und wurde hier verwendet, um mehr Aufschluss darüber zu ermöglichen, was pkg_add(1) eigentlich macht. Beachte die Meldung, die /etc/screenrc erwähnt. Die Verwendung von mehreren -v-Optionen wird auch mehr Informationen in die Ausgabe schreiben.
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p1 screen-4.0.3p1-shm screen-4.0.3p1-static
Choose one package
0: <None>
1: screen-4.0.3p1
2: screen-4.0.3p1-shm
3: screen-4.0.3p1-static
Your choice: 1
screen-4.0.3p1: complete
Für einige Pakete werden weitere wichtige Informationen über die Konfiguration oder über die Verwendung der Applikation auf einem OpenBSD-System ausgegeben. Da diese wichtig sind, werden sie immer ausgegeben - ob du nun die Option -v verwendet hast oder nicht. Sieh dir zum Beispiel das folgende Beispiel an:
$ sudo pkg_add ghostscript-fonts-8.11 ghostscript-fonts-8.11: complete You may wish to update your font path for /usr/local/share/ghostscript/fonts --- ghostscript-fonts-8.11 ------------------- To install these fonts for X11, just make sure that the fontpath lists the 75dpi or 100dpi bitmap fonts before the ghostscript fonts, and make sure you have the string ":unscaled" appended to the bitmap font's fontpath. This way, the bitmap fonts will be used if they match, and the Type 1 versions will be used if the font needs to be scaled. Below is the relevant section from a typical xorg.conf file. FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/local/lib/X11/fonts/ghostscript/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
Lass uns nun mit einem Beispiel fortfahren, in dem ein Paket installiert wird, welches Abhängigkeiten besitzt:
Wieder haben wir die Option -v hinzugefügt, um mehr über das eigentliche Geschehen zu erfahren. Beim Überprüfen der Paketinformationen wurden Abhängigkeiten gefunden, die nun zuerst installiert werden. Ungefähr in der Mitte kannst du sehen, wie das Paket gettext installiert wurde, welches wiederum von libiconv abhängig ist. Vor der Installation von gettext wurden seine Paketinformationen ausgelesen und sichergestellt, ob libiconv bereits installiert wurde.$ sudo pkg_add -v tin-1.8.2p0 parsing tin-1.8.2p0 Dependencies for tin-1.6.2 resolve to: gettext-0.14.6, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo: libiconv-1.9.2p3,gettext-0.14.6,pcre-6.4p1,libutf8-0.8) tin-1.8.2p0:parsing libiconv-1.9.2p3 tin-1.8.2p0:libiconv-1.9.2p3: complete tin-1.8.2p0:parsing gettext-0.14.6 Dependencies for gettext-0.14.6 resolve to: expat-2.0.0, libiconv-1.9.2p3 (todo: expat-2.0.0) tin-1.8.2p0:parsing expat-2.0.0 tin-1.8.2p0:expat-2.0.0: complete tin-1.8.2p0:gettext-0.14.6: complete tin-1.8.2p0:parsing pcre-6.4p1 tin-1.8.2p0:pcre-6.4p1: complete tin-1.8.2p0:parsing libutf8-0.8 tin-1.8.2p0:libutf8-0.8: complete tin-1.8.2p0: complete
Es ist möglich, mehrere Paketnamen bei einem Aufruf anzugeben, wodurch alle auf einmal installiert werden - neben allen möglichen Abhängigkeiten.
Falls du dich aus irgendeinem Grund gegen die Nutzung von PKG_PATH entscheiden solltest, ist es trotzdem möglich, die absolute Angabe eines Pakets auf der Kommandozeile anzugeben. Diese absolute Angabe kann ein lokaler Pfad oder eine URL sein, die auf FTP-, HTTP- oder SCP-Pfade verweist. Lass uns im nächsten Beispiel eine Installation über FTP ansehen:
$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/5.2/packages/`machine -a`/screen-4.0.3p1.tgz screen-4.0.3p1: complete
In diesem Beispiel wurde die Option -v nicht verwendet, sodass nur die notwendigen Nachrichten angezeigt werden. Achte darauf, dass der vollständige Dateiname angegeben werden muss, indem man ein .tgz-Suffix anhängt. Du kannst jedoch auch wie in den vorherigen Beispielen auf dieses Suffix verzichten, da es automatisch durch pkg_add(1) hinzugefügt wird.
Hinweis: Nicht alle Architekturen verfügen über die gleichen Pakete. Einige Portierungen funktionieren nur auf bestimmten Architekturen; außerdem beschränkt die Leistung bestimmter Architekturen die Anzahl der Pakete, die auf diesen kompiliert werden kann.
Bei der Installation eines Pakets, das du zuvor schon installiert (oder eine frühere Version) und entfernt hast, wird pkg_add(1), um sicherzugehen, keine Konfigurationsdateien überschreiben, die du verändert hast. Stattdessen wird es dich über diese wie folgt informieren (jedoch nur, wenn du die Option -v angegeben hast!):
Manchmal kann es sein, dass du einen Fehler wie in dem folgenden Beispiel siehst:$ sudo pkg_add -v screen-4.0.3p1 parsing screen-4.0.3p1 The existing file /etc/screenrc has NOT been changed** | 71% It does NOT match the sample file /usr/local/share/examples/screen/screenrc You may wish to update it manually screen-4.0.3p1: complete
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.14p0: complete
xv-3.10ap4:tiff-3.8.2p0: complete
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
tiff-3.8.2p0, jpeg-6bp3, png-1.2.14p0
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Um diese Art des Konfliktes zu lösen, musst du herausfinden, was installiert werden muss, um die benötigten Bibliotheken auf dein System zu bekommen. Es gibt mehrere Dinge, die überprüft werden sollten:
$ pkg_info aterm-0.4.2p1 color vt102 terminal emulator with transparency support bzip2-1.0.4 block-sorting file compressor, unencumbered expat-2.0.0 XML 1.0 parser written in C fluxbox-0.9.15.1p0 window manager based on the original Blackbox code gettext-0.14.6 GNU gettext imlib2-1.3.0 image manipulation library jpeg-6bp3 IJG's JPEG compression utilities libiconv-1.9.2p3 character set conversion library libltdl-1.5.22p1 GNU libtool system independent dlopen wrapper libungif-4.1.4p0 tools and library routines for working with GIF images libutf8-0.8 provides UTF-8 locale support mutt-1.4.2.2i tty-based e-mail client pcre-6.4p1 perl-compatible regular expression library png-1.2.14p0 library for manipulating PNG images screen-4.0.3p1 multi-screen window manager tcsh-6.14.00p1 extended C-shell with many useful features tiff-3.8.2p0 tools and library routines for working with TIFF images tin-1.8.2p0 threaded NNTP and spool based UseNet newsreader
Wenn der Name eines installierten Pakets angegeben wird (oder ein Pfad zu einem Paket, das installiert werden soll), wird pkg_info(1) detailliertere Informationen über dieses bestimmte Paket ausgeben.
$ sudo pkg_add -u unzip unzip-5.52p0 (extracting): complete unzip-5.52 (deleting): complete unzip-5.52p0 (installing): complete Clean shared items: complete
Der Aufruf von pkg_add(1) mit der Option -u und keinem Paketnamen wird versuchen, alle installierten Pakete zu aktualisieren.
Hinweis: Die Option -u baut auf der Umgebungsvariable PKG_PATH auf. Wenn diese nicht gesetzt ist, wird pkg_add(1) nicht in der Lage sein, Updates finden zu können.
Mehrere Einträge in PKG_PATH zu haben bedeutet nicht, dass bei Aktualisierungsvorgängen alle Einträge durchsucht werden. Stattdessen wird pkg_add(1) beim ersten Pfad aufhören, der passende Kandidaten vorweist.
Wenn du eine Konfigurationsdatei für die alte Version hattest, die du auch geändert hast, wird sie standardmäßig nicht modifiziert. Du kannst sie jedoch mit der Standardkonfigurationsdatei der neuen Version überschreiben, indem du pkg_add(1) mit der Option -c aufrufst.
Um ein Paket zu deinstallieren, nimm einfach den richtigen Namen des Pakets, der beim Aufruf von pkg_info(1) angezeigt wird (siehe Installierte Pakete auflisten weiter oben) und verwende pkg_delete(1), um Pakete zu entfernen. In dem folgenden Beispiel wird das Paket screen deinstalliert. Beachte, dass es manchmal sein kann, dass es weitere Anweisungen für die Deinstallation von weiteren Dingen gibt, die pkg_delete(1) nicht für dich ausführt. Wie es auch mit dem Werkzeug pkg_add(1) der Fall ist, kannst du die Option -v verwenden, um mehr Informationen in der Ausgabe zu erhalten.
$ sudo pkg_delete screen screen-4.0.3p1: complete Clean shared items: complete
Hinweis: Oft ist es nicht notwendig, die Versionsnummern und die Aromata mit dem Paketnamen anzugeben, da pkg_delete(1) normalerweise in der Lage ist, diese Namen selbstständig herauszufinden. Du musst den kompletten Paketnamen (in diesem Fall wäre das screen-4.0.3p1) nur dann angeben, wenn eine Verwechslung aufgrund von mehreren installierten Paketen mit dem angegebenen Namen möglich wäre; in dem Fall kann pkg_delete(1) nicht wissen, welches Paket deinstalliert werden soll.
Konfigurationsdateien werden von pkg_delete(1) nicht gelöscht, falls sie geändert wurden - um sicherzugehen. Stattdessen wird es dich darüber wie folgt informieren:
$ sudo pkg_delete screen screen-4.0.3p1: complete Clean shared items: complete --- screen-4.0.3p1 ------------------- You should also remove /etc/screenrc (which was modified)
Wenn du möchtest, dass diese Konfigurationsdateien automatisch deinstalliert werden, kannst du das tun, indem du die Option -c angibst.
$ sudo pkg_add screen-4.0.3p1 screen-4.0.3p1: complete Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8 /usr/sbin/pkg_add: Installation of screen-4.0.3p1 failed , partial installation recorded as partial-screen-4.0.3p1
Es ist immer eine gute Idee, teilweise installierte Pakete von deinem System zu entfernen und potenzielle Probleme zu lösen, die zu diesem Fehler geführt haben könnten. Wenn so etwas eintritt, dann ist das oft ein Zeichen dafür, dass du kein ordentliches System hast, das vollständig nur von Paketen aus installiert wurde, sondern mit Software vermischt wurde, die du direkt vom Quelltext aus übersetzt hast.
WICHTIGER HINWEIS: Der Portierungsbaum ist nur für erfahrene Anwender gedacht. Es wird jedem nahegelegt, die vorkompilierten Binärpakete zu verwenden. Frage NICHT Anfängerfragen auf der Mailingliste wie zum Beispiel "How can I get the ports tree working?". Wenn du Fragen über den Portierungsbaum hast, dann wird vorausgesetzt, dass du die Handbuchseiten und diese FAQ gelesen hast, und dass du in der Lage bist, mit ihm zu arbeiten.
Neben dem Makefile beinhaltet jede Portierung ebenfalls mindestens folgende Dinge:
All diese Informationen werden in einer Verzeichnishierarchie unter /usr/ports gespeichert. Die Hierarchie besteht aus drei speziellen Unterverzeichnissen:
Wenn ein Benutzer make(1) in einem Unterverzeichnis einer speziellen Portierungen aufruft, dann wird das System rekursiv den Abhängigkeitsbaum durchgehen und prüfen, ob alle benötigten Abhängigkeiten bereits installiert wurden, die fehlenden Abhängigkeiten übersetzen und installieren und dann mit der Erzeugung der gewünschten Portierung fortsetzen. All dies passiert in dem Arbeitsverzeichnis, das die Portierung erstellt. Normalerweise ist dies unterhalb von ${WRKOBJDIR}, das den Standardwert /usr/ports/pobj hat, was aber überschrieben werden kann (siehe Konfiguration des Portierungssystems). Wenn WRKOBJDIR explizit entfernt wurde, so wird stattdessen ein Unterverzeichnis des Portierungs-Hauptverzeichnisses (Paketname mit vorangestelltem »w-«) benutzt.
Hinweis: Portierungen werden niemals direkt auf deinem System installiert! Sie verwenden ein Scheininstallationsverzeichnis. Alles, was dort installiert wird, wird in ein Paket zusammengefasst (welches dann im Unterverzeichnis packages/ des Portierungsbaums abgelegt wird, wie es zuvor beschrieben wurde). Eine Portierung zu installieren bedeutet daher in Wirklichkeit: Ein Paket erstellen und dann dieses installieren!
Weitere Informationen über das Portierungssystem können in diesen Handbuchseiten gefunden werden:
| Quelle | Form | Aroma | |||
| -release | -stable | Schnappschuss | -current | ||
| CD-ROM | .tar.gz | x | - | - | - |
| FTP-Spiegelserver | .tar.gz | x | - | x | - |
| AnonCVS | cvs checkout | x | x | - | x |
Auf der CD-ROM und den FTP-Spiegelservern musst du nach einer Datei mit dem namen ports.tar.gz suchen. Du solltest die Datei in das Verzeichnis /usr/ entpacken, womit du /usr/ports und alle dazugehörigen Unterverzeichnisse erstellst. Zum Beispiel:
$ cd /tmp $ ftp ftp://ftp.openbsd.org/pub/OpenBSD/5.2/ports.tar.gz $ cd /usr $ sudo tar xzf /tmp/ports.tar.gz
Die Schnappschüsse, die auf den FTP-Spiegelservern vorliegen, werden täglich vom Portierungsbaum -current erstellt. Diese Schnappschüsse kannst du im Verzeichnis pub/OpenBSD/snapshots finden. Wenn du einen Schnappschuss des Portierungsbaums verwendest, dann solltest du einen dazu passenden OpenBSD-Schnappschuss haben. Stelle sicher, dass du deinen Portierungsbaum und dein OpenBSD-System synchron hälst!
Lies bitte die AnonCVS-Seite, die eine Liste aller verfügbaren Server und einige Beispiele bereitstellt, wenn du weitere Informationen über das Beziehen des Portierungsbaum per AnonCVS hast.
HINWEIS: Dieses Kapitel führt einige zusätzliche systemweite Einstellungen für das Erzeugen von Applikationen aus den Portierungen ein. Du kannst dieses Kapitel überspringen, doch musst du dann viele der make(1)-Ausdrücke in den Beispielen als root ausführen.
Da dem OpenBSD-Projekt nicht genügend Ressourcen zur Verfügung stehen, um den gesamten Quelltext der Software aus dem Portierungsbaum zu überprüfen, kannst du das Portierungssystem so konfigurieren, dass einige weitere Sicherheitsmaßnahmen genutzt werden. Die Portierungs-Infrastruktur ist in der Lage, die gesamte Erzeugung als normaler Benutzer auszuführen; nur die Schritte, die Superuserrechte benötigen, werden als root ausgeführt. Beispiele hierfür sind die Make-Targets fake und install. Weil die Rootrechte jedoch immer irgendwann notwendig sind, wird dich das Portierungssystem nicht schützen können, wenn du dich für die Installation einer bösartigen Software entschieden hast.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
Dies zwingt die Erzeugungsphase dazu, in den erlaubten Verzeichnissen zu bleiben und verbietet das Schreiben auf ungültige Positionen. Hierdurch wird die Gefahr, dass das System beschädigt werden könnte, deutlich verringert. Beachte aber, dass systrace(2) die Zeit, die zum Erzeugen der Portierungen benötigt wird, um ungefähr 20 % verlängert.USE_SYSTRACE=Yes
Es ist auch möglich, einen schreibgeschützten Portierungsbaum zu nutzen, indem man die Verzeichnisse trennt, die während der Erzeugung der Portierung Schreibrechte haben müssen:
Wenn du möchtest, dann kannst du auch den Besitzer dieser Verzeichnisse auf deinen lokalen Benutzernamen und deine Gruppe ändern, sodass das Portierungssystem die Unterverzeichnisse als regulärer Benutzer anlegen kann.WRKOBJDIR=/usr/obj/ports DISTDIR=/usr/distfiles PACKAGE_REPOSITORY=/usr/packages
Das Suchergebnis gibt dir einen schönen Überblick über jede einzelne Applikation, die gefunden wurde: der Name der Portierung, der Pfad zur Portierung, eine einzeilige Beschreibung, den Verantwortlichen der Portierung, der Portierung zugewiesene Schlüsselwörter, Bibliotheken/Erzeugungs/Laufzeitabhängigkeiten und die Architekturen, bei denen bekannt ist, dass die Portierung auf ihnen läuft.$ cd /usr/ports $ make search key=rsnapshot Port: rsnapshot-1.3.1p0 Path: net/rsnapshot Info: remote filesystem snapshot utility Maint: Antoine Jacoutot <ajacoutot@openbsd.org> Index: net sysutils L-deps: B-deps: :net/rsync R-deps: :devel/p5-Lchown :net/rsync Archs: any
Dieser Mechanismus ist allerdings ein recht simpler, da er nur awk(1) auf die Indexdatei der Portierung anwendet. Mit OpenBSD 4.0 wurde eine neue Portierung namens »sqlports« erstellt, die genaue Suchanfragen mit SQL erlaubt. Es handelt sich dabei um eine SQLite-Datenbank, doch kann mit der Portierungs-Infrastruktur im Grunde jedes Datenbankformat erstellt werden.
Benutze einfach pkg_add(1), um das Paket sqlports hinzuzufügen. Eine Beispielsitzung könnte wie folgt aussehen:
Dieses Beispiel zeigt noch immer eine sehr einfache Suche. Mit SQL kann aber alles durchsucht werden: Abhängigkeiten, Configureoptionen, Shared Librarys etc.$ sqlite3 /usr/local/share/sqlports SQLite version 3.3.12 Enter ".help" for instructions sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%'; Guppi-0.40.3p1|GNOME-based plot program with statistics capabilities mailgraph-1.12|a RRDtool frontend for Postfix statistics R-2.4.1|clone of S, a powerful math/statistics/graphics language py-probstat-0.912p0|probability and statistics utilities for Python darkstat-3.0.540p1|network statistics gatherer with graphs pfstat-2.2p0|packet filter statistics visualization tcpstat-1.4|report network interface statistics wmwave-0.4p2|Window Maker dockapp to display wavelan statistics diffstat-1.43p0|accumulates and displays statistics from a diff file sqlite>
$ cd /usr/ports/net/rsnapshot $ make install ===> Checking files for rsnapshot-1.2.9 >> rsnapshot-1.2.9.tar.gz doesn't seem to exist on this system. >> Fetch http://www.rsnapshot.org/downloads/rsnapshot-1.2.9.tar.gz. 100% |**************************************************| 173 KB 00:02 >> Size matches for /usr/ports/distfiles/rsnapshot-1.2.9.tar.gz >> Checksum OK for rsnapshot-1.2.9.tar.gz. (sha1) ===> rsnapshot-1.2.9 depends on: rsync-2.6.9 - not found ===> Verifying install for rsync-2.6.9 in net/rsync ===> Checking files for rsync-2.6.9 >> rsync-2.6.9.tar.gz doesn't seem to exist on this system. >> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.9.tar.gz. 100% |**************************************************| 792 KB 00:31 >> Size matches for /usr/ports/distfiles/rsync-2.6.9.tar.gz >> Checksum OK for rsync-2.6.9.tar.gz. (sha1) ===> Verifying specs: c ===> found c.40.3 ===> Extracting for rsync-2.6.9 ===> Patching for rsync-2.6.9 ===> Configuring for rsync-2.6.9 [... Schnipp ...] ===> Building for rsync-2.6.9 [... Schnipp ...] ===> Faking installation for rsync-2.6.9 [... Schnipp ...] ===> Building package for rsync-2.6.9 Link to /usr/ports/packages/i386/ftp/rsync-2.6.9.tgz Link to /usr/ports/packages/i386/cdrom/rsync-2.6.9.tgz ===> Installing rsync-2.6.9 from /usr/ports/packages/i386/all/rsync-2.6.9.tgz rsync-2.6.9: complete ===> Returning to build of rsnapshot-1.2.9 ===> rsnapshot-1.2.9 depends on: rsync-2.6.9 - found ===> Extracting for rsnapshot-1.2.9 ===> Patching for rsnapshot-1.2.9 ===> Configuring for rsnapshot-1.2.9 [... Schnipp ...] ===> Building for rsnapshot-1.2.9 [... Schnipp ...] ===> Faking installation for rsnapshot-1.2.9 [... Schnipp ...] ===> Building package for rsnapshot-1.2.9 Link to /usr/ports/packages/i386/ftp/rsnapshot-1.2.9.tgz Link to /usr/ports/packages/i386/cdrom/rsnapshot-1.2.9.tgz ===> rsnapshot-1.2.9 depends on: rsync-2.6.9 - found ===> Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz rsnapshot-1.2.9: complete
Wie du sehen kannst macht das Portierungssystem viele Dinge automatisch. Es bezieht, extrahiert und korrigiert den Quelltext, konfiguriert und erzeugt (kompiliert) den Quelltext, installiert die Dateien in ein Scheinverzeichnis, erstellt ein Paket (mit Bezug auf die Paketliste) und installiert das Paket auf dein System (normalerweise unter /usr/local/). Das Portierungssystem macht das sogar rekursiv für alle Abhängigkeiten der Portierung. Achte einfach mal auf die Zeilen »===> Verifying install for ...« und »===> Returning to build of ...« der vorherigen Ausgabe, die auf das Durchlaufen des Abhängigkeitsbaum deuten.
Wenn bereits eine vorherige Version der Applikation, die du installieren möchtest, auf deinem System installiert wurde, kannst du make update an Stelle von make install aufrufen. Hiermit übergibst du pkg_add(1) die Option -r.
Hinweis: Große Applikationen werden viele Systemressourcen für die Erzeugung benötigen. Gute Beispiele hierfür sind Compiler wie GCC 4.0 oder Java 2 Software Development Kit. Wenn du Fehlermeldungen wie »out of memory« bei der Erzeugung einer solchen Portierung erhältst, geschah das meist aus einem dieser beiden Gründe:
Zusätzlich kannst du auch die Arbeitsverzeichnisse aller Abhängigkeiten der Portierung mit diesem Make-Target aufräumen:$ make clean ===> Cleaning for rsnapshot-1.2.9
Wenn du das Set oder die Sets der Quelltextdistribution der Portierung löschen möchtest, würdest du Folgendes aufrufen:$ make clean=depends ===> Cleaning for rsync-2.6.9 ===> Cleaning for rsnapshot-1.2.9
Falls du mehrere Aromata der gleichen Portierung kompiliert hast, kannst du das Arbeitsverzeichnis aller Aromata auf einmal aufräumen:$ make clean=dist ===> Cleaning for rsnapshot-1.2.9 ===> Dist cleaning for rsnapshot-1.2.9
Du kannst auch eine spezielle Variable setzen, mit der automatisch nach der Übersetzung aufgeräumt wird. Arbeitsverzeichnisse werden somit automatisch nach der Erstellung eines Pakets geleert:$ make clean=flavors
$ make package BULK=Yes
Dies wird pkg_delete(1) so aufrufen, dass das zugehörige Paket von deinem System entfernt wird. Wenn du möchtest, dann kannst du mit folgendem Aufruf das Paket einer Portierung deinstallieren und zugleich wieder neu installieren:$ make uninstall ===> Deinstalling for rsnapshot-1.2.9 rsnapshot-1.2.9: complete Clean shared items: complete
Wenn du einfach nur die Pakete loswerden willst, die du gerade erzeugt hast, kannst du dies wie folgt tun:$ make reinstall ===> Cleaning for rsnapshot-1.2.9 /usr/sbin/pkg_delete rsnapshot-1.2.9 rsnapshot-1.2.9: complete Clean shared items: complete ===> Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz rsnapshot-1.2.9: complete
$ make clean=packages ===> Cleaning for rsnapshot-1.2.9 rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
Der erste Mechanismus wird Aroma (»Flavor«) genannt. Ein Aromata verweist normalerweise auf einen bestimmten Satz Kompilationsoptionen. Zum Beispiel haben einige Applikationen ein no_x11-Aromata, das auf Systemen ohne X genutzt werden kann. Einige Shells haben ein static-Aromata, das eine statisch gelinkte Version erzeugen wird. Es gibt Portierungen, die verschiedene Aromata für die Erzeugung mit unterschiedlichen grafischen Toolkits besitzen. Andere Beispiele sind u. a.: Unterstützung für verschiedene Datenbankformate, verschiedene Netzwerkoptionen (SSL, IPv6, ...), verschiedene Papierformate etc.
Zusammenfassung: Am wahrscheinlichsten wirst du Aromata verwenden, wenn ein Paket nicht für das Aroma bereitgestellt wurde, nach dem du suchst. In diesem Fall musst du das gewünschte Aroma angeben und selbst die Portierung erzeugen.
Die meisten Aromata haben ihr eigenes Arbeitsverzeichnis während der Erzeugungsphase; ebenfalls wird jedes Aroma in ein Paket mit dem zum Aroma gehörigen Namen gepackt, um Verwechslungen mit anderen auszuschließen. Um die Aromata einer bestimmten Portierung anzeigen zu lassen, würdest du in das Unterverzeichnis wechseln und Folgendes aufrufen:
Wirf auch einen Blick in die DESCR-Dateien der Portierungen; mit ihnen sollen die verfügbaren Aromata erklärt werden.$ make show=FLAVORS
Der zweite Mechanismus wird Unterpakete genannt. Ein Portierer könnte entscheiden, dass Unterpakete für verschiedene Teile der gleichen Applikation erstellt werden, falls diese logisch getrennt werden können. Dir werden oft Unterpakete für den Client- und für den Serverteil eines Programmes begegnen. Manchmal wird auch sehr ausgiebige Dokumentation in ein separates Unterpaket gebündelt, da dieses viel Plattenspeicher in Anspruch nimmt. Ebenfalls werden zusätzliche Funktionalitäten in eigene Pakete ausgelagert, falls diese eine große Anzahl zusätzlicher Abhängigkeiten mit sich bringen. Der Portierer entscheidet ebenfalls, welches Unterpaket das Haupt-Unterpaket ist und somit standardmäßig installiert wird. Andere Beispiele sind: ausgiebige Testumgebungen, die mit der Software ausgeliefert werden, separate Module mit Unterstützung für unterschiedliche Dinge etc.
Zusammenfassung: Einige Portierungen werden in mehrere Pakete aufgeteilt. Mit make install wird nur das Haupt-Unterpaket installiert.
Um die unterschiedlichen Pakete anzuzeigen, die von einer Portierung erzeugt werden, verwende:
$ make show=PKGNAMES
Mit make install wird nur das erste Unterpaket installiert. Um alle zu installieren, verwende:
$ make install-all
Um die verschiedenen verfügbaren Unterpakete für eine Portierung anzuzeigen, verwende:
Es ist möglich, auszuwählen, welche Unterpakete vom Portierungsbaum aus installiert werden soll - das Gleiche gilt für mehrere Unterpakete. Nach einigen Tests wird ein pkg_add(1)-Aufruf erfolgen, der das gewünschte Unterpaket (oder die gewünschten Unterpakete) installiert.$ make show=MULTI_PACKAGES
$ env SUBPACKAGE="-server" make install
Hinweis: Der Unterpaket-Mechanismus verarbeitet nur Pakete - es werden keine Konfigurationsoptionen vor dem Erzeugen der Portierung geändert. Du müsstest hierfür Aromata verwenden.
wird die Liste der pkgpaths (pkgpath(7)) in ~/localports lesen und alle Pakete bauen. Es kann die Pakete auch installieren, nachdem sie kompiliert wurden. ~/localports würde in etwa so aussehen:/usr/ports/infrastructure/bin/dpb -P ~/localports
Wenn keine Liste von zu kompilierenden Portierungen auf der Kommandozeile, oder aber durch die Optionen -P oder -I angegeben wurde, so kompiliert dpb(1) den kompletten Portierungsbaum.net/cvsync www/mozilla-firefox net/rsync net/nfsen textproc/mupdf misc/magicpoint lang/sbcl editors/emacs23
Dies bedeutet, dass du lediglich darauf achten musst, dass du den korrekten Branch des Portierungsbaums verwendest und die gewünschte Software von diesem aus erzeugst. Halte deinen Baum mit CVS aktuell, und dich zusätzlich in der Mailingliste ports-changes einschreiben, um über sicherheitsbezogene Ankündigungen, die die Software im Portierungsbaum betrifft, auf dem Laufenden gehalten zu werden.
Selbstverständlich landen die Sicherheitsupdates erst im Portierungsbaum -current, bevor sie in den -stable-Zweig übernommen werden.
Um damit zu beginnen, signierte Pakete zu kompilieren, müssen wir zuerst ein (selbst signiertes) Wurzelzertifikat inklusive Schlüssel erzeugen, um damit als Zertifizierungsautorität (»root CA«, »Certificate Authority«) fungieren zu können. Für dieses Beispiel benutzen wir eine Gültigkeit von zehn Jahren.
Nun erzeugen wir ein Kompilations-Zertifikat mit Schlüssel, welche benutzt werden, um unsere Pakete zu signieren. Für das Beispiel benutzen wir eine Gültigkeit von einem Jahr. Wir erzeugen ebenfalls eine entsprechende Zertifikats-Signierungsanfrage, welche von unserer Zertifizierungsautorität zur Signierung des Zertifikats benutzt werden wird.# openssl req -x509 -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/pkgca.key -out /etc/ssl/pkgca.pem
Nun signieren wir das Zertifikat mit Hilfe der Zertifizierungsautorität, die wir im ersten Schritt erzeugt haben.# openssl genrsa -out /etc/ssl/private/pkg.key 2048 # openssl req -new -key /etc/ssl/private/pkg.key -out /etc/ssl/private/pkg.csr
# openssl x509 -req -days 365 -in /etc/ssl/private/pkg.csr -CA /etc/ssl/pkgca.pem -CAkey /etc/ssl/private/pkgca.key -CAcreateserial -out /etc/ssl/pkg.crt # rm /etc/ssl/private/pkg.csr
Zuletzt fügen wir die folgenden Zeilen zu /etc/mk.conf hinzu, um standardmäßig signierte Pakete zu bauen.
PKG_CREATE=/usr/sbin/pkg_create -s x509 -s /etc/ssl/pkg.crt -s /etc/ssl/private/pkg.key
Wenn signierte Pakete installiert werden, wird man eine zusätzliche Zeile am Ende der Ausgabe sehen, die über die Anzahl der signierten Pakete informiert, die gerade installiert wurden.
$ sudo pkg_add vte-0.24.3.tgz vte-0.24.3: ok Packages with signatures: 1
Wenn man in Schwierigkeiten mit signierten Paketen gerät (z. B. ein abgelaufenes Zertifikat ...), so kann man eine (erneute) Installation und/oder Entfernung mit Hilfe eines der folgenden Kommandos erzwingen (je nachdem, was erreicht werden soll):
$ sudo pkg_add -r -D installed PKGNAME $ sudo pkg_add -D nosig PKGNAME $ sudo pkg_delete -q PKGNAME
Es ist sehr wahrscheinlich, dass du ein System und einen Portierungsbaum verwendest, die nicht synchron sind.
Bitte was?
Ein weiterer häufiger Grund ist eine fehlende X11-Installation. Selbst wenn die Portierung, den du übersetzen willst, keine direkte X11-Abhängigkeit vorweist, so könnten Unterpakete oder weitere Abhängigkeiten X11-Header und -Bibliotheken voraussetzen. Übersetzen von Portierungen auf Systemen ohne X11 wird daher nicht unterstützt. Solltest du dennoch darauf bestehen, bist du auf dich allein gestellt und musst Fehler selbst herausfinden. Für viele Portierungen gibt es dennoch »no_x11«-Pakete, die du auch ohne X11 auf deinem System installieren kannst.
WARNUNG: Mische NIEMALS Versionen der Portierungen und von OpenBSD!
Tätest du das, so würdest du früher oder später (aber vermutlich sogar schon sehr früh) dir selbst Kopfzerbrechen bereiten, da du alle möglichen Fehler beheben müsstest.
Was solls, alles was ich hier habe ist -current!
Die Portierungs-Kollection ist ein Projekt von Freiwilligen. Manchmal hat das Projekt einfach nicht genügend Entwicklerressourcen, um alles auf dem neuesten Stand zu halten. Entwickler beschäftigen sich meist mit dem, was sie selbst als interessant ansehen und testen es in ihrer Umgebung. Einige individuelle Portierungen können gerade deshalb hinter den Mainstreamversionen liegen. Wichtiger noch, nicht auf die neueste Version zu aktualisieren ist oftmals eine absichtliche Entscheidung. Die neuere Version könnte Probleme haben, die der Betreuer zu beheben versucht, oder schlichtweg die Anwendung, verglichen mit der alten Version, verschlechtert haben. Außerdem könnte OpenBSD andere Ziele haben, als die Entwickler anderer Projekte, was manchmal dazu führt, dass Funktionalitäts-, Entwurfs- oder Implementierungsentscheidungen getroffen werden, die aus Sicht der OpenBSD-Entwickler nicht wünschenswert sind. Die Aktualisierung mag auch einfach aus dem Grund verschoben worden sein, dass die neue Version nicht als entscheidende Aktualisierung betrachtet wird.
Wenn du wirklich die neuere Version einer Portierung benötigst, so solltest du ihren Betreuer bitten, sie zu aktualisieren (siehe weiter unten, wie man herausfindet, wer der Betreuer einer Portierung ist). Wenn du helfen kannst, umso besser.
Du kannst helfen. Ziehe das Erstellen einer eigenen Portierung in Betracht. Es gibt einige Dokumentationen darüber: das OpenBSD Portiererhandbuch. Lies es - und lies es wieder. Insbesondere den Teil über das Verwalten deiner Portierungen. Versuche dann, eine eigene Portierung zu erstellen und teste sie sorgfältig Schritt für Schritt. Wenn sie schlussendlich einwandfrei für dich arbeitet, sende ihn an die Portierungs-Mailingliste ports@openbsd.org. Die Chancen, eine Rückmeldung und Testberichte von anderen Leuten zu erhalten, stehen gut. Wenn die Tests erfolgreich sind, so wird eine Aufnahme deiner Portierung in den Baum in Betracht gezogen.
Weitere Antworten hierzu können ebenfalls in der FAQ 1 gefunden werden.
Das Erzeugen einer komplexen Applikation vom Quelltext aus ist nicht trivial. Nicht nur muss die Applikation kompiliert werden, auch die Werkzeuge, die während der Erzeugung genutzt werden, müssen übersetzt werden. Leider entwickeln sich OpenBSD, die Werkzeuge und die Applikationen ständig weiter; oft ist es schwer, alle Teile zusammenfügen zu können. Wenn dann alles läuft, könnte eine Revision eines der Teile wieder alles zunichte machen. Alle sechs Monate wird ein neues Release von OpenBSD veröffentlicht. Es gibt Bemühungen, das Erzeugen jeder einzelnen Portierung auf allen Plattformen gewährleisten zu können, doch ist es während dem Entwicklungszyklus sehr wahrscheinlich, dass das mit einigen Portierungen nicht funktioniert.
Neben der Zusammenstellung aller Teile ist es eine Frage der benötigten Zeit und der Ressourcen, einige der Applikationen vom Quelltext aus zu übersetzen. Applikationen wie zum Beispiel Mozilla oder KDE können Stunden und riesige Mengen Plattenspeicher und RAM/Swap während der Erzeugung in Anspruch nehmen. Warum willst du dir das alles antun und die Zeit opfern, wenn die Programme bereits kompiliert vorliegen und auf deiner CD-ROM oder auf einem FTP-Spiegelserver darauf warten, installiert zu werden?
Selbstverständlich gibt es in einigen Fällen ein paar gute Gründe, Portierungen anstatt der Pakete zu verwenden:
$ cd /usr/ports/archivers/unzip $ make show=MAINTAINER
Alternativ dazu, falls kein Verantwortlicher angegeben ist oder du ihn/sie nicht erreichen kannst, sende eine E-Mail an die OpenBSD-Portierungs-Mailingliste ports@openbsd.org. Bitte verwende NICHT die misc@openbsd.org-Mailingliste für Portierungsbezogene Fragen.
Stelle in jedem Fall Folgendes bereit:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/bin/portslogger \
~/portslogs
Alternativ dazu kannst du auch Folgendes machen:
Hardwarespenden können dazu beitragen, Portierungen auf den verschiedenen Plattformen zu testen, auf denen OpenBSD läuft.
Hinweis: Für alle Erstellungen von neuen Portierungen und das subsequente Testen, oder für das Testen von Portierungsaktualisierungen musst du ein -current-System verwenden! Generell ist das aufgrund der ständigen Änderungen keine schöne Grundlage, sodass du dir sicher sein solltest, ob du -current ständig folgen willst.
[FAQ-Index] [Zum Kapitel 14 - Festplattenkonfiguration]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org