Wer OTRS als HelpDesk System einsetzt und zudem ein iPhone hat, der wird sich freuen, daß er Tickets nun auch von unterwegs leicht bearbeiten kann. Die iPhone App für OTRS ist da.

Die war notwendig, denn man kann konnte die OTRS Site auf einem iPhone zwar im Browser prinzipiell öffnen, aber nicht damit arbeiten. Auf dem iPad funktionierte das perfekt, denn 1024*768 ist für OTRS gerade richtig:

Übrigens funktioniert der Rich-Text Editor im Safari Browser auf dem iPad nicht, ich habe ihn aber sowieso ausgeschaltet, weil er mir zu schwerfällig ist. Der Parameter ist in der SysConfig unter Framework zu finden: Core::Web::

Zum Betrieb der iPhone App muß aber zunächst in der Paketverwaltung von OTRS das iPhoneHandle Package heruntergeladen und installiert werden:

Jetzt kann man im AppStore die OTRS App herunterladen, sie ist, wie OTRS auch, natürlich kostenlos erhältlich. Die Adresse zu OTRS wird als http://<sitename>/otrs/json.pl eingetragen, das Perl Script wird durch das iPhoneHandle Paket installiert. Credentials dazu, connect drücken und das Dashboard erscheint:

Mal schnell ein neues Ticket eröffnen:

und das erscheint (natürlich) sofort auch im Dashboard auf dem PC. Man kann auf Tickets per E-Mail antworten, Notizen hinzufügen und die gearbeiteten Zeiteinheiten erfassen. OTRS für das iPhone ist eine praktische Möglichkeit, sein HelpDesk tatsächlich immer dabei zu haben. Es wird sicherlich nicht mein primärer Weg werden, um in unserem OTRS zu arbeiten, aber unterwegs bestimmt gute Dienste leisten.

Zugegeben, ein seltener Moment, darum mußte ich ihn festhalten: Die Übersichtsseite meines Ticket Systems OTRS ist leer (und mit den 3 Wiedervorlagen während meines Urlaubs komme ich zurecht):

So kann ich beruhigt für eine Woche in Urlaub gehen.

Seit heute kann unser Nagios bei Systemstörungen ein Ticket im OTRS eröffnen und auch wieder schließen, wenn die Störung vorbei ist. Im Gegenzug hat OTRS gelernt, die Störung im Nagios zu acknowledgen, wenn das Ticket zur Bearbeitung geöffnet wird.

Zunächst wird im OTRS in der Paketverwaltung das Modul “System Monitoring” installiert. Die Konfiguration besteht aus zwei Teilen, dem E-Mail Script, das eingehende Mails von Nagios interpretiert und dem Acknowledge Teil, der im Nagios die Störung acknowledged.

