Benachrichtigung nach Installationsende

[ueluekmen]

Hallo Holger,

dass kann man jetzt so oder so sehen. Ich habe auch in meinem Beitrag eben geschrieben, dass wir diese Frage damals so für uns beantwortet haben und aus dieser Antwort dann der opsi-nagios-connector entstanden ist. Diese Ansicht muss ja nicht jeder Teilen, wäre ja langweilig sonst.

Ich habe nie gesagt, dass opsi dies nicht können soll. Wie du schon vorher ja richtig festgestellt hast, verschickt der opsi-product-updater eine Mail, wenn man das will. Dort ist es aber auch nicht schwierig, da das ganze ja ein abgeschlossener Workflow ist, mit einem Anfang und einem Ende, was durch den Aufruf vom opsi-product-updater klar definiert ist.

Das was du willst ist halt schwieriger um zu setzen. Wie soll das ablaufen? Soll er jedes mal eine Mail schicken? Wie soll opsi die Aufträge auseinander halten? Du müsstest an der Stelle Pollen. Was du auch tun könntest, du kannst ggf. euer System an der Stelle erweitern. Stell dir vor, deine Leute können vom Tivoli Management aus direkt Aufträge in opsi reinkippen und die Erfolgskontrolle auf der selben Art und Weise durchführen. Dann hast du eine komplette Auftragsverwaltung und nach wie vor, kümmert sich jedes System, um seine eigene Aufgabe.

Du kannst auch ein Skript laufen lassen, welches einfach regelmäßig guckt und entsprechend eine Mail schickt oder nicht. Aber du willst ja wahrscheinlich nur einmal eine Mail haben und nicht jedesmal, also musst du dir an der Stelle auch das Delta merken und irgendwie eine logische Gruppierung nach Clients oder nach Produkten oder nach Depots oder ... . Irgendwie musst du ja auch an den User und die Auftrags-ID rankommen. Da könnte man eine schöne Lösung bauen, die aber wahrscheinlich nur bei euch passt. Ob man jetzt Icinga, bzw. Nagios als komplexes System betrachtet.... ja, welches System zur heutigen Zeit ist nicht komplex. Ob Ihr das wollt oder nicht, ist auch eine andere Frage.

Ich habe mit meinem Beitrag einfach nur eine andere Sichtweise aufzeigen wollen, die viele draußen im IT-Service auch so leben (wie man im ITIL so schön sagt). Ob das jetzt genau für euch passt oder nicht, weiß ich nicht.

Wir sehen das so: Wenn du als Admin einen Job auf 100 Plätzen triggerst, soll opsi genau das tun, wofür halt opsi gedacht ist. Wenn du aber jetzt sagst, dieser Job soll mir eine Rückmeldung geben, wenn er auf zwei Clients auf den Job nicht ausführen konnte: Dann willst du eigentlich eine Überwachung des Software-Rollouts. Oder eine Überwachung des Client-Rollouts. Es geht um die Frage, ob man proAktiv vor den Anwendern merken will, dass man ein Problem hat oder eben nicht.

[tobias]

Eine Backenderweiterung zum Versand von E-Mails über den WebService.
Nun müsste man noch die Stelle finden wo OPSI eine Produktaktion auf FAILED setzt und dort diese Methode zusätzlich aufrufen.

Natürlich gilt auch hier wieder:
Der Code ist geklaut, ich übernehmen keine Gewährleistung und es ist sicherlich total unprofessional , zeigt aber das man OPSI super einfach erweitern kann

Code: Alles auswählen

def SendMail (self, To, Subject, Message):
        # Import smtplib to provide email functions
        import smtplib

        # Import mail module
        from email.mime.text import MIMEText

        # Define email addresses to use
        addr_to   = To
        addr_from = 'opsi@yourdomain'

        # Define SMTP email server details
        smtp_server = 'YourSMTPServer'

        # Construct email
        msg = MIMEText(Message)
        msg['To'] = To
        msg['From'] = 'opsi@yourDomain'
        msg['Subject'] = Subject

        # Send the message via an SMTP server
        s = smtplib.SMTP(smtp_server)
        s.sendmail(addr_from, addr_to, msg.as_string())

Am einfachsten und am besten steuerbar wäre es nun jedoch, diese methode innerhalb eines Scriptes aufzurufen z.B. wenn ein Fehler aufgetreten ist.

[pandel]

Hi!

Vorneweg: ich kann deine die Argumentation durchaus nachvollziehen, klar, aber ...

(Was unser Tivoli anbelangt, das wird durch unser RZ, an das wir angeschlossen sind gepflegt, da kommen wir nicht ran. Daher ist eine Integration beider Systeme nicht denkbar.)

Du schreibst:

Das was du willst ist halt schwieriger um zu setzen. Wie soll das ablaufen? Soll er jedes mal eine Mail schicken? Wie soll opsi die Aufträge auseinander halten? Du müsstest an der Stelle Pollen

