FreeBSD und eigene Packete erstellen

marzl

Well-Known Member
Hi,

Also so langsam komm ich in Bereiche wo ich wohl darauf angewiesen sein werden, eine eigene "Update-Infrastruktur" zu schaffen.
Es sollen also quasi automatisch aus einem aktuellen Portbaum gewisse Anwendungen (Teils mit eigenen Modifizierungen) automatsch samt Abhängigkeiten gebaut und als Packet zur Verfügung gestellt werden.
So in etwa macht es ja auch der FreeBSD Packete Server. Aber wie machen die das? Ich hab jetzt irgendie nix gefunden was mein Brett vor dem Kopf lösen könnte.
Ausweitend noch die Frage ob dies auch mit der FreeBSD-Welt auch gehen kann? Also eigene Sicherheitspatches des FreeBSD-Systems?
 
Packages werden durch ein "make package" im Verzeichnis des Ports gebaut. Man benötigt folglich nur ein Script oder Programm, welches erkennt ob ein Port geupdated wurde. Sollte dies der Fall sein, baut er das Packet und kopiert es z.B. in ein Sammelverzeichnis, wo die Vorgängerversion gleich gelöscht wird. Der Packageserver macht es AFAIK ähnlich, auch wenn ich den genauen Aufbau nicht kenne.

Alternativ kann man auch mit "portinstall -p" ein Packet bauen, aber da gucke lieber nich mal in die Manpage.

Eigene Sicherheitspatches? Könnte man es nicht so ähnlich wie freebsd-update lösen? Man kompiliert den betroffenen Bereich der Welt neu, packt das Ergebnis in ein zu / relatives Tararchiv und entpackt es auf dem Client?
 
Wird nicht bei eigenem Paketbau dieses auch immer gleich installiert? Oder kann man das inzwischen echt nur bauen?

I.MC
 
Nein, es wird gleich installiert und dann aus den Installatiopnsverzeichnissen heraus gepackt. Allerdings kann man das AFAIK nicht wirklich umgehen...
 
Automatisiert irgendwelche Packages bauen und installieren? Das machst du aber hoffentlich nicht in einer Produktivumgebung.
 
Automatisiert irgendwelche Packages bauen und installieren? Das machst du aber hoffentlich nicht in einer Produktivumgebung.

die updates und das bauen passiert natürlich NICHT auf einem produktivserver, sondern auf einem 0815-server, der die packete dann ähnlich wie ftp.freebsd.org zur verfügung stellen kann. irgendiw machen die das ja auch, diese 10000 packete zu bauen, und das ziemlich automatisch. :)

Warum nimmst du nicht die offiziellen Pakete?
weil das nur mit GENERIC kernel und welt geht.

Packages werden durch ein "make package" im Verzeichnis des Ports gebaut.
das wies ich auch, aber nun erzähl mir nich das dies auch auf den packageserver von freebsd so gemacht wird. viel spass :)
 
Packages werden durch ein "make package" im Verzeichnis des Ports gebaut.
das wies ich auch, aber nun erzähl mir nich das dies auch auf den packageserver von freebsd so gemacht wird. viel spass
Auch möglich das der jeweilige Maintainer seine fertigen Packages auf den Server dort schiebt? Jedenfalls gleichen die Maintainer ihren Portstree mit dem offiziellen ab und können dort auch Änderungen einbringen. Also gut möglich das der Server dort auch die Packages baut. (Bei SF kannst ja auch automatische Builds in der ServerFarm dort erstellen lassen).

Es sollen also quasi automatisch aus einem aktuellen Portbaum gewisse Anwendungen (Teils mit eigenen Modifizierungen) automatsch samt Abhängigkeiten gebaut und als Packet zur Verfügung gestellt werden.
Im Prinzip musst dir ja nur eigene Ports machen, welche die nötigen offiziellen Packages installieren (durch entsprechende dependices) und im post-install Target deine Modifizierungen ausführen. Oder was für Modifikationen meinst du?. Deinen Ports/Packages kannst du auch sagen, ob benötigte Packages über den Portstree gebaut oder als Package geladen werden sollen (Von welchem Server die Packages kommen sollen kannst du angeben).

Grundlektüre sollte dieses sein:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

Ein Blick in die Datei "bsd.port.mk" in "/usr/ports" ist auch immer hilfreich.
 
grml. hey, mit bitte nicht erklären wie die ports funktionieren (das weis ich),
sondern wie die 10000 packete auf ftp.freebsd.org gebaut werden.
die kde-packages werden auch automatisch gebaut, aber leider kann ich da nicht finden, wie die das machen. http://rabarber.fruitsalad.org (leider down)

