![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 14 - Platteneinrichtung]
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 libraries« hält, die Software sicherer machen, wenn das möglich ist, etc.
Das Endergebnis dieser Portierungsbemühung ist ein Binarypackage, das direkt installiert werden kann. Das Ziel des Package-Systems ist es, die Installation der Software zu vermerken, so dass 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 Package-System 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 Packages bereits kompiliert wurden und nun bereitstehen, um auf einem OpenBSD-System eingesetzt werden zu können. Innerhalb von Minuten kann eine große Anzahl Packages heruntergeladen und installiert werden - und alles landet an der richtigen Stelle.
Die Packages- und Ports-Kollektionen unterliegen NICHT der gründlichen Sicherheitsüberprüfung, die für das OpenBSD-Basissystem gilt. Obwohl wir danach streben, die Qualität der Packageskollektion auf hohem Niveau zu halten, stehen zu wenig Entwickler bereit, um die gleiche Robustheit und Sicherheit zu gewährleisten. Selbstverständlich werden so schnell wie möglich Sicherheitsupdates für unterschiedlichste Applikationen eingepflegt; auch die dazugehörigen Sicherheitsupdates für die Packages werden ebenfalls wie weiter unten erklärt bereitgestellt.
Packages sind die vorkompilierten Binaries von einigen der am meist genutzten Software von Drittanbietern. Packages 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. Genausogut 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.
Packages wirken wie einfache .tgz-Bündel. Im Grunde genommen sind sie es auch doch gibt es einen wichtigen Unterschied: sie enthalten zusätzliche Packageinformationen. 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 Packages suchen und ebenfalls alle notwendigen Abhängigkeiten des Packages automatisch herunterladen und installieren.
Eine Liste möglicher Orte, von wo aus Packages 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/3.8/packages/`machine -a`/
2. Beispiel: Installation von einem nahe gelegenen FTP-Mirror
$ export PKG_PATH=ftp://your.ftp.mirror/OpenBSD/3.8/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). Jedes Verzeichnis in der PKG_PATH-Variable MUSS JEDOCH 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 Package gefunden wurde. Wenn das Package 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 Snapshots verwendest, musst du natürlich »3.8« gegen »snapshots« austauschen.
Wenn du den Ports-Tree auf deinem System hast, dann kannst du das Package sehr schnell aufspüren, indem du nach ihm suchst wie es in Den Ports-Tree durchsuchen beschrieben steht.
Es wird dir auffallen, dass bestimmte Packages in verschiedenen Variationen vorliegen; formal Flavors genannt. Andere sind Teile der gleichen Applikation, die separat installiert werden könnten; diese werden Subpackages genannt. Das ganze wird in der Sektion Flavors und Subpackages verwenden genauer erläutert, doch bedeutet Flavor im Grunde nichts anderes, als dass sie mit anderen Optionen konfiguriert wurden. Momentan haben viele Packages Flavors; beispielsweise Datenbankunterstützung, Unterstützung für Systeme ohne X oder weitere Netzwerkfunktionalitäten wie SSL und IPv6 bereitstellen. Jedes Flavor eines Packages hat einen anderen Suffix im Packagenamen. Detailliertere Informationen über Packagenamen können in packages-specs(7) gefunden werden.
Hinweis: Nicht alle möglichen Packages 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 Flavors für einen Port 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 den Port vom Quelltext aus übersetzen. Weitere Informationen darüber, wie du das machst, kannst du im Kapitel Flavors und Subpackages verweden der Portssektion dieses Dokumentes nachlesen.
$ sudo pkg_add -v screen-4.0.2 parsing screen-4.0.2 installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71% screen-4.0.2: 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.
Für einige Packages 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-6.0 ghostscript-fonts-6.0: complete You may wish to update your font path for /usr/local/share/ghostscript/fonts --- ghostscript-fonts-6.0 ------------------- 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 Package 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 Packageinformationen wurden Abhängigkeiten gefunden, die nun zuerst installiert werden. Ungefähr in der Mitte kannst du sehen, wie das gettext-Package installiert wurde, welches wiederum von libiconv abhängig ist. Vor der Installation von gettext wurden seine Packageinformationen ausgelesen und sichergestellt, ob libiconv bereits installiert wurde.$ sudo pkg_add -v tin-1.6.2 parsing tin-1.6.2 Dependencies for tin-1.6.2 resolve to: gettext-0.10.40p3, libiconv-1.9.2p1, libutf8-0.7.3, pcre-4.5 (todo: libiconv-1.9.2p1,gettext-0.10.40p3,pcre-4.5,libutf8-0.7.3) tin-1.6.2:parsing libiconv-1.9.2p1 tin-1.6.2:libiconv-1.9.2p1: complete tin-1.6.2:parsing gettext-0.10.40p3 Dependencies for gettext-0.10.40p3 resolve to: libiconv-1.9.2p1 tin-1.6.2:gettext-0.10.40p3: complete tin-1.6.2:parsing pcre-4.5 tin-1.6.2:pcre-4.5: complete tin-1.6.2:parsing libutf8-0.7.3 tin-1.6.2:libutf8-0.7.3: complete tin-1.6.2: complete
Es ist möglich, mehrere Packagenamen bei einem Aufruf anzugeben, wodurch alle auf einmal installiert werden - neben allen möglichen Abhängigkeiten.
Falls aus irgendeinem Grund du dich gegen die Nutzung von PKG_PATH entscheiden solltest, ist es trotzdem möglich, die absolute Angabe eines Packages 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/3.8/packages/`machine -a`/screen-4.0.2.tgz screen-4.0.2: complete
In diesem Beispiel wurde die Option -v nicht verwendet, so dass 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 Packages. Einige Ports funktionieren nur auf bestimmten Architekturen; außerdem beschränkt die Leistung bestimmter Architekturen die Anzahl der Packages, die auf diesen kompiliert werden kann.
Beim Installieren eines Packages, 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.2 parsing screen-4.0.2 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.2: complete
$ sudo pkg_add xv-3.10ap3
xv-3.10ap3:jpeg-6b: complete
xv-3.10ap3:png-1.2.8: complete
xv-3.10ap3:tiff-3.7.3: complete
Can't install xv-3.10ap3: lib not found X11.9.0
Even by looking in the dependency tree:
tiff-3.7.3, jpeg-6bp2, png-1.2.8
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.2 color vt102 terminal emulator with transparency support bzip2-1.0.3 block-sorting file compressor, unencumbered fluxbox-0.9.13 window manager based on the original Blackbox code gettext-0.10.40p3 GNU gettext imlib2-1.1.2p0 image manipulation library jpeg-6bp2 IJG's JPEG compression utilities libiconv-1.9.2p1 character set conversion library libltdl-1.5.18 GNU libtool system independent dlopen wrapper libungif-4.1.0b1 tools and library routines for working with GIF images libutf8-0.7.3 provides UTF-8 locale support mutt-1.4.2ip0 tty-based e-mail client ncftp-3.1.9 ftp replacement with advanced user interface pcre-4.5 perl-compatible regular expression library png-1.2.8 library for manipulating PNG images screen-4.0.2 multi-screen window manager tcsh-6.13.00 extended C-shell with many useful features tiff-3.7.3 tools and library routines for working with TIFF images tin-1.6.2 threaded NNTP and spool based UseNet newsreader
Wenn der Name eines installierten Packages angegeben wird (oder ein Pfad zu einem Package, das installiert werden soll), wird pkg_info(1) detailliertere Informationen über dieses bestimmte Package ausgeben.
Angenommen, du hättest eine ältere Version von unzip installiert, bevor du diesen Rechner von OpenBSD 3.7 auf 3.8 upgegradet hast. Die Option -u kann verwendet werden, um den neuen Packagenamen zu ermitteln (insbesondere die neue Versionsnummer), indem ich Folgendes ausführe:
Nun kannst du auf einfache Art und Weise auf das neue 3.8-Package upgraden, indem du diesen Anweisungen folgst und das alte Package in einem Zug ersetzen wirst:$ sudo pkg_add -u unzip Updating unzip-5.51 -> unzip-5.52 Update using pkg_add -r unzip-5.52
$ sudo pkg_add -r unzip-5.52 unzip-5.52 (extracting): complete unzip-5.51 (deleting): complete unzip-5.52 (installing): complete Clean shared items: complete
Das Aufrufen von pkg_add(1) mit der Option -u und keinem Packagenamen wird alle installierten Packages auf aktualisierte Versionen hin überprüfen.
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.
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 jdoch mit der Standardkonfigurationsdatei der neuen Version überschreiben, indem du pkg_add(1) mit der Option -c aufrufst.
Das hier beschriebene ist ein handlicher Weg, um ein Package schnell auf eine neue Version upzugraden. In 99 % der Fälle gibt es auch keine Probleme dabei. Einige der sehr komplizierten Software benötigt jedoch weiterhin die alte Methode, d. h. erst das alte Package entfernen und dann das neue Package installieren. Dies ist recht unpraktisch, da Packages Abhängigkeiten sein können und du dann einen ganzen Subbereich von Packages für ein Update deinstallieren müsstest.
Um ein Package zu deinstallieren, nimm einfach den richtigen Namen des Packages, der beim Aufruf von pkg_info(1) angezeigt wird (siehe Installierte Packages auflisten weiter oben) und verwende pkg_delete(1), um Packages zu entfernen. In dem folgenden Beispiel wird das screen-Package 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.2: complete Clean shared items: complete
Hinweis: Oft ist es nicht notwendig, die Versionsnummern und die Flavors mit dem Packagenamen anzugeben, da pkg_delete(1) normalerweise in der Lage ist, diese Namen selbstständig herauszufinden. Du musst den kompletten Packagenamen (in diesem Fall wäre das screen-4.0.2) nur dann angeben, wenn eine Verwechslung aufgrund von mehreren installierten Packages mit dem angegebenen Namen möglich wäre; in dem Fall kann pkg_delete(1) nicht wissen, welches Package 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.2: complete Clean shared items: complete --- screen-4.0.2 ------------------- 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.
Bitte lies die Seite über Packages für -stable, um mehr über aktualisierte Packages und wichtige Updates für den -stable-Branch zu erfahren. Beachte, dass aktualisierte Packages nur für die i386-Plattform bereitgestellt werden. Für andere Plattformen gilt, dass sie den -stable-Branch des Ports-Trees beziehen und vom Quelltext aus übersetzen müssen.
Wenn du sicherheitsbezogene Ankündigungen in Bezug auf Software im Packages- und Ports-System erhalten möchtest, dann kannst du dich in der Mailingliste ports-security einschreiben.
Im Fall einer Packageaktualisierung werden die Namen der Packages immer geändert, um die Verwechslungsgefahr zwischen einem Package des Releases und eines fehlerbehobenen Packages zu vermeiden. Dieser Name könnte eine höhere Versionsnummer beinhalten oder, falls die Versionsnummer gleichgeblieben ist, ein pN-Suffix haben, wobei N+1 für die Anzahl der angewandten Patches für dieses Package steht.
$ sudo pkg_add screen-4.0.2 screen-4.0.2: complete 7% Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8 /usr/sbin/pkg_add: Installation of screen-4.0.2 failed , partial installation recorded as partial-screen-4.0.2
Es ist immer eine gute Idee, teilweise installierte Packages von deinem System zu entfernen und potentielle Probleme zu lösen, die zu diesem Fehler geführt haben könnten. Wenn soetwas eintritt, dann ist das oft ein Zeichen dafür, dass du kein ordentliches System hast, das vollständig nur von Packages aus installiert wurde sondern mit Software vermischt wurde, die du direkt vom Quelltext aus übersetzt hast.
WICHTIGER HINWEIS: Der Ports-Tree ist nur für erfahrene Anwender gedacht. Es wird jedem nahegelegt, die vorkompilierten Binarypackages 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 Ports-Tree hast, dann wird vorausgesetzt, dass du die Manualseiten und diese FAQ gelesen hast, und dass du in der Lage bist, mit ihm zu arbeiten.
Neben der Makefile beinhaltet jeder Port 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 eines speziellen Ports 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 des gewünschten Ports forsetzen. All dies passiert in dem Arbeitsverzeichnis, das der Port erstellt. Dies ist entweder ein Unterverzeichnis des Porthauptverzeichnisses (in diesem Fall kann es am Prefix »w-« erkannt werden) oder es ist ein Unterverzeichnis von $WRKOBJDIR, falls die Variable WRKOBJDIR gesetzt wurde (siehe Zusätzliche Konfiguration des Ports-Systems).
Hinweis: Ports werden niemals direkt auf deinem System installiert! Sie verwenden ein Scheininstallationsverzeichnis. Alles, was dort installiert wird, wird in ein Package zusammengefasst (welches dann im packages/-Unterverzeichnis des Ports-Trees abgelegt wird, wie es zuvor beschrieben wurde). Einen Port installieren bedeutet daher in Wirklichkeit: ein Package erstellen und dieses dann installieren!
Weitere Informationen über das Ports-System können in diesen Manualseiten gefunden werden:
| Quelle | Form | Flavor | |||
| -release | -stable | Snapshots | -current | ||
| CD-ROM | .tar.gz | x | - | - | - |
| FTP-Mirror | .tar.gz | x | - | x | - |
| AnonCVS | cvs checkout | x | x | - | x |
Auf der CD-ROM und den FTP-Mirrors 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/3.8/ports.tar.gz $ cd /usr $ sudo tar xzf /tmp/ports.tar.gz
Die Snapshots, die auf den FTP-Mirrors vorliegen, werden täglich vom -current-Ports-Tree erstellt. Diese Snapshots kannst du im Verzeichnis pub/OpenBSD/snapshots finden. Wenn du einen Snapshot vom Ports-Tree verwendest, dann solltest du einen dazu passenden OpenBSD-Snapshot haben. Stelle sicher, dass du deinen Ports-Tree und dein OpenBSD-System synchron hälst!
Lese bitte die AnonCVS-Seite, die eine Liste aller verfügbaren Server und einige Beispiele bereitstellt, wenn du weitere Informationen über das Beziehen des Ports-Trees per AnonCVS hast.
HINWEIS: Dieses Kapitel führt einige zusätzliche systemweite Einstellungen für das Erzeugen von Applikationen aus den Ports 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 Ports-Tree zu überprüfen, kannst du das Ports-System so konfigurieren, dass einige weitere Sicherheitsmaßnahmen genutzt werden. Die Portsinfrastruktur 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 Ports-System 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 Ports benötigt wird, um ungefähr 20 % verlängert.USE_SYSTRACE=Yes
Es ist auch möglich, einen schreibgeschützten Ports-Tree zu nutzen, indem man die Verzeichnisse trennt, die während der Erzeugung des Ports Schreibrechte haben müssen:
Wenn du möchtest, dann kannst du auch den Besitzer dieser Verzeichnisse auf deinen lokalen Benutzernamen und deine Gruppe ändern, so dass das Ports-System die Unterverzeichnisse als regulärer Benutzer anlegen kann.WRKOBJDIR=/usr/obj/ports DISTDIR=/usr/distfiles PKGREPOSITORYBASE=/usr/packages
Das Suchergebnis gibt dir einen schönen Überblick über jede einzelne Applikation, die gefunden wurde: der Portname, der Pfad zum Port, eine einzeilige Beschreibung, den Verantwortlichen des Ports, dem Port zugewiesene Schlüsselwörter, Bibliotheken-/Erzeugungs-/Laufzeitabhängigkeiten und die Architekturen, bei denen bekannt ist, dass der Port auf ihnen läuft.$ cd /usr/ports $ make search key=fetchmail Port: fetchmail-6.2.5.2 Path: mail/fetchmail Info: mail retrieval utility for POP2, POP3, KPOP, IMAP and more Maint: Federico Schwindt <fgsch@openbsd.org> Index: mail L-deps: iconv.2::converters/libiconv intl.1:gettext->=0.10.38:devel/gettext B-deps: gettext->=0.10.38:devel/gettext R-deps: gettext->=0.10.38:devel/gettext Archs: any
Wie du sehen kannst macht das Ports-System viele Dinge automatisch. Es bezieht, extrahiert und patcht den Quelltext, konfiguriert und erzeugt (kompiliert) den Quelltext, installiert die Dateien in ein Scheinverzeichnis, erstellt ein Package (mit Bezug auf die Packinglist) und installiert das Package auf dein System (normalerweise unter /usr/local/). Das Ports-System macht das sogar rekursiv für alle Abhängigkeiten des Ports. 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.$ cd /usr/ports/mail/fetchmail $ make install ===> Checking files for fetchmail-6.2.5.2 >> fetchmail-6.2.5.2.tar.gz doesn't seem to exist on this system. >> Attempting to fetch /usr/ports/distfiles/fetchmail-6.2.5.2.tar.gz from http://download.berlios.de/fetchmail/. 100% |**************************************************| 1247 KB 00:24 >> Size matches for /usr/ports/distfiles/fetchmail-6.2.5.2.tar.gz >> Checksum OK for fetchmail-6.2.5.2.tar.gz. (sha1) ===> fetchmail-6.2.5.2 depends on: gettext->=0.10.38 - not found ===> Verifying install for gettext->=0.10.38 in devel/gettext ===> Checking files for gettext-0.10.40p3 >> gettext-0.10.40.tar.gz doesn't seem to exist on this system. >> Attempting to fetch /usr/ports/distfiles/gettext-0.10.40.tar.gz from ftp://ftp.gnu.org/gnu/gettext/. 100% |**************************************************| 1321 KB 00:11 >> Size matches for /usr/ports/distfiles/gettext-0.10.40.tar.gz >> Checksum OK for gettext-0.10.40.tar.gz. (sha1) ===> gettext-0.10.40p3 depends on: iconv.2 (libiconv-*) - iconv.2 missing... ===> Verifying install for iconv.2 (libiconv-*) in converters/libiconv ===> Checking files for libiconv-1.9.2p1 >> libiconv-1.9.2.tar.gz doesn't seem to exist on this system. ttempting to fetch /usr/ports/distfiles/libiconv-1.9.2.tar.gz from ftp://ftp.gnu.org/gnu/libiconv/. 100% |**************************************************| 3828 KB 00:30 >> Size matches for /usr/ports/distfiles/libiconv-1.9.2.tar.gz >> Checksum OK for libiconv-1.9.2.tar.gz. (sha1) ===> libiconv-1.9.2p1 depends on: metaauto-0.5 - found ===> libiconv-1.9.2p1 depends on: autoconf-2.57 - found ===> Extracting for libiconv-1.9.2p1 ===> Patching for libiconv-1.9.2p1 [...snip...] ===> Configuring for libiconv-1.9.2p1 [...snip...] ===> Building for libiconv-1.9.2p1 [...snip...] ===> Faking installation for libiconv-1.9.2p1 [...snip...] ===> Building package for libiconv-1.9.2p1 Switching to /usr/ports/converters/libiconv/pkg/PFRAG.shared Link to /usr/ports/packages/i386/ftp/libiconv-1.9.2p1.tgz Link to /usr/ports/packages/i386/cdrom/libiconv-1.9.2p1.tgz ===> Installing libiconv-1.9.2p1 from /usr/ports/packages/i386/all/libiconv-1.9.2p1.tgz libiconv-1.9.2p1: complete ===> Returning to build of gettext-0.10.40p3 ===> gettext-0.10.40p3 depends on: iconv.2 (libiconv-*) - found ===> Extracting for gettext-0.10.40p3 ===> Patching for gettext-0.10.40p3 ===> Configuring for gettext-0.10.40p3 [...snip...] ===> Building for gettext-0.10.40p3 [...snip...] ===> Faking installation for gettext-0.10.40p3 [...snip...] ===> Building package for gettext-0.10.40p3 Switching to /usr/ports/devel/gettext/pkg/PFRAG.shared Link to /usr/ports/packages/i386/ftp/gettext-0.10.40p3.tgz Link to /usr/ports/packages/i386/cdrom/gettext-0.10.40p3.tgz ===> gettext-0.10.40p3 depends on: libiconv-* - found ===> Installing gettext-0.10.40p3 from /usr/ports/packages/i386/all/gettext-0.10.40p3.tgz gettext-0.10.40p3: complete ===> Returning to build of fetchmail-6.2.5.2 ===> fetchmail-6.2.5.2 depends on: gettext->=0.10.38 - found ===> fetchmail-6.2.5.2 depends on: iconv.2 (libiconv-*) - found ===> fetchmail-6.2.5.2 depends on: intl.1 (gettext->=0.10.38) - found ===> Extracting for fetchmail-6.2.5.2 ===> Patching for fetchmail-6.2.5.2 ===> Configuring for fetchmail-6.2.5.2 configure: loading site script /usr/ports/infrastructure/db/config.site checking for a BSD-compatible install... /usr/bin/install -c -o root -g bin checking whether build environment is sane... yes checking for gawk... (cached) nawk [...snip...] ===> Building for fetchmail-6.2.5.2 [...snip...] ===> Faking installation for fetchmail-6.2.5.2 [...snip...] ===> Building package for fetchmail-6.2.5.2 Link to /usr/ports/packages/i386/ftp/fetchmail-6.2.5.2.tgz Link to /usr/ports/packages/i386/cdrom/fetchmail-6.2.5.2.tgz ===> fetchmail-6.2.5.2 depends on: gettext->=0.10.38 - found ===> Installing fetchmail-6.2.5.2 from /usr/ports/packages/i386/all/fetchmail-6.2.5.2.tgz fetchmail-6.2.5.2: complete
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 eines solchen Ports erhälst, geschah das meist aus einem dieser beiden Gründe:
Zusätzlich kannst du auch die Arbeitsverzeichnisse aller Abhängigkeiten des Ports mit diesem Make-Target aufräumen:$ make clean ===> Cleaning for fetchmail-6.2.5.2
Wenn du das Set oder die Sets der Quelltextdistribution des Ports löschen möchtest, würdest du Folgendes aufrufen:$ make clean=depends ===> Cleaning for help2man-1.29 ===> Cleaning for autoconf-2.57 ===> Cleaning for metaauto-0.5 ===> Cleaning for libiconv-1.9.2p1 ===> Cleaning for gettext-0.10.40p3 ===> Cleaning for fetchmail-6.2.5.2
Falls du mehrere Flavors des gleichen Ports kompiliert hast, kannst du das Arbeitsverzeichnis aller Flavors auf einmal aufräumen:$ make clean=dist ===> Cleaning for fetchmail-6.2.5.2 ===> Dist cleaning for fetchmail-6.2.5.2
$ make clean=flavors
Dies wird pkg_delete(1) so aufrufen, dass das zugehörige Package von deinem System entfernt wird. Wenn du möchtest, dann kannst du mit folgendem Aufruf das Package eines Ports deinstallieren und zugleich wieder neu installieren:$ make uninstall ===> Deinstalling for fetchmail-6.2.5.2 fetchmail-6.2.5.2: complete Clean shared items: complete
Wenn du einfach nur das Package loswerden willst, das du gerade erzeugt hast, kannst du dies wie folgt tun:$ make reinstall ===> Cleaning for fetchmail-6.2.5.2 /usr/sbin/pkg_delete fetchmail-6.2.5.2 fetchmail-6.2.5.2: complete Clean shared items: complete ===> Installing fetchmail-6.2.5.2 from /usr/ports/packages/i386/all/fetchmail-6.2.5.2.tgz fetchmail-6.2.5.2: complete
Verwende Packages statt Package, um ebenfalls alle Subpackages zu deinstallieren (siehe das folgende Kapitel).$ make clean=Package ===> Cleaning for fetchmail-6.2.5.2 rm -f /usr/ports/packages/i386/all/fetchmail-6.2.5.2.tgz
Der erste Mechanismus wird Flavors genannt. Ein Flavor verweist normalerweise auf einen bestimmten Satz Kompilierungsoptionen. Zum Beispiel haben einige Applikationen ein no_x11-Flavor, das auf Systemen ohne X genutzt werden kann. Einige Shells haben ein static-Flavor, das eine statisch gelinkte Version erzeugen wird. Es gibt Ports, die verschiedene Flavors 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 Flavors verwenden, wenn ein Package nicht für das Flavor bereitgestellt wurde, nach dem du suchst. In diesem Fall musst du das gewünschte Flavor angeben und selbst den Port erzeugen.
Jedes Flavor eines Ports hat sein eigenes Arbeitsverzeichnis während der Erzeugungsphase; ebenfalls wird jedes Flavor in ein Package mit dem zum Flavor gehörigen Namen gepackt, um Verwechslungen mit anderen auszuschließen. Um die Flavors eines bestimmten Ports anzeigen zu lassen, würdest du in das Unterverzeichnis wechseln und Folgendes aufrufen:
$ make show=FLAVORS
Der zweite Mechanismus wird Subpackages genannt. Ein Portierer könnte entscheiden, dass Subpackages für verschiedene Teile der gleichen Applikation erstellt werden, falls diese logisch getrennt werden können. Dir werden oft Subpackages für den Client- und für den Serverteil eines Programmes begegnen. Manchmal wird auch sehr ausgiebige Dokumentation in ein separates Subpackage gebündelt, da dieses viel Plattenspeicher in Anspruch nimmt. Andere Beispiele sind: ausgiebige Testumgebungen, die mit der Software ausgeliefert werden, separate Module mit Unterstützung für unterschiedliche Dinge, etc.
Zusammenfassung: Du wirst Subpackages verwenden, wenn du nur einen bestimmten Teil einer gewissen Applikation benötigst statt die gesamte Applikation. Jedoch ist es sehr wahrscheinlich, dass das Subpackage, das du suchst, auch existiert und auf dem dir am naheliegendsten FTP-Mirror vorliegt und von dir installiert werden kann.
Um die verschiedenen verfügbaren Subpackages für einen Port anzuzeigen, verwende:
Es ist möglich, auszuwählen, welches Subpackage vom Ports-Tree aus installiert werden soll - das gleiche gilt für mehrere Subpackages. Nach einigen Tests wird ein pkg_add(1)-Aufruf erfolgen, der das gewünschte Subpackage (oder die gewünschten Subpackages) installiert.$ make show=MULTI_PACKAGES
$ env SUBPACKAGE="-server" make install
Hinweis: Der Subpackagesmechanismus verarbeitet nur Packages - es werden keine Konfigurationsoptionen vor dem Erzeugen des Ports geändert. Du müsstest hierfür Flavors verwenden.
Dies bedeutet, dass du lediglich darauf achten musst, dass du den korrekten Branch des Ports-Trees verwendest und die gewünschte Software von diesem aus erzeugst. Du kannst deinen Tree mit CVS auf dem aktuellen Stand halten und dich zusätzlich in der Mailingliste ports-security einschreiben, um über sicherheitsbezogene Ankündigungen, die die Software im Ports-Tree betrifft, auf dem Laufenden gehalten zu werden.
Selbstverständlich landen die Sicherheitsupdates erst im -current-Ports-Tree bevor sie in den -stable-Branch übernommen werden.
Es ist sehr wahrscheinlich, dass du ein System und einen Ports-Tree verwendest, die nicht synchron sind.
Bitte was?
WARNUNG: Mische NIEMALS Versionen der Ports 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 soll's, alles was ich hier habe ist -current!
Die Ports-Collection 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. Deine Spenden können einen Unterschied machen, auf wievielen Plattformen die Ports getestet werden.
Einige individuelle Ports können gerade deshalb hinter den Mainstreamversionen liegen. In der Ports-Collection könnte eine Version eines Programms vom Januar sein, obwohl eine neue Version des Programms von dessen Entwicklern im Mai - also drei Monate später - veröffentlicht wurde. Oft ist das eine schwere Entscheidung; die neue Version könnte Probleme unter OpenBSD haben, die der Verantwortliche beheben muss - oder aber die Entwickler haben die Software einfach schlechter gemacht als die alte: OpenBSD könnte andere Ziele als die Mainstreamentwickler der anderen Projekte haben, was manchmal dazu führt, dass Funktionalitäts-, Entwurfs- oder Implementationsänderungen der Software aus Sicht der OpenBSD-Entwickler nicht hinnehmbar sind. Das Update könnte aber auch einfach nach hinten verschoben worden sien, da die neue Version einfach nicht als wichtig genug für eine Aktualisierung angesehen wird.
Wenn du wirklich unbedingt eine neue Version eines Ports benötigst, kannst du den Verantwortlichen des Ports bitten, eine Aktualisierung des Ports zu veröffentlichen (siehe unten, wie man herausfindet, wer der Verantwortliche ist). Wenn du helfen kannst, dann ist es natürlich noch besser.
Du kannst helfen. Ziehe das Erstellen eines eigenen Ports in Betracht. Es gibt einige Dokumentationen darüber: Einen OpenBSD-Port erzeugen. Lies es - und lies es wieder. Insbesondere den Teil über das Verwalten deines Ports. Versuche dann, einen eigen Port zu erstellen und teste ihn sorgfältig Schritt für Schritt. Wenn er schlussendlich einwandfrei für dich arbeitet, sende ihn an die Portsmailingliste ports@openbsd.org. Die Chancen, eine Rückmeldung und Testberichte von anderen Leuten zu erhalten, stehen gut. Wenn die Tests erfolgreich sind wird dein Port in Betracht gezogen, in den Ports-Tree übernommen zu werden.
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 jedes einzelnen Ports auf allen Plattformen gewährleisten zu können, doch ist es während dem Entwicklungszyklus sehr wahrscheinlich, dass das mit einigen Ports 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. Ein typisches Beispiel ist CVSup - ein Werkzeug, das oft zum Folgen des OpenBSD-Source-Trees genutzt wird. Um CVSup auf einem durchschnittlich schnellen System mit guter Internetanbindung zu installieren dauert ca. zehn Sekunden - das ist die Zeit, die zum Download und Entpacken einer einzelnen 779 kB großen Packagedatei benötigt wird. Im Gegensatz dazu ist das Erzeugen von CVSup auf der gleichen Maschine vom Quelltext aus eine riesige Aufgabe, die viele Werkzeuge und einen Bootstrap eines Compilers benötigt; das ganze nimmt mehr als eine halbe Stunde auf der gleichen Maschine in Anspruch. Andere Applikationen wie zum Beispiel Mozilla oder or KDE können Stunden und riesige Mengen an Plattenspeicher und RAM/Swap in Anspruch nehmen, um erzeugt werden zu können. 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-Mirror darauf warten, installiert zu werden?
Selbstverständlich gibt es ein paar gute Gründe, in einigen Fällen Ports statt Packages 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-Portsmailingliste ports@openbsd.org. Bitte verwende NICHT die misc@openbsd.org-Mailingliste für portsbezogene Fragen.
Stelle in jedem Fall folgendes bereit:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Alternativ dazu kannst du auch Folgendes machen:
[FAQ-Index] [Zum Kapitel 14 - Platteneinrichtung]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org