opsi liefert doch selbst den Failed-Status, falls ein Inst-Job nicht geklappt hat. Wenn darüber eine Mail verschickt würde mit einem definierbaren Adressaten, wär's doch schon ok. Das darf ruhig jedesmal passieren. Und was meinst du mit "Wie soll opsi die Aufträge auseinanderhalten?" ... tut opsi doch - pro Maschine! Also könnte opsi doch sagen, "Softwarepaket xy ist auf Maschine bla nicht erfolgreich installiert worden".

Schicker wär folgendes (so macht's das Tivoli halt):
Software, die zur Installation oder zum Update markiert wird, wird pro Maschine in einen separaten "Auftrag" gesteckt, und dieser "Auftrag" wird entsprechend abgearbeitet (sofort oder zeitgesteuert). In einem Auftrag werden die einzelnen Teile systematisch von oben nach unten abgearbeitet. Läuft ein Teil vor den Hammer, stoppt der gesamte Auftrag und es geht eine Mail mit der Auftrags-ID raus, die sich der Admin nochmal ansehen muss. Ist der Fehler bereinigt, kann der Auftrag erneut angestartet werden. Der Auftrag läuft dann einfach ab der Stelle weiter, wo er gestoppt hat. Ist alles erledigt, wird er als "Successful" gekennzeichnet und ist raus - in diesem Fall gibt's halt keine Mail.

Klar, du brauchst für sowas eine eigene Job-Queue, die "Aufträge" verwaltet und eine zweite Verwaltungseinheit, die wiederum den Inhalt der "Aufträge" verwaltet. Aber das ist eigtl. nicht wild.

Wir sehen das so: Wenn du als Admin einen Job auf 100 Plätzen triggerst, soll opsi genau das tun, wofür halt opsi gedacht ist. Wenn du aber jetzt sagst, dieser Job soll mir eine Rückmeldung geben, wenn er auf zwei Clients auf den Job nicht ausführen konnte: Dann willst du eigentlich eine Überwachung des Software-Rollouts.

Da könnte ich jetzt ketzerisch sagen: klar, opsi soll tun wofür es gedacht ist, nämlich Softwareinstsallationen managen, aber wie krieg ich denn mit, dass es das auch erfolgreich getan hat? Muss ich mir extra NUR DAFÜR wieder eine andere Software installieren, die jetzt opsi überwacht?

[tobias]

Kann es sein das wenn ein Product "failed" nicht die Methode setProductState aufgerufen wird?
Ich habe nämlich einfach mal diese Methode um eine Zeile erweitert die eben eine Mail verschickt.
Ist die installation Erfolreich kommt eine Mail bei mir an, schlägt sie fehl passiert nix

Habe dort einfach die oben gepostete Methode angegeben:
self.SendMail("Test","Test","mail@meinedomain.de")

kann natürlich auch noch sein das ich an der falsche stelle rumwurschtel. 20_legacy ist die einzige datei wo ich was passendes finden konnte

[n.wenselowski]

Hallo tobias,

jetzt ist die Frage, welche Methode wann aufgerufen wird

Um mich mal von vorher zu quoten:

Die zu überschreibende Methode müsste productOnClient_updateObject sein.

Nicht sicher, aber wär nen Versuch wert


Gruß

Niko

[tobias]

mhh wo sind diese methoden definiert?
Legacy methoden sind ja eigtl. die OPSI3 methoden, wobei ich mich da wunder das die überhaupt noch aufgerufen werden von OPSI Selbst

[ueluekmen]

Ok, jetzt geht das ganze aber in eine komplett andere Richtung. Das was du jetzt beschreibst ist eine Auftragsbearbeitung. Genau so etwas hat opsi noch nicht. So etwas wäre vielleicht ein Bestandteil von Scheduled Tasks, die wir auch geplant haben.

Noch mal, eine Mail zu verschicken ist kein Hexenwerk, die Frage ist (wie ja auch tobias herausgefunden hat) WANN und an WEN wird eine Mail verschickt. Man könnte jetzt bei jedem Failed eine Mail an alle schicken (ist die einfachste Lösung). Aber, wenn es drei admins gibt, und ein produkt an 100 Clients verteilt wird, was ein failed zurückliefert, weil man vergessen hat ein DefVar vor dem set zu setzen. Dann werden auch 300 Mails verschickt, Was man aber wissen will ist, dass ein Produkt einen Fehler hat, dafür will ich wiederum keine 100 Mails bekommen. Und jetzt stell dir mal vor du hast mehr als 1000 Clients dran. Da wirst du verrückt.

Aber wie man uns kennt, für Geld bauen wir viel.

@tobias: Die methoden aus der legacy sind opsi3 Methoden, die auf die opsi4 gemapped wurden. Aber diese Methoden sind leichter zu benutzen, wenn man Skripte schreibt, deshalb fliegen diese Methoden nicht raus.

Die Methode productOnClient_updateObjects ist schon richtig, nur ist das eine Backend-Methode. Diese Methode zu überschreiben oder zu verändern würde ich nicht empfehlen. Man könnte aber diese Methode über die Dispatcher in einem anderen Context aufrufen. Dafür müsste man sich ein Mini-Backend bauen. Aber einfacher ist es in dem Fall die Mails von den Clients verschicken zu lassen. Weil die Clients Ihre zustände zurück mailen. Wie man das machen kann steht ja weiter oben im Thread.

Dennoch bleibe ich dabei, für mich ist das ein klarer Fall von Monitoring.

[pandel]

... Was man aber wissen will ist, dass ein Produkt einen Fehler hat...

eben nicht! Ich will nicht wissen, ob das Produkt einen Fehler hat, denn das habe ich hoffentlich bei der Entwicklung bereits ausgemerzt! Ich will sehen, ob ein Produkt bei der regulären Installation (aus erstmal egal welchem Grund) vor den Hammer gelaufen ist. Denn du kannst eine Produktinstallation noch so gut vorplanen, testen, entwicklen, bla, aber es kann immer mal vorkommen, dass etwas vereinzelt nicht richtig läuft. Bspw. bei der Installation von MS Patchen, wenn mal auf einem Rechner ein Registry Eintrag kaputt ist, der die Installation ausbremst, etc.

Aber gut, da haben wir offensichtlich einfach unterschiedliche Ansichten...

@tobias
Das klingt vielversprechend. Wenn deine Anpassung jetzt Mails nur bei Status "failed" versendet, ist es genau das, was ich meine. Dann muss nur iwie der Rechnername und die Produktbezeichnung, am besten mit Version in die Mail und fertig.

[tobias]

Ok, jetzt geht das ganze aber in eine komplett andere Richtung. Das was du jetzt beschreibst ist eine Auftragsbearbeitung. Genau so etwas hat opsi noch nicht. So etwas wäre vielleicht ein Bestandteil von Scheduled Tasks, die wir auch geplant haben.

Noch mal, eine Mail zu verschicken ist kein Hexenwerk, die Frage ist (wie ja auch tobias herausgefunden hat) WANN und an WEN wird eine Mail verschickt. Man könnte jetzt bei jedem Failed eine Mail an alle schicken (ist die einfachste Lösung). Aber, wenn es drei admins gibt, und ein produkt an 100 Clients verteilt wird, was ein failed zurückliefert, weil man vergessen hat ein DefVar vor dem set zu setzen. Dann werden auch 300 Mails verschickt, Was man aber wissen will ist, dass ein Produkt einen Fehler hat, dafür will ich wiederum keine 100 Mails bekommen. Und jetzt stell dir mal vor du hast mehr als 1000 Clients dran. Da wirst du verrückt.

Das ist eigl. ganz Simpel.
Wenn Fehler dann Mail. Wenn man dann 1000 Clients hat und 1000 Fehler auftreten dann ist das gleichzeitig die Strafe dafür das man das Paket nicht richtig getestet hat

@tobias: Die methoden aus der legacy sind opsi3 Methoden, die auf die opsi4 gemapped wurden. Aber diese Methoden sind leichter zu benutzen, wenn man Skripte schreibt, deshalb fliegen diese Methoden nicht raus.

Jop das weis ich, nur wunderts mich das selbst OPSI noch standardmäßig auf diese Methoden zugreift, aber scheinbar nur wenn eine Installation successfull ist.
Lungern da eventuell noch Altlasten im WINST rum?

Die Methode productOnClient_updateObjects ist schon richtig, nur ist das eine Backend-Methode. Diese Methode zu überschreiben oder zu verändern würde ich nicht empfehlen. Man könnte aber diese Methode über die Dispatcher in einem anderen Context aufrufen. Dafür müsste man sich ein Mini-Backend bauen.

Mhh also doch nicht so einfach wie gedacht, schade. Da hörts bei mir leider auf wüsste nicht wo ich solche Codeschnipsel klauen soll

Aber einfacher ist es in dem Fall die Mails von den Clients verschicken zu lassen. Weil die Clients Ihre zustände zurück mailen. Wie man das machen kann steht ja weiter oben im Thread.

Stimmt schon, jedoch muss dafür jedes Paket vorbereitet sein und es funktioniert nicht bei WAN/VPN und eine mal gehts mal gehts nicht Lösung finde ich da auch nicht so toll

Dennoch bleibe ich dabei, für mich ist das ein klarer Fall von Monitoring.

Es ist ein Teil vom Monitoring, ein Fehler Reporting halte ich jedoch immer noch für einen Spezialbereich.


ps. wo finde ich die Backend Methoden? So schnell geb ich mich nicht geschlagen

[n.wenselowski]

Guten Morgen tobias,

ps. wo finde ich die Backend Methoden? So schnell geb ich mich nicht geschlagen

https://opsi.server.fqdn:4447/interface


Gruß

Niko