Benachrichtigung nach Installationsende

[hawaii]

Hey @ll,

irgend jemand eine Idee wie ich mir eine Benachrichtigung (z.B. Email) zukommen lassen kann, wenn ein Client installiert ist?
Gibt es so einen Mechanismus in Opsi bereits und ich finde ihn nur nicht?

Grüßle,
Kai

[n.wenselowski]

Hallo Kai,

einen solchen Mechanismus gibt es meines Wissens nach noch nicht.

Man könnte die Backend-Methoden überschreiben, so dass jedes Mal, wenn ein Netboot-Produkt in den Status installed gestellt wird eine entsprechende E-Mail versendet wird.
Ein paar Infos gibts im Handbuch, aber wenn du ein wenig Programmieren kannst, ist es vermutlich keine schlechte Idee sich die Scripe in /etc/opsi/backendManager/extend.d mal anzuschauen.
Die zu überschreibende Methode müsste productOnClient_updateObject sein.


Gruß

Niko

PS: Das wäre ein Thema, das man auch im Rahmen einer Schulung genauer durchgehen kann.

[hawaii]

Hallo Niko,

danke für den Hinweis, ich werde mir das mal anschauen.
Schulung ist schon eingeplant für dieses Jahr, ich muss nur noch schauen wann, da ich jetzt demnächst schnell in Elternzeit muss

Aber da wir dank MS ja jetzt Windows 7 schnell raushauen müssen hab ich OPSI hier in den letzten 2 Monaten aus dem Boden gestampft und kann euch nur Danken!
Tolles Stück Software und macht Spaß damit zu arbeiten! Hat die Professionalität unserer IT auf jeden Fall um ein ganzes Stück erhöht!
So, da muss ja auch mal sein

Grüßle,
Kai

[pandel]

Hallo!

Darf ich mich da an die Wunschliste mit dran hängen ? Wir haben heute morgen noch darüber gesprochen, dass es total gut wäre, wenn man solche Mailbenachrichtigungen erzeugen könnte. Falls es da also jemanden von offizieller Seite in den Fingern juckt, eine kleine Ergänzung zur Verfügung zu stellen, wär das schon echt Klasse

Ich würds ja selber probieren, aber Python ist iwie überhaupt nicht mein Fall (zumindest bis jetzt)...

Lieber Gruß
Holger

[ueluekmen]

Hi,

die Frage ist, wie bekommt man mit, dass der Client fertig ist? Es gibt dazu keinen automatismus. Was man machen könnte, es hat sich ja jemand schon mal gedanken dazu gemacht:

wiki/userspace:library:sendmail

Das könnte man verwenden, um ein Paket zu bauen, was einfach nur eine Mail fertig macht. Dieses Paket kann man dann mit einer sehr niedrigen prio immer mitsetzen, dann läuft dieses Paket als letztes und verschickt die Mail.

Allerdings habe ich es auch nur mal im Wiki gesehen, getestet oder mal inhaltlich reingeguckt hab ich nicht, aber der Author ist bestimmt gerne bereit ein zwei Sachen dazu zu erklären, falls notwendig.

Ansonsten könnte man sich auch an das postinst-Verfahren von den Netbootpaketen hängen. Aber der Client ist ja nach dem Netboot noch nicht fertig.

Sonst bleibt momentan wahrscheinlich nur pollen.

[pandel]

Hi,

ok, Clientinstallation ist natürlich ne schwierige Frage, da ist die Idee mit dem Abschlusspaket, was ne Mail schickt, gar nicht schlecht.

Aber was "normale" Produkte anbelangt müsste es doch gehen, wenn in der Produktkonfiguration nach beendetem Installationslauf das Feld, welches die Spalte "Report" im configed füllt, auf "failed" oder "success (setup)" gesetzt wird, oder? Wenn es da einen globalen Parameter gäbe, wo man sagen könnte "wenn Report=failed, dann Mail an xy@bla.de".

Als Randinfo:
Für bestimmte Systeme müssen wir im Hause ein System unseres RZs einsetzen, was auf Tivoli Management basiert. Da wird für jeden User, der was darin darf, ein Kompetenzprofil und eine passende Mailadresse hinterlegt, und wenn derjenige einen Auftrag startet (Install, Uninstall, Update, etc....) wird bei Fehlschlag eine Mail an diese Adresse abgesetzt mit Nennung der Auftrags-ID, die gerade vor die Pumpe gelaufen ist.

Gruß
Holger

[n.wenselowski]

Hallo Holger

