Opsi "Update" Paket / incremental package

[tobias]

Hi,

mich nervt das im Moment wieder sehr das der Paketierungs Vorgang (also opsi-makeproductfile) bei großen Paketen so eeewig lange dauert.
Das passiert sicher jedem ab und zu, man Paketiert nen mehrere Gigabyte großes Paket installiert es im Depot und stellt fest irgendwie ist ein Tipfehler im Script oder ein Pfad falsch angegeben.
Also nochmals neu paketieren.

Ich fände es gut wenn - entweder veränderte Dateien einfach in das OPSI Paket hinzugefügt werden könnten oder einfach ein OPSI Patch Paket eingeführt wird welches eben nur die Änderungen enthält.

opsi-makeproductfile besitzt ja sogar den Schalter "incremental package", hat jedoch noch nie funktioniert

[n.wenselowski]

Hallo tobias,

opsi-makeproductfile besitzt ja sogar den Schalter "incremental package", hat jedoch noch nie funktioniert

das ist ein experimentelles Feature, welches nie so zufriedenstellend lief und vermutlich in nächster Zeit zumindest als deprecated markiert wird.
Von daher halte ich die Einführung eines entsprechenden Features momentan für sehr unwahrscheinlich, solange kein Kunde dies beauftragt.

Als momentaner Workaround bietet sich die Verwendung von pigz (Version > 2.2.3) an, damit das Komprimieren schneller abläuft.
Das sollte ab opsi 4.0.4.1 dafür sorgen, dass die Archivierungsarbeiten auf mehreren Kernen statt nur einem ausgeführt werden.

Ich hoffe das hilft zumindest ein bisschen.


Schönen Gruß

Niko

[tobias]

Hallo tobias,
das ist ein experimentelles Feature, welches nie so zufriedenstellend lief und vermutlich in nächster Zeit zumindest als deprecated markiert wird.
Von daher halte ich die Einführung eines entsprechenden Features momentan für sehr unwahrscheinlich, solange kein Kunde dies beauftragt.

Mhh ganz kurze Aussage wie aufwändig das in etwa ist - und ich mach vielleicht ein Ticket auf.

Als momentaner Workaround bietet sich die Verwendung von pigz (Version > 2.2.3) an, damit das Komprimieren schneller abläuft.
Das sollte ab opsi 4.0.4.1 dafür sorgen, dass die Archivierungsarbeiten auf mehreren Kernen statt nur einem ausgeführt werden.

Ich hoffe das hilft zumindest ein bisschen.

Schönen Gruß

Niko

Leider nicht wirklich - wir haben einen Virtuellen Server - und solange Kernkomponenten der auf einer VM laufenden Software nicht mehr als 1 Kern benutzen, bekommen VMs aus Performance Gründen immer nur einen Kern zugewiesen.
Das Problem bei 2 Kern VMs ist immer, dass diese 2 physikalische CPU kerne immer zeitgleich belegen und somit die gesamt Performance des Physikalischen Systems verschlechtern (auch wenn in der VM der eine Kern nur am rumidlen ist )
Und da das Paketieren keine Kernkomponente ist, wird es das nicht geben.

Alternativ könnt ich mir vorstellen -lokal- auf meinem Mac zu paketieren der hat genug Power opsi-makeproductfile hängt jedoch scheinbar an OPSI Komponenten

[embl-structures]

Hi Tobias,

mich nervt das im Moment wieder sehr das der Paketierungs Vorgang (also opsi-makeproductfile) bei großen Paketen so eeewig lange dauert.
Das passiert sicher jedem ab und zu, man Paketiert nen mehrere Gigabyte großes Paket installiert es im Depot und stellt fest irgendwie ist ein Tipfehler im Script oder ein Pfad falsch angegeben.
Also nochmals neu paketieren.

Ich fände es gut wenn - entweder veränderte Dateien einfach in das OPSI Paket hinzugefügt werden könnten

Das kann man doch. In solchen Faellen korrigiere ich das Skript/File und kopiere es schlicht und einfach per `cp` ins Paketverzeichnis /opt/pcbin/install/.... Das geht natuerlich nur, wenn man nicht deswegen die Software- oder die Paketversion aendern will. I.d.R mache ich trotzdem noch ein OPSI-Paket, aber ich erspare mir den zweiten zeitaufwendigen Schritt des Installierens des Paketes.

