Problembreichte über OPSI versenden

[stephan.holljes]

Hallo,

wir würden unseren Benutzern gerne eine Funktion zur Verfügung stellen auf einfache Art und Weise Probleme an Administratoren weiterzuleiten.
Ich habe bereits eine lokal installierte OPSI Installation im Backend (/usr/share/pyshared/OPSI/Backend/Backend.py) daraufhin angepasst. Die Änderung stellt lediglich eine weitere Funktion für OPSI rpc-Aufrufe zur Verfügung.
OPSI selbst stellt ja auch ein Webinterface zur Verfügung, vielleicht könnte es auch dort implementiert werden.

Mein eigentliches Problem ist die Frage, ob OPSI diese Aufgabe überhaupt übernehmen soll und wenn ja, wo diese implementiert werden soll, oder ob eine Implementation in einem externen Webservice sinnvoller wäre. Der Webservice soll dann eine Authentifizierung des Benutzers über OPSI durchführen.

-Stephan Holljes

[n.wenselowski]

Hallo Stephan,

die Backend.py anzupassen ist möglich, aber nicht sehr elegant, da man diese Änderungen bspw. bei Updates wieder verliert.
Wenn es nur um eine weitere Funktion geht, dann kann man diese einfach durch eine Backend-Erweiterung einbringen und im Webservice zur Verfügung stellen.

Was ich mich frage ist, wie der Use-Case aussehen soll.
Sollen die Mitarbeiter im Configed solche Meldungen aufgeben können?
Sollen es die Mitarbeiter am Rechner machen können?


Viele Grüße

Niko

[d.oertel]

Hi,

Du hast die wesentliche Frage ja selber gestellt:

Mein eigentliches Problem ist die Frage, ob OPSI diese Aufgabe überhaupt übernehmen soll

Wenn ich die Idee richtig verstehe, ist das der Beginn eines Ticketsystems.
Ich glaube nicht das wir (uib) ein eigenes opsi-Ticketsystem entwickeln wollen. Vielmehr arbeiten wir ja (mit Partnern) hier an Schnittstellen für existierende Ticketsysteme.
In diese Richtung kann man die Überlegungen konkretisieren.
Dabei stellt sich ein anderes Problem, das Du auch ansprichst:

Der Webservice soll dann eine Authentifizierung des Benutzers über OPSI durchführen.

Opsi kennt keine user - opsi kennt nur Maschinen.
Opsi könnte höchstens sowas wie entgegen nehmen : "Der User auf der Maschine XY (eingeloggt als abc) hat folgendes Problem gemeldet: '....'".
Das könnte dann an ein Ticketsystem weitergegeben werden.

Geht das in die Richtung Deiner Ideen ?

gruß
d.oertel

[stephan.holljes]

Hallo zusammen,

die Backend.py anzupassen ist möglich, aber nicht sehr elegant, da man diese Änderungen bspw. bei Updates wieder verliert.
Wenn es nur um eine weitere Funktion geht, dann kann man diese einfach durch eine Backend-Erweiterung einbringen und im Webservice zur Verfügung stellen.

Die Backend-Erweiterung scheint genau das zu sein, was ich gerne gefunden hätte.

Wenn ich die Idee richtig verstehe, ist das der Beginn eines Ticketsystems.

Genau das habe ich mir damals auch gedacht!

Opsi könnte höchstens sowas wie entgegen nehmen : "Der User auf der Maschine XY (eingeloggt als abc) hat folgendes Problem gemeldet: '....'".
Das könnte dann an ein Ticketsystem weitergegeben werden.

Das wäre nach meiner Ansicht genau das was wir erreichen wollten. Gibt es bereits in Opsi "integrierte" Ticketsysteme?

Gruß Stephan Holljes

[d.oertel]

Hi,

Gibt es bereits in Opsi "integrierte" Ticketsysteme?

Derzeit im wesentlichen Integration in Richtung Inventarisierung und CMDB zu OTRS und Itomig/Itop
siehe:
http://uib.de/de/opsi/inventarisierung/

gruß
d.oertel

[brann]

Unser Zusatzmodul InventorySync bietet folgenden Umfang für OTRS und OTRS mit KIX4OTRS:

• - Integriert die Hardware- und Softwaredaten verschiedener IT-Inventarisierungssysteme in die OTRS-CMDB
  - die Daten können vor dem CMDB-Import nochmals gefiltert werden
  - zu Inventaränderungen wird automatisch ein Änderungsticket angelegt
  - Erweiterung der Schnittstelle über produktspezifische Backend-Module
  - verfügbare Backends: opsi (OPSI4KIX), baramundi, generisches Backend u.a. für OCS Inventory

Dabei erfolgt einerseits ein Abgleich der CMDB-Daten im OTRS sowie eine automatische Erstellung eines Tickets pro geändertes CI im Rahmen einer solchen Synchronisation. Am CR-Ticket werden die Attributte vermerkt, die sich wegen der Synchronisation geändert haben, und man sieht den alten und den neuen Wert im direkten Vergleich. Dieses CR-Ticket wird automatisch mit dem betroffenen CI verknüpft. Dazu folgt eine automatische Änderung der Werte des CI, weswegen in der CMDB eine neue Version des Objektes entsteht.

Ein Datenblatt mit Screenshots der Integration ist online verfügbar:
http://www.cape-it.de/de/produkte/maint ... ysync.html

Für Fragen stehen wir zur Verfügung.

VG, Anna

[mensch90]

Ich habe für uns firmenintern ein wenig weiter geskripted und in die zentrale Fehlerprüfung eine Meta-Sub-Funktion eingebunden, die automatisch eine Email vom Client aus versendet und Infos in der Mail wie folgt darstellt & das Logfile anhängt:

Code: Alles auswählen

Betreff: Softwareverteilung - FEHLER - rechn483devx86.XXX.de - Paket: libreoffice_4.2.6_beta_25.09.2014

 Server: 10.X.X.X
 Client: rechn483devx86.XXX.de
 Paket: libreoffice_4.2.6_beta_25.09.2014 
 Rechte: SYSTEM 
 Exitcode: 1 
 Zeit: 06.10.2014,  8:33:14,12 
 
 Attachment: 10.X.X.X-rechn483devx86.XXX.de-libreoffice_4.2.6_beta_25.09.2014.log

Bei Interesse kann ich gerne Details dazu nachreichen.