Ablauf des opsi-product-updater - Bug oder Feature

[JMS]

Hallo opsi-team,

der opsi-product-updater startet sein Lauf, stellt ein Delta fest, startet den Download und stellt dann fest, dass er sich für die Installation (Paketintegration) ausserhalb des Zeitfensters befindet und bricht die Installation ab.

Wenn ich den opsi-product-updater nochmal starte, dann wiederholt sich das Ganze, natürlich auch der wiederholte Download von OPSI-Paketen

Frage: wäre es - den Ablauf betreffend - nicht sinnvoller, wenn opsi-product-updater erst prüfen würde, ob er sich im "zulässigen" Zeitfenster befindet, ehe er mit Download beginnt. Das würde Bandbreite einsparen, den er staret jedesmal den Download (jedesmal zig MBs) und stellt danach fest, dass er nicht installieren (integrieren) soll...

[Nachtrag: Versionsnummer /usr/bin/opsi-product-updater 4.0.2.3]

Viele Grüße

JMS


BTW:

• Ist das Feature geplant, in der Konfiguration des opsi-product-updaters im Abschnitt [wol] ein kommasepariertes Feld einzurichten, in das man Clientnamen eintragen kann, die NICHT per WOL gestartet werden sollen?
  Ein "excludeProductIDs" gibts ja bereits, ein "excludeClients" wäre hilfreich...
• Ist das Feature geplant, in der Konfiguration des opsi-product-updaters im Abschnitt [wol] ein kommasepariertes Feld einzurichten, in das man Clientnamen eintragen kann, die NICHT per ShutdownWanted heruntergefahren werden sollen?
  Ich habe - als Workaround - im Paket Shutdownwanted eine Property angelegt, doch schön finde ich das nicht, da ich die OPSI-Pakete gerne unberührt lassen würde.

[ueluekmen]

Hi,

das ist einfach zu beantworten. Das ist definitiv ein FEATURE und kein Bug, denn das Installationszeitfenster ist nur für das autoSetup und WOL-Sektion entscheidend. Die normale Synchronisation findet trotzdem statt, nur werden die Pakete ausserhalb eines konfigurierten Zeitfensters nicht fertig synchronisiert werden findet keine Installation statt.

Ist das Feature geplant, in der Konfiguration des opsi-product-updaters im Abschnitt [wol] ein kommasepariertes Feld einzurichten, in das man Clientnamen eintragen kann, die NICHT per WOL gestartet werden sollen?
Ein "excludeProductIDs" gibts ja bereits, ein "excludeClients" wäre hilfreich...

Geplant nicht, aber wir nehmen immer gerne Featurerequests im Rahmen von einem Supportvertrag entgegen.

Ist das Feature geplant, in der Konfiguration des opsi-product-updaters im Abschnitt [wol] ein kommasepariertes Feld einzurichten, in das man Clientnamen eintragen kann, die NICHT per ShutdownWanted heruntergefahren werden sollen?
Ich habe - als Workaround - im Paket Shutdownwanted eine Property angelegt, doch schön finde ich das nicht, da ich die OPSI-Pakete gerne unberührt lassen würde.

Auch hier gilt das selbe wie beim oberen Zitat. Man könnte auch beide in einem Rutsch implementieren.

Allerdings ist das Problem, dass ein Supportvertag benötigt wird, da es sich hier nicht um Bugs handelt, sondern um Features. ( Lieblingsfrage übrigends auch unter den Entwicklern: Ist das ein Feature oder ein Bug? )

Wir nehmen auch gerne Patches zur Prüfung entgegen, also wenn du es direkt implementieren kannst, prüfen wir gerne eine Aufnahme des Patches.

Grüße
E. Ueluekmen

[JMS]

Hallo,

ok, verstanden: die beiden Punkte (in den Spiegelstrichen genannt) sind Features.

das Installationszeitfenster ist nur für das autoSetup und WOL-Sektion entscheidend

Könnte noch ergänzt werden: "das Installationszeitfenster ist für das Anstoßen der Downloads irrelevant: werden neue Pakete gefunden, so werden diese grundsätzlich erst einmal heruntergeladen, ehe fallweise die weitere Verarbeitung angestoßen wird."
(Zumindest stellt es sich bei mir so dar)