oder einfach ein OPSI Patch Paket eingeführt wird welches eben nur die Änderungen enthält.
opsi-makeproductfile besitzt ja sogar den Schalter "incremental package", hat jedoch noch nie funktioniert

Nett waere vielleicht eine Option -o/--overwrite fuer opsi-makeproductfile, womit man einfach das Paket unter Beibehaltung der Paketnummer ohne Dialog im Hintergrund erstellen koennte (`opsi-makeproductfile -o &`)

frank

[tobias]

Das kann man doch. In solchen Faellen korrigiere ich das Skript/File und kopiere es schlicht und einfach per `cp` ins Paketverzeichnis /opt/pcbin/install/.... Das geht natuerlich nur, wenn man nicht deswegen die Software- oder die Paketversion aendern will. I.d.R mache ich trotzdem noch ein OPSI-Paket, aber ich erspare mir den zweiten zeitaufwendigen Schritt des Installierens des Paketes.

Das ist aber eher unschön - dann habe ich 2 verschiedene Stellen bei der ich an Scripten rumfummel. Eigtl. ist das Depot eben nicht dafür da das man da an den Scripten etwas ändert. Geht auch bei mir nicht da dann die Checksummen in der Files nicht mehr passen => VPN/WAN Modul
Und da jedes Paket durch alle Deployment Szenarios durch muss ...

[embl-structures]

Das kann man doch. In solchen Faellen korrigiere ich das Skript/File und kopiere es schlicht und einfach per `cp` ins Paketverzeichnis /opt/pcbin/install/.... [...]

Das ist aber eher unschön

Klar, aber pragmatisch und zeitsparend.

dann habe ich 2 verschiedene Stellen bei der ich an Scripten rumfummel

Eigentlich nur eine (naemlich in /home/opsiproducts/...) und danach kopieren/rsync nach /ope/pcbin/.... Master ist immer /home/opsiproducts.

Geht auch bei mir nicht da dann die Checksummen in der Files nicht mehr passen => VPN/WAN Modul

Da kann ich nichts dazu sagen, da ich diese Erweiterung nicht verwende. Wenn aber alle Files auf beiden Seiten identisch sind, sollten auch die Checksummen stimmen. Die Idee des Kopieren ist ja gerade, dass beide Seiten synchron sind. Es entfaellt lediglich der Zwischenschritt des Generierens des .opsi-Files.

frank

[tobias]

Da kann ich nichts dazu sagen, da ich diese Erweiterung nicht verwende. Wenn aber alle Files auf beiden Seiten identisch sind, sollten auch die Checksummen stimmen. Die Idee des Kopieren ist ja gerade, dass beide Seiten synchron sind. Es entfaellt lediglich der Zwischenschritt des Generierens des .opsi-Files.

frank

Und die files wird beim paketieren generiert gut ich müsste meinen Workflow ändern und erstmal nur On_demand testen ohne Caching auf dem Client.
Und dann ein script schreiben welches eben die pakete rüber synct...

mhh die idee inkrementelle Pakete find ich dennoch schöner - alles andere ist nur ein Workaround

[ueluekmen]

Hi,

hier muss man ganz klar untescheiden zwischen:

Pakete packen und testen.
Pakete ausrollen.

Zum ausrollen der Pakete empfehlen wir nach wie vor den opsi-package-manager zu verwenden. Ich hatte mal angefangen, den Packagemanager so auf zu bohren, dass das paketieren umgangen wird und direkt aus dem ausgepackten Paket (normalerweise /home/opsiproducts) die Pakete auf dem Server installiert werden. Das wäre an der Stelle kein gebastel, sondern würde die Standard Paketinstallationswege von opsi verwenden. Ich hatte auch mal überlegt, ob man das Depotverzeichnis nicht synchronisiert, statt komplett platt zu machen. Weiterhin sollte dies auch nur für localboot-Produkte gehen. Aus Zeitgründen ist das halbgar auf der Seite gelandet. Aber ich kann das nachvollziehen, mir ging es damals genauso, deshalb hatte ich so eine verrückte Idee.

Da die Pakete an der Stelle noch nicht getestet sind, würde man seine Produktiv-Umgebung in einen Dirty-Stand bringen. Ich würde dafür ein Depot aufsetzen, welches nur zum Paketieren gedacht ist, das ausrollen in die normale Umgebung (Freigabe für den Betrieb) würde ich dann über die Standardwege deployen.