Nagios wird nun so eingestellt, daß er alle, oder auch nur ausgewählte Alarme an eine Mailbox sendet, die von OTRS ausgelesen wird (Nagios contacts.cfg). OTRS wird nun der Absender der E-Mails mitgeteilt (“FromAddressRegExp” in “PostMaster::PreFilterModule###1-SystemMonitoring”):

Wenn im Nagios alles standardmäßig konfiguriert ist, dann hat OTRS schon alle Parameter per Default dabei, um aus dem nächsten eingehenden Mail von Nagios ein Ticket zu erstellen, hier habe ich einfach einen Service auf einem überwachten System gestoppt, Nagios hat die E-Mail Notification an OTRS gesendet und OTRS hat ein Ticket eröffnet und sogar die beiden freien Felder “Host” und “Service” gefüllt:

Nun wird das Acknowledgement konfiguriert, hier gibt es zwei Möglichkeiten, per HTTP oder per Named Pipe. Da unser OTRS Server und der Nagios Server durch einige Firewalls getrennt sind, benutze ich die HTTP Methode. Diese wird eingestellt und es wird die URL zum Nagios System und User und Passwort angegeben:

Wichtig: Die beiden freien Felder, in die OTRS den Host und den betroffenen Service einträgt, sollte man nicht verändern, sonst klappt das Acknowledgement nicht!

Wird nun im OTRS das Ticket gesperrt

dann wird der Alarm sofort im Nagios acknowledged:

Ist die Notification im OTRS aktiviert, dann erhält der zuständige Techniker natürlich auch die Nachricht, über das neue Ticket, aber auch über das Acknowledgement:

Das Acknowledgement wird natürlich auch in das Ticket hineingefügt, so daß man den gesamten Verlauf des Problemes schön dokumentiert hat:

Wenn das Problem dann behoben ist, schickt Nagios die RECOVERY Meldung per E-Mail und OTRS schließt automatisch das Ticket:

Auch darüber wird man, bei aktivierter Benachrichtigung, per Mail informiert, weil das Recorverymail ja zunächst eine Nachfrage ist:

Variationen sind leicht möglich, durch verschiedene Contacts im Nagios, welche dann die Mails an verschiedene Adressen senden und somit in verschiedene OTRS Queues einsortieren, ich empfehle natürlich immer, das System so simpel, wie möglich, zu halten!

Es sollen die OTRS Notizen so eingerichtet werden, daß der Status des Tickets beim Erfassen einer Notiz geändert werden kann.

Config Einstellungen: Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###State
Ja = Eingabefelder für Status des Tickets werden angezeigt

Dann sollte man auch gleich den voreingestellten Notiz Typ auf Extern ändern, damit Kunden im Kundenfrontend diese Notizen auch sehen können:

Ticket::Frontend::AgentTicketNote###ArticleTypeDefault
note-external

Wenn der TinyMCE Editor im Firefox quälend langsam ist, dann macht das Eingeben von Texten in Wordpress oder das Ergänzen von Tickets in OTRS keinen wirklichen Spaß, weil der Editor der Eingabe weit hinterherhinkt.

In allen Fällen hilft, den Cache im Firefox zu löschen, den erreicht man über das Menü “Tools” dann “Clear Recent History”:

Danach hat Firefox allerdings alles gemerkte vergessen, vielleicht hat mal jemand Zeit, herumzuexperimentieren, welches der Settings es genau ist, das den TinyMCE Editor so ausbremst.

Benutzt man in OTRS die Bausteine “Anrede”, “Signatur” und “Antworten” so muß man leider festestellen, daß diese in einer recht ungebräuchlichen Reihenfolge zusammengebaut werden. Da kommt beim Erstellen einer Standard e-Mail Antwort zunächst die Anrede, dann das Mail, das der Kunde geschickt hat als Zitat, dann der Inhalt der eigenen Standardantwort und am Ende die Signatur. Steht übrigens auch so im OTRS Handbuch:

Diese Elemente sind standardmäßig so angeordnet, dass beim Antworten zuerst die Anrede, danach der zitierte Text des zu beantwortende Ticket, anschließend ggf. der Text der Antwortvorlage und zum Schluss die Signatur ausgegeben wird.

Zum Glück ist ORTS voll parametrisierbar und so ist die Änderung über das Sysconfig Modul einfach. Man sucht nach “ResponseFormat” und findet den Parameterblock “Frontend::Agent::Ticket::ViewCompose” und dort den Parameter “Ticket::Frontend::ResponseFormat”. Der enthält standardmäßig:

$QData{“Salutation”}
$TimeShort{“$QData{“Created”}”} – $QData{“OrigFromName”} $Text{“wrote”}:
$QData{“Body”}

$QData{“StdResponse”}

$QData{“Signature”}

und ich habe ihn geändert auf die für uns passendere Variante:

$QData{“Salutation”}
$QData{“StdResponse”}
$QData{“Signature”}

$TimeShort{“$QData{“Created”}”} – $QData{“OrigFromName”} $Text{“wrote”}:
$QData{“Body”}

So kommt nun zunächst die Anrede, dann die Standard-Antwort, die Signatur und unten das bisherige Mail:

Von uns eingesetzte Open Source Produkte

• Nagios – der Netzwerkmonitor, paßt aber nicht nur auf, daß nichts ausfällt, sondern liefert auch noch Statistiken über die Verfügbarkeit.
• OTRS – Ticketsystem, das unseren Support organisiert und ITIL konform abbildet.
• FreeNAS – Storage Server, der iSCSI Targets, Windows Shares, NFS Shares, FTP Laufwerke in unserem Netzwerk zur Verfügung stellt.
• KeePass – sicherer Passwortsafe.
• Firefox – der Browser für’s Internet.
• Ubuntu – Linux Distribution für ein DELL Notebook und unser Netbook.
• Asterisk – Freie Telefonanlage, die uns als Vermittlungsstelle für unsere Telefonnummern in Österreich, der Schweiz und Spanien dient.
• Wordpress – Das Weblogging System, auf dem dieses Blog hier läuft.
• TightVNC und System Tools Remote Control Manager zum Fernsteuern von Systemen im LAN (beschrieben hier).