forum.opsi.org

Hallo zusammen!

Ich habe eine Problem mit unterschiedlichen Versionsständen von Produkten über unsere verschiedenen Depotserver. Wie es entsteht, weiss, nur nicht, WARUM überhaupt. Ich beschreib's mal:

a) ich packe ein neues Paket "xy_1.0-1" und installiere es mit opsi-package-manager -i -d auf Configserver A (der via opsi-product-updater.conf gleichzeitig Repositoryquelle für meine Depots ist)
-> das Paket steht im Configed zur Verfügung und wird unter /var/lib/opsi/repository bereitgestellt
b) auf Depot B läuft opsi-product-updater per cron
-> das neue Paket "xy_1.0-1" wird heruntergeladen und weisungsgemäß auf dem Depot installiert
-> Verzeichnisinhalte sind gleich in \\config_a\opsi-depot\xy und \\depot_b\opsi-depot\xy
c) ich stelle am nächsten Tag einen Fehler im Setupscript fest, korrigiere ihn (OHNE ÄNDERUNG DER PAKETVERSION), packe es neu und installiere es erneut auf Configserver A
-> das Paket wird im opsi_depot Share wunschgemäß geändert und erneut unter /var/lib/opsi/repository eingestellt, mit geänderter MD5
d) auf Depot B läuft opsi-product-updater per cron
-> es wird NICHT erneut heruntergeladen, da sich lt opsi-product-updater Paket- und Produktversion ja nicht geändert haben ( MD5 jedoch schon !!!)
-> man sieht deutliche Unterschiede in \\config_a\opsi-depot\xy und \\depot_b\opsi-depot\xy

Warum wird das Paket auf dem Depot B nicht aktualisiert? Es gibt gem. MD5 eine eindeutig Änderung im Paket!

Man könnte argumentieren, dass ich einfach die Paketversion ändern könnte, aber das würde sich im Configed bei den Clients widerspiegeln, wo ich es definitiv nicht will, denn ich habe nur einen Fehler korrigiert und dem Paket keine neuen Features oder sonstwas verpasst, was ein möglicher Grund für eine Paketversionsänderung wäre. Sonst müsste ich das Paket ja als "nicht aktuelles" Paket auf den Clients ebenfalls neu installieren (um die rote Meldung weg zu bekommen).

Wie zwinge ich Depot B, auf der der opsi-product-updater läuft, dazu, die Pakete bei einer MD5 Änderung neu herunterzuladen und auf dem Depot zu installieren?

EDIT: Sogar eine Paketversionsunterschied scheint da nix auszurichten. Folgende Zeile habe ich gerad vom Updater gemeldet bekommen: Das ist eindeutig Mumpitz - 1.0-1.corr141048corr ist was anderes als 1.0-1.corr172327corr...

Ok, sehe gerade da kommt bei -vvvv ein: Aber das ist auch Quark. Er soll da nix checken ob größer oder kleiner, sondern nur, ob anders! Das kann er gar nicht beurteilen...

Lieber Gruß
Holger

Ok, habe ein Posting gefunden, was das Verhalten erklären könnte: viewtopic.php?p=25164#p25164



Wie kann ich ggf. selber den opsi-product-updater so abändern, dass er einzig und alleine auf Basis der MD5 vergleicht. Ich bin so braun und behaupte, die Versionsnummern gehen ihn absolut NICHTS an, da das meine eigene Logik hat, die er gar nicht interpretieren können muss.

Oder hat jemand zufällig schon ein Script, was vielleicht mittels rsync abgleicht oder so rumliegen?

EDIT: ich habe den Vergleich auf Basis MD5 testweise in meinen Depotmanager im oPB eingebaut. Sieht gut aus. Wenn sich das bewährt, dann liefere ich das die Tage aus.

Hallo pandel,

da du das Posting schon selbst gefunden habt, bleibt mir nur noch die Empfehlung die Versionen möglichst simpel zu halten - dann klappt auch der Vergleich. Andere Logiken sind von uns nicht wirklich vorgesehen.

Berechnest du im oPB die md5 immer on-the-fly? Es kann ja durchaus mal Pakete ohne .md5 geben.


Gruß

Niko

Hi Niko!

Nein, ich berechne die MD5s nicht, sondern lese sie aus den vorhandenen *.md5 aus. Wenn keine da ist oder ich nicht darauf zugreifen kann, dann weise ich das einfach aus und fertig. Ich hatte bis dato noch kein einziges Paket ohne .md5 oder ohne .zsync Datei. Daher bin ich davon ausgegangen, dass es zwingend immer so ist. Ich hatte allerdings schonmal das Problem, dass ich den Inhalt der .md5 nicht lesen durfte, weil die Dateirechte nicht stimmten.

So lese ich das per plink aus: Das ergibt Ausgabezeilen á la "d25f093e0004014443d41f4c58e4cb7a-@MD5@-testdummy_1.0-2.opsi". Das lässt sich dann gut weiterverarbeiten und auch wenn mal keine kommt, ist es nicht schlimm. Da ließe sich sogar drauf reagieren und dann otf eine erzeugen.