Auch möglich das der jeweilige Maintainer seine fertigen Packages auf den Server dort schiebt?
nein definitiv nicht. das wäre viel zu inkonsistent.

ich würde es gerne so machen:
- auf einem server exisitiert ein aktueller ports-tree.
- aus diesem wird eine ausgewählte zahl an programmen gebaut und als package mitsamt den abhängigkeiten als package zur verfügung gestellt.
- auf einem testserver werden die packete geprüft
- und dann als update für die anderen server zur verfügung gestellt.

und nein, ich möchte nicht das aktuellen package-verzeichnis nutzen, sondern ein eigenes haben, von dem ich gezielte versionen verbreiten kann.
 
und nein, ich möchte nicht das aktuellen package-verzeichnis nutzen, sondern ein eigenes haben, von dem ich gezielte versionen verbreiten kann.
Ist ja im Prinzip das was ich meinte. Du musst dir deine eigenen Ports machen. Und daraus auf deinem Test/Dev Rechner deine Packages bauen. In den Makefiles von deinen Ports gibst dann an, von welchem Server abhängige Packages (eben die wo du erstellt hast) geladen werden sollen. Auf den Zielrechnern musst halt das (Haupt-) Package mit einer URI bei pkg_add angeben (oder passt generell in der config den Server an woher Packages kommen).
 
Ich habe _keinen_ GENERIC Kernel und benutze für fast jedes installierte Programm die Packages von ftp5.de.freebsd.org.
Die Pakete dort werden vom bento cluster gebaut afaik, die skripte dazu gibts bestimmt auch irgendwo, aber soviel aufwand willst du bestimmt nicht treiben...

P.S.:
Deutsch: Paket
Englisch: Packet
 
Und du bist dir sicher das wirlich alle auf dem offiziellen server vorhandenen packete installiert wurden? ich glaube es nich, da auch viele konflikt-packete dabei sind.

z.B. unter ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable
findet man klar die packete und aber auch im "Latest" und "All"-Verzeichnis.
Dieser Inhalt wird automatisch von einem Cluster erstellt.
Welcher Mechanismus hängt dahinter? Das kann ja kein Geheimnis sein.
 
Code:
% grep -C 1 de.free /usr/local/etc/pkgtools.conf
  PKG_SITES = [
    'ftp://ftp5.de.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/',
    'ftp://ftp4.de.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/',
  ]
% uname -rsm
FreeBSD 5.4-RELEASE-p5 i386
Wie gesagt _kein_ GENERIC!

Wegen den Skripten fragst du mal auf freebsd-ports@freebsd.org nach...
 
Wie gesagt _kein_ GENERIC!
Ja, für meine Zuhausemaschinen mach ich das ja bei gelegenheit auch,
wobei ich zu 99% selbst aus den Ports baue.

Mir kommt es primär auf eine genaue Versionskontrolle an. Quasi ein "Stand" wird festgefroren, getestet und dann beteitgestellt. Bei den offiziellen Packeten hab ich da keinen Einfluss, da ist u.U. morgen schon wieder ne neue Version drauf und dann differiert der Versionsstand von Maschine zu Maschine. Nich gut.
 
Mal davon abgesehen das es bei einigen Ports doch erheblich Einstellmöglichkeiten gibt, die per default nicht gesetzt sind....
 
Die meisten Pakete haben imo sehr gute Default Einstellungen.

Mir kommt es primär auf eine genaue Versionskontrolle an.
Ist auch bei Paketen gegeben. Die genau Version ist im Dateinamen.

Quasi ein "Stand" wird festgefroren, getestet und dann beteitgestellt.
Nennt sich "portsfreeze" und findet für jedes Release statt.
Besser und breiter kannst du die Pakete wohl kaum testen, auch nicht ihr zusammenspiel.

Bei den offiziellen Packeten hab ich da keinen Einfluss, da ist u.U. morgen schon wieder ne neue Version drauf und dann differiert der Versionsstand von Maschine zu Maschine. Nich gut.
Nö. Z.B. die Packages unter
ftp://ftp5.de.freebsd.org/pub/FreeBSD/ports/i386/packages-5.4-release/
ändern sich nicht mehr, das sind genau die aus dem freeze für 5.4-RELEASE. Also extrem gut getestet.
 
Ich benutze übrigens portinstall bzw. portupgrade mit dem Schalter -p zum Erstellen von Paketen. Das hat einige Vorteile gegen über der "make package"-Methode, z.B. werden auch Pakete von den Abhängigkeiten erstellt. "make package-recursive" hat den zeit- und ressourcenraubenden Nachteil, dass Pakete immer erstellt werden, d.h. auch wenn sie bereits existieren.

Björn
 
