OTRS als Ticketing-Lösung: Teil III – Konfiguration

Grundsätzliches

Die Konfiguration findet bei OTRS weitestgehend im WebInterface statt. Es müssen nur wenige Anpassungen in den Konfigurationsfiles vorgenommen werden. Im WebInterface wird fast alles im Admin-Interface gemacht und nach der ersten Anmeldung sollte das so aussehen, wie unterstehend abgebildet.

1. Nach dem Anmelden sieht man auch gleich den Admin-Reiter, in dem die meisten Konfigurationen vorgenommen werden können.

2. Diese Meldung, die einem direkt ins Auge springt soll dich darauf hinweisen, dass das Arbeiten mit dem Superuser nicht empfohlen wird. Die Erste Aktion nach einer OTRS Installation ist deshalb immer den Superuser zu deaktivieren und einen personalisierten Admin-User zu erstellen.

Den personalisierten User kann man ganz leicht im Admin-Interface anpassen unter der Agentenverwaltung -> Agenten.

Danach den Root@localhost deaktivieren und einen neuen Benutzer zum Administrieren erstellen unter „Agent hinzufügen“. Und keine Angst bei den vielen Varianten und Einstellungen die man verändern kann bei einer Agenten-Erstellung. Vorerst sind diese nicht wichtig, ich komme da später noch darauf zu sprechen. Wichtig ist evtl. nur die Sprache, die Gültigkeit und der Benutzername, sowie die E-Mail Adresse.

Bei den Gruppenzugehörigkeiten des Benutzers ist es einfach wichtig, dass er in der Admin Gruppe ist und RW-Zugriff hat (Read/Write).

Danach gleich mit dem neuen Benutzer anmelden und die Nachricht sollte verschwunden sein.

Scheduler

Oft kann es am Anfang sein, dass eine Meldung vom Scheduler aufpoppt, die meldet, dass der Prozess nicht läuft.
Die Hilfestellung von OTRS ist da aber relativ gut.
Im allwissenden Admin-Handbuch der entsprechenden OTRS-Version befindet sich eine Information wie der Scheduler gestartet werden kann.

Bei meiner Linux-Variante ist es ein einfacher Befehl:

perl /opt/otrs/bin/otrs.Scheduler.pl –a start

Am besten diesen Befehl in die Cron-Tabelle einfügen und einmal alle 2 Stunden durchlaufen lassen, zum Prüfen ob der Dienst noch läuft und ihn allenfalls zu starten, falls nicht.

Damit komme ich zum nächsten Punkt, der zu beachten ist bei einer neuen Installation.  Die Cron-Jobs.

Cron-Jobs

Cron ist unter Linux ein Dienst, der wiederkehrende Tasks im Betriebssystem ausführt. Unter Windows kennt man das als Scheduled Tasks.

Da das OTRS sehr eng mit den Cron-Jobs arbeitet, wird bei einer Windows Installation sogar eine Windows Variante des Cron-Dienstes installiert mit einer eigenen Cron-Tabelle.

Für Cron-Neulinge gibt es eine Fülle an Websites, die genauestens beschreiben wie ein Task in der Tabelle auszusehen hat, welche Mechanismen es gibt und was alles bedacht werden muss bei Cron-Jobs. In der Link-Sammlung zu diesem Blog habe ich ein paar Links eingefügt für alle die sich ein wenig dafür interessieren.

Für alle anderen liegt gleich hier der einfachste und schnellste Weg: Ein Auszug wie ich die Tabelle für ein neues OTRS-System vorschlagen würde.

# Wer soll alle Cron-Benachrichtigungen erhalten?
MAILTO="root@localhost"

# Überprüft den Scheduler, startet den Scheduler alle 2 Stunden
*/5 * * * *    $HOME/bin/otrs.Scheduler.pl -w 1 >> /dev/null
* */2 * * *    $HOME/bin/otrs.Scheduler.pl –a start >> /dev/null

# Startet den Generic Agent alle 20 Minuten um Geplante Tasks im OTRS abzuarbeiten
# (Automatisches Ticket-schliessen und zuweisungen, die im WebInterface gemacht wurden)
*/20 * * * *    $HOME/bin/otrs.GenericAgent.pl >> /dev/null

# Startet den Generic Agent alle 10 Minuten um geplante Tasks an der DB abzuarbeiten
*/10 * * * *    $HOME/bin/otrs.GenericAgent.pl -c db >> /dev/null