Aber: In welchem Fall ist denn keine .md5 vorhanden? Wenn jemand eine .opsi Datei per Hand ins Repo kopiert und nicht per opsi-package-manager hochlädt? Wäre sowas überhaupt zulässig?

Und unabhängig davon, was spricht gegen einen MD5 Vergleich? Der Vorgang dauert ja eh eine gewisse Zeit, da könnte der Updater auch noch eben MD5s ausrechnen, die fehlen...

MD5s erstellen ---------------

Ich werde mir jetzt mit der Erweiterung vom oPB helfen, da ich durchaus nicht auf eine "erweiterte" Interpretation der Paketversionsnummern verzichten will. Mich wundert allerdings, dass du schreibst, dass ihr da nicht wirklich etwas anderes vorgesehen habt, denn was machst du in folgendem Fall:

- Paket für MS Office gebaut, Volumenslizenz hart im Paket verstaut, da das Lizenzmanagement Modul noch nicht zum Einsatz kommt
- Paket auf 100 Rechner erfolgreich installiert
- aufgrund geänderter Anforderungen Lizenzmanagement-Modul gekauft und Paket so umgebaut, dass es das auch nutzt
--> nach eurer Logik müsste ich für ein sauberes Update die Paketversion hochziehen, damit es neu verteilt wird
---> führt aber dazu, dass angeblich 100 Rechner nicht mehr aktuell sind und rote Versionszahlen zeigen

Wenn ich jetzt im configed den Menüpunkt "Nicht aktuelles Produkt..." nutze, bekomme ich für MS Office 100 false positives. Oder würdest du dann hingehen und überall neu installieren, nur, damit im configed die Versionsnummer wieder ordentlich aussieht?

Für den Fall, jemand sagt, ignoriers doch einfach im configed: unsere Verbandsprüfer sind sehr pingelig, was aktuelle Softwarestände und Inbetriebnahmedaten von Updates, etc. anbelangt. Wenn die aus irgendeinem Grund einen veralteten Stand sehen (ob es nur so aussieht, wie bei den o. g. false positives oder wirklich so ist, spielt keine Rolle), kommt man schnell in Begründungsnot. Wenn die Zahl dann auch noch rot leuchtet, ohjee...

Lieber Gruß
Holger

Hallo Holger,

du machst Sachen du... na na na

Niko hat in seinem Post schon Recht, dass haben wir nicht vorgesehen. Der Mechanismus ist so ausgelegt, dass er nur reagiert, wenn die Version sich erhöht. Wir können gerne darüber diskutieren, ob das so richtig ist oder nicht. Bei uns kommt es an dieser Stelle nicht auf MD5-Summen an, sondern um die Versionen. Ich kann dir auch genau sagen warum: du musst in deinen Gedächtnis-Stack noch die Option autoSetup mit reinnehmen . Gemäß dem Fall wir würden das so machen wie du es sagst, dann würde bei autoSetup genau das eintreten, was du bei deiner kleinen Änderung nicht haben willst: Die 100 Rechner würden office auf setup gestellt bekommen und es installieren. Weil genau an der Stelle überprüfen wir nicht, ob die Pakete Outdated sind, da ja per Definition es nur soweit kommen kann, wenn du die Versionen hochzählst.

Im übrigen hinkt dein Vergleich mit dem Lizenzmanagement etwas:
Nehmen wir mal an du hast tatsächlich erst den Lizenzkey hart im Paket verteilt und aktivierst dann erst das Lizenzmanagement. Das bedeutet nicht, dass dann alles im Butter ist. Ich würde mal sehr stark behaupten (schlagt mich aber nicht, wenn das nicht ganz korrekt ist, war ein harter Tag heute), dass es keinen Mechanismus gibt, der dann automatisch einen abgleich macht und merkt, ohh wir haben 100 Rechner mit dieser Lizenz, also machen wir mal ein Update auf das Backend. Es könnte jetzt sein, dass es im Servercore oder im Configed eine Magic-Implementation gibt, aber das wage ich mal sehr stark zu bezweifeln.

Was kannst du machen?
Richtig wäre, dass du wenigstens die PackageVersion hochzählst. Aber das willst du ja nicht. Du könntest im Paket bei Office prüfen, ob die Version die du installieren willst, schon drauf ist (intelligentes Paket), aber damit würdest du das Lizenzmanagment-Problem von oben auch nicht lösen, es sei denn du beziehst eine Lizenz im Skript, egal ob du installierst oder nicht. Diese Lösung hat aber noch einen Hinkefuss, damit zerstörst du dir das Reinstall Feature (wenn z.b. Office kaputt ist), um das wieder zu umschiffen, müsstest du eine Force-Möglichkeit einbauen, .... ich glaube mehr brauche ich hier nicht zu schreiben.

