Re: von FreeBSD 10 auf 11 - ALLE Ports neu bauen?

"O. Hartmann" <[email protected]> Sat, 28 Jan 2017 13:55:43 +0100
Newsgroups	gmane.os.freebsd.questions.german
Organization	FU Berlin
Message-ID	<[email protected]>
Am Sat, 28 Jan 2017 12:30:18 +0100
Heino Tiedemann <[email protected]> schrieb:

> Polytropon <[email protected]> wrote:
> 
> > On Fri, 27 Jan 2017 23:29:44 +0100, Heino Tiedemann wrote:  
> >> Ich habe Montag angefangen mit dem Update von 10.2 auf 10.3 und bin
> >> JETZT (Freitag) endlich fertig alle Ports zu updaten.  
> >
> > Von 10.2 auf 10.3 sollte das nicht nötig sein (obwohl es
> > auch grundsätzlich nicht schadet), aber wenn Du auf 11.0
> > aktualisierst, wäre es schon sehr empfehlenswert.  
> 
> Missverstanden: Nur die Ports, die fällig waren - aber das waren
> viele!

In vielen Fällen lauert noch ein weiteres Problem: zwar laufen Ports partiell, aber nach
meiner letzten Erfahrung, das war ein Wechsel von 10.3 auf 11 auf einem
Überwachungsserver, gabs immer wieder ABI Probleme, die in mysteriösen Abbrüchen von
Programmen führten.

> 
> >> Am liebsten würde ich auf v11 gehen. Aber diese Schweine Arbeit immer..  
> >
> > Eigentlich macht "pkg upgrade -a" die ganze Arbeit, auch
> > für portmaster gibt es in "man portmaster" einen Aufruf,
> > der sehr einfach ist und auch sein _sollte_ - nur zeigt
> > die Praxis, daß es nicht immer so glatt läuft. :-)  
> 
> Es läuft NIE durch und vor allem der Rechner isz ja dann solange
> nicht nutzbar.
> 
> 
> Es Dauert einfach ZU LANGE alles.

Was dauert zu lange? Der eigene Bau von Paketen/Ports aus den Quellen oder das "Upgrade"
via binärme "pkg -a"? Letzteres ist wesentlich schneller, aber es hat einige gravierende
Nachteile in einer produktiven Umgebung!

> 
> 
> Gerade wenn die installierten Ports nicht laufen, dann habe ich kein X
> kein XFce, keinen Firefox, Keinen Emacs/Gnus, keinen Clementine-Player...
> 
> .. final also einen unbrauchbaren PC für mehrere Tage, wenns hoch kommt.
> 
> Sehr ärgerlich, wenn man was zum bauen startet, nach der Arbeit nach
> hause kommt und merkt: Abgebrochen. Das wirft einen wieder einen Tag
> nach Hinten.

Ja, das geht mir ähnlich. Vor allem auf etwas "schwächeren" Maschinen, ich habe einen
älteren Zweikern-IvyBridge, bricht Libreoffice sehr oft ab, nicht zu vergessen die
Schwergewichte gtk2/gtk3/qt5 und webkits. Libreoffice baut rund drei Stunden. Ein Abbruch
bedeutet: alles neu. Müsig.

> 
> > Der Vorteil, wenn man nur mit Binärpaketen arbeiten kann,
> > liegt hier klar auf der Hand, da macht pkg alles neu,
> > auch sich selbst (ggf. die "pkg-static-Falle"). 

"Arbeitet" man mit Binärpaketen, ist amn darauf angewiesen, daß der Host, der die
Binärpakete vorhält, immer erreichbar ist und die Pakete so konfiguriert, wie man sie
selber braucht. In einer heimischen Frikkelumgebung mag das noch alles problemlos gehen,
wird FreeBSD aber, ausnahmsweise, mal in einer komplexeren Umgebung eingesetzt, läuft
man mit den "Kompromißlösungen" aus den Standardrepositorien ganz schnell gegen die
Wand! Das beginnt bei SASL Unterstützungen diverser Pakete (OpenLDAP), die Verwendung
neuer Datenbanken (PostgreSQL 9.6 statt 9.5) und SAMBA 4.4, nur um ein paar der schweren
Gewichte zu nennen. Der Apache 2.4 und Multithreading ist ebenso ein solcher Kandidat.
FreeBSD hat ernste Probleme auf dem terrain, wo eigentlich die Domäne des Systems liegen
sollte, nämlich im Serversektor, wenn man Binärpakete einsetzt. 

