Ports

Bad Toro

Member
Hallo liebe BSDForen Mitglieder,

vor einem Jahr bin ich von Centos aus FreeBSD umgestiegen, da mir die Politik von RedHat bezügl. Centos nicht gefallen hat und Rocky noch nicht auf dem Markt war.

Also warum nicht mal FreeBSD ausprobieren, zu mal man soviel gutes über das OS hört. Mit Linux hab ich 15 Jahre Erfahrung, also dachte ich mich ich wage es mal.

Und nun läuft die Kiste seit einem Jahr auf FreeBSD, hat schon ein großes Update von 12 auf 13 hinter sich und läuft und läuft und läuft.

Soweit sogut, ich habe nun nahezu alles per pkg installiert, leider musste ich vor einiger Zeit auf die Ports zurück greifen, da anscheinend das Paket nginx-full verschwunden ist, ich aber webdav brauche, welches im Paket nginx nicht drin ist.

Und genau jetzt fängt das Problem an. Aktuell hab ich das mit make install clean gemacht, hat auch alles geklappt, der nginx läuft wie er soll.

Aber ich merke jetzt, dass es Zeit wird sich mit den Ports zu beschäftigen.
Ich habe versucht mich einzulesen, aber leider ist die Verwirrung nun komplett, man ließt widersprüchliches und zu dem einen Thema scheint es x verschiedene Antworten zu geben.
Z.B. das Portmaster ínzwischen nicht mehr zu nutzen sei, da es veraltert ist. Portupgrade ist blöde weil es Ruby als Abhängigkeit hat. Dann gibt es noch Poudriere und Synth und die klassiche Methode cd www/nginx && make install clean.

Ich würde die Geschichte gerne simpel halten, Poudriere ist glaube ich etwas too much.

Auf jedenfall kommen einige Fragen auf.

1. Kann man pkg Pakete und Ports mischen?
2. Sollte man pkg Pakete und Ports mischen?
3. Welche Methode/Tool bei den Ports sollte ich nehmen?
4. Wie kann ich NUR das den nginx Port updaten OHNE das, dass ganze System von den Ports kompilliert wird?
5. Wie ist den die "Best practice" bei den Ports?

Für jegliches Licht wäre ich sehr dankbar.

Marcus
 

Andy_m4

Well-Known Member
Kann man pkg Pakete und Ports mischen?
Ja. Kann man. Am besten nimmt man aber dann die Pakete aus dem lastest-Repository (siehe Handbuch Abschnitt 4.4.2). Die sind vom Versionnsstand nämlich (so ziemlich) gleich auf mit den Ports.
Insofern kannst Du Deine Packages auch sofort daher beziehen und musst Dich eigentlich nur aus den Ports bedienen, wenn Du Compiler-Optionen anpassen möchtest.

Mit dem lastest-Repository hättest Du für die Packages quasi eine Art Rolling-Release-Modell. Das klingt etstmal wackeliger als es in der Praxis aus meiner Erfahrung häufig ist (ich setze fast ausschließlich aufs latest-Repository).

Willst Du nur einzelne Services (wie bei Dir halt nginx) dem unterwerfen könnte man überlegen den in einer Jail zu betreiben (salopp gesagt ist eine Jail ein Container mit einer eigenen FreeBSD-Instanz). Dann bleibt der Rest von dem System unberührt egal was Du in der Jail machst. Und packst Du die Jail noch auf ein ZFS-Dataset kannst Du mit Snapshots da auch zusätzliche Absicherungen schaffen.

Welche Methode/Tool bei den Ports sollte ich nehmen?
Also ich nutze zum Aktualisieren Portsnap. Seit die per GIT verfügbar sind kannst Du die aber auch darüber aktualisieren.
Beide Möglichkeiten sind im Handbuch beschrieben:
https://docs.freebsd.org/en/books/handbook/ports/#ports-using

Noch eine generelle Bemerkung zum Handbuch: Das ist in verschiedene Sprachen übersetzt (inkl. deutsch). Allerdings sind die Übersetzungen manchmal etwas veraltet, so das im Zweifel das englischsprachige Original vorzuziehen ist.

Wie kann ich NUR das den nginx Port updaten OHNE das, dass ganze System von den Ports kompilliert wird?
Ja. Geht im Prinzip. Es sei denn es gibt Abhängigkeiten mit entsprechenden Versionen.
Du kannst auch aus (ausgewählten) Ports Dir recht einfach mit (dem schon von Dir angesprochenen) Poudriere Dein eigenes Package-Repository bauen.
 