Was würde ICH in so einem Fall machen?
Ich würde das Paket mit einer neuen Packageversion bauen und zum verteilen freigeben. Ins lokale Repo (übrigends sollte keiner manuell ins Repo können, du kannst es aber wie so oft auch nicht wirklich verhindern. Da zählt die alte Weisheit, wenn man was kaputt machen will, kriegt man das auch kaputt ) rein und über den opsi-product-updater verteilen. Wenn es wirklich nur um die Anzeige im configed geht, würde ich persönlich das Backend manipulieren. Alle productOnClients mit einem Filter für das Produkt ziehen, Versionen anpassen und alle betroffenen productOnClients updaten. Fertig!

Grüße aus dem Zug
Erol

Hi Erol,

absolut nachvollziehbar, deswegen nutze ich autoSetup auch nicht .... wenn, dann würde ich das paketabhängig nutzen, also manche autoSetup ja, manche nicht, aber das geht ja eh nicht.

Das mit dem Hinken liegt glaube ich eher an einer sprachlichen Undeutlichkeit meinerseits: ich stelle nur von paketintern auf Lizenzverwaltung (im Setup Script) um, d. h. da muss überhaupt kein Mechanismus einen Abgleich mit dem Backend machen, sondern es gilt einzig für kommende Installationen. Daher möchte ich das Paket auch nur deshalb erneut verteilen, weil bei zukünftigen Installationen dann von jedem Depot aus der Liz.-Man. verwendet werden soll. Ergo ändere ich die Versionsnummern nicht, damit es eben nicht zu einer ungewollten Wiederinstallation kommt.

Was du meinst ist (glaube ich) die nachträgliche Erfassung / Registrierung der bereits verwendeten (100) Lizenzen im Liz.-man.-backend. Das war nicht gemeint, sorry...

OT: das mit dem kaputt machen wollen und auch kriegen ist sowas von war , heute noch erlebt!

Deine Idee, das Backend bzgl. der Versionsnummern anzupassen ist allerdings interessant. Das ist auch einfach zu scripten. Da denke ich mal drüber nach... (ansonsten hab ich jetzt alles Nötige dafür in den oPB gepackt (gut, on-the-fly MD5 fehlt, aber das kann ich derzeit verschmerzen). Wird noch ein paar Tage getestet, dann wird's offiziell)

Lieber Gruß und schönes Wochenende!
Holger

Hi Holger,

pandel hat geschrieben: dann würde ich das paketabhängig nutzen, also manche autoSetup ja, manche nicht, aber das geht ja eh nicht.

das stimmt nicht ganz. Du kannst es sehr wohl Paketabhängig benutzen, die Konfiguration sieht einfach nur etwas kurios aus. Du musst praktisch zwei Repo-Configs anlegen. In die eine kommen die autoSetup-Pakete rein, in dem anderen der Rest. Haben wir schon mal gemacht, als ein Kunde genau das selbe haben wollte, aber nur autoSetup für opsi-client-agent Paket und für den Rest nicht.

pandel hat geschrieben:ansonsten hab ich jetzt alles Nötige dafür in den oPB gepackt

Da machst du aber den Push über den opsi-package-manager oder? Das kannst du für deinen Fall übrigends auch so benutzen, dem ist das egal, ob du die Version hochzählst. Der prüft aber auch nicht wirklich, sondern pushed das Paket immer ins Depot-Repo. Das ist nunmal eine andere herangehensweise, als das der opsi-product-updater macht.

Grüße
Erol

ueluekmen hat geschrieben: das stimmt nicht ganz. Du kannst es sehr wohl Paketabhängig benutzen, die Konfiguration sieht einfach nur etwas kurios aus. Du musst praktisch zwei Repo-Configs anlegen. In die eine kommen die autoSetup-Pakete rein, in dem anderen der Rest. Haben wir schon mal gemacht, als ein Kunde genau das selbe haben wollte, aber nur autoSetup für opsi-client-agent Paket und für den Rest nicht.

Daran hab ich nicht gedacht, simpel, aber effektiv! Das ist eine wirkliche Überlegung wert. Danke für den Hinweis!!

ueluekmen hat geschrieben: Da machst du aber den Push über den opsi-package-manager oder? Das kannst du für deinen Fall übrigends auch so benutzen, dem ist das egal, ob du die Version hochzählst. Der prüft aber auch nicht wirklich, sondern pushed das Paket immer ins Depot-Repo. Das ist nunmal eine andere herangehensweise, als das der opsi-product-updater macht.

Wenn ich was mit Paketen rein-raus mache, dann nehme ich den opsi-package-manager, richtig. Was ich mit "in den oPB eingebaut" meinte war auch nur, dass ich den Versionsvergleich um MD5 erweitert und das allg. Handling in Details verbessert habe. Nix weltbewegendes also...

EDIT: fürs Protokoll, neue Version oPB is draussen. MD5s können jetzt nicht nur verglichen, sondern auch paket- und serverweise neu generiert werden.