Aber was "normale" Produkte anbelangt müsste es doch gehen, wenn in der Produktkonfiguration nach beendetem Installationslauf das Feld, welches die Spalte "Report" im configed füllt, auf "failed" oder "success (setup)" gesetzt wird, oder? Wenn es da einen globalen Parameter gäbe, wo man sagen könnte "wenn Report=failed, dann Mail an xy@bla.de".

Idee dazu: Schau mal im extend.d/30_configed.conf nach getClientsWithFailed_hash. Das ist das, was im Configed als Failed Clients angezeigt wird. Da könnte man ein Programm drum stricken, was sich den letzten Zustand merkt und sobald ein neuer Client / neues Produkt dort auftaucht entsprechend eine Mail verschickt.


Gruße

Niko

[tobias]

Nur mal so eine Idee:
Könnte man das nicht auch mit dem NAGIOS Modul erledigen?

[ueluekmen]

Hallo zusammen,

das ist ein ewiger Diskussionspunkt. Hier werden ITSM Bereiche zusammengewürfelt. Wir standen vor dem nagios-connector-modul vor der selben Frage, die wir für uns wie folgt beantwortet haben:

opsi ist und bleibt ein Management Tool. Das was hier gewünscht ist, gehört klar in den Bereich Monitoring. Opsi ist kein Monitoring Tool und wird auch keine Funktionalität in diese Richtung bekommen, da es genug Software und besonders OpenSource Software gibt, die genau für diesen Zweck gebaut wurden.

Solche Dinge lassen sich wunderbar mit dem Nagios-Connector und einem Nagios bzw. Icinga Server umsetzen. Inklusive Mails verschicken (ist ja ein Hauptbestandteil). Wenn man das noch genauer haben möchte, kann man auch OTRS mit ins Boot holen und die Systeme miteinander verheiraten. Somit kann man ganz viel im ITSM Bereich abdecken. Zum Beispiel könnte man mit Icinga das opsi monitoren und bei einem Problemfall automatisch ein Ticket im OTRS öffnen lassen. Diese dann wiederrum koppeln mit opsi Funktionen. Wenn man dann noch die CMDB von OTRS nutzt, kommt ein schönes Gesamt ITSM Gebilde raus, wo jedes Produkt sich auf seine Stärken konzentriert.

Wenn Interesse an so einem System besteht, sollte man sich auf jeden Fall die kixbox von cape-it anschauen. Die cape-it vereinigen genau die oben erwähnte Konstellation und haben auch fertige Integrationen mit opsi (Automatische Übernahme der Inventory Daten in die CMDB und weitere Funktionen von OPSI.)

http://www.cape-it.de/de/

Dort gibt es auch ein Demosystem zum anschauen.

Ansonsten kann man auch den Nagios-Connector von opsi, wie die anderen Module auch, mal testen.

[pandel]

opsi ist und bleibt ein Management Tool.
...
Zum Beispiel könnte man mit Icinga das opsi monitoren und bei einem Problemfall automatisch ein Ticket im OTRS öffnen lassen. Diese dann wiederrum koppeln mit opsi Funktionen. Wenn man dann noch die CMDB von OTRS nutzt, kommt ein schönes Gesamt ITSM Gebilde raus, wo jedes Produkt sich auf seine Stärken konzentriert.

Die Aussage ist natürlich richtig, aber auch ein Management Tool darf durchaus über Ereignisse berichten, die direkt mit seinen Managementaufgaben zu tun haben. Das hat nichts mit allg. Netzwerk-Monitoring (Nagios und Konsorten) zu tun. Wenn ich als Admin auf 100 Plätzen einen Job initiiere, der auf 2 Plätzen vor die Pumpe läuft, dann halte ich es sehr wohl für die Aufgabe des Management Tools, mich davon zu unterrichten; es kann sicherlich nicht meine Aufgabe als Admin sein, in 100 Maschinendefinitionen mal eben nachzusehen, ob auch alle Jobs sauber gelaufen sind - vor allem, wenn das Management Tool eh aufgrund seiner Aufgabenstellung in der Lage sein muss, Stati zu ermitteln und festzuhalten.

Dieses komplexere Gebilde mit Icinga, etc. will garantiert nicht jeder, sondern einzig ein gut funktionierendes Softwaremanagement Tool. Und wenn dieses Tool in der Lage wäre, den Admin per Mail auf Fehler während der Durchführung der originären Managementaufgaben hinzuweisen, ist das meineserachtens kein Monsterzusatzfeature, sondern eine Abrundung der Grundfunktionalität.