Das größte Übel ist: hat man EINEN Port manuell mit seinen Optionen gebaut und ist der
Baum neuer als der Paketbaum eines entfernten Servers, will pkg sehr oft aufgrund seiner
Konsistenzprüfung eben andere pakete nachinstallieren, meist "Downgrade". Und dann
beginnt ein echter Kampf. 

> 
> Was ist das,die pkg-static-Falle?
> 
> > Wenn man
> > aber Programme braucht, wo die Bau-Optionen andere sind
> > als die Vorgaben, aus denen die Binärpakete gebaut werden,
> > dann bleibt einem (leider) nur der Weg über portmaster
> > oder äquivalente Tools...  

Mist, ich habe das hier zu spät gesehen, siehe oben, ja, so ist das.

> 
> Ich muss zugeben ich habe mich nie groß mit Binärpaketen
> auseinandergesetzt.

Ich auch nicht, siehe oben. Es frißt mehr Arbeit, als daß es einem Arbeit erspart.

> 
> Habs zu 5.2 Zeiten mal versucht, und dann gemerkt, das:
> 
> Die Binärpakete waren alle denen aus dem Ports hinterher. Kaum eines
> war aktuell.
> 
> Binärpakete funktionierten nicht, wenn man alles 'auf dem Stand' haben
> wollte.

Wir (und ich auch) setzen zunehmend JAILS auf diversen Hosts zur trennung von Diensten
ein. Hinzu kommt, daß ich einige "Eigenbaurouter" habe, die auf der Basis der PCengine
APU 2C4 aufbauen und als TK Anlage, Router und Firewall arbeiten. Aus Sicherheitsgründen
können und dürfen diese Systeme nicht mit der Außenwelt in Verbindung treten und hier
sind auch speziell konfigurierte und gepatchte Ports im Einsatz. Und hier tritt dann
wieder einer der Vorteile des FreeBSD Systems in den Vordergrund: poudriere!

Anfangs ist die Lernkurve sehr steil - man muß etwas Zeit und Geduld aufbringen, um das
System zu konfigurieren und vor allem: auf die eigenen bedürfnisse anpassen. Dann aber
kann man einfach seine benötigten Ports konfigurieren und bauen lassen. Über Nacht, auch
mit Abbrüchen und späterer Fortsetzung! Das Resultat ist ein eigenes
Binärpaket-Repositorium. Es kann lokal im Dateisystem abgelegt und auch lokal von pkg
angesprochen werden oder man geht den "Männerweg" ;-) und baut sich einen Webserver, der
im LAN erreichbar die Pakete anbietet. Wir haben Ports für CURRENT und 11. Ich schimpfe
zwar oft über FBSD, weil es doch einigen Murks gibt, aber diese Autarkie, die wir mit
unseren Paketen haben, ist mit anderen Systemen nur schwer erreichbar!

Vor allem aber kann man mit poudriere die Auszeiten und den Frust, falls ein Port defekt
ist und nicht gebaut werden kann, lindern. Solange poudriere Ports nicht bauen kann,
wird das intakte Repositorium, das man tunlichst "woanders" hostet (wir synchronisieren
die Buildfolder mit rsync nach Erfolg auf eine andere Partition, die via NFS eingebunden
ist - beispielsweise), nicht zerstört. Erst wenn der komplette Bauprozeß erfolgreich
abgeschlossen wurde, synchronisiert man. und es ist einfach "scharf" zu sehen, wie
schnell Binärpakete, die man exakt mit allen Optimierungen für die Platform (CPU,
Anpassungen, Patches) über ein 1GBit oder 10GBit LAN auf die zu erneuernden Systeme
fließen.

Der Frustfaktor "Bau von Libreoffice abgebrochen, neu beginnen ..." und die Auszeit von
Stunden, Tagen etc. wird durch den lokalen Einsatz von poudriere erheblich gemildert, ja
bis auf ein Minimum reduziert. Es lohnt sich! 

Ein für uns/mich wichtiger Punkt ist, daß ich nach einem Audit des Codes und einer
digitalen Signatur Pakete innerhalb meines isolierten LANs habe und kein WAN brauche, um
Ports zu verteilen. Vor allem aber, wenn man mehr als 5 Rechner/Jails zu versorgen hat,
beginnt der Faktor "Effizienz" oder "Wirtschaftlichkeit" eine signifikante Rolle zu
spielen. 

> 
> 
> Heino

Gruß
oh

> 
> 
> To Unsubscribe: send mail to [email protected]
> with "unsubscribe de-bsd-questions" in the body of the message
signature.asc (application/pgp-signature, 488 B)