midnight

OpenBSD & FreeBSD
Soweit sogut, ich habe nun nahezu alles per pkg installiert, leider musste ich vor einiger Zeit auf die Ports zurück greifen, da anscheinend das Paket nginx-full verschwunden ist, ich aber webdav brauche, welches im Paket nginx nicht drin ist.
Ja, da habe ich bei meinem Update auch nicht aufgepasst und ploetzlich war nginx-full verschwunden. Ich habe nun einfach nginx auch den latest packages installiert und webdav funktioniert bei mir auch damit ohne Probleme bei NextCloud mit dem NextCloud-Client, der ja auch webdav voraussetzt. Ich musste nur die nginx-config geringfuegig abaendern. Vermutlich ist das auch das Problem bei dir?

Es ist natuerlich bitter, wenn packages einfach auf Produktivmaschinen verschwinden und man dann auf ports ausweichen muss. Aus faulheit nutze ich bis jetzt keine ports, aber gerade das Beispiel mit nginx-full laesst mich die Situation neu ueberdenken.
 

mr44er

moderater Moderator
Teammitglied
1. Kann man pkg Pakete und Ports mischen?
Ja, geht. Aus einem Port, der eine Bauanleitung ist, wird am Ende auch nur ein Paket gebaut. Die schlechte Mischung besteht dann oft aus nicht zusammenpassenden Versions-/Konfigurationsständen der Pakete.
2. Sollte man pkg Pakete und Ports mischen?
Siehe oben, eine 'gute' Mischung gibts im Umkehrschluss nicht, nur zusammenpassende Pakete am Ende. ;)
3. Welche Methode/Tool bei den Ports sollte ich nehmen?
portsnap für den portstree, einerseits um ihn runterzuladen und andererseits, um ihn aktuell zu halten. portmaster ist nicht veraltet in dem Sinne, dass es nicht aktualisiert wird, das funktioniert weiterhin prima. Manuell 'make install' kannst du natürlich machen, aber portmaster rödelt alle benötigten Abhängigkeiten durch, die es in deinem Fall bei nginx braucht. Es gibt bei portmaster -PP als Schalter, steht für "baue was nötig, nimm Paket, wenn vorhanden".
Poudriere und synth sind etwas anders zu betrachten, das ist eher was, wenn man sich eine Buildmaschine ins Netz stellt, die auf updates horcht und hinterherbaut, sodass man ein eigenes repository hat und immer aktuellste Software als fertige Pakete zur Verfügung. Man kann das aber natürlich auch lokal auf einer Maschine laufen lassen, das nur so als grobe Einsortierung.
4. Wie kann ich NUR das den nginx Port updaten OHNE das, dass ganze System von den Ports kompilliert wird?
portmaster nehmen. Am Ende wird aufgelistet, was für diesen Schritt gebaut werden muss. Sieht oft nach viel aus, sind aber selten ALLE auf dem System.
5. Wie ist den die "Best practice" bei den Ports?
Wie es am besten zu deinem workflow passt, es gibt nicht nur den einen Weg. Vielleicht bist du ja schon total happy mit poudriere auf einer Extramaschine oder jail oder vm....oder usw. :)
 

Bad Toro

Member
Super!

Vielen Dank euch. Jetzt ist tatsächlich viel Licht im Dunklen.

Ich denke, ich kann mir jetzt das ganze so stricken, dass es passt.
 

jmos

Member
Z.B. das Portmaster ínzwischen nicht mehr zu nutzen sei, da es veraltert ist.
Ich bin glücklich mit.

Zum Jahreswechsel gabs erst ein Portmaster-Update - wird also noch gepflegt. Für mich hat dieses "oh Gott, das nimmt man nimmer" mehr was von Religion als von Sachlichkeit (Probleme haben die Leute eher mit den anderen Tools - zu Portmaster finde ich: keine). Laut sind sie, die Portmaster verteufeln - doch lese ich das offizielle FreeBSD Forum quer, dann nutzen sehr viele nicht verblödete User sehr erfolgreich und ohne Probleme Portmaster.
 

Bad Toro

Member
Brauche nochmal etwas Hilfe.

Portmaster eben manuell mal angeschmissen. Meckerte zuerst ein bisschen. Hab dann mit den Hinweistexten und durch Internetrecherche die Optionen angepasst.