Die meisten Pakete haben imo sehr gute Default Einstellungen.
Default is meist nicht gut genug, sondern eher etwas zu konservativ.

Ist auch bei Paketen gegeben. Die genau Version ist im Dateinamen.
Hab ich mich falsch ausgedrückt, ich meine keine optische, sondern vielmehr eine tatsächliche Versionskontrolle. Was ist stabil, bzw läuft wie gewünscht und was nicht.

ändern sich nicht mehr, das sind genau die aus dem freeze für 5.4-RELEASE. Also extrem gut getestet.
Aber bei einem Sicherheitsupdate sind diese dann doch wieder nich aktuell genug :)
Das bringt mich auch nicht weiter.

Ich benutze übrigens portinstall bzw. portupgrade mit dem Schalter -p zum Erstellen von Paketen. Das hat einige Vorteile gegen über der "make package"-Methode, z.B. werden auch Pakete von den Abhängigkeiten erstellt.
guter tipp, werd ich mal probieren, aber löst noch nicht meine zentrale bereitstellung einer echten PACKAGESITE.

Preisfrage: Wie erstellt man eine eigen PACKAGESITE :)
 
Vielleicht versteht niemand, wo überhaupt dein Problem liegt? Daher hast du auch wohl auch meinen Beitrag bezüglich der Produktivsysteme nicht richtig eingeordnet.

Nehmen wir also mal deine letzte Auflistung:
marzl schrieb:
- auf einem server exisitiert ein aktueller ports-tree.
- aus diesem wird eine ausgewählte zahl an programmen gebaut und als package mitsamt den abhängigkeiten als package zur verfügung gestellt.
- auf einem testserver werden die packete geprüft
- und dann als update für die anderen server zur verfügung gestellt.
Erstelle /usr/ports/packages und exportiere es per NFS oder sonstwie. Einen anderen Pfad kannst du über make.conf einstellen. Baue dann einen gewünschten Port mit make package-recursive. Da hierbei der Port gleich installiert wird, kannst du ihn direkt auf dem "Build-Server" austesten. Im Prinzip ein ganz normaler Vorgang im Portssystem - und die normalen Vorgänge wolltest du ausdrücklich nicht erklärt bekommen.
 
marzl schrieb:
guter tipp, werd ich mal probieren, aber löst noch nicht meine zentrale bereitstellung einer echten PACKAGESITE.
Wenn das Verzeichnis /usr/ports/packages existiert, dann werden Pakete darin genau wie auf'm FTP abgelegt (packages/Latest/, packages/All/, etc.). Das kannst du dann entweder herummounten, per FTP oder HTTP zur Verfügung stellen.

Björn
 
Neben einem 0815-Server der mit Tinderbox die gewünschten Packages erstellt, brauchst Du nur noch auf den Clients den Package-Pfad auf die freigegebenen Packages des 0815-Servers umzubiegen:

http://wiki.bsdforen.de/index.php/FreeBSD_-_Ports_und_Programme_aktualisieren#Stable-Pakete

und ein Skript zu erstellen, welches mit cron, anacron oder periodic möglichst einmal täglich aufgerufen wird. Das Skript enthält einen Aufruf von portupgrade:

Code:
# portupgrade -aPP

wie unter:

http://wiki.bsdforen.de/index.php/FreeBSD_-_Ports_und_Programme_aktualisieren#Produktive_Clients

beschrieben. Und die Programme auf den Clients werden aktualisiert..
 
Zuletzt bearbeitet:
Meine Erfahrung dazu...

marzl schrieb:
Mal davon abgesehen das es bei einigen Ports doch erheblich Einstellmöglichkeiten gibt, die per default nicht gesetzt sind....

Ja! Du hast recht, deshalb habe ich in 5 Jahren FreeBSD auch nur zwei mal auf ein paar Binär-PKGs zurückgegriffen.
Bei FreeBSD gibt es da keine richtig gute Lösung, die schon vorbereitet ist. :grumble:
Desshalb hab ich mir bis jetzt auch nur von OpenOffice Binär-PKGs gebaut, alles andere wird IMMER auf der Zielmaschine (nachts) kompiliert.

Du müsstest Dir einen Sandkasten bauen, in dem dann die PKGs gebaut werden. Wenn dann Konflickte auftreten, musst Du den Sandkasten löschen und neu bauen, und dann da weiter machen, wo der letzte Konflikt auftrat.

Ich wechsle jetzt auch jangsam von FreeBSD zu NetBSD, dort gibt es all diese schönen Admin-Tools (für den Rechenzentrum-Betrieb) schon und sie funktionieren blendent. :D
Wie man das mit moderatem Aufwand unter FreeBSD hin bekommt weiss ich nicht... :confused:
 
Zurück
Oben