Wir haben auch schon mal darüber nachgedacht, wie man Installationsskripte sauber von der Software selbst trennen kann, da geht es aber mehr darum eine Versionierung für Winst-Skripte auf zu bauen und Datenredundanz in der workbench zu vermeiden. In dem Bereich gibt es verschiedene Ideen und Ansätze, aber keinen wirklichen Konsens.

Grüße
Erol

[tobias]

Hi,

hier muss man ganz klar untescheiden zwischen:

Pakete packen und testen.
Pakete ausrollen.

Zum ausrollen der Pakete empfehlen wir nach wie vor den opsi-package-manager zu verwenden. Ich hatte mal angefangen, den Packagemanager so auf zu bohren, dass das paketieren umgangen wird und direkt aus dem ausgepackten Paket (normalerweise /home/opsiproducts) die Pakete auf dem Server installiert werden. Das wäre an der Stelle kein gebastel, sondern würde die Standard Paketinstallationswege von opsi verwenden. Ich hatte auch mal überlegt, ob man das Depotverzeichnis nicht synchronisiert, statt komplett platt zu machen. Weiterhin sollte dies auch nur für localboot-Produkte gehen. Aus Zeitgründen ist das halbgar auf der Seite gelandet. Aber ich kann das nachvollziehen, mir ging es damals genauso, deshalb hatte ich so eine verrückte Idee.
Da die Pakete an der Stelle noch nicht getestet sind, würde man seine Produktiv-Umgebung in einen Dirty-Stand bringen. Ich würde dafür ein Depot aufsetzen, welches nur zum Paketieren gedacht ist, das ausrollen in die normale Umgebung (Freigabe für den Betrieb) würde ich dann über die Standardwege deployen.

Die Idee ist nicht verrückt - die ist gut - und ja das stimmt man bringt sein depot in einen Dirty Stand. Die idee mit dem 2. Depot hatte ich auch schon. Begründung warum ich da nicht begeistert von bin siehe unten.

Wir haben auch schon mal darüber nachgedacht, wie man Installationsskripte sauber von der Software selbst trennen kann, da geht es aber mehr darum eine Versionierung für Winst-Skripte auf zu bauen und Datenredundanz in der workbench zu vermeiden. In dem Bereich gibt es verschiedene Ideen und Ansätze, aber keinen wirklichen Konsens.

Grüße
Erol

Allgemein belegt OPSI Viel platz der nicht notwendig ist.
Master Server
- Workbench => Komplette Installationsdateien + Pakete + alte Versionen (sofern man sie nicht löscht)
- Repository => Noch einmal alle Installationsdateien - allerdings komprimiert im OPSI Paket
- Depot => Und wieder alle Installationsdateien - diesmal entpackt

Slave Server
- Depot => Und wieder alle Installationsdateien - diesmal entpackt (gut hier ist es halt Notwendig, da entfernter Standort)
- Repository => Auch wieder alle OPSI Pakete

OPSI belegt also mit ein und den selben Daten gleich mehrfach die Systeme - ist an der Stelle also nicht wirklich effizient

Wenn ich nun noch einen Server nur zum paketieren vorhalten soll - owei - dann hab ich ja noch mehr zeug rumliegen

[ueluekmen]

Hi,

die Workbench würde ich über einen gemeinsamen Share dem Haupt und dem Paketierungsserver zur Verfügung stellen. (Ist bei uns intern auch ein einfacher NFS-Share)

Die Repository Verzeichnisse kannst du getrost übersehen, denn dort landen nur Daten, wenn du opsi-package-manager -d verwendest oder den opsi-product-updater verwendest. Wäre in dem Fall für das Paketierungsdepot nicht notwendig. Der Vorteil bei dem NFS-Share wäre allerdings, du kannst auf dem Paketierungsdepot beim ausrollen opsi-makeproductfile verwenden. Wenn der fertig ist, steht dir das Paket auch auf deinem Produktiv-System zur Verfügung.

Das Depot-Share ist an der Stelle auch egal, denn du solltest nur Pakete drauf haben, die auch im Bau sind, wenn du die ausrollst, brauchst du die Pakete auf diesem Server nicht mehr.

Alles eine Frage des Workflows.