habe ich also richtig verstanden, dass der in meinem Fall alle vier Stunden per cron getriggerte Product-updater jedesmal den Download von Paketen startet, auch wenn das Skript außerhalb "windowStart" & "windowEnd" gestartet wird? Dass das Paket nicht integriert (OPSI-Wording:"Installiert") wird, mag ja okay sein, aber warum dann der immer wiederkehrende Download? Sollte nicht besser vor dem Download geprüft, ob sich das Skript im Zeitfenster befindet und dann - abhängig vom Ergebnis - die weiteren Trigger gesetzt werden?

Wie auch immer: Bislang war ich der Annahme, dass das zu definierende Zeitfenster auch den Download steuert und nicht nur die eigentliche Installation (Paketintegration ins Depot). Ich werde das Zeitfenster wieder rausnehmen, denn so macht es - zumindest für mein Szenario - keinen Sinn und beansprucht nur Bandbreite, wenn die Pakete außerhalb des Zeitfensters immer wieder heruntergeladen werden...
Außerdem "dachte" ich, dass das Skript auch einen "on demand" auf den Clients triggert, damit auch die PCs erreicht werden, die abends nicht ausgeschaltet werden. (Ein "OnDemand" sollte dann natürlich ein WOL inkludieren)

Wir nehmen auch gerne Patches zur Prüfung entgegen, also wenn du es direkt implementieren kannst, prüfen wir gerne eine Aufnahme des Patches.

Da ich ungerne an Euren python-Skripten "rumlöten" möchte und ich - sollte ein bereitgestellter Patch nicht ins Release aufgenommen werden - keinenfalls irgenwelche Forks pflegen möchte, werde ich mir mal was ausdenken, wie ich per bash-Skript neue Pakete ins Depot bekomme. Im Grunde wird das dann nichts anderes als das besagte Phyton-Skript, aber mit etwas mehr Funktionen...
Ist dann zwar nicht 100% interoperabel, aber OPSI läuft auch nur auf Debian... hinzu kommt, dass ich mich mit Phyton (noch) Null auskenne ...

Viele Grüße

JMS

[ueluekmen]

Hi,

ich verstehe gerade nicht wirklich was du versuchst zu erreichen.

Wenn du ein Zeitfenster setzt, und dafür sorgen willst, dass der opsi-product-updater nichts tut, wenn man sich nicht im Zeitfenster befindet: Wäre meiner Meinung nach der einfachste Weg, den opsi-product-updater nicht zu starten. Warum willst du den updater alle 4 Stunden laufen lassen, um dann nichts zu tun?

Das Zeitfenster wurde implementiert, da man im Falle eines Downloads nie genau sagen kann, wann der Download abgeschlossen ist. Deshalb wurde als präventive Maßnahme vorgesehen, dass die Installation auf den Clients nicht startet, wenn eine gewisse Uhrzeit überschritten wird.

Das Hauptziel dieser Funktionen vom opsi-product-updater liegt darin, alles nötige Nachts wenn keiner Vorort ist an zu stoßen und ab zu schliessen, so dass die Anwender vom Client-Management nichts mitbekommen und keine Verzögerungen bestehen. Das ist eine Methode um dem entgegen zu wirken. Mittlerweile gibt es verschiedene Methoden die man verwendet kann, um eine Entlastung des allmorgendlichen "Kampfpatchens" entgegen zu wirken. Unter anderem: WAN/VPN Modul, InstallByShutdown, eventuell auch SilentInstall....

wenn die Pakete außerhalb des Zeitfensters immer wieder heruntergeladen werden...

Das darf nicht sein. Es wird nicht immer wieder heruntergladen, sondern er merkt normalerweise, dass er die aktuelle Version im lokalen Repository schon hat. Da wird also nichts runtergeladen, wenn doch, dann ist das ein Bug.

Da ich ungerne an Euren python-Skripten "rumlöten" möchte

Es ist jeder Eingeladen nicht nur mit zu diskutieren, sondern auch gerne mit zu arbeiten.

Wir bieten auch neben der normalen Schulung einen opsi-Praxis-Workshops in Mainz an. Dort werden auch solche Themen mit angesprochen.

Näheres dazu unter: http://www.uib.de/www/opsi-kurse/index.html (Die nächste Schulung ist vom 24.07. - 25.07.2013) Man sollte die Anmeldung aber nicht zu lange rauszögern, da diese Schulungen auf einen kleine Teilnehmeranzahl beschränkt ist.

Grüße
E. Ueluekmen