Mit folgenden Optionen ist er durch gelaufen:
portmaster --no-confirm -y --update-if-newer www/nginx

Aber ich musste am Ende ein Hinweistext mit q beenden.

Mit -PP gab es eine Fehlermeldung, dass das Package neuer sei. Aber ich möchte jetzt den Port nutzen.

War der Portmaster Befehl so richtig?

Und gibt's da auch was für Cron.
Oder bleibt der Befehl da identisch?

Marcus
 

mr44er

moderater Moderator
Teammitglied
Das kann 'gefährlich' sein, in dem Sinne, dass Abhängigkeiten gelöscht werden, daher würde ich mir immer erst das Ergebnis am Ende schauen, bevor man loslegt.

Aber ich musste am Ende ein Hinweistext mit q beenden.
Das ist normal.

Mit -PP gab es eine Fehlermeldung, dass das Package neuer sei
--update-if-newer , ansonsten halt nicht ;)

Und gibt's da auch was für Cron.
Wenn es in Richtung Automatik gehen soll, bist du mit poudriere wahrscheinlich besser beraten.
 

pit234a

Well-Known Member
--update-if-newer , ansonsten halt nicht
wobei das eigentlich nie der Fall sein sollte, wenn die Ports, also der lokale Ports-Tree, aktuell sind.
Das eben muss vor jedem Bau eines Paktes aus den Ports gewährleistet sein.

Ich sage es mal ganz praktisch als Desktop-User und nicht als Profi mit hohen Ansprüchen:
Wenn es nur ein einziges Paket ist, würde ich genau nur dies mit make install aus den Ports mit den gewünschten Optionen zusätzlich installieren.
Wenn es fünf oder zehn Pakete sind, die ich aus den Ports brauche, würde ich mir das manuell ebenfalls noch zu trauen.
Wenn es aber mehr wird, vielleicht sogar deutlich mehr, dann würde ich wohl doch ein System entsprechend aufstellen, um alles aus den Ports zu bauen und das geht auf Dauer nur mit Poudriere gut, weil es immer auf einem frischen und unveränderten System aufsetzt, um neue Pakete aus den Ports zu bauen, also nicht auf möglicherweise verhunzte Abhängigkeiten des laufenden Systems trifft.
portmaster ist neuer und besser als portupgrade, aber beide sind gedacht, Anwendungen aus den Ports zu installieren, also inklusive aller Abhängigkeiten, also eben ein System zu bedienen, das nur aus Ports lebt, also eben jenes System, das in einer Jail lebt und mit Poudriere neue Pakete aus den Ports baut.

In einem laufenden System, das nur aus Paketen und ohne Ports gebaut ist und wo nur einmal ein (bis zehn) Pakete aus den Ports gebaut werden müssen, würde ich das nicht einsetzen, weil da zu schnell ein allzu großes Delta entstehen kann.
 

Esjott

Kellerkind
Guck dir echt mal poudriere an. Am Anfang ist es vielleicht ne etwas steilere Lernkurve, aber einmal eingerichtet läuft das Ding vor sich hin. Die handvoll Ports, die man so braucht, trägt man in ne Datei ein (in der Form www/nginx z.B.), geht mit poudriere einmal die options durch und läßt ihn dann arbeiten. Lässt sich gut automatisieren (Nachts den portstree updaten und Pakete bauen lassen, falls was zu tun ist; pkg über nen cronjob die installierten Pakete mit dem Repo vergleichen lassen, gibts neuere Pakete, kommt ne mail).
Ich habe früher auch portmaster benutzt, dann kamen die flavors und portmaster war erstmal "kaputt" (im Sinne von ich hätte mich in was einlesen müssen, da kann ich auch gleich über den Tellerrand gucken und was neues ausprobieren). Poudriere ist wirklich einen Blick wert, von einer handvoll Ports für den homeserver bis hin zum desktop (wenn man Lust drauf hat, benutze da dann doch wieder die offiziellen repos,).
 

Bad Toro

Member
So, langsam wirds dann doch komplexer als gedacht.

Ich fasse noch mal zusammen.

Ich möchte nur nginx als port haben, alles andere als package.

Hab pkg lock nginx gemacht, damit mir pkg upgrade nicht dazwischen funkt.
Und als Befehl: portmaster -P -y --no-confirm nginx

Das passt soweit.
Aber jetzt kompiliert er mir jedes mal nginx, auch wenn sich an der Version gar nichts geändert hat.