# löscht den abgelaufenen Cache (Jeden Sonntag)
20 0 * * 0  $HOME/bin/otrs.DeleteCache.pl --expired >> /dev/null
30 0 * * 0  $HOME/bin/otrs.LoaderCache.pl -o delete >> /dev/null

# aktualisiert die Statistiken alle Stunde
5 * * * *    $HOME/bin/otrs.GenerateDashboardStats.pl >> /dev/null

# Aktualisiert einmal am Tag den Ticket-Index
01 01 * * * $HOME/bin/otrs.RebuildTicketIndex.pl >> /dev/null

# löscht abgelaufene Sitzungen jede 2te Stunde
55 */2 * * *    $HOME/bin/otrs.DeleteSessionIDs.pl --expired >> /dev/null

# Gibt abgelaufene Tickets frei (Keine Besitzübernahme mehr erforderlich)
35 * * * *  $HOME/bin/otrs.UnlockTickets.pl --timeout >> /dev/null

# überprüft alle 2 Stunden die Anstenden Tickets
45 */2 * * *    $HOME/bin/otrs.PendingJobs.pl >> /dev/null

# holt alle 10 Minuten die definierten Mailboxen ab
*/10 * * * *    $HOME/bin/otrs.PostMasterMailbox.pl >> /dev/null

# Überprüft täglich das Spool-Directory (Bei Fehlerhaften E-Mails)
10 0 * * *  $HOME/bin/otrs.ReprocessMails.pl >> /dev/null

Diese Tabelle fügt man am einfachsten per Shell auf dem System ein mit folgendem Befehl

Crontab –u otrsweb –e

Es startet ein Editor, in den man 1:1 diese Tabelle einfügen kann.

Security

Da das Ticketingsystem oft von extern erreichbar sein soll, für Kunden wie auch HelpDesk Mitarbeiter, ist es ratsam sich über die Security-Aspekte Gedanken zu machen.
Es gibt 3 wichtige Einstellungen die ich empfehle zu überdenken.

1. Die Debug und Security Einstellungen im WebInterface

1. Es gibt die Möglichkeit das OTRS schon von Haus aus sicher zu gestalten und das einfach per WebInterface. Am einfachsten navigiert man einmal in die SysConfig in der Adminübersicht und lässt sich berieseln von den vielen Einstellungsmöglichkeiten.
   
   VORSICHT: Nicht alle Einstellungen ziehen sofort. Wenn man sich „Verkonfiguriert“ kann es sein, dass das System erst ab dem nächsten Reboot abriegelt und nicht mehr zu gebrauchen ist.
   Folgende Einstellungen sollte man aus Security-Aspekten einmal näher anschauen:

   

   Viele Wichtige Einstellungen kann und muss man dort konfigurieren, zumindest am Anfang.
   Einige sind nur die Secure-Einstellung, der HTTP-Typ (ob HTTP oder HTTPS), der Debug-Mode (für Entwickler interessant, sonst aber bitte ausschalten), der Config-Level (wie viel der Administrator konfigurieren darf) und der SecureBanner. Die Letzte ist eine kleine, perfide Einstellung, die dir das Leben zur Hölle machen kann. Gerade aus Security-Aspekten.
   Stell dir vor, jeder im Netz sieht deine aktuelle OTRS-Version. OTRS ist OpenSource. Somit kann jeder Bug öffentlich nachvollzogen werden. Ohne Banner ist die Suche schwer, denn es gibt hunderte OTRS-Versionen.
   Auch ohne Security-Aspekt sollte die Core-Einstellung einmal überprüft werden, es stehen viele einfache Konfigurationen drin.

2. Security

Beim hinzufügen von E-Mail Adressen zum verwalten durch OTRS gibt es eine Vielzahl an Einstellungsmöglichkeiten. Aus Sicht der Security gibt es nur eine Einstellung die ich dringend überdenken würde:

POP3 und IMAP sind zwar nett und gut, aber bei einem System, das aus dem Internet erreichbar ist, zu überdenken.
Falls das OTRS nur intern benötigt wird soll auch dem Security-Aspekt nicht so viel Gewicht beigemessen werden, aber ansonsten sollten nur Verschlüsselte Protokolle verwendet werden. Ich für meinen Teil empfehle POP3S oder POP3TLS, da IMAP immer ein wenig speziell reagiert beim Abholen von Nachrichten. Eventuell wurde der Fehler, den ich bei meinen Tests vor einem Jahr hatte ausgemerzt, ich für meinen Teil traue dem OTRS aber bei IMAP nicht.

3. ACHTUNG!