Ein --only-if-newer wirkt nicht.

Gibt es dafür eine Lösung?

Danke, Marcus
 

Bad Toro

Member
Ich habs jetzt mit nem Script gelöst.

Portmaster -L und dann mit grep suchen.

Wenn es gefunden wird -> Portmaster ausführen.
 

PMc

Well-Known Member
1. Kann man pkg Pakete und Ports mischen?
2. Sollte man pkg Pakete und Ports mischen?
3. Welche Methode/Tool bei den Ports sollte ich nehmen?
4. Wie kann ich NUR das den nginx Port updaten OHNE das, dass ganze System von den Ports kompilliert wird?
5. Wie ist den die "Best practice" bei den Ports?
Die best practice ist, dass man auf dem produktiven System keine ports verwendet (wie das portupgrade u.ä. zu tun pflegen).
Denn die jew. prerequsite Ports, Compiler, Dokumentationserstelltools, usw.usf. werden alle auf dem System mit installiert, und du hast dann erstens eine Entwicklungsumgebung installiert die du nicht unbedingt wolltest, und zweitens ist das produktive System verändert.

Stattdessen baut man den Port woanders, bsut dabei ein pkg, und installiert auf dem Zielsystem immer nur pkgs. (Für das "woanders" reicht in den meisten Fällen ein schlichtes chroot, hab ich lange so gemacht. Allgemein scheinen aber jails beliebter zu sein. Und ich nehm inzwischen bhyve, weil ich damit auch für höhere Releases bauen kann.)

Damit vermeidet man Ärger, der zwar nich allzu häufig ist, aber früher oder später kommt: nicht nur werden auf dem System Sachen installiert, die man da nicht wirklich braucht, sondern auch die Ports kompilieren zuweilen anders je nachdem was schon auf dem System installiert ist. Nach einem halben Dutzend Install-zyklen (2-3 jahre) weiss man dann nicht mehr was warum wie wo so oder anders konfiguriert war und sich jetzt unerklärlicherwese anders verhält (zB pdfs im drucker plötzlich andere Schriften haben - das war immer der Klassiker nsch jedem zweiten Portupgrade).

Ein bhyve oder chroot kann man erzeugen, drin seine Sachen bauen und danach alles wieder wegschmeißen, aufheben braucht man nur das file mit den Options (die stehen aber auch im pkg selber).

Was ich so höre, scheint Poudriere sowas in der Art zu machen. Das geht natürlich alles nicht ohne Aufwand, und ob man das will, oder ob man lieber dann im Fall des Falles nach dem konkreten Problem sucht, das muss man natürlich selber entscheiden.
(In allen BSD Foren sind posts von Leuten, die in genau solche Probleme gelaufen sind, und dann nicht wirklich so klingen als ob sie das hätten haben wollen. bösegrins)
 

CommanderZed

OpenBSD User
Teammitglied
Ich bin langjähriger OpenBSD nutzer und mit FreeBSD gerade erst vor einigen Monaten vorsichtig eingestiegen.

Ich hab nach dem ersten versuchen irgendwie mal poudiere ausprobiert und fand den einstieg zwar etwas sperrig aber durchaus machbar. Also villeicht ja auch etwas für dich?
 

pit234a

Well-Known Member
Bei Poudriere wird alles schön in einer Jail gebaut.
und das ist sicher die einzig richtige Antwort.
Ist mir aber zu überladen gewesen.

Ich nutze nur Pakete und mein Desktop-System läuft gut.
Zwischendurch gab es aber mal Grund, zB ffmpeg selbst zu bauen. Das ist nur ein einziges Paket und ja, man sollte selbst dann ein Poudiere benutzen, aber es geht eben auch mit make install clean.

Du liebe Herrn: gar kein Aufwand und es geht, wenn eben dieses eine Paket selbst gebaut wird und der Rest als fertige-Pakte benutzt wird: in meinen Augen nicht weiter denken, machen und nutzen!
Vor allem dann, wenn die Optionen gleich bleiben und nicht noch zusätzliche Pakete fordern.
Aber auch dann werden die Abhängigkeiten aufgelöst, ohne portsmaster und poudiere.

Das System ist dann vielleicht eine Weile "unsauber", was bei "latest" nicht gravierend sein sollte.
Wenn es wieder fertige Pakete gibt, nutzt man halt diese und vergisst die Ports wieder.
 
Oben