Noch einmal für alle, die noch nicht verstanden haben was es bedeutet, falls das OTRS nach aussen hin zugänglich ist: Alle Kommunikation, E-Mails, Benutzernamen und Passwörter, die das OTRS benötigt gehen über das Internet. Vielleicht geht jetzt bei einigen das Licht auf wieso ich einen solchen Wert auf Security lege bei OTRS. Man stelle sich jetzt vor das passiert über HTTP. Natürlich muss die Kommunikation über das OTRS nicht zwangsläufig businesskritisch sein, aber falls man eine AD-Anbindung an OTRS hat, versendet man seinen Benutzernamen und das Kennwort über das Internet… Unverschlüsselt… Und alle E-Mails die man sich via OTRS gerade anschaut sind unverschlüsselt… Deshalb empfehle ich dringendst ein Zertifikat. Am besten öffentlich, aber das muss nicht unbedingt sein. Sowie die bereits angetönte Einstellung im Core mit HTTPS zu arbeiten zu bearbeiten.
Unter Windows sollte es kein Problem sein, ein Zertifikat einzubinden. Unter Linux muss man das Zertifikat an den Apache anbinden. Das kann zuweilen aufwändig und kompliziert erscheinen, aber im Internet finden sich dazu ganz leichte Anleitungen. z.B. die Anleitung von SSL-Trust.

SysConfig

Wie bereits angedroht ist vieles der Konfiguration in der SysConfig von OTRS.
Die wichtigsten Einstellungen dazu sind im Core versteckt. Ich gehe da nicht genauer ins Detail, ich rate aber dort als Erstes zu suchen, falls etwas zu verändern ist.
Nur eine Einstellung möchte ich in der SysConfig näher erklären: Die Ticket-Einstellungen.

Es gibt viele Einstellungsmöglichkeiten in den Ticket-Einstellungen. Um genau zu sein 68 Einstellungen. Beispielsweise die Archiveinstellungen oder der NumberGenerator, die TicketWatcher Einstellungen oder das Aktivieren der Services.
Um einmal Angst zu machen, so sieht das ungefähr aus:

Die Einstellungen müssen wirklich für jedes System separat konfiguriert werden. Ich kann da nur Empfehlungen abgeben.
Trotzdem versuche ich mal aufzulisten was mir oft ins Auge springt.

1. TicketCounter

Standardeinstellung der TicketID ist ein DateChecksum. Das bedeutet, dass die Ticketnummer aus dem aktuellen Datum (20150129…) besteht und 5 Laufnummern.
Diese Zahlen werden schnell exorbitant und unleserlich. Ich empfehle stattdessen den AutoIncrement. Dann besteht die Ticketnummer nur noch aus der System-ID (Die im Core eingestellt werden kann) und einer Laufnummer aus N Zahlen.

2. IndexModule

Da die Geschwindigkeit einen Einfluss darauf hat, in welchem Ton über eine Ticketing-Lösung geredet wird, empfehle ich hier auf die StaticDB zu wechseln. Gemäss Admin-Handbuch soll man die StaticDB einschalten, sobald man mehr als 50’000 Article hat. Glaube mir: das sind maximal 10’000 Tickets. Das geht ruck-zuck…

3. StorageModule

Es gibt 2 Varianten, wie eine Mail im OTRS abgelegt wird. Entweder direkt in der DB oder auf dem FileSystem mit einem Verweis in der Datenbank.
Alleine für die Grösse der Datenbank würde ich die Artikel eines Tickets im FileSystem abspeichern, ganz zu schweigen von der Performance-Verbesserung.

4. LostPassword

Ich persönlich würde keinem Mitarbeiter oder Kunden die Möglichkeit geben, sein Passwort selber zurücksetzen zu können. Falls du mich verstehen kannst, kann man das Feature ganz einfach deaktivieren unter Frontend::Agent bzw. Frontend::Customer.

5. Kundenzugang

Falls man den Kunden Zugang zum OTRS geben will, sollte man sich dringend einmal die Konfig Frontend::Customer anschauen. Dort kann man den Firmennamen angeben und den Kunden ermöglichen sich selbst zu registrieren, falls das gewünscht ist. Ausserdem lässt sich das Logo anpassen, so dass man das Formenlogo hinterlegen kann.
Customisation ist in einem solchen Frontend oft gewünscht.

Ich denke, das war es nun soweit von meiner Seite.
In nächster Zeit werden noch mehr Konfigurationen zum Thema OTRS kommen, das Grundgerüst ist nun denke ich aber fertig.

Viel Spass mit dem neuen System!