Playa Esmeralda 2003-2007 OTRS AG 2007-02-12 Christian Schöpplein, Richard Kammermeyer, Stefan Rother, Thomas Raith, Burchard Steinbild, Andre Mindermann, Martin Edenhofer, Christopher Kuhn Dieses Werk ist geistiges Eigentum der OTRS AG. Es darf als Ganzes oder in Auszügen kopiert werden, vorausgesetzt, dieser Copyright-Vermerk befindet sich auf jeder Kopie. UNIX ist ein eingetragenes Warenzeichen von X/Open Company Limited. Linux ist ein eingetragenes Warenzeichen von Linus Torvalds. MS-DOS, Windows, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP und Windows 2003 sind eingetragene Warenzeichen der Microsoft Corporation. Andere Warenzeichen oder registrierte Warenzeichen: SUSE und YaST von SUSE GmbH, Red Hat und Fedora von Red Hat Inc., Debian von Software in the Public Interest, Inc., Mandrake von MandrakeSoft, SA. MySQL und das MySQL Logo sind eingetragene Warenzeichen von MySQL AB. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Die Firma OTRS AG richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Andere hier genannte Produkte können Warenzeichen des jeweiligen Herstellers sein. Das folgende Buch richtet sich besonders an OTRS Neulinge und Administratoren des Open Ticket Request Systems. Beschrieben werden die Installation, Konfiguration und Administration des Systems, die eigentliche Benutzung von OTRS für Agenten oder Kunden-Benutzer wird weniger in diesem Buch angesprochen. Obwohl viele Arbeitsstunden, einige Liter an Kaffee und so manche Pizza in die Erstellung der folgenden Abschnitte investiert wurden, erhebt das Buch keinen Anspruch auf Vollständigkeit. Mit Sicherheit haben sich Fehler eingeschlichen, wurden manche Dinge umständlich erklärt oder sind einige wichtige Dinge komplett vergessen worden. Mit Sicherheit werden auch manche Kapitel noch mal überarbeitet bzw. neue Kapitel oder Abschnitte hinzugefügt werden. Da das Buch versucht, sich an den Bedürfnissen von OTRS Administratoren und OTRS Neulingen zu orientieren und da die Qualität der folgenden Kapitel so hoch wie möglich sein soll, sind wir auf Ihr Feedback angewiesen. Bitte teilen Sie uns mit, wenn Sie Abschnitte in diesem Buch vermissen, wenn Dinge für Sie unverständlich erklärt sind oder auch wenn Sie Rechtschreib-, Tipp oder Grammatikfehler in diesem Buch entdecken. Jede Art von Rückmeldung ist ausdrücklich erwünscht und sollte durch einen Eintrag auf http://bugs.otrs.org an uns gerichtet werden, da sie so nicht verloren geht und direkt beim zuständigen Ansprechpartner landet. Wir bedanken uns schon jetzt für jede Art von Mithilfe! In diesem Abschnitt soll kurz die grundlegende Idee, die hinter Trouble Tickets im Allgemeinen und Trouble Ticket Systemen im Speziellen steht, erläutert werden. An einem kleinen Beispiel wird gezeigt, wofür Trouble Ticket Systeme in der Praxis verwendet werden können und wo die Vorteile dieser Systeme liegen. Das folgende Beispiel soll verdeutlichen, was ein Trouble Ticket System ist und wie damit in der Praxis Zeit und Geld eingespart werden können. Nehmen wir an, dass Max Mustermann Fabrikant ist und Videorekorder produziert. Da die Programmierung der Videorekorder sehr unübersichtlich und kompliziert ist, wenden sich die Kunden von Herrn Mustermann gerne und häufig mit Supportanfragen per Mail an ihn. An manchen Tagen kann Herr Mustermann der Mailflut kaum Herr werden und so kommt es, dass seine Kunden sich einige Zeit gedulden müssen, bis die Antwort mit der rettenden Lösung bei ihnen eintrifft. Manchen Kunden dauert dies jedoch zu lange, eine weitere E-Mail mit dem gleichen Inhalt wird an Herrn Mustermann geschickt. Die E-Mails mit den Supportanfragen werden alle in eine INBOX weitergeleitet, wie sie von fast allen E-Mailprogrammen verwendet wird. An manchen Tagen ist die Anfragewelle besonders groß und Herr Mustermann sieht sich außerstande, alle Mails noch in einem vertretbaren Zeitrahmen zu beantworten. Aus diesem Grund kommandiert er seine Entwickler Meier und Schulze zur Bearbeitung der Supportanfragen ab. Da von allen das gleiche System benutzt wird, greifen alle auf die gleiche INBOX und daher auch auf die gleichen Mails zu. Meier und Schulze haben jedoch keine Ahnung, dass manch ein Kunde in seiner Not gleich zwei E-Mails verfasst und an Herrn Mustermann geschickt hat. So kommt es vor, dass Meier die erste Mail mit einem anderen Ratschlag beantwortet als Schulze der sich im selben Moment der zweiten Nachricht des gleichen Kunden annimmt. Das Ergebnis ist, dass der Kunde unterschiedliche Antworten bekommt. Darüber hinaus hat Herr Mustermann keinen Einblick darüber, welcher Mitarbeiter wann was welchem Kunden gesagt hat, welche Probleme besonders häufig auftreten und wie groß sein gesamter Aufwand für den Kundensupport ist. Von einem Kollegen erfährt Herr Mustermann schließlich, dass es Trouble Ticket Systeme gibt, die genau die Probleme lösen, die Herr Mustermann mit dem Support für seine Kunden hat. Herr Mustermann entscheidet sich für das offene Trouble Ticket Request System OTRS und installiert dieses System auf einem Rechner, der über einen Webserver sowohl für seine Mitarbeiter als auch über das Internet erreichbar ist. Von nun an werden die Hilferufe der Kunden nicht mehr länger an seine private INBOX, sondern direkt an den Mail-Account für OTRS weitergeleitet. OTRS hat eine Schnittstelle zur INBOX für die Supportanfragen, so dass alle ankommenden E-Mails automatisch ins Trouble Ticket System eingespeist werden. Unabhängig ob Herr Mustermann nun gerade anwesend ist oder nicht, generiert OTRS eine automatische Antwort und teilt dem Kunden mit, dass seine E-Mail angekommen ist und so schnell wie möglich bearbeitet wird. Dabei wird eine eindeutige Trouble Ticket Nummer vergeben. Der Kunde ist glücklich, dass sein Flehen schnell erhört wurde und wartet gespannt auf eine Antwort. Sowohl Herr Mustermann als auch die Entwickler Meier und Schulze können nun über einen beliebigen Internetbrowser und die Weboberfläche von OTRS auf die Supportanfragen zugreifen und diese einzeln beantworten. Stellen wir uns vor, dass Herr Schmidt eine Anfrage ans System gestellt hat und Herr Meier diese kurz und knapp beantwortet. Herrn Schmidt reicht diese Antwort jedoch nicht aus und so antwortet er auf die Lösungsmail am folgenden Tag. Herr Meier ist jedoch gerade mit anderen Dingen beschäftigt, so dass sich Herr Mustermann der Sache annimmt. Über die History-Funktion von OTRS kann er jetzt auf alle vergangenen E-Mails von Herrn Schmidt und Herrn Meier zugreifen, deren Inhalt abfragen und eine ausführlichere Antwort versenden. Herr Schmidt erhält nun die Lösung für sein Problem, weiß aber nicht, dass diese von unterschiedlichen Personen stammt. Natürlich ist dies nur ein sehr kleiner Einblick in die Funktionalitäten von Trouble Ticket Systemen. Da Herr Mustermann eine kleine Firma führt, erhält er vielleicht nur wenige E-Mails mit Supportanfragen pro Tag, die er vielleicht noch ganz überschaulich mit seiner normalen Mailsoftware handhaben kann und somit kein Trouble Ticket System braucht. Wenn aber der neue DVD-Rekorder in die Regale kommt, werden es vielleicht schon 500 oder in ein paar Jahren schon 10.000 Nachrichten pro Tag sein. Spätestens dann rechnet sich der Einsatz von Trouble Ticket Systemen wie OTRS. Der Einsatz von Trouble Ticket Systemen kann also für solche Umgebungen große Vorteile bringen, in denen viele Anfragen per E-Mail oder Telefon anfallen und wo die Anfragen von verschiedenen Mitarbeitern bearbeitet werden. Trouble Ticket Systeme helfen dabei, Supportaufgaben zu strukturieren und zu beschleunigen, ebenfalls können Arbeitsabläufe abgebildet werden. Durch Systeme wie OTRS lässt sich Arbeitszeit einsparen bzw. effektiver nutzen und die Kommunikation zwischen Kunden und Mitarbeitern wird transparenter. Sowohl das Unternehmen als auch die Kunden profitieren also vom Einsatz eines Trouble Ticket Systems. Ein Trouble Ticket lässt sich im Wesentlichen mit einem Krankenblatt eines Krankenhauspatienten vergleichen. Bei der erstmaligen Einlieferung in das Krankenhaus wird das Krankenblatt im Zuge der Anamnese neu angelegt. Jeder Arzt trägt nun seine Diagnose sowie die verordnete Therapie und Medikation ein und dokumentiert deren Erfolg. Das Krankenblatt gibt nun einen schnellen Überblick, gewährleistet eine schnelle Einarbeitung und verhindert eine Mehrfachdosierung von Medikamenten. Ist die Krankheit besiegt und der Patient entlassen, wird das Krankenblatt archiviert. Im OTRS werden Trouble Tickets, also die Krankenblätter aus dem obigen Beispiel, als normale E-Mails behandelt und gespeichert. Schickt z. B. ein Kunde eine Anfrage an das Trouble Ticket System, wird das Krankenblatt eingerichtet, ein neues Ticket wird geöffnet. Die Antwort eines Mitarbeiters auf die Anfrage kann als Eintrag eines Arztes gesehen werden, eine erneute Antwort bzw. Anfrage des Kundens auf das selbe Ticket als Veränderung oder Erweiterung des Krankheitsbildes. Ein Ticket gilt als erledigt bzw. geschlossen, wenn eine Antwort auf die Anfrage an den Kunden zurückgesendet wurde oder das Ticket über das System als geschlossen markiert wird. Antwortet ein Kunde auf ein bereits geschlossenes Ticket, so wird es erneut geöffnet und die neuen Informationen ergänzt. Um die Konsistenz der Daten sicherzustellen, werden alle Tickets mit all ihren spezifischen Informationen archiviert und verbleiben im System. Durch die Speicherung der Tickets als ganz normale E-Mails ist es möglich, dass diese auch E-Mail-Anhänge enthalten können. Zusätzlich zu den normalen Informationen einer E-Mail lassen sich beliebige Notizen zu jedem Ticket hinzufügen. Die Tickets selbst werden auf der Festplatte bzw. in einer Datenbank archiviert, ebenso zusätzliche Meta-Informationen des Tickets wie Notizen, an der Beantwortung des Tickets beteiligte Mitarbeiter, Zeit und Datum der Bearbeitung, Bearbeitungsdauer usw. Eine Sortierung oder eine Suche über den Datenbestand wird mit Hilfe aller vorhandenen Informationen zu den Tickets realisiert. In diesem Abschnitt werden die Features des Open Ticket Request Systems (OTRS) vorgestellt. Des Weiteren wird näher auf die Systemanforderungen von OTRS eingegangen und erläutert, wie Kontakt zur OTRS-Community aufgenommen werden kann bzw. wie kommerzieller Support erhältlich ist. Das Open Ticket Request System (OTRS) ist eine Webapplikation, die mit jedem HTML kompatiblen Browser benutzt werden kann. OTRS verzichtet bewusst auf aktive Webkomponenten wie z. B. Javaskript, JavaApplets und Flash. Dadurch wird es möglich, das System nicht nur über einen PC, sondern auch von Mobiltelefonen und anderen Handcomputern, welche HTML unterstützen, zu benutzen. Als Client kann jedes Betriebssystem eingesetzt werden. OTRS ist in mehrere Komponenten aufgeteilt. Als Basis wird ein Framework benötigt, der alle grundlegenden Funktionen des Systems und das Trouble Ticket System enthält. An zusätzlichen Komponenten können ein Webmailer, ein Dateimanager, ein Contentmanager, ein Kalender und ein Modul zur Ausgabe verschiedener Systemstatus bequem über die Weboberfläche nachinstalliert werden. OTRS bietet viele verschiedene Features. Die folgende Aufzählung gibt einen Überblick über die wichtigsten Eigenschaften und Fähigkeiten des zentralen OTRS-Frameworks. Webinterface: Leichte und intuitive Bedienung über einen HTML-Browser. Auf aktive Inhalte wie Flash oder Java-Applets wird in der Weboberfläche bewusst verzichtet. Das System kann somit mit nahezu allen Browsern benutzt werden, auch von Mobiltelefonen oder Handcomputern aus. Eine Weboberfläche zur Administration des Systems ist vorhanden. Ein Webinterface für die Mitarbeiter (Agenten) zur Bearbeitung von Kundenanfragen ist verfügbar. Eine Weboberfläche für Kunden, über die Nachrichten an zuständige Agenten geschickt werden können und der Status eigener Tickets abgerufen werden kann, ist vorhanden. Unterstützung für verschiedene Oberflächen-Layouts (themes). Unterstützung vieler Sprachen. Eigene Anpassungen der Ausgabe-Vorlagen sind möglich (dtl). Mehrfach-Anhänge sind über die Weboberfläche möglich. E-Mail-Schnittstelle: Unterstützung für E-Mail-Anhänge (MIME support). Automatische Umwandlung von HTML- in reine Text-Nachrichten (höhere Sicherheit vor schädlichen Inhalten und schneller durchsuchbar). Filterung von E-Mails über eigene X-Header-Einträge oder Mailadressen, z. B. für die Aussortierung von Spam. PGP-Support, Erstellung und Import eigener Zertifikate, verschlüsselter und signierter Mails, Anzeige von verschlüsselten und signierten Nachrichten. Unterstützung für die Verschlüsselung und Anzeige von SMIME-Nachrichten. Automatisierte Antworten (auto responder) für die Benachrichtigung von Kunden, abhängig von der Queue konfigurierbar. E-Mail-Benachrichtigungen für Agenten über neue Tickets, Follow-ups oder freigegebene Tickets. Follow-Ups an Hand von Reference- oder In-Reply-To-Headern, automatisierte Zuordnung von Follow-Ups über den Ticket-Bezeichner im Betreff, Mailbody oder in Text-Anhängen. Tickets: Erweiterte Queue-Ansicht, Übersicht über alle Anfragen innerhalb einer Queue. Sperren von Tickets. Überwachen der Aktivitäten rund um ein Ticket mit Hilfe des TicketWatcher-Features. Festlegen eines Ticket-Verantwortlichen mit Hilfe des TicketResponsible-Features. Erstellung eigener Antwortvorlagen. Erstellung eigener auto responder, abhängig von der Queue. Ticket-History, Übersicht über die komplette Entwicklung eines Tickets, Änderungen der Ticketstatus, Übersicht über die verschidenen Aktionen für ein Ticket usw. Druckansicht für Tickets, Export als PDF möglich. Hinzufügen eigener (interner oder externer) Notizen zu einem Ticket (eigener Text und Dateianhänge). Möglichkeit zum Zoomen von Tickets. Definition von ACL's (access control lists) für Tickets. Tickets können an andere E-Mail-Adressen weiter- oder umgeleitet werden (forwarding, bouncing). Verschieben von Tickets zwischen verschiedenen Queues. Festlegen der Priorität für Tickets. Erfassung der Bearbeitungsdauer für Tickets. Anstehende Aufgaben für ein Ticket festlegen (pending features). Massenoperationen auf Tickets sind möglich (bulk features). Automatische und zeitgesteuerte Aktionen können mit Hilfe eines sog. Generic-Agenten auf Tickets ausgeführt werden. Volltextsuche über den gesamten Ticketbestand und Export der Suchergebnisse als PDF. System: OTRS läuft unter vielen Betriebssystemen (Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x, Microsoft Windows). Unterstützung von ASP (active service providing). Verknüpfung von Objekten wie z. B. Tickets, FAQ-Einträgen o.ä. innerhalb des Systems. Einbindung externer Datenquellen für die Kundendaten, z. B. über AD, eDirectory oder OpenLDAP). Festlegen einer eigenen Kennzeichnung für Tickets, z. B. Cal#, Ticket#, Request# o.ä. Festlegen einer eigenen Nummerierung für Tickets. Unterstützung verschiedener Datenbanktypen für die zentrale Datenbank von OTRS (MySQL, PostgreSQL, SAPDB, Oracle MSSQL, usw.). Framework für die Erstellung von Statistiken über die Web-Oberfläche, Export und Import von Reports und Statistikmodulen, Export von Statistiken als PDF ist möglich. utf-8-Unterstützung für Front- und Back-End. Die Authentifikation für Agenten oder Kunden kann unabhängig voneinander über eine Datenbank, LDAP, HTTPAuth oder Radius realisiert werden. Unterstützung von Benutzer-Accounts, Benutzergruppen und Rollen. Unterstützung verschiedener Zugriffsrechte, z. B. auf Queues oder Systembereiche. Die Erstellung von Standardantworten ist möglich. Unter-Queues werden unterstützt. Anreden und Signaturen können abhängig von der Queue definiert werden. E-Mail-Benachrichtigungen für Administratoren. Bekanntgabe von Informationen zu Updates über die Weboberfläche oder via E-Mail. Festlegen von Ablauffristen für problematische Tickets. Benutzerabhängige Unterstützung für verschiedene Zeitzonen. Einfache Einbindung eigener Addons und Module mit Hilfe der OTRS API. Einfache Erstellung eigener Front-Ends, z. B. X11, Console usw. Multi-Kalnder-Funktionalität: Dieses Feature vereinfacht das Arbeiten in verschiedenen Umgebungen mit verschiedenen Zeitzonen. Die relevanten Arbeitsstunden des Systems können abhängig von der Zeitzone festgelegt werden, die Spezifikation von Urlaubs- und Feiertagen ist abhängig von der Region möglich. Statistik-Framework: Integration eines komplett überarbeiteten Statistik-Frameworks der es erlaubt, nahezu jede Art von Report über die Weboberfläche zu erstellen. Die Erstellung und Ansicht von Statistiken kann pro Benutzer, Gruppe und / oder Rolle freigeschaltet werden. Der Ex- und Import von bereits vorhandenen oder neuen Statistiken ist möglich, Statistikmodule aus früheren OTRS-Versionen können weiter verwendet werden. PDF-Generator: Die Druck-Ansicht von Tickets, Statistiken und Suchergebnisse können nun als PDF-Datei exportiert werden. Unterstützung von MSSQL: Eine Schnittstelle zu Microsofts SQL-Server wurde integriert, so dass nun die komplette OTRS Datenbank auch auf MSSQL-basierten Systemen installiert und benutzt werden kann. FAQ-Modul: Das FAQ-Modul von OTRS wurde komplett neu implementiert und aus dem zentralen OTRS-Framework herausgenommen, so dass eine Installation als seperates Modul möglich ist. Das neue FAQ-Modul bietet erweiterte Such- und Navigationsfunktionen, eine verbesserte Administration und eine Möglichkeit zur Bewertung von einzelnen FAQ-Einträgen. Unterstützung hirarchischer Team-Strukturen: Mit hilfe der neu eingeführten Überwachungs- und Verantwortlichkeitsfunktionen für Tickets, wird die strukturierte Bearbeitung von Tickets in Teams vereinfacht. Das Verantwortlichkeits-Feature ermöglicht es einem Agenten den Ticket-Besitz abzugeben, jedoch trotzdem noch alle Schreibrechte am Ticket zu behalten. Das Überwachungs-Features ermöglicht die Vrfolgung der Aktivitäten für ein Ticket, ohne selbst Eigentümer des Tickets zu sein. Optimierte Erkennung von Follow-Ups: Neben der Auswertung der Ticketnummer im Betreff einer Nachricht kann OTRS 2.1 nun auch nach Ticket-Bezeichnern im Body einer Mail und innerhalb von Textanhängen suchen und so ggfs. ein Follow-Up automatisiert zuordnen. OTRS kann unter vielen Betriebssystemen installiert werden. Neben Linux und den verschiedenen Unix-Derivaten (z. B. OpenBSD oder FreeBSD), läuft OTRS auch unter allen Windows-Versionen. Bezüglich der Hardware empfiehlt es sich, mindestens einen 2 GHz Pentium Xeon oder vergleichbare CPU, 2 GB RAM und eine 160 GB Festplatte zu verwenden. Für den Betrieb von OTRS werden einige externe Software-Komponenten benötigt. Ein Web- sowie ein Datenbankserver und eine funktionierende perl-Installation mit einigen Zusatzmodulen sind die Grundvorraussetzungen für ein funktionierendes System. Der Webserver und perl müssen auf der gleichen Maschine installiert sein, auf der später auch OTRS ausgeführt werden soll. Das Datenbank-Back-End kann auf der lokalen oder auf einer entfernten Maschine installiert werden. Für den Webserver wird empfohlen, auf apache 1.3.x oder apache 2.x zurück zu greifen. Vor allem durch die Erweiterung der apache-Konfiguration um das mod-perl-Modul, kann die Geschwindigkeit von OTRS enorm gesteigert werden. Prinzipiell sollte aber jeder Webserver, der die Ausführung von perl-Skripten unterstützt, für den Betrieb von OTRS geeignet sein. Als Datenbank-Back-End eignen sich besonders MySQL ab Version 3.1.x oder PostgreSQL. Grundsätzlich sollten jedoch alle Datenbankserver zusammen mit OTRS verwendet werden können, die SQL als Datenbanksprache unterstützen. Ein Vorteil der Benutzung von MySQL ist, dass OTRS über einen Webinstaller die Datenbank und Tabellen automatisch anlegen kann. Für perl gilt mindestens die Version 5.8 zu verwenden. Es werden einige Zusatzmodule benötigt, die Sie entweder direkt über die Shell von perl und CPAN oder mit Hilfe des Paketmanagers (yast, apt-get) Ihres Betriebssystems einspielen müssen. Im Abschnitt für die manuelle Installation der für OTRS benötigten perl-Module wird beschrieben, wie Sie perl-Module manuell einspielen können. Wenn Sie ein bereits vorgefertigtes OTRS-Paket für Ihr Betriebssystem zur Installation verwenden (rpm, Windows-Installer), sollten die benötigten perl-MOdule automatisch installiert werden. Um OTRS hat sich in den letzten Jahren eine große Community gebildet. Über Mailinglisten tauschen sich Anwender und Entwickler zu den verschiedensten Themen rund um das Trouble Ticket System aus. Behandelt werden Fragen rund um die Installation, Konfiguration, Benutzung, Lokalisation und Entwicklung. Fehler in der Software können über ein Bug-Tracking-System gemeldet werden und erreichen so die zuständigen Entwickler bzw. gehen nicht verloren, so dass schnell Fixes bereit gestellt werden können. Homepage OTRS.org Die Community ist über die Homepage http://www.otrs.org zu erreichen. Neben der Unterstützung aus der Open Source Community auf http://www.otrs.org ist auch kommerzieller Support rund um OTRS erhältlich. Über die Adresse http://www.otrs.com sind die Seiten der OTRS AG zu finden, die den kommerziellen Teil des OTRS.org-Projektes darstellen. Das Angebot der OTRS AG umfasst Support, Consulting und fertige Installations-CDs für OTRS und richtet sich an den Mittelstand, Behörden, Institutionen und große Konzerne. Von der professionellen Beratung zum Einsatz des Trouble Ticket Systems bis hin zur kompletten Installation und Wartung mit 24-Stunden Rückrufservice sind verschiedene Supportpakete erhältlich. Fertige High-Performance- und High-Availabilty-Systeme, aber auch die Anfertigung von Spezialanpassungen runden das Angebot der OTRS AG ab. Detaillierte Informationen zu den verschiedenen Angeboten der OTRS AG sind unter http://www.otrs.com zu finden oder können über die Mailadresse sales at otrs.com erfragt werden. Dieser Abschnitt beschreibt die Installation und die grundlegende Einrichtung des zentralen OTRS Frameworks. Dabei wird auf die Installation von bereits fertigen Paketen für die Betriebssysteme Linux und Microsoft Windows eingegangen, aber auch die manuelle Installation direkt über die Quellen erklärt, wodurch eine Installation auch auf anderen, hier nicht näher beschriebenen, Betriebssystemen übertragbar sein sollte. Die Einrichtung des Web- und Datenbankservers, die Schnittstelle zwischen OTRS und der Datenbank, das Einspielen einzelner perl-Module, das Setzen der richtigen Berechtigungen, die Einrichtung der OTRS-eigenen cron-Jobs sowie grundlegende Einstellungen in den OTRS-Konfigurationsdateien, sind in diesem Kapitel zu finden. Am Ende dieses Abschnitts sollte ein lauffähiges OTRS auf Ihrem Betriebssystem installiert sein, an dessen Weboberfläche Sie sich bereits als OTRS-Administrator anmelden können. Der einfachste und komfortableste Weg ein lauffähiges OTRS zu installieren ist sicherlich, auf bereits vorgefertigte Pakete zurück zu greifen. Viele bereits vorgefertigte Installations-Pakete sind im Download-Bereich unter http://www.otrs.org zu finden. Da der Aufwand viel zu groß wäre, die Installation aller dort aufgeführten Pakete in dieser Dokumentation anzuführen, soll im Folgenden nur näher auf die Installation von OTRS unter SUSE Linux, Debian und Microsoft Windows eingegangen werden. Sehen Sie unter der o.g. URL nach, ob auch für Ihr Betriebssystem ein fertiges Installations-Paket vorhanden ist und greifen Sie nur auf die manuelle Installation zurück, wenn Sie keine andere Möglichkeit haben. Dieser Abschnitt beinhaltet die Anleitung für die Installation von OTRS unter SUSE Linux. Getestet wurden die Versionen bis SUSE Linux 9.3. Bevor Sie mit der Installation beginnen, sehen Sie bitte unter http://www.otrs.org nach, ob eine aktuellere Version von OTRS als .rpm-Datei vorliegt. Sollte dies der Fall sein, verwenden Sie bitte diese neuere Version. Installieren Sie OTRS mittels yast (yast2) oder der Kommandozeile und rpm, je nach Vorliebe. Beachten Sie jedoch, dass OTRS einige perl-Module benötigt, die nicht standardmäßig in einer typischen SUSE-Installation enthalten sind. yast sollte die bessere Wahl sein, da es alle Abhängikeiten automatisch beachtet und auflösen kann. Sollten Sie den Weg über die Kommandozeile mit rpm bevorzugen, so müssen Sie die perl-Module manuell vor Beginn der Installation von OTRS installieren. Angenommen Sie haben die Datei otrs.rpm im Verzeichnis /tmp gespeichert, dann geben Sie zur Installation von OTRS folgenden Befehl ein. linux:~ # rpm -ivh /tmp/otrs.rpm otrs ################################################## Check OTRS user (/etc/passwd)... otrs exists. Next steps: [SuSEconfig] Execute 'SuSEconfig' to configure the webserver. [start Apache and MySQL] Execute 'rcapache restart' and 'rcmysql start' in case they don't run. [install the OTRS database] Use a webbrowser and open this link: http://localhost/otrs/installer.pl [OTRS services] Start OTRS 'rcotrs start-force' (rcotrs {start|stop|status|restart|start-force|stop-force}). Have fun! Your OTRS Team http://otrs.org/ linux:~ # Nach der Installation des rpm's ist es notwendig SuSEconfig zu starten. Geben Sie hierzu Folgendes ein. linux:~ # SuSEconfig Starting SuSEconfig, the SuSE Configuration Tool... Running in full featured mode. Reading /etc/sysconfig and updating the system... Executing /sbin/conf.d/SuSEconfig.aaa_at_first... Executing /sbin/conf.d/SuSEconfig.apache... Including /opt/otrs/scripts/apache-httpd.include.conf Executing /sbin/conf.d/SuSEconfig.bootsplash... Executing /sbin/conf.d/SuSEconfig.doublecheck... Executing /sbin/conf.d/SuSEconfig.guile... Executing /sbin/conf.d/SuSEconfig.hostname... Executing /sbin/conf.d/SuSEconfig.ispell... Executing /sbin/conf.d/SuSEconfig.perl... Executing /sbin/conf.d/SuSEconfig.permissions... Executing /sbin/conf.d/SuSEconfig.postfix... Setting up postfix local as MDA... Setting SPAM protection to "off"... Executing /sbin/conf.d/SuSEconfig.profiles... Finished. linux:~ # Die Installation des OTRS-rpm ist abgeschlossen. Starten Sie nun Ihren Webserver neu, um die Änderungen in der Konfiguration zu übernehmen. linux:~ # rcapache restart Shutting down httpd done Starting httpd [ PERL ] done linux:~ # Der nächste Schritt ist das Aufsetzen der Datenbank. Wenn sie MySQL als Datenbankserver verwenden, können Sie hierzu den Webinstaller von OTRS benutzen. Geben Sie dazu folgende Adresse in Ihrem Browser ein. http://localhost/otrs/installer.pl Der Webinstaller wird gestartet. Folgen Sie den Anweisungen auf dem Bildschirm. installer.pl screen - Lizenz (1/4) installer.pl screen - Datenbank erstellen (2/4) Es ist niemals eine gute Idee, Standardpasswörter zu verwenden! Bitte ändern Sie deshalb unbedingt das von OTRS standardmäßig gesetzte Passwort! installer.pl screen - Datenbank erstellen (2/4) installer.pl screen - System einstellungen (3/4) installer.pl screen - Fertig (4/4) Nachdem alle Einstellungen vorgenommenw urden, kann OTRS nun gestartet werden. linux:~ # rcotrs restart-force Shutting down OTRS Disable /opt/otrs/bin/PostMaster.pl ... done. no crontab for otrs Shutting down cronjobs ... failed! Shutting down OTRS (completely) Shutting down Apache ... done. Shutting down MySQL ... done. done Starting OTRS (completely) Starting Apache ... done. Starting MySQL ... done. Starting OTRS Checking Apache ... done. Checking MySQL ... done. Checking database connect... (It looks Ok!). Enable /opt/otrs/bin/PostMaster.pl ... done. Checking otrs spool dir... done. Creating cronjobs (source /opt/otrs/var/cron/*) ... done. -->> http://linux.example.com/otrs/index.pl <<-- done done linux:~ # Die Installation von OTRS ist beendet, Sie sollten das System nun verwenden können. Um sich in die Weboberfläche des Trouble Ticket Systems einloggen zu können, geben sie die Adresse http://localhost/otrs/index.pl in Ihrem Browser ein. Melden sie sich als OTRS-Administrator an und konfigurieren Sie das System Ihren Wünschen entsprechend. Als Benutzername verwenden Sie root@localhost, das Passwort lautet root. Bitte ändern Sie auch dieses Passwort schnellstmöglich! Es handelt sich auch hier um ein Standardpasswort! Eine ausführliche Beschreibung zur Installation von OTRS auf Debian-Systemen wurde dankenswerter Weise vom Maintainer des OTRS-Pakets, Torsten Werner, bereit gestellt. Sie kann über den Link http://www.writely.com/View.aspx?docid=drm3kmx_0cbr3x9 eingesehen werden. Die Installation von OTRS unter Microsoft Windows ist denkbar einfach. Laden Sie den auf http://www.otrs.org bereit gestellten Installer herunter und speichern Sie die Datei. Anschließend führen Sie den Installer einfach aus und folgen den einzelnen Installationsschritten. Der Windows-Installer für OTRS beinhaltet bereits alle Komponenten, die für den Betrieb von OTRS benötigt werden. D.h., es wird zusätzlich zum eigentlichen OTRS der apache2 Webserver, MySQL, perl mit den für OTRS benötigten Modulen und cron für Windows installiert. Aus diesem Grund ist es empfehlenswert OTRS über den Installer nur auf solchen Windowssystemen zu installieren, auf denen noch kein apache2 bzw. ein anderer Webserver und MySQL läuft. Wenn Sie OTRS manuell über die Quellen installieren möchten oder müssen, laden Sie sich zuerst das aktuelle Archiv herunter. Sie finden die entsprechenden .tar.gz- oder .tar.bz2-Dateien im Downloadbereich auf http://www.otrs.org Entpacken Sie das Archiv mit Hilfe von tar z. B. in das Verzeichnis /opt: linux:/opt# tar xf /tmp/otrs-2.0.0.tar.gz linux:/opt# ls otrs linux:/opt# Da die Skripte von OTRS später nicht mit root-Rechten laufen sollen, muss im nächsten Schritt ein Benutzer für OTRS im System angelegt werden. Dieser Benutzer sollte als Homeverzeichnis das Verzeichnis erhalten, in das gerade die Quellen von OTRS entpackt wurden, also /opt/otrs. Wird der Webserver unter einem anderen Benutzer als dem OTRS-User betrieben, so muss der neue OTRS-Benutzer noch zur Gruppe des Webserver-Users hinzugefügt werden. linux:/opt# useradd -d /opt/otrs/ -c 'OTRS user' otrs linux:/opt# usermod -G nogroup otrs linux:/opt# Im nächsten Schritt werden einige Demo-Konfigurationsdateien innerhalb der entpackten Quelldateien bzw. innerhalb des Homeverzeichnisses des OTRS-Benutzers kopiert. Die Dateien befinden sich in den Verzeichnissen /opt/otrs/Kernel bzw. /opt/otrs/Kernel/Config und haben die Endung .dist. linux:/opt# cd otrs/Kernel/ linux:/opt/otrs/Kernel# cp Config.pm.dist Config.pm linux:/opt/otrs/Kernel# cd Config linux:/opt/otrs/Kernel/Config# for foo in *.dist; do cp $foo `basename $foo .dist`; done linux:/opt/otrs/Kernel/Config# Zum Abschluss der Vorbereitungen werden noch die richtigen Zugriffsrechte für die Dateien des Ticket Systems gesetzt. Dazu kann das Skript SetPermissions.sh verwendet werden, das sich im Verzeichnis bin innerhalb des Homeverzeichnisses des OTRS-Benutzers befindet. Das Skript kann mit folgenden Parametern aufgerufen werden: SetPermissions.sh Homedirectory des OTRS Benutzers OTRS Benutzer Webserver Benutzer Gruppe des OTRS Benutzers Gruppe des Webserver Benutzers Läuft Ihr Webserver mit den Benutzerrechten des OTRS Benutzers, dann lautet das Kommando also SetPermissions.sh /opt/otrs otrs otrs. Unter SUSE Linux wird der Webserver mit dem Benutzer wwwrun betrieben. Geben Sie hier das Komando SetPermissions.sh /opt/otrs otrs wwwrun ein. Nach diesen Schritten ist die Vorbereitung zur Installation des Ticket Systems abgeschlossen und es kann der Webserver auf die Verwendung von OTRS vorbereitet werden. Für den Betrieb von OTRS werden einige perl-Module benötigt. Wenn Sie OTRS manuell einrichten, müssen Sie wahrscheinlich einige dieser Module per Hand nachinstallieren. Dies können Sie entweder über den Paketmanager ihrer Distribution erledigen (yast, apt-get), oder, wie in diesem Kapitel beschrieben, direkt über die Shell von perl und CPAN. Die folgenden perl-Module werden von OTRS benötigt. Name Beschreibung CGI Mit diesem Modul wird die Darstellung der OTRS-Oberfläche als Webinterface ermöglicht. Date::Pcalc Dieses Modul enthält Berechnungsgrundlagen zum gregorianischen Kalender und wird in OTRS z. B. für die zeitspezifischen Berechnungen auf Tickets benötigt. DBI Dieses Modul wird von OTRS für die Verbindung zum Datenbank-Backend benötigt. DBD::mysql Modul zum Verbindungsaufbau zum MySQL-Datenbank-Backend. Digest::MD5 Ermöglicht die Verwendung des md5-Algorithmus. LWP::UserAgent Modul zur Verarbeitung von http-Anfragen. MIME::Base64 En- und Decodierung von Base64-Strings. MIME::Tools Modul mit verschiedenen Werkzeugen für die Verarbeitung von Nachrichten mit MIME-Teil. Mail::Internet Modul für die Bearbeitung von E-Mails nach RFC 822 Net::DNS Schnittstelle zum Domain Name System (DNS). Net::POP3 Modul mit Funktionen für den Zugriff auf einen POP3-Server. Net::LDAP Modul zur Verarbeitung von Anfragen an ein LDAP-Directory. Dieses Modul wird nur benötigt, wenn OTRS mit einem LDAP-Directory betrieben werden soll, z. B. fuer die Abfrage von Kundendaten. Net::SMTP Modul mit Funktionen zum Versenden von Mails. Authen::SASL SASL Authentication Framework, wird z. B. für die Anmeldung an Mailservern benötigt. GD Schnittstelle zur Gd Graphics Library. Wird nur benötigt, wenn das Statistikmodul von OTRS verwendet werden soll. GD::Text, GD::Graph, GD::Graph::lines, GD::Text::Align Text- und Grafikwerkzeuge für die Benutzung zusammen mit der GD Graphics Library. Diese Komponenten werden nur benötigt, wenn das Statistikmodul von OTRS verwendet werden soll. XML::Parser Dieses Modul wird benötigt, um Konfigurationsparameter aus XML-Files auszulesen bzw. Konfigurationen in XML-Dateien zu schreiben. Die grafische Administrations-Oberfläche von OTRS greift auf diese Mechanissmen zurück. PDF::API2, Compress::Zlib Diese Module werden für die Generierung der PDF-Ausgaben von Statistiken, Suchergebnissen oder Druckansicht eines Tickets benötigt. Um eines der oben aufgeführten Module mit Hilfe von CPAN zu installieren, geben Sie als root das Kommando perl -e shell -MCPAN ein. perl wird im interaktiven Modus gestartet und das CPAN Modul wird geladen. Ist CPAN bereits ordentlich konfiguriert, können Sie die für OTRS benötigten Module mit Hilfe des Kommandos install gefolgt vom Modulnamen einrichten. CPAN weist darauf hin, wenn Abhängigkeiten zwischen einzelnen Modulen nicht erfüllt sind und schlägt automatisch die zusätzlich benötigten Module für die Installation vor. Nachdem Sie alle perl-Module installiert haben, können Sie mit Hilfe des Skriptes otrs.checkModules überprüfen, ob OTRS wirklich alle benötigten Module finden und verwenden kann. Das Skript finden sie im Verzeichnis bin innerhalb des Homeverzeichnisses des OTRS Benutzers. linux:~# cd /opt/otrs/bin/ linux:/opt/otrs/bin# ./otrs.checkModules CGI ... ok Date::Pcalc ... ok Date::Format ... ok DBI ... ok DBD::mysql ... ok Digest::MD5 ... ok Crypt::PasswdMD5 ... ok LWP::UserAgent ... ok IO::Scalar ... ok IO::Wrap ... ok MIME::Base64 ... ok MIME::Tools ... ok Mail::Internet ... ok Net::DNS ... ok Net::POP3 ... ok Net::LDAP ... ok Net::SMTP ... ok Authen::SASL ... ok GD ... ok GD::Text ... ok GD::Graph ... ok GD::Graph::lines ... ok GD::Text::Align ... ok XML::Parser ... ok PDF::API2 ... not installed! (for PDF output - not required) Compress::Zlib ... ok linux:/opt/otrs/bin# Führen Sie weiterhin die beiden Befehle perl -cw bin/cgi-bin/index.pl und perl -cw bin/PostMaster.pl aus, nach dem Sie in das Verzeichnis /opt/otrs gewechselt sind. Wird bei beiden Befehlen die Meldung "syntax OK" angezeigt, verfügt Ihre perl-Installation über alle von OTRS benötigten Module und Sie können im nächsten Schritt mit der Einrichtung des Webservers beginnen. linux:~# cd /opt/otrs linux:/opt/otrs# perl -cw cgi-bin/installer.pl cgi-bin/installer.pl syntax OK linux:/opt/otrs# perl -cw PostMaster.pl PostMaster.pl syntax OK linux:/opt/otrs# In diesem Abschnitt wird beschrieben, wie der apache Webserver grundlegend für OTRS eingerichtet werden muss. Der Webserver solte cgi- bzw. perl-Skripte ausführen können, anderenfalls ist kein Betrieb von OTRS möglich. Überprüfen Sie die Konfigurationsdateien Ihres Webservers und stellen Sie fest, ob das cgi-Modul geladen wird: Wenn Ihr Webserver die Ausführung von cgi-Skripten unterstützt, sollte eine Zeile ähnlich der folgenden zu finden sein. LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so Um die Oberfläche von OTRS bequem erreichen zu können, wird ein Alias- und ein ScriptAlias-Eintrag angelegt. Für die meisten Installationen des apache Webservers gilt, dass ein Verzeichnis mit dem Namen conf.d vorhanden ist, unter Linux ist es meist unterhalb des Verzeichnisses /etc/apache bzw. /etc/apache2 zu finden. Wechseln Sie als root in dieses Verzeichnis und öffnen Sie die Datei otrs.conf mit einem Editor bzw. legen Sie diese Datei an. Tragen Sie die folgenden Zeilen in die Datei ein. # # Basic apache configuration for OTRS # # agent, admin and customer frontend # ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/" Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/" # # directory settings # <Directory "/opt/otrs/bin/cgi-bin/"> AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all </Directory> <Directory "/opt/otrs/var/httpd/htdocs/"> AllowOverride None Order allow,deny Allow from all </Directory> Speichern Sie die Datei, schließen Sie den Editor und starten Sie Ihren Webserver neu, um die neue Konfiguration zu laden. Auf den meisten Systemen lässt sich der Webserver über den Befehl /etc/init.d/apache restart bzw. /etc/init.d/apache2 restart neu starten. linux:/etc/apache2/conf.d# /etc/init.d/apache2 restart Forcing reload of web server: Apache2. linux:/etc/apache2/conf.d# Das war bereits die grundlegende Konfiguration des Webservers für OTRS. Im nächsten Schritt kann die Datenbank eingerichtet werden. Wenn Sie MySQL als Datenbankserver einsetzen, können Sie die OTRS Datenbank leicht und bequem mit Hilfe des Webinstallers einrichten. Geben Sie folgende Adresse in Ihrem Browser ein, um den Webinstaller zu starten: http://localhost/otrs/installer.pl Der Webinstaller wird gestartet. Folgen Sie den Anweisungen auf dem Bildschirm. installer.pl screen - Lizenz (1/4) installer.pl screen - Datenbank erstellen (2/4) Es ist niemals eine gute Idee, Standardpasswörter zu verwenden! Bitte ändern Sie deshalb unbedingt das von OTRS standardmäßig gesetzte Passwort! installer.pl screen - Datenbank erstellen (2/4) installer.pl screen - System einstellungen (3/4) installer.pl screen - Fertig (4/4) Die OTRS Datenbank wurde aufgesetzt. Im nächsten Schritt werden die cron-Jobs eingerichtet, die von OTRS benötigt werden. Wenn Sie den Webinstaller nicht einsetzen können, kann die Datenbank für OTRS auch manuell eingerichtet werden. Skripte mit dem Datenbankschema und den SQL-Statements finden Sie im Verzeichnis scripts/database innerhalb des Homeverzeichnisses des OTRS Benutzers. linux:~# cd /opt/otrs/scripts/database/ linux:/opt/otrs/scripts/database# ls initial_insert.sapdb.sql otrs-schema-post.maxdb.sql initial_insert.sql otrs-schema-post.mysql.sql otrs-schema.maxdb.sql otrs-schema-post.oracle.sql otrs-schema.mysql.sql otrs-schema-post.postgresql.sql otrs-schema.oracle.sql otrs-schema.xml otrs-schema.postgresql.sql linux:/opt/otrs/scripts/database# Für die verschiedenen Datenbanktypen sind mehrere .sql-Dateien vorhanden, die nacheinander abgearbeitet werden müssen. Um die Datenbank anzulegen, gehen Sie folgendermaßen vor: Anlegen der Datenbank für OTRS: Legen Sie mit Hilfe Ihres Datenbankinterfaces bzw. Ihrer Datenbankoberfläche die Datenbank an, die später von OTRS verwendet werden soll. Erstellen der Tabellen: Mit Hilfe der otrs-schema.Datenbanktyp.sql-Dateien (z. B. otrs-schema.oracle.sql, otrs-schema.postgresql.sql, usw.) können Sie die Tabellen innerhalb der OTRS Datenbank erzeugen. Einfügen der vom System benötigten Daten: Damit OTRS richtig funktioniert, müssen einige Daten in verschiedene Tabellen geschrieben werden (z. B. die verschiedenen Ticketstatus, Ticket- und Benachrichtigungstypen, etc.). Verwenden Sie entweder die Datei initial_insert.sql oder initial_insert.sapdb.sql zum Einspielen der Daten, je nachdem welche Datenbank verwendet wird. Erzeugen von "foreign keys" auf andere Tabellen: Abschließend müssen noch die "foreign keys" erstellt werden, über die die verschiedenen Tabellen in der OTRS Datenbank voneinander abhängen. Dies kann mit Hilfe der otrs-schema-post.Datenbanktyp.sql-Dateien erreicht werden (z. B. otrs-schema-oracle.post.sql, otrs-schema-post.postgresql.sql, usw.). Nachdem Sie die Datenbank angelegt haben, sollten Sie die Zugriffsrechte dafür setzen und z. B. sicherstellen, dass nur ein bestimmter Benutzer ohne Datenbank-Administrationsrechte Zugriff auf die OTRS Datenbank hat. Je nachdem, welche Datenbank Sie einsetzen, unterscheiden sich hier die Vorgehensweisen, es sollte jedoch möglich sein dies mit Hilfe Ihres Datenbankinterfaces bzw. Ihrer Datenbankoberfläche zu erledigen. Wurden die nötigen Einstellungen für die Datenbank vorgenommen, muss nun noch dem Ticket System mitgeteilt werden, welche Datenbank es verwenden soll. Öffnen Sie die Datei Kernel/Config.pm innerhalb des Homeverzeichnisses des OTRS Benutzers und passen Sie die dafür vorgesehenen Parameter an. Am wichtigsten sind die folgenden Parameter. # Database # (The database name.) $Self->{Database} = 'otrs'; # DatabaseUser # (The database user.) $Self->{DatabaseUser} = 'otrs'; # DatabasePw # (The password of database user.) $Self->{DatabasePw} = 'some-pass'; Nachdem nun die Verbindung zur Datenbank steht, können im nächsten Schritt die verschiedenen cron-Jobs für OTRS eingerichtet werden. Damit OTRS voll funktioniert, werden einige cron-Jobs benötigt. Die cron-Jobs sollten mit denselben Benutzerrechten ausgeführt werden, die auch für die restlichen OTRS-Skripte vergeben wurden, d.h. die cronJobs sollten in die crontab des OTRS-Benutzers eingetragen werden. Alle Skripte für die verschiedenen cron-Jobs befinden sich im Verzeichnis var/cron innerhalb des Homeverzeichnisses des OTRS-Benutzers. linux:~# cd /opt/otrs/var/cron linux:/opt/otrs/var/cron# ls aaa_base.dist pending_jobs.dist session.dist fetchmail.dist postmaster.dist unlock.dist generic_agent-database.dist postmaster_pop3.dist generic_agent.dist rebuild_ticket_index.dist linux:/opt/otrs/var/cron# Alle Skripte tragen die Endung .dist und sollten zunächst so umkopiert werden, dass keine Endung mehr vorhanden ist. linux:/opt/otrs/var/cron# for foo in `ls -1 *.dist` ; do cp $foo `basename $foo .dist`; done linux:/opt/otrs/var/cron# ls aaa_base generic_agent.dist rebuild_ticket_index aaa_base.dist pending_jobs rebuild_ticket_index.dist fetchmail pending_jobs.dist session fetchmail.dist postmaster session.dist generic_agent postmaster.dist unlock generic_agent-database postmaster_pop3 unlock.dist generic_agent-database.dist postmaster_pop3.dist linux:/opt/otrs/var/cron# Die folgende Tabelle gibt eine kurze Übersicht über die Aufgabe der verschiedenen Skripte, die als cron-Job in der crontab des OTRS-Benutzers installiert werden sollten. Skript Aufgabe aaa_base Über dieses Skript werden die grundlegenden Einstellungen für die crontab des OTRS-Benutzers festgelegt. fetchmail Falls Nachrichten mit Hilfe von fetchmail in das System eingespeißt werden sollen, kann dieses Skript verwendet werden. generic_agent Mit Hilfe dieses Skripts werden die Jobs des GenericAgents ausgeführt, die über eigene Konfigurationsdateien festgelegt wurden. generic_agent-database Mit Hilfe dieses Skripts werden die Jobs des GenericAgents ausgeführt, die über dem Administrations-Bereich innerhalb von "GenericAgent" angelegt wurden. pending_jobs Mit Hilfe dieses Skripts wird das System auf "wartende" (pending) Tickets überprüft. postmaster Mit Hilfe dieses Skripts wird die Nachrichten-Warteschlange von OTRS überprüft und noch nicht verarbeitete Nachrichten werden im System gespeichert bzw. zugestellt.. postmaster_pop3 Mit Hilfe dieses Skripts werden die verschiedenen pop3-Konten abgefragt, die im Administrations-Bereich innerhalb von "PostMaster POP3 Account" eingerichtet wurden. rebuild_ticket_index Mit Hilfe dieses Skripts wird der Ticket-Index für die Queue-Ansicht neu erzeugt, wodurch die Anzeige beschleunigt wird. session Über dieses Skript werden alte und nicht mehr gültige Session-IDs entfernt. unlock Mit Hilfe dieses Skripts wird die Freigabe von Tickets innerhalb des Systems ermöglicht. Für die Einrichtung aller cron-Jobs kann das Skript Cron.sh verwendet werden, das sich im Verzeichnis bin innerhalb des Homeverzeichnisses des OTRS-Benutzers befindet. Dem Cron.sh Skript muss beim Aufruf ein Parameter übergeben werden. Dieser Parameter legt fest, ob die cron-Jobs installiert, deinstalliert oder neu gestartet werden. Es sind folgende Parameter zulässig. Cron.sh start stop restart OTRS-Benutzer Da die cron-Jobs für den OTRS-Benutzer angelegt werden sollen, muss das Skript von diesem Benutzer ausgeführt werden. Sind Sie z. B. als Benutzer root am System angemeldet, können Sie mit Hilfe des Kommandos su otrs zum OTRS-Benutzer wechseln. Nehmen Sie also die Installation wie folgt vor. Bitte beachten Sie, dass durch die Verwendung von Cron.sh evtl. andere Cron-Jobs des OTRS-Benutzers überschrieben bzw. gelöscht werden. Um weitere, nicht von OTRS benötigte Cron-Jobs für den OTRS-Benutzer zu installieren, erweitern Sie bitte Cron.sh dementsprechent. linux:/opt/otrs/var/cron# cd /opt/otrs/bin/ linux:/opt/otrs/bin# su otrs linux:~/bin$ ./Cron.sh start Cron.sh - start/stop OTRS cronjobs - <$Revision: 1.17 $> Copyright (c) 2002 Martin Edenhofer <martin@otrs.org> (using /opt/otrs) done linux:~/bin$ exit exit linux:/opt/otrs/bin# Mit Hilfe des Kommandos crontab -l -u otrs, das Sie als root ausführen können, wird die crontab-Datei des OTRS-Benutzers angezeigt und Sie können überprüfen, ob alle Einträge vorhanden sind. linux:/opt/otrs/bin# crontab -l -u otrs # -- # cron/aaa_base - base crontab package # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # This software comes with ABSOLUTELY NO WARRANTY. # -- # Who gets the cron emails? MAILTO="root@localhost" # -- # cron/fetchmail - fetchmail cron of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # This software comes with ABSOLUTELY NO WARRANTY. # -- # fetch every 5 minutes emails via fetchmail #*/5 * * * * /usr/bin/fetchmail -a >> /dev/null # -- # cron/generic_agent - GenericAgent.pl cron of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # -- # This software comes with ABSOLUTELY NO WARRANTY. # -- # start generic agent every 20 minutes */20 * * * * $HOME/bin/GenericAgent.pl >> /dev/null # example to execute GenericAgent.pl on 23:00 with # Kernel::Config::GenericAgentMove job file #0 23 * * * $HOME/bin/GenericAgent.pl -c "Kernel::Config::GenericAgentMove" >> /dev/null # -- # cron/generic_agent - GenericAgent.pl cron of the OTRS # Copyright (C) 2001-2004 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # -- # This software comes with ABSOLUTELY NO WARRANTY. # -- # start generic agent every 10 minutes */10 * * * * $HOME/bin/GenericAgent.pl -c db >> /dev/null # -- # cron/pending_jobs - pending_jobs cron of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # -- # This software comes with ABSOLUTELY NO WARRANTY. # -- # check every 120 min the pending jobs 45 */2 * * * $HOME/bin/PendingJobs.pl >> /dev/null # -- # cron/postmaster - postmaster cron of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # -- # This software comes with ABSOLUTELY NO WARRANTY. # -- # check daily the spool directory of OTRS #10 0 * * * * test -e /etc/init.d/otrs & /etc/init.d/otrs cleanup >> /dev/null; test -e /etc/rc.d/init.d/otrs && /etc/rc.d/init.d/otrs cleanup >> /dev/null 10 0 * * * $HOME/bin/otrs.cleanup >> /dev/null # -- # cron/postmaster_pop3 - postmaster_pop3 cron of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # -- # This software comes with ABSOLUTELY NO WARRANTY. # -- # fetch emails every 10 minutes */10 * * * * $HOME/bin/PostMasterPOP3.pl >> /dev/null # -- # cron/rebuild_ticket_index - rebuild ticket index for OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # This software comes with ABSOLUTELY NO WARRANTY. # -- # just every day 01 01 * * * $HOME/bin/RebuildTicketIndex.pl >> /dev/null # -- # cron/session - delete old session ids of the OTRS # Copyright (C) 2001-2004 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # This software comes with ABSOLUTELY NO WARRANTY. # -- # delete every 120 minutes old/idle session ids 55 */2 * * * $HOME/bin/DeleteSessionIDs.pl --expired >> /dev/null # -- # cron/unlock - unlock old locked ticket of the OTRS # Copyright (C) 2002-2003 Martin Edenhofer <martin+code@otrs.org> # -- # $Id: installation-and-basic-configuration.xml,v 1.17 2006/10/18 13:02:43 cs Exp $ # This software comes with ABSOLUTELY NO WARRANTY. # -- # unlock every hour old locked tickets 35 * * * * $HOME/bin/UnlockTickets.pl --timeout >> /dev/null linux:/opt/otrs/bin# Nach der Einrichtung der Cron-Jobs ist die Installation von OTRS abgeschlossen, Sie können das System nun über dessen Weboberfläche weiter an Ihre Bedürfnisse anpassen und benutzen. Dieser Abschnitt soll einen ersten Überblick über die Funktionsweise von OTRS und den Aufbau der Weboberfläche des Systems geben. Es werden die Unterschiede zwischen Mitarbeitern (Agents), Kunden (Customer) und Administratoren erklärt. Anschließend wird die erste Anmeldung als OTRS-Administrator durchgeführt und erläutert, was mit Hilfe der Benutzereinstellungen für jeden Account innerhalb des Systems festgelegt werden kann. Die Mitarbeiter bearbeiten über die Weboberfläche des Systems die Anfragen der Kunden, erstellen neue Tickets für andere Mitarbeiter oder Kunden, legen Tickets über Telefongespräche mit Kunden an, schreiben FAQ-Einträge, bearbeiten Kundendaten usw. index.pl - Login Bildschirm für Agenten Angenommen, Ihr Host mit der OTRS-Installation ist über die Domain http://www.example.com erreichbar, so kann der Login-Bildschirm für die Mitarbeiter und somit auch für den OTRS-Administrator über die URL http://www.example.com/otrs/index.pl aufgerufen werden. Kunden können über das speziell für sie vorhandene Webinterface von OTRS einen eigenen Kundenaccount anlegen, die eigenen Tickets einsehen, Tickets erstellen und bearbeiten, die Account-Einstellungen anpassen usw. customer.pl - Login Bildschirm für Kunden Angenommen, Ihr Host mit der OTRS-Installation ist über die Domain http://www.example.com zu erreichen, so kann der Login-Bildschirm für die Kunden über die URL http://www.example.com/otrs/customer.pl geladen werden. Neben diesen beiden Bereichen der Weboberfläche verfügt OTRS weiterhin über ein Interface, mit dem die FAQ des Systems durchsucht werden kann und welches öffentlich, also ohne Anmeldung, zugänglich ist. public.pl - Öffentliche Weboberfläche Das öffentliche Web-Interface ist über die URL http://www.example.com/otrs/faq.pl erreichbar. Ebenfalls ist ein Zugriff auf die FAQ über die URL http://www.example.com/otrs/public.pl möglich. Wie im Abschnitt über die Agenten Weboberfläche beschrieben, erreichen Sie den Bildschirm für die Anmeldung am System über die URL http://www.example.com/otrs/index.pl. index.pl - Login screen für OTRS-Administrator Hier haben Sie die Möglichkeit, einen Benutzernamen und ein Kennwort anzugeben. Um sich als OTRS-Administrator anzumelden, verwenden Sie als Benutzername "root@localhost" und als Kennwort "root". Diese Zugangsdaten werden bei jeder OTRS-Installation standardmäßig vergeben. Da das Kennwort für den OTRS-Administrator somit öffentlich bekannt ist, sollten Sie es schnellstmöglich ändern! Sie können dies nach der Anmeldung als OTRS-Administrator über die Benutzereinstellungen vornehmen. Wollen Sie sich nicht als OTRS-Administrator anmelden, geben Sie einfach den Benutzernamen und das Kennwort Ihres normalen OTRS-Accounts in die dafür vorgesehenen Eingabefelder ein. Mit Hilfe der Listbox unterhalb der Eingabefelder für den Benutzernamen und das Kennwort können Sie weiterhin die Sprache auswählen, die Sie innerhalb der Oberfläche von OTRS verwenden möchten. Falls Sie einmal ihr Kennwort vergessen haben sollten, können Sie sich automatisch vom System ein neues Kennwort an die Mailadresse schicken lassen, die für Ihren OTRS-Account im System hinterlegt ist. Geben Sie dazu im unteren Bereich des Login-Bildschirms den Benutzernamen Ihres Accounts an und schicken Sie die Eingabe über den dafür vorgesehenen Schalter ab. Kurze Zeit später sollte sich in Ihrem Postfach eine Mail vom OTRS-System befinden, die das neu vergebene Kennwort enthält. Nachdem Sie sich erfolgreich am System angemeldet haben, wird die Oberfläche von OTRS geladen. Sie befinden sich nach einer Anmeldung standardmäßig in der sog. Queue-Ansicht. Die Queue-Ansicht vermittelt einen schnellen Überblick über die Tickets in den verschiedenen Queues. Sie werden auf neue Nachrichten hingewiesen, die Anzahl ihrer gesperrten Tickets wird angezeigt usw. Bildschirm nach erster erfolgreicher Anmeldung Um die Übersichtlichkeit zu erhöhen, wurde die Oberfläche von OTRS in verschiedene Bereiche aufgeteilt. Innerhalb des schwarzen Balkens am oberen Fensterrand werden allgemeine Informationen wie die aktuelle Uhrzeit, das Datum, Ihr Name und Ihre in den Account-Einstellungen hinterlegte Mailadresse angezeigt. Weiterhin finden Sie auf der linken Seite des Balkens einen Link über den die Oberfläche neu geladen werden kann. Im weißen Balken darunter, der sog. Navigationsleiste, werden verschiedene Schaltflächen dargestellt, über die die Navigation im System oder die Aktivierung bestimmter Aktionen möglich ist. Der Balken unterteilt sich in drei Abschnitte. Der linke Bereich enthält Schaltflächen zur Abmeldung vom System, zur Aktivierung der Queue-Ansicht, einen Schalter, um auf das Kunden-Backend zuzugreifen oder einen Schalter zum Laden der Maske für die Volltextsuche über die im System gespeicherten Tickets. Über die Schalter "Phone-Ticket" und "E-Mail-Ticket" kann ein neues Telefon- oder E-Mail-Ticket angelegt werden. Mit Hilfe des Schalters "Statistik" wird der Bildschirm zur Ausgabe verschiedener Systemstatistiken geladen, über "Einstellungen" gelangen Sie in den Bereich zur Anpassung Ihrer eigenen Account-Einstellungen. "Bulk-Action" lädt den Bildschirm für die Ausführung verschiedener Aktionen auf markierte Tickets. Hiermit können z. B. mehrere Tickets auf einmal geschlossen oder verschoben werden. Im mittleren Bereich des weißen Balkens werden die Schalter zur Navigation im System angezeigt. Nach der ersten Anmeldung als OTRS-Administrator ist hier nur die Schaltfläche "Admin" aufgeführt. Werden später weitere Module wie z. B. der Kalender oder der Dateimanager installiert, tauchen die Schalter für diese Komponenten ebenfalls in diesem Bereich auf. An der rechten Seite des Balkens wird angezeigt, ob neue Nachrichten für Sie vorhanden sind bzw. wie viele Tickets Sie gesperrt haben, d.h. von wie vielen Tickets Sie der Eigentümer sind. Im hellgrauen Balken unterhalb der Navigationsleiste werden verschiedene Systemmeldungen angezeigt. Wenn Sie als Administrator angemeldet sind, werden Sie z. B. darauf aufmerksam gemacht, dass normale Arbeiten nicht als Administrator durchgeführt werden sollten. Wurde das Kalender-Modul installiert, werden innerhalb dieses Balkens z. B. die nächsten Termine angezeigt. Der darunter liegende schwarze Balken enthält die gerade selektierte Queue bzw. zeigt an, dass "Meine Queues" ausgewählt wurde. Hinter dem Begriff "Meine Queues" verbergen sich alle Queues, die Sie für sich als wichtig erachten und genauer überwachen möchten. Sie können in Ihren Benutzereinstellungen die Queues auswählen, die Sie in "Meine Queues" aufnehmen möchten. Unter dem Bereich mit der gerade selektierten Queue wird ein grauer Balken angezeigt, der einen Überblick über die im System verfügbaren Tickets gibt. Innerhalb des nächsten Balkens wird eine Übersicht für die verschiedenen Queues und deren Anzahl an offenen Tickets präsentiert. Nach einer Neuinstallation ist zu erkennen, dass in "Meine Queues" noch kein offenes Ticket vorhanden ist, in der Queue "Raw" sich jedoch ein noch nicht gesperrtes Ticket befindet. Inhalt der Raw-Queue nach der ersten Anmeldung Wenn Sie nun die Queue "Raw" auswählen, wird die Oberfläche neu aufgebaut und der Inhalt dieser Queue angezeigt. Im unteren Bereich des Bildschirms erscheinen nun noch die zusätzlichen Informationen für das Ticket, welches sich in der Queue "Raw" befindet. In einem schwarzen Balken ist die ID, also die eindeutige Ticket-Kennung, und das Alter des Tickets zu erkennen. Auf der linken Seite dieses Balkens sehen Sie die Checkbox, mit der das Ticket für die Bulk-Action markiert werden kann. In der nächsten Zeile, die grau dargestellt wird, sind die Eigenschaften bzw. die Aktionen aufgeführt, die auf das Ticket angewendet werden können ("Sperren", "Inhalt", "History" usw.). In der gleichen Zeile ist rechts eingerückt das Erstellungsdatum und die Erstellungszeit des Tickets zu erkennen. Im weiteren Verlauf teilt sich die Oberfläche in zwei Bereiche auf. Auf der linken Seite wird in weißer Farbe eine Vorschau des Ticketinhaltes angezeigt. Es ist zu erkennen, wer das Ticket gesendet hat, an welche Adresse es geschickt wurde, wie der Betreff lautet und was die ersten Zeilen beinhalten. Rechts daneben werden in grauer Farbe weitere Informationen wie die Priorität oder der aktuelle Status des Tickets angezeigt. Weiterhin kann eingesehen werden, ob das Ticket bereits einem Kunden zugeordnet wurde. Über verschiedene Schaltflächen können Sie auf das Ticket antworten, eine Anrufnotiz erstellen oder das Ticket in eine neue Queue verschieben. Am unteren Ende des Bildschirms erscheint innerhalb eines schwarzen Balkens der Seitenfooter. Dieser beinhaltet ebenfalls einige Schalter zum Aktivieren der Queue-Ansicht oder für die Erstellung eines Telefontickets. Da Queues in OTRS sehr wichtig sind und als Grundkonzept hinter allem stehen und der Begriff in den letzten Abschnitten schon mehrmals verwendet wurde, soll hier näher erklärt werden, was sich hinter dem Begriff Queue verbirgt. Normalerweise werden E-Mails in einer INBOX gespeichert und verwaltet. Eine INBOX ist eine große Datei, in der alle E-Mails aneinandergereiht werden. Neue E-Mails werden einfach an das Ende der INBOX angehängt. Das E-Mail-Programm, welches Sie zum Lesen und Bearbeiten Ihrer Nachrichten benutzen, liest die INBOX-Datei aus, strukturiert den Inhalt dieser Datei neu (wenn z. B. eine E-Mail mitten aus der INBOX-Datei gelöscht wird) und bereitet den Inhalt für Sie als Nutzer auf. Eine Queue in OTRS ist ein Mechanismus, mit dessen Hilfe viele Tickets gespeichert und verwaltet werden können, also auch eine Art INBOX. Als Anwender ist es völlig unwichtig zu wissen, wo oder wie das Ticket gesichert ist. Wichtig ist nur, zu wissen, welcher Queue das Ticket zugeordnet wurde. Anwender, also die sog. Agents (z. B. die Mitarbeiter ihrer Supportabteilung), können nun Tickets zwischen den Queues verschieben! Warum aber sollten sie das tun? Gehen wir zur praktischeren Erklärung noch mal von Max Mustermanns Unternehmen aus dem Abschnitt ein Beispiel für ein Trouble Ticket System aus. Max Mustermann hat nach seinem anfänglichen Support-Chaos OTRS installiert, und er und seine Mitarbeiter nutzen das System zur Bearbeitung der Anfragen für die Videorekorder. Eine Queue, in die alle Anfragen einsortiert werden, reicht in dieser Situation aus. Nach einiger Zeit bringt Max Mustermann einen DVD-Player auf den Markt, der von den Kunden gut angenommen wird. Doch auch zu diesem Gerät laufen immer mehr Anfragen in das Ticket System und die Verwaltung der E-Mails mit einer Queue wird immer unübersichtlicher. Deshalb entschließt sich Max Mustermann nach einiger Zeit, sein Supportsystem weiter zu optimieren. Er richtet zwei neue Queues ein, so dass er nun insgesamt drei Queues in OTRS definiert hat. Die erste und schon länger vorhandene Queue wird zur Eingangsqueue, in die erst mal alle Mails wandern, umfunktioniert. Daneben gibt es jetzt noch die neuen Queues "Videorekorder" und "DVD-Player". Herr Mustermann beauftragt Frau Müller als sog. Dispatcherin tätig zu werden und mehrmals am Tag die Mails in der Eingangsqueue zu sichten und sie, je nach Inhalt, der Queue "Videorecorder" oder der Queue "DVD-Player" zuzuordnen. Herr Meier bearbeitet ab jetzt nur noch die Anfragen in der Videorekorder-Queue, Herr Schulze geht nur noch auf die Anfragen innerhalb der DVD-Player-Queue ein. Beide haben auf die jeweils anderen zwei Queues keinen Zugriff. Herr Mustermann kümmert sich weiter wie gewohnt um alle Arten von Anfragen und darf auf alle drei Queues zugreifen, die Möglichkeiten der Vergabe von Zugriffsrechten innerhalb von OTRS macht es möglich. Das Sortieren von Mails in verschiedene Queues schafft also Ordnung und mehr Übersicht in der täglichen Mailflut, deshalb sind Queues sehr wichtig für OTRS. Durch die Einteilung der Mitarbeiter (agents) in verschiedene Benutzergruppen mit differenzierten Zugriffsrechten auf die einzelnen Queues, kann die Abarbeitung der Anfragen weiter optimiert werden. Mit Hilfe von Queues können Sie die Struktur Ihres Unternehmens abbilden bzw. einzelne Geschäftsvorgänge abgrenzen. So könnte Max Mustermann neben seinem Support-Queues für die verschiedenen Geräte für Bestellungen eine Queue mit dem Namen "Sales" anlegen und als Unter-Queues "Anfragen", "Angebote", "Bestellungen" usw. definieren, um den Bestellvorgang zu optimieren. Je besser und strukturierter ein Support- system organisiert ist, desto weniger Zeit und letztlich auch finanzielle Mittel müssen dafür aufgebracht werden. Queues und Unter-Queues helfen bei der Strukturierung bzw. bei der Abbildung von Abläufen. Die Einstellungen eines Accounts lassen sich mit Hilfe der Benutzereinstellungen den eigenen Wünschen entsprechend anpassen. Dabei spielt keine Rolle, ob man als Mitarbeiter, Kunde oder Administrator am System angemeldet ist. Die Benutzereinstellungen sind über den Link "Einstellungen" sowohl innerhalb des Interfaces für Mitarbeiter bzw. Administratoren als auch der Oberfläche für Kunden erreichbar. Persönliche Account-Einstellungen für Kunden Für Kunden-Accounts gilt, dass die Oberflächensprache, die maximale Anzahl an angezeigten Tickets pro Seite und die Aktualisierungszeit für das Kunden-Webinterface angepasst werden kann. Weiterhin ist es möglich, das persönliche Kennwort zu ändern und die Anzeige von geschlossenen Tickets an- bzw. abzuschalten. Persönliche Account-Einstellungen für Agenten In den Benutzereinstellungen eines Mitarbeiters kann ebenfalls die Oberflächensprache, das Anzeigeschema, das Standardwörterbuch für die Rechtschreibprüfung und die Ansicht für die Queues ausgewählt werden. Weiterhin kann eingestellt werden, in welchem Zeitintervall die Oberfläche neu geladen werden soll, wie viele Tickets maximal pro Seite angezeigt werden sollen und welcher Bildschirm nach der Erstellung eines neuen Tickets automatisch geladen wird. Sie können Ihr Kennwort ändern und festlegen, bei welchen Ereignissen Sie vom System per Mail benachrichtigt werden möchten. Benachrichtigungen können verschickt werden, wenn ein neues Ticket in "Meine Queues" verfügbar ist, wenn Sie eine Nachfrage auf ein von Ihnen gesperrtes Ticket erhalten (also wenn Sie der Eigentümer eines solchen Tickets sind), wenn ein Ticket vom System freigegeben wurde und wenn ein Ticket in "Meine Queues" verschoben wurde. Die Benachrichtigungsmails werden an die Mailadresse gesendet, die bei der Erstellung Ihres Accounts im System hinterlegt wurde. Die Queues, die sie in "Meine Queues" aufnehmen möchten, können Sie ebenfalls in Ihren Benutzereinstellungen auswählen. Sie sollten in "Meine Queues" nur die Queues aufnehmen, die für Sie am wichtigsten sind und die Sie besonders aufmerksam überwachen möchten. Der Administrationsbereich von OTRS ist die zentrale Anlaufstelle für den Administrator des Ticket Systems. Innerhalb dieses Bereiches können alle wichtigen Einstellungen der Systemkonfiguration eingesehen bzw. geändert und das System auf die eigenen Bedürfnisse angepasst werden. Die Administrationsoberfläche kann über den Link "Admin" innerhalb der Navigationsleiste des Agent-Interfaces geladen werden. Damit dieser Link in der Navigationsleiste überhaupt sichtbar ist, müssen Sie als OTRS-Administrator am System angemeldet sein bzw. über Administrationsrechte im System verfügen. Nach einer Standardinstallation können Sie sich mit dem Benutzernamen "root@localhost" und dem Kennwort "root" als OTRS-Admin am System anmelden. Bitte ändern Sie schnellstmöglich über die Benutzereinstellungen das Kennwort für root@localhost, da es sich hierbei um ein standardmäßig vergebenes Kennwort handelt, das allgemein bekannt ist. Der Administrationsbereich von OTRS Über den Link "Benutzer" gelangen Sie in die Benutzerverwaltung von OTRS. Hier können Sie Benutzer anlegen, bearbeiten und deaktivieren. Weiterhin lassen sich einige grundlegende Einstellungen für den Benutzer festlegen, z. B. die Oberflächensprache oder das Anzeigeschema. Benutzerverwaltung in OTRS Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, können einmal im System angelegte Benutzer nicht entfernt werden. Um einen Benutzer-Account zu deaktivieren, setzen Sie in den Einstellungen den entsprechenden Benutzer mit Hilfe der Listbox für "Gültig" auf "ungültig" bzw. "ungültig-temporär". Nachdem Sie einen neuen Benutzer angelegt haben, muss dieser einer Gruppe bzw. einer Rolle zugewiesen werden. Sie werden nach dem Anlegen eines neuen Benutzers automatisch auf die Bildschirmmaske für die Zuweisung eines Benutzers in Gruppen weitergeleitet. Jeder Mitarbeiter mit einem Account im OTRS, sollte mindestens einer Benutzergruppe angehören. Über den Link "Gruppen" gelangen Sie in die Gruppenverwaltung von OTRS. Gruppenverwaltung in OTRS Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, können einmal im System angelegte Gruppen nicht entfernt werden. Um eine Gruppe zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Gruppe in der Listbox für "Gültig" den Wert entweder auf "ungültig" bzw. "ungültig-temporär". Nach einer Standard-Installation sind bereits vier Gruppen im System verfügbar. Gruppe Beschreibung admin Gruppe für die Benutzer mit Administrationsrechten. Nach einer Installation ist in dieser Gruppe nur der Benutzer "root@localhost". faq Benutzer in dieser Gruppe dürfen lesend (ro) oder schreibend (rw) auf das FAQ-System von OTRS zugreifen. Standardmäßig befindet sich nach einer Installation kein Benutzer in dieser Gruppe, auch nicht "root@localhost". stats Benutzer in dieser Gruppe dürfen lesend (ro) oder schreibend (rw) auf das Statistikmodul von OTRS zugreifen, d.h. sie können Statistiken einsehen oder auch erstellen. Nach einer Installation befindet sich lediglich "root@localhost" in dieser Gruppe. users Dies ist die Gruppe, in die normale Mitarbeiter aufgenommen und mit den kompletten Rechten ausgestattet werden sollten. Dadurch wird für die Mitarbeiter das normale Arbeiten im System ermöglicht, der Zugriff auf alle Funktionen rund um Tickets ist gegeben. Nach einer Installation ist diese Gruppe leer. Um einen Benutzer einer Gruppe zuzuweisen bzw. die Gruppenmitgliedschaft eines Benutzers zu ändern, kann der Link "Benutzer <-> Gruppen" im Administrationsbereich genutzt werden. Zuweisung von Benutzer und Gruppen Im unteren Bereich des Bildschirms wird eine Übersicht angezeigt, die alle Benutzer und Gruppen auflistet. Indem Sie auf einen Benutzernamen klicken, bekommen Sie dessen Gruppenzugehörigkeiten angezeigt und können diese ändern. Bei der Auswahl einer Gruppe werden alle Benutzer aufgelistet, die sich in dieser Gruppe befinden. Um eine bessere Abstufung der Rechte im System sicher zu stellen, können einem Benutzer verschiedene Rechte pro Gruppe zugewiesen werden. Nach einer Standardinstallation sind in jede Gruppe die folgenden Rechte vorhanden. Berechtigung Beschreibung ro Nur Lesezugriff auf die Tickets bzw. Beiträge dieser Gruppe bzw. der Gruppe zugewiesenen Queues oder Bereiche. Verschieben in (move into) Recht zum Verschieben von Tickets oder Beiträgen innerhalb der Queues bzw. Bereiche dieser Gruppe. Erstellen (create) Recht zum Erstellen von Tickets oder Beiträgen in den Queues, bzw. Bereichen dieser Gruppe. Besitzer (owner) Recht zum Ändern des Eigentümers von Tickets, bzw. Beiträgen in den der Gruppe zugewiesenen Queues bzw. Bereiche. Priorität (priority) Recht zum Ändern der Priorität von Tickets, bzw. Beiträgen in den der Gruppe zugewiesenen Queues bzw. Bereiche. rw Voller Lese- und Schreibzugriff auf alle Inhalte der dieser Gruppe zugewiesenen Queues, bzw. Bereiche. Rollen sind ein sehr nützliches und mächtiges Feature in OTRS, um schnell und einfach die Vergabe von Zugriffsrechten für viele Benutzer vorzunehmen. Vor allem bei großen und komplexen Installationen mit vielen Benutzern, Gruppen und Queues, zahlt sich dieses Feature schnell aus und erspart dem OTRS-Administrator viel Zeit und Arbeit. Um den Nutzen von Rollen zu verdeutlichen, stellen Sie sich die Situation vor, dass Sie ein OTRS-System mit 100 Benutzern verwalten. 90 Benutzer haben Zugriff auf eine Queue namens Support, die mehrere themenspezifische Unter-Queues enthält und in der die Support-Anfragen Ihrer Kunden landen. Die restlichen Queues des Systems sind für die 90 Supporter nicht zugänglich, dies wurde durch Gruppenzugriffsrechte so festgelegt. Die übrigen 10 Benutzer haben Zugriff auf alle Queues im System. Sie sortieren falsch einsortierte Mails aus, behalten die "Raw"-Queue im Auge und verschieben Spam-Mails in die "Junk"-Queue. Im Rahmen einer Unternehmensumstrukturierung wird eines Tages zusätzlich eine Abteilung eröffnet, die Produkte verkaufen soll. Es müssen Angebote, Auftragsbestätigungen und Rechnungen erstellt, Anfragen bearbeitet, Bestellungen ans Lager weitergeleitet und Stornierungen entgegen genommen werden. Ein Teil der bisherigen Mitarbeiter soll in verschiedenen Bereichen der neuen Abteilung tätig werden und Sie als OTRS-Administrator haben nun die Aufgabe die neuen Queues anzulegen, die erweiterten Zugriffsrechte anzupassen und diese für die einzelnen Benutzer zu ändern. Da es mühsam und viel zu umständlich wäre, für einen Teil aller 100 Benutzer einzeln die Zugrifssrechte zu ändern, richten Sie Rollen ein die mit Hilfe von Gruppenberechtigungen die verschiedenen Zugriffsrechte regeln. Anschließend ändern Sie für die entsprechenden Benutzer auf einmal die Zugriffsberechtigungen, indem Sie diese der entsprechenden Rolle zuweisen. Beim Anlegen neuer Benutzer müssen Sie nicht mehr einzeln die Gruppen und Zugrifssrechte einstellen, auch hier genügt die Verknüpfung des neuen Benutzers mit einer Rolle. Rollenverwaltung in OTRS Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, können einmal im System angelegte Rollen nicht mehr entfernt werden. Um eine Rolle zu deaktivieren, setzen Sie in den Einstellungen die entsprechende Rolle mit Hilfe der Listbox für "Gültig" auf "ungültig" oder "ungültig-temporär". Zuweisung von Benutzern zu Rollen Zuweisung von Gruppen zu Rollen Um die Zugriffsrechtevergabe einer Rolle näher zu spezifizieren, können die Links "Rollen <-> Benutzer" bzw. "Rollen <-> Gruppen" genutzt werden. Mit Hilfe dieser beiden Links können Sie sich eine Übersicht über die 1:n und n:1 Beziehungen der Rolle zu den einzelnen im System vorhandenen Benutzer oder Gruppen anzeigen lassen und diese ändern. OTRS unterstützt, wie bereits erwähnt, verschiedene Arten von Benutzern. Über den Link "Kunden Benutzer", den Sie im Admin-Bereich von OTRS finden, können Sie die Benutzerdaten der im System angelegten Kunden verwalten. Ein Kunde kann sich mit Hilfe seines Accounts in das vom Ticket-System bereitgestellte Webinterface für Kunden einloggen, um dort die eigenen Tickets einzusehen, neue Tickets zu verfassen, usw. Weiterhin wird ein Kunden-Account vom System für die Historie von Tickets benötigt. Kundenverwaltung in OTRS Neben der Möglichkeit in der Datenbank nach einem bestimmten Kunden zu suchen, kann das Backend umgestellt werden, über das auf die Kundendaten zugegriffen wird. In OTRS lassen sich mehrere Datenbanken mit Kundendaten einbinden, genauere Informationen hierzu finden Sie im Abschnitt Einbinden externer Backends für Agents und Customer . Mit Hilfe des Formulars an der rechten Bildschirmseite kann ein neuer Kunden-Account erstellt werden. Alle Eingabefelder, die mit einem Stern (*) markiert sind, müssen ausgefüllt werden. Neben den üblichen Daten wie Vor- und Nachname, Mailadresse, den Einstellungen für die Oberfläche, usw. muss ein Benutzername und ein Kennwort angegeben werden, wodurch die Anmeldung am System ermöglicht wird. Desweiteren ist eine Angabe für "Kunden#" erforderlich, die eine eindeutige Kennung darstellt, über die das System den Kunden ansprechen kann bzw. identifiziert. Für "Kunden#" kann also z. B. eine Kundennummer oder auch die Mailadresse des Kunden eingetragen werden. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann ein einmal im System angelegter Kunde nicht entfernt werden. Um einen Kunden-Account trotzdem zu deaktivieren, setzen Sie in den Einstellungen des entsprechenden Kunden-accounts in der Listbox für "Gültig" den Wert entweder auf "ungültig" bzw. "ungültig-temporär". Genau wie Agenten, können in OTRS auch Kundenbenutzer verschiedenen Gruppen zugewiesen werden. Dieses Feature kann z. B. dann interessant sein, wenn Sie mehrere Kundenbenutzer einer Firma anlegen möchten, die alle über das Kundeninterface nur Tickets in eine oder mehrere bestimmte Queues senden sollen. Legen Sie hierzu zuerst über die Gruppenverwaltung die Gruppe an, in der alle Kundenbenutzer der Firma aufgenommen werden sollen. Anschließend erstellen Sie im Verwaltungsbereich für queues die Queues und ordnen diese der gerade angelegten Gruppe zu. Im nächsten Schritt aktivieren Sie mit Hilfe des Konfigurationsparameters CustomerGroupSupport die Unterstützung für Kundengruppen. Mit Hilfe des Parameters CustomerGroupAlwaysGroups legen Sie fest, welchen Gruppen ein neu angelegter Kundenbenutzer automatisch zugeordnet werden soll. Verwaltung von Kundengruppen Über den Link "Kunden Benutzer <-> Gruppen" können Sie nun die Zuordnung der Kundenbenutzer in die gewünschten Gruppen vornehmen. Je nachdem, welche Queues zu welchen Gruppen gehören, werden später im Webinterface für Kunden auch nur die entsprechenden Queues zur Verfügung gestellt. Über den Link "Queue" innerhalb des Admin-Bereiches von OTRS können Sie die Queues Ihres Systems verwalten. Nach einer Standard-Installation sind bereits die Queues "Junk", "Misc", "Postmaster" und "Raw" im System angelegt. "Raw" ist die Default-Queue, in ihr landen alle neuen Tickets, so lange kein Filter definiert wurde. "Junk" kann z. B. zum Aussortieren von Spam-Mails genutzt werden. Verwaltung der Queues in OTRS Über das Formular auf der rechten Bildschirmseite kann eine neue Queue angelegt werden. Zusätzlich zum Namen der neuen Queue kann angegeben werden, für welche Benutzergruppe die Queue bereitgestellt werden und ob die neue Queue eine Unter-Queue (sub queue) von einer bereits in Ihrem System vorhandenen Queue sein soll. Wurde ein Ticket von einem Agenten gesperrt, so können Sie mit Hilfe des Freigabezeit-Intervalls festlegen, wann ein Ticket wieder automatisch vom System freigegeben werden soll. So können auch die anderen Mitarbeiter wieder auf dieses Ticket zugreifen und es bearbeiten. Geben Sie für Eskalationszeit einen Wert an, so blockieren Tickets, die älter als die angegebene Zeit sind, die Bearbeitung neuerer Tickets. Diese Einstellung stellt also sicher, dass ältere Tickets ab einem bestimmten Alter bevorzugt bearbeitet werden müssen, neuere Tickets werden dann nicht mehr in der Queue angezeigt. Weiterhin können Sie festlegen, dass bei einem Follow-Up auf ein Ticket wieder der Mitarbeiter Eigentümer dieses Tickets wird, der zuletzt als Eigentümer im System für dieses Ticket vermerkt war. Dies stellt sicher, dass die Nachfrage eines Kunden zuerst bei demselben Mitarbeiter landet, der sich zuletzt um dieses Ticket gekümmert hat. Der Parameter für die Systemadresse legt fest, mit welcher Absenderadresse Mails aus dieser Queue versendet werden sollen. Mit Hilfe der Parameter für Anrede und Signatur kann eingestellt werden, welche Vorgaben hier standardmäßig bei Antworten auf Tickets in dieser Queue genutzt werden. In den Abschnitten E-Mailadressen Anreden und Signaturen erfahren Sie mehr über die Einrichtung dieser Parameter. Mit Hilfe der verschiedenen Kundeninfo-Parameter können Sie schließlich festlegen, bei welchen Ereignissen ein Kunde über die Änderungen bei einem Ticket in dieser Queue informiert werden soll. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System angelegte Queue nicht entfernt werden. Um eine Queue trotzdem zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Queue in der Listbox für "Gültig" den Wert entweder auf "ungültig" bzw. "ungültig-temporär". Alle gerade beschriebenen Konfigurationsmöglichkeiten für Queues, gelten auch für Unter-Queues. Somit lassen sich mit Hilfe der Queues in OTRS z. B. die einzelnen Abteilungen Ihres Betriebes oder die verschiedenen Phasen eines Geschäftsvorgangs (Anfrage, Angebot, Bestellung, usw.) abbilden. Dies sollten Sie sich bei der Strukturierung Ihres OTRS zu Nutze machen. Um das Antworten auf Tickets zu beschleunigen und das Aussehen beantworteter Tickets zu vereinheitlichen, können in OTRS Antwortvorlagen erstellt werden. Jede Antwortvorlage kann einer oder mehreren Queues bzw. Unter-Queues zugeordnet werden, es können mehrere Antwortvorlagen für jede Queue definiert werden. In der Queue-Ansicht bzw. in "Meine Queues" erscheinen die verschiedenen Antwortvorlagen als Links unter jedem angezeigten Ticket, eine Antwort auf ein Ticket mit einer bestimmten Vorlage kann somit schnell durchgeführt werden. Nach einer Standardinstallation ist für jede Queue die Antwortvorlage "empty answer" vorhanden. Im Admin-Bereich kann über den Link "Antworten" auf die im System gespeicherten Antwortvorlagen zugegriffen und diese bearbeitet werden. Antwortvorlagen Zuweisung einer Antwortvorlage zu einer Queue Um eine Antwortvorlage einer oder mehreren Queues zuzuweisen, aktivieren Sie im Admin-Bereich den Link "Antworten <-> Queues". Es wird eine Tabelle geladen, die die Queues und die einzelnen Antwortvorlagen und deren Beziehung zueinander (1:n oder n:1) anzeigt. Hier können Sie nun die Queue oder die Antwortvorlage auswählen, um die Zuordnung zu bearbeiten. Wenn Sie zum Beantworten eines Tickets, z. B. in der Queue-Ansicht, auf den Link für eine Antwortvorlage klicken, können Sie feststellen, dass nicht nur der Text der Antwortvorlage sondern auch eine Anrede, der zitierte Ticketinhalt und eine Signatur geladen werden. Antwortvorlagen setzen sich also aus verschiedenen Textbausteinen zusammen. Dies sind die Anrede und Signatur der Queue, in der sich das zu beantwortende Ticket befindet, der Text des Tickets auf das geantwortet werden soll und ggf. der Text der Antwortvorlage selbst, der wie gerade beschrieben, festgelegt werden kann. 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. Ein Textbaustein für eine Antwortvorlage ist die Anrede. Anreden können einer Queue zugeordnet werden, wie im Abschnitt zu den Queues beschrieben, nur so werden Sie bei Antworten für Tickets aus dieser Queue verwendet. Über den Link "Anreden" innerhalb des Admin-Bereiches, können Sie die verschiedenen Anreden Ihres Systems verwalten. Verwaltung von Anreden Nach einer Standardinstallation von OTRS sind bereits zwei Anreden im System gespeichert, "system standard salutation (de/buiss)" und "system standard salutation (en)". Damit auch dynamische Inhalte in eine Anrede eingebaut werden können, also Inhalte, die sich bei jeder Anrede ändern, können verschiedene Variablen in den Anredentext eingebaut werden. Der in der Variable gespeicherte Text wird beim Antworten automatisch in den Text eingefügt. Ein variabler Textteil könnte z.b. der Name oder die Mailadresse der Person sein, auf deren Ticket sie antworten. Im unteren Teil der Bildschirmmaske zum Ändern oder Anlegen einer Anrede finden Sie die verschiedenen OTRS-Variablen, die Sie für die dynamische Aufbereitung eines Anredentextes verwenden können. OTRS-Variablen zeichnen sich dadurch aus, dass sie von spitzen Klammern (<>) eingeschlossen sind. Zwischen den spitzen Klammern steht der Name der Variable, der sich oft auf den in der Variable gespeicherten Inhalt bezieht. Bauen Sie z. B. in Ihrem Anredentext die Variable <OTRS_LAST_NAME> ein, so wird diese später durch den Nachnamen der Person ersetzt, deren Ticket Sie beantworten. Sehen Sie sich auch die schon bereits im System gespeicherten Anreden an, dann wird die Verwendung der verschiedenen Variablen klarer. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System angelegte Anrede nicht entfernt werden. Um eine Anrede trotzdem zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Anrede in der Listbox für "Gültig" den Wert entweder auf "ungültig" bzw. "ungültig-temporär". Ein weiterer Textbaustein für eine Antwortvorlage, ist die Signatur. Signaturen können einer Queue zugeordnet werden, wie im Abschnitt zu den Queues beschrieben, nur so werden Sie bei Antworten für Tickets aus dieser Queue verwendet. Über den Link "Signaturen" innerhalb des Admin-Bereiches, können Sie die verschiedenen Signaturen Ihres Systems verwalten. Verwaltung von Signaturen Nach einer Standardinstallation von OTRS sind bereits zwei Signaturen im System gespeichert, "system standard signature (de/buiss)" und "system standard signature (en)". Auch in Signaturen können dynamische Inhalte eingebaut werden. Dies geschieht, genauso wie bei den Anreden, mit Hilfe verschiedener OTRS-Variablen, die in den Text der Signatur integriert werden können. Ein variabler Textteil könnte z.b. der Name des Mitarbeiters sein, der das Ticket beantwortet hat. Im unteren Teil der Bildschirmmaske zum Ändern oder Anlegen einer Signatur finden Sie die verschiedenen OTRS-Variablen, die Sie für die dynamische Aufbereitung eines Signaturentextes verwenden können. OTRS-Variablen zeichnen sich dadurch aus, dass sie von spitzen Klammern (<>) eingeschlossen sind. Zwischen den spitzen Klammern steht der Name der Variable, der sich oft auf den in der Variable gespeicherten Inhalt bezieht. Bauen Sie z. B. in Ihrem Anredentext die OTRS-Variable <OTRS_LAST_NAME> ein, so wird diese später durch den Nachnamen des Agents ersetzt, der das Ticket beantwortet hat. Sehen Sie sich auch die schon bereits im System gespeicherten Anreden an, dann wird die Verwendung der verschiedenen Variablen klarer. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System angelegte Signatur nicht entfernt werden. Um eine Signatur trotzdem zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Signatur in der Listbox für "Gültig" den Wert entweder auf "ungültig" oder auf "ungültig-temporär". Ein weitere optionaler Teil einer Antwortvorlage kann eine Anlage sein. Diese wird bei der Benutzung einer Antwortvorlage als Anhang an das zu beantwortende Ticket angehängt, kann aber über eine Checkbox im Antworten-Bildschirm für Tickets leicht deaktiviert werden. Verwaltung von Anlagen für Antwortvorlagen Über den "Anlagen"-Link im Admin-Bereich können Sie neue Anlagen in das System integrieren. Nachdem eine Anlage im System gespeichert wurde, kann sie noch einer oder mehreren Antwortvorlagen zugeordnet werden. Die Zuordnung der Anlagen zu den einzelnen Antwortvorlagen kann über den Link "Anlagen <-> Antworten" im Admin-Bereich von OTRS erreicht werden. Zuweisung einer Anlage zu einer Antwortvorlage Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System gespeicherte Anlage nicht mehr entfernt werden. Um eine Anlage trotzdem systemweit zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Anlager in der Listbox für "Gültig" den Wert entweder auf "ungültig" oder "ungültig-temporär". OTRS bietet die Möglichkeit, automatische Antworten an Kundenbenutzer zu verschicken. Automatische Antworten sind an bestimmte Ereignisse im System gebunden, z. B. an das Anlegen eines neuen Tickets in einer Queue, wenn ein Followup eines Tickets stattfindet, wenn ein Ticket geschlossen oder vom System zurückgewiesen wird. Über den Link "Auto Antworten" innerhalb des Admin-Bereiches erreichen Sie die Verwaltung der automatischen Antworten. Im Formular zum Ändern oder Anlegen einer automatischen Antwort stellen Sie über die Listbox für "Typ" das Ereignis ein, das mit der automatischen Antwort verknüpft werden soll. Nach einer Standardinstallation sind folgende Ereignistypen vorhanden. Verwaltung von automatischen Antworten Name Beschreibung auto reply Dieses Ereignis tritt ein, wenn ein neues Ticket in einer Queue angelegt wird. auto reply/new ticket Dieses Ereignis tritt ein, wenn ein bereits geschlossenes Ticket, z. B. durch die Antwort eines Kunden, mit einer neuen Ticketnummer erneut geöffnet wird. auto follow up Dieses Ereignis tritt ein, wenn ein Follow up für ein bereits vorhandenes Ticket eintrifft. auto reject Dieses Ereignis tritt ein, wenn ein Ticket vom System zurückgewiesen wird. auto remove Dieses Ereignis tritt ein, wenn ein Ticket entfernt wird. Für die Betreffzeile und den Text von automatischen Antworten kann genauso wie bei Signaturen oder Anreden, der Inhalt mit Hilfe von OTRS-Variablen dynamisch erzeugt werden. So werden über die Variable <OTRS_CUSTOMER_EMAIL[5]> die ersten 5 Zeilen der an das System gesendeten E-Mail in die automatische Antwort eingefügt, oder durch <OTRS_CUSTOMER_FROM> die From-Zeile. Die Anmerkungen im unterem Bereich der Bildschirmmaske zur Verwaltung der automatischen Antworten listen alle OTRS-Variablen auf, die verwendet werden können. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System angelegte Auto-Antwort nicht entfernt werden. Um eine Auto-Antwort trotzdem systemweit zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Auto-Antwort in der Listbox für "Gültig" den Wert entweder auf "ungültig" oder "ungültig-temporär". Zuweisung einer automatischen Antwort zu einer Queue Um eine automatische Antwort einer oder mehreren Queues zuzuweisen, folgen Sie im Admin-Bereich den Link "Auto Antworten <-> Queues". Dort sind für jede Queue die verschiedenen Ereignistypen aufgelistet und es kann eine Zuordnung einer Auto-Antwort vom gleichen Ereignistyp durchgeführt bzw. entfernt werden. Um aus OTRS heraus E-Mails verschicken zu können, benötigen Sie mindestens eine gültige Mailadresse. Da in vielen Fällen eine Mailadresse nicht ausreicht, ist OTRS auch in der Lage, mit mehreren Mailadressen zu arbeiten. Für jede Queue kann mindestens eine Mailadresse festgelegt werden, es ist aber auch möglich eine Adresse mehreren Queues zuzuordnen. D.h., dass von außen eine Queue über mehrere Mailadressen ereicht werden kann, für das Versenden von Nachrichten aus einer Queue muss jedoch eine Adresse festgelegt werden. Beim Anlegen oder Bearbeiten einer Queue stellen Sie ein, welche im System gespeicherte Mailadresse für die ausgehenden Nachrichten der entsprechenden Queue benutzt werden soll. Die Verwaltung der Mailadressen des Systems erreichen Sie, indem sie im Admin-Bereich dem Link "E-Mail Adressen" folgen. Verwaltung von Mailadressen Im Formular zur Verwaltung der E-Mailadressen können Sie u.a. direkt auswählen, mit welcher Queue oder Unter-Queue die neue Mailadresse verknüpft werden soll. Diese Verknüpfung ist wichtig, da so eingehende Mails anhand der Adresse im To: Feld der entsprechenden Queue zugewiesen werden können. Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, kann eine einmal im System angelegte Mailadresse nicht entfernt werden. Um eine Mailadresse trotzdem systemweit zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Mailadresse in der Listbox für "Gültig" den Wert entweder auf "ungültig" oder "ungültig-temporär". Kunden und Mitarbeiter können im Einstellungs-Bereich ihres Accounts festlegen, bei welchen Ereignissen Sie automatisch vom System per Mail benachrichtigt werden wollen. Verwaltung von Benachrichtigungen Über den "Benachrichtigungen"-Link im Admin-Bereich erreichen Sie die Verwaltung der Benachrichtigungen. Sie können die Betreffzeile und den Text einer Benachrichtigung anpassen, indem Sie die entsprechende Benachrichtigung aus der Listbox auswählen und deren Einstellung über den "Ändern"-Schalter laden. Am Namen einer Benachrichtigung erkennen Sie, bei welcher Oberflächensprache die Benachrichtigung verwendet wird, für welches Ereignis die Benachrichtigung steht und ob sie für einen Kunden oder Agenten bestimmt ist. Auch innerhalb der Benachrichtigungen können die Textinhalte mit Hilfe der OTRS-Variablen dynamisch aufbereitet werden. Innerhalb der Anmerkungen im unteren Bereich der Bildschirmmaske zur Benachrichtigungen-Verwaltung werden die verschiedenen zur Verfügung stehenden Variablen und deren Verwendung aufgelistet und näher erklärt. Mit OTRS ist es möglich, Tickets mit Hilfe von SMIME zu ent- und verschlüsseln bzw. Tickets zu signieren. Bevor SMIME allerdings systemweit genutzt werden kann, muss das Feature mit Hilfe einiger Konfigurationsparameter z. B. über die grafische Administrationsoberfläche des Systems aktiviert und konfiguriert werden Verwaltung von SMIME-Zertifikaten Über den "SMIME"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung der SMIME-Zertifikate. Es können Zertifikate und private Fingerprints hinzugefügt und entfernt werden und eine Suche in den Zertifikaten ist möglich. Mit OTRS ist es möglich, Tickets mit Hilfe von PGP zu ent- und verschlüsseln bzw. zu signieren. Bevor PGP allerdings systemweit genutzt werden kann, muss das Feature mit Hilfe einiger Konfigurationsparameter z. B. über die grafische Administrationsoberfläche des Systems aktiviert und konfiguriert werden Verwaltung von PGP-Schlüsseln Über den "PGP"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung des Schlüsselrings Ihres Systems. Es können Schlüssel und Signaturen hinzugefügt und entfernt werden und eine Suche innerhalb des Schlüsselrings ist möglich. Das Kapitel Verschlüsselung mit PGP beschreibt die einrichtung und Verwendung detaillierter. Über den Link "Status" können Sie die Status, die Sie in OTRS verwenden möchten, bearbbeiten. Verwaltung der Status Nach einer Standardinstallation sind die Status "closed successful", "closed unsuccessful", "merged", "new", "open", "pending auto close+", "pending auto close-" "pending reminder" und "removed" vorhanden. Jeder Status ist einem Status-Typ zugeordnet, der auch beim Anlegen eines neuen Status vergeben werden muss. Es gibt standardmäßig die Status-Typen "geschlossen", "merged", "neu", "offen", "pending auto", "warten zur Erinnerung" und "entfernt". Seit OTRS 2.0 kann das System nahezu vollständig über das Webinterface konfiguriert werden und manuelle Anpassungen der Konfigurationsdateien gehören der Vergangenheit an. MÖglich wird dies durch das grafische Administrations-Frontend. Das grafische Konfigurations-Frontend von OTRS Über den "SysConfig"-Link im Admin-Bereich von OTRS erreichen sie die grafische Administrationsoberfläche. Über diese können Sie eigene Konfigurationsdateien in das System integrieren bzw. Ihre persönlichen Änderungen an der Standardkonfiguration in eine Datei sichern. Nahezu alle Konfigurationsparameter des OTRS Frameworks und der zusätzlich installierten Module können eingesehen und geändert werden, die Navigation durch die Vielzahl der Konfigurationsparameter wurde durch die Einteilung in Module und Gruppen übersichtlich aufgeteilt. Weiterhin ist es möglich, eine Suche über alle Konfigurationsparameter hinweg durchzuführen, so dass einzelne Parameter schnell aufgefunden und bearbeitet werden können. Das Kapitel Nähere Beschreibung der grafischen Administrationsoberfläche geht ausführlicher auf das grafische Konfigurations-Frontend ein. Es gibt mehrere Möglichkeiten, Mails in OTRS einzuspeisen. Neben der Nutzung des PostMaster.pl-Skripts, welches die Mails direkt in das System piped, können auch POP3-Konten abgefragt werden, an die Mails für Ihr Ticket-System gehen. Über den Link "PostMaster POP3 Account" innerhalb des Admin-Bereiches erreichen Sie die Verwaltung der POP3-Konten, die OTRS automatisch auf neue Nachrichten überprüfen soll. Verwaltung von POP3 Konten Im Kapitel über die Mailkonfiguration für OTRS wird die Einrichtung der POP3-Konten näher erläutert. Damit Sie automatisch Mails vorsortieren können bzw. ungewünschte Mails gar nicht in die Queues des Ticket-Systems gelangen, können Filterregeln für eingehende Nachrichten festgelegt werden. Dabei spielt es keine Rolle, ob die Mails über POP3-Konten oder mit Hilfe des PostMaster.pl Skriptes ins System gelangen. Der Link "PostMaster Filter" innerhalb des Admin-Bereiches von OTRS ruft die Verwaltung für die Filterregeln auf. Verwaltung von Filterregeln für eingehende E-Mails Eine Filterregel besteht aus einem oder mehreren Kriterien die erfüllt werden müssen, damit die Filterregel greift, und aus einer oder mehreren Aktionen die ausgeführt werden, nachdem die Filterkriterien erfüllt wurden. Sie können für die Kopfzeilen und den Body einer Nachricht Filterregeln festlegen, also z. B. nach bestimmten Headern suchen oder nach Zeichenketten bzw. regulären Ausdrücken innerhalb der Mail. Alle Aktionen für eine Filterregel werden über sog. X-OTRS-Header gesteuert, die in die Mail eingefügt werden. Das Ticket-System wertet die X-OTRS-Header aus und nimmt die entsprechenden Aktionen vor. Mit den X-OTRS-Headern kann z. B. die Priorität einer Nachricht geändert werden, die Mail in eine bestimmte Queue einsortiert oder die Mail komplett verworfen werden, usw. Die folgende Tabelle listet die verschiedenen X-OTRS-Header, deren zulässige Werte und die Bedeutung der einzelnen Header auf. Name Mögliche Werte Beschreibung X-OTRS-Priority: 1 very low, 2 low, 3 normal, 4 high, 5 very high Legt die Priorität eines Tickets fest. X-OTRS-Queue: Name einer Queue des Systems. Legt die Queue fest, in die das Ticket einsortiert werden soll. Wird mit dem X-OTRS-Queue-Header eine Queue voreingestellt, so hat diese Einstellung Vorrang vor allen anderen Filterregeln, die sich auf Queues beziehen. X-OTRS-Ignore: Yes Wird dieser Header gesetzt, wird die Mail komplett ignoriert und gelangt somit nie als Ticket in das System. X-OTRS-State: new, open, closed successful, closed unsuccessful, ... Setzt den nächsten Status eines Tickets. X-OTRS-CustomerUser: CustomerUser Legt den Kunden-Benutzer fest, dem das Ticket zugeordnet werden soll. X-OTRS-CustomerNo: CustomerNo Legt die Kunden-ID fest, die dem Ticket zugeordnet werden soll. X-OTRS-ArticleKey(1|2|3): Zusätzlicher Info-Key für den Artikel. Speichert einen zusätzlichen Info-Key für den Artikel. X-OTRS-ArticleValue(1|2|3): Zusätzlicher Info-Value. Speichert einen zusätzlichen Info-Value für den Artikel. X-OTRS-SenderType: agent, system, customer Legt die Art des Ticket-Absenders fest. X-OTRS-ArticleType: email-external, email-internal, email-notification-ext, email-notification-int, phone, fax, sms, webrequest, note-internal, note-external, note-report Legt den Typ des Artikles für das eingehende Ticket fest. X-OTRS-TicketKey(1|2|...|8): Zusätzlicher Info-Key Speichert einen zusätzlichen Info-Key für das Ticket. X-OTRS-TicketValue(1|2|...|8): Zusätzlicher Info-Value Speichert einen zusätzlichen Info-Value für das Ticket. X-OTRS-Loop: True Ist dieser X-OTRS-Header gesetzt, wird keine automatische Antwort an den Absender des neuen Tickets geschickt, z. B. um Mailschleifen zu vermeiden. Über das Formular auf der rechten Seite der Verwaltung für die Filterregeln können neue Filterregeln hinzugefügt werden. Sie müssen für jede Regel einen Namen vergeben. Darunter legen Sie in der Sektion für "Treffer" die verschiedenen Kriterien fest, nach denen gefiltert werden soll. Wählen Sie aus den Listboxen für "Header 1", "Header 2" usw. aus, an welcher Stelle in der eingehenden Nachricht Sie suchen möchten und tragen Sie rechts neben dem entsprechenden Header den Wert ein, nach dem gesucht werden soll. In der Sektion "Setzen" legen Sie die Aktionen fest, die ausgeführt werden sollen, wenn die Filterkriterien zutreffen. Hier können Sie für "Header1", "Header 2" usw. den entsprechenden X-OTRS-Header auswählen und rechts daneben den entsprechenden Wert eintragen. Eine nützliche Filterregel könnte sein, alle Mails, die von spamassassin als Spam markiert wurden, automatisch in die Queue "Junk" einsortieren zu lassen. Spamassassin fügt bei allen überprüften Mails die Kopfzeile "X-Spam-Flag" hinzu. Wird die Mail als Spam markiert, wird dieser Header auf "Yes" gesetzt. Das Filterkriterium lautet also "X-Spam-Flag: Yes". Um nun eine Filterregel mit diesem Kriterium zu erzeugen, tragen Sie hierzu als Name für die Filterregel z. B. "spam-mails" ein und wählen in der Sektion "Treffer" für "Header 1" den Header "X-Spam-Flag:" aus der Listbox aus. Rechts daneben fügen Sie als Wert "Yes" hinzu. Das Filterkriterium wurde somit festgelegt. Um nun die Einsortierung der von spamassassin als Spam klassifizierten Mails in die Queue "Junk" zu erzwingen, wählen Sie in der Sektion "Setzen" für "Header 1" den Eintrag "X-OTRS-Queue:" aus und tragen als Wert rechts daneben "Junk" ein. Abschließend wird mit Hilfe des "Hinzufügen"-Buttons die neue Regel gespeichert und aktiviert, beim nächsten Abruf der POP3-Konten bzw. für die nächste an das System gesendete Nachricht wird die Filterregel abgearbeitet. Es gibt weitere Module, die zum Filtern eingehender E-Mails genutzt werden und bei komplexeren Installationen nützlich sein können. Der GenericAgent ist ein Tool zum automatischen Ausführen von Aufgaben, die normalerweise ein richtiger Agent manuell durchführen müsste. Er kann z. B. bestimmte Tickets in einer Queue schließen oder Benachrichtigungen für eskalierte Tickets versenden. Jobliste des GenericAgents Um einen neuen Job für den GenericAgent zu definieren, folgen Sie dem Link "GenericAgent". Es wird eine Tabelle mit den bereits vorhandenen Jobs angezeigt, über die Jobs auch manuell ausgeführt oder gelöscht werden können. Zum Hinzufügen eines neuen Jobs geben Sie den Namen ein und klicken auf "Hinzufügen". Anlegen eines Jobs für den GenericAgent Über die Bildschirmmaske zum Erstellen eines neuen Jobs kann der Zeitplan für die Ausführung des Jobs eingestellt werden. Desweiteren kann über verschiedene Kriterien festgelegt werden, welche Tickets vom Job erfasst werden sollen. Schließlich ist es möglich, die neuen Eigenschaften der vom Job betroffenen Tickets einzustellen. Nachdem der Job gespeichert wurde, werden alle Tickets aufgeführt, die durch den Job verändert werden. Diese Auflistung dient zur Übersicht, ob der Job richtig funktioniert, es werden noch keine Veränderungen vorgenommen. Erst nach der Übernahme des Jobs in die Job-Liste, wird der Job aktiviert. Um als OTRS-Administrator eine Mail an bestimmte Benutzer (Agents) oder Benutzergruppen im System zu versenden, folgen Sie dem Link "Admin Notification". Administratoren E-Mail an Benutzer oder Gruppen Es wird ein Formular geladen, in das Sie die Absenderadresse, den Betreff und den Inhalt der Administratoren-Mitteilung eintragen können. Weiterhin können Sie aus der Tabelle auswählen, an welche Benutzer und / oder Benutzergruppen die Mitteilung gesendet werden soll. Um eine Übersicht über die gerade im System angemeldeten Benutzer und deren Sitzungseigenschaften zu erhalten, folgen Sie dem Link "Sitzungsverwaltung". Sitzungsverwaltung Innerhalb der Sitzungsverwaltung werden allgemeine Informationen zu allen Sitzungen im System ausgegeben, also z. B. wie viele Sitzungen gerade insgesamt aktiv sind oder wie viele Agenten- und Kunden-Sitzungen laufen, usw. Es besteht die Möglichkeit mit Hilfe des "Alle Sitzungen löschen"-Schalters die Sitzungen aller angemeldeten Benutzer zu beenden. Weiterhin können detaillierte Informationen für jede einzelne Sitzung abgerufen und einzelne Sitzungen gelöscht werden. Der Link "System Log" ermöglicht es, die letzten Logeinträge des Ticket-Systems über die Weboberfläche einzusehen. Systemlog Ein Logeintrag setzt sich aus der Zeit, der Priorität, der betroffenen Systemkomponente und der eigentlichen Meldung zusammen. Die System Logs können nur auf Unix- oder Linux-Systemen über das Web-Interface eingesehen werden, unter Windows-Betriebssystemen steht diese Funktion nicht zur Verfügung. Die Anzahl der im Web-Interface angezeigten Logeinträge kann über den Konfigurationsparameter für die Größe des Systemlog-Caches beeinflusst werden. Über den Link "Select Box" kann eine Bildschirmmaske aufgerufen werden, die es ermöglicht direkt mit SQL-Statements den Inhalt von Tabellen der OTRS-Datenbank abzurufen. Es sind nur SELECT-Abfragen möglich, d.h. die Tabellen können auf diesem Weg nicht verändert werden. SQL-Abfragen über die Weboberfläche Seit Version 2.0 besteht OTRS aus einem zentralen Framework und mehreren Zusatzpaketen, um die das System wahlweise erweitert werden kann. An zusätzlichen Paketen stehen z. B. ein web-basierter Filemanager, ein Web-Mailer, ein Content-Manager oder ein Tool zur Überwachung von verschiedenen Betriebssystemparametern zur Verfügung. Um die Installation der verschiedenen Komponenten zu erleichtern, können diese mit Hilfe des Paket Managers bequem über das Web-Interface von OTRS installiert oder entfernt werden. Die Paket Verwaltung erreichen sie über den Link "Paket Verwaltung". Paketmanager Die Pakete, die über die Paket Verwaltung hinzugefügt oder entfernt werden können, müssen im sog. opm-Format vorliegen, andere Formate werden nicht unterstützt. Es können mehrere Installations-Quellen angegeben werden, über die die opm-Pakete installiert werden können. Steht Ihnen ein Paket lokal zur Verfügung und kann darauf über das Filesystem der Maschine zugegriffen werden, auf der OTRS installiert ist, können Sie im Eingabefeld für "Paket" die genaue Lokation zu diesem Paket angeben, also den absoluten Pfad gefolgt vom Dateinamen des opm-Pakets. Mit Hilfe des Schalters "Installieren" unterhalb des Eingabefeldes, wird das Paket in die vorhandene OTRS-Installation integriert. D.h., es werden die benötigten Dateien kopiert, Icons und Ausgabevorlagen installiert und ggf. die Datenbank angepasst. Ist dieser Vorgang beendet, kann das neu installierte Modul genutzt werden. Um immer Zugriff auf die aktuellen Versionen der zusätzlichen Module zu haben, empfielt es sich, die Pakete über ein Online-Repository einzuspielen. Die neueste Modulliste des Online-Repositorys erhalten Sie, indem Sie aus der Listbox für "Quelle" den Server auswählen, von dem die Daten des Repositorys heruntergeladen werden sollen. Verwenden Sie den "Aktualisieren"-Schalter, um die Daten auf den neuesten Stand zu bringen. Nach kurzer Zeit werden auf der rechten Seite im Abschnitt für das Online Repository die Module aufgelistet, die online für eine Installation zur Verfügung stehen. In der rechten Spalte dieser Tabelle können Sie den "Installieren"-Schalter verwenden, um das entsprechende Modul in Ihr System zu integrieren. Hängt das Modul von der Installation anderer Module ab, erhalten Sie einen entsprechenden Hinweis. War die Installation eines Moduls erfolgreich, wird das Modul in den Abschnitt für das lokale Repository übertragen und dort aufgeführt. Das lokale Repository listet also alle Module auf, die sie zusätzlich über die Paket Verwaltung Ihrer Installation hinzugefügt haben. Benötigen Sie einmal ein bestimmtes Modul nicht mehr und wollen es entfernen, so ist dies über den "deinstallieren"-Schalter rechts vom entsprechenden Modul innerhalb des lokalen Repositorys möglich. Auch bei diesem Vorgang werden eventuelle Abhängigkeiten beachtet. Alle Konfigurationsdateien des OTRS-Frameworks befinden sich innerhalb des Verzeichnisses Kernel bzw. in Unterverzeichnissen dieses Directorys. Bis auf die Datei Kernel/Config.pm sollten Sie keine Konfigurationsdatei manuell verändern, da alle anderen Dateien beim Updaten des Systems überschrieben werden und so Ihre eigenen Einstellungen verloren gehen. Übertragen Sie lediglich die Parameter aus den anderen Dateien nach Kernel/Config.pm und passen Sie die Parameter Ihren Wünschen entsprechend an. Die Datei Kernel/Config/Defaults.pm enthält die Konfigurationsparameter für den OTRS-Framework. In ihr finden Sie grundlegende Einstellungen wie die Mailkonfiguration, die Datenbankanbindung, Standardsprache o.ä. In der Datei Kernel/Config/Files/Ticket.pm sind alle Konfigurationsparameter für das Ticketsystem aufgeführt. Das Verzeichnis Kernel/Config/Files enthält weitere Konfigurationsdateien, die beim Starten von OTRS eingelesen werden. Sind zusätzliche Module wie der Filemanager oder der Webmailer installiert, liegen die Konfigurationsdateien dieser Applikationen ebenfalls in Kernel/Config/Files. Im Moment sind immer eine .pm- und eine .xml-Datei für jedes Modul vorhanden, da aus Kompatibilitätsgründen zu älteren OTRS-Versionen noch die Einstellungen in den .pm-Dateien benötigt werden. Die .xml-Dateien werden von der grafischen Administrationsoberfläche ausgewertet, die seit OTRS 2.0 verfügbar ist und die es Ihnen ermöglicht, das System nahezu vollständig über die Web-Oberfläche zu konfigurieren. In zukünftigen Versionen von OTRS wird auf die .pm-Dateien vollständig verzichtet und alle Einstellungen aus Kernel/Config/Defaults.pm werden nur noch in Kernel/Config/Files/Framework.xml zu finden sein bzw. alle Einstellungen für das Ticketsystem befinden sich dann nur noch in der Datei Kernel/Config/Files/Ticket.xml. Die Konfigurationsparameter werden also in zukünftigen Versionen komplett in das xml-Format übertragen. Wird die Web-Oberfläche von OTRS aufgerufen, werden die xml-Dateien in Kernel/Config/Files in alphabetischer Reihenfolge ausgelesen und die Einstellungen des Frameworks und der evtl. zusätzlich installierten Applikationen geladen. Anschließend werden die Einstellungen in den Dateien Kernel/Config/Files/ZZZAAuto.pm und Kernel/Config/Files/ZZZAuto.pm ausgewertet. Beide Dateien werden vom grafischen Konfigurations-Frontend angelegt und sollten auf keinem Fall manuell geändert werden. Zuletzt wird die Datei Kernel/Config.pm mit den von Ihnen individuell angepassten Konfigurationsparametern ausgewertet, so dass auf jeden Fall Ihre eigenen Einstellungen geladen werden. Seit OTRS 2.0 können nahezu alle Konfigurationsparameter des Frameworks oder der ggf. zusätzlich installierten Applikationen bequem über ein grafisches Frontend angepasst werden. Melden Sie sich als OTRS-Administrator an und folgen Sie im Admin-Bereich den Link "SysConfig", um das grafische Konfigurations-Frontend zu laden. Die grafische Konfigurationsoberfläche Da OTRS mittlerweile über mehr als 600 verschiedene Konfigurationsparameter verfügt, bietet das Konfigurations-Frontend mehrere Möglichkeiten zur schnellen Auffindung der gewünschten Einstellung. Es kann über alle Konfigurationsparameter hinweg nach einem bestimmten Stichwort gesucht werden. Bei der Suche werden neben dem Namen des Konfigurationsparameters auch die Beschreibungen ausgewertet, eine Einstellung kann also auch gefunden werden, wenn ihr Name nicht bekannt ist. Weiterhin wurden die verschiedenen Konfigurationsparameter in Haupt- und Untergruppen unterteilt. Die Hauptgruppe stellt die Applikation dar, für die der Konfigurationsparameter zuständig ist, also z.B. "Framework" für das OTRS-Framework oder "Ticket" für das Ticketsystem. Die Untergruppen einer Hauptgruppe können eingesehen werden, indem die Gruppe bzw. Applikation aus der dazu vorgesehenen Listbox ausgewählt und der "Zeigen"-Knopf gedrückt wird. Für jeden einzelnen Konfigurationsparameter kann über eine Checkbox festgelegt werden, ob er vom System beachtet werden soll oder nicht. Wird eine Einstellung verändert, kann die Änderung mit Hilfe des "Aktualisieren"-Buttons übernommen werden. Eine Einstellung kann mit Hilfe des "Rücksetzen"-Schalters auf ihren Default-Wert zurückgesetzt werden. Für die Sicherung aller von Ihnen vorgenommenen Änderungen, kann eine .pm-Datei heruntergeladen werden, die alle vom Standard abweichenden Konfigurationsparameter Ihres Systems enthält. Die selbe Datei können Sie ebenfalls über die Konfigurationsoberfläche eines frisch installierten Systems zurück spielen und so alle Einstellungen wieder herstellen. Die Einstellungen für die Datenbankanbindung können aus Sicherheitsgründen nicht über das grafische Konfigurations-Frontend geändert werden und müssen manuell in die Datei Kernel/Config.pm eingefügt werden. OTRS ist in der Lage, E-Mails via Sendmail (z. B. Sendmail, Postfix, Qmail oder Exim) zu versenden. Die Standard-Konfiguration sollte gleich ohne Probleme funktionieren, verwendet wird das sendmail-Binary Ihres Betriebssystems. Die Konfiguration kann über die grafische Administrationsoberfläche vorgenommen werden, oder die Datei Kernel/Config.pm wird um die entsprechenden Parameter erweitert: # SendmailModule # (Where is sendmail located and some options. # See 'man sendmail' for details.) $Self->{'SendmailModule'} = 'Kernel::System::Email::Sendmail'; $Self->{'SendmailModule::CMD'} = '/usr/sbin/sendmail -t -i -f '; Wenn kein sendmail-Binary zur Verfügung steht, kann OTRS E-Mails via SMTP versenden (Simple Mail Transfer Protocol / RFC 821). Diese Möglichkeit kann hauptsächlich auf Nicht-Unix-Plattformen (z. B. Win32) genutzt werden. Die Konfiguration kann über die grafische Administrationsoberfläche vorgenommen werden, oder die Datei Kernel/Config.pm wird um die entsprechenden Parameter erweitert: # SendmailModule $Self->{"SendmailModule"} = "Kernel::System::Email::SMTP"; $Self->{"SendmailModule::Host"} = "mail.example.com"; $Self->{"SendmailModule::AuthUser"} = ""; $Self->{"SendmailModule::AuthPassword"} = ""; OTRS ist in der Lage, E-Mails von POP3-Konten zu empfangen. Konfigurieren Sie Ihre POP3-Konten im Admin-Bereich von OTRS in der Sektion PostMaster POP3 Account . Verwaltung von POP3 Konten Beim Anlegen eines neuen POP3-Accounts muss der POP3-Server, ein Login und ein Kennwort angegeben werden. Wählen Sie für "Vertraut" den Wert "Ja" aus, dann werden die sog. X-OTRS-Header-Einträge ausgewertet und angewendet, sofern derartige Header-Einträge in einer abgerufenen Nachricht vorhanden sind. Da mit Hilfe der X-OTRS-Header einige Dinge am System beeinflusst werden können, sollten Sie "Vertraut" nur auf "Ja" setzen, wenn Sie genau wissen, von welchen Absendern die abgerufenen Nachrichten stammen. X-OTRS-Header werden vom Modul für die Nachrichtenfilterung in OTRS benutzt, die X-OTRS-Header werden in dieser Tabelle näher beschrieben. Es spielt keine Rolle, welcher Wert für "Vertraut" ausgewählt wurde, eventuell eingerichtete Filterregeln für eingehende Mails werden trotzdem abgearbeitet. Weiterhin können Sie die Verteilung der abgerufenen Mails durch die Angabe steuern, ob die neuen Nachrichten nach dem To-Feld oder nach der Queue im System einsortiert werden sollen. Wählen Sie "Verteilung nach ausgewählter Queue" aus, landen die abgerufenen Mails auf jeden Fall in der Queue, die zusätzlich in der dafür vorgesehenen Listbox angegeben werden kann. Dabei spielt keine Rolle, an welche Adresse die Mail geschickt wurde. Wählen Sie "Verteilung nach To: Feld" aus, wird überprüft, welcher Queue die Adresse zugeordnet ist, an die die abgerufene Mail gesendet wurde. Die Zuordnung einer Mailadresse zu einer Queue kann über die Mailadressen Verwaltung vorgenommen werden. Existiert eine Zuordnung der Adresse im To: Feld zu einer Queue innerhalb des Systems, wird die abgerufene Nachricht in die entsprechende Queue einsortiert. Kann keine Zuordnung gefunden werden, landet das Ticket in der Standard-Queue des Systems (Raw), die mit Hilfe des Konfigurationsparameters PostmasterDefaultQueue eingestellt werden kann. Die Daten zu allen POP3-Konten werden in der Datenbank von OTRS gespeichert. Das Skript PostMasterPOP3.pl, welches sich im Verzeichnis bin innerhalb des OTRS-Homeverzeichnisses befindet, fragt die Einstellungen ab und holt die Mails von den einzelnen POP3-Konten. PostMasterPOP3.pl wird mit Hilfe von cron bzw. unter Windows von CRONW regelmäßig ausgeführt. Einen Beispiel-Cronjob finden Sie in der Datei var/cron/postmaster_pop3.dist. Dieser führt bin/PostMasterPOP3.pl alle 10 Minuten aus. Das Kapitel "Einrichten der von OTRS benötigten cron-Jobs" beschreibt das Zusammenspiel zwischen OTRS und cron ausführlicher. OTRS ist in der Lage, E-Mails über ein Kommandozeilen-Programm (bin/PostMaster.pl) zu empfangen. Das bedeutet, dass E-Mails im OTRS angezeigt werden, wenn der MDA (mail delivery agent, z. B. procmail) die E-Mails an bin/PostMaster.pl" weiterleitet. Um bin/PostMaster.pl auf der Kommandozeile ohne MDA zu testen, führen Sie folgendes Kommando aus: linux:/opt/otrs# cd bin linux:/opt/otrs/bin# cat ../doc/test-email-1.box | ./PostMaster.pl linux:/opt/otrs/bin# Wird die E-Mail in der Queue-Ansicht angezeigt, sind Ihre Einstellungen in Ordnung. Procmail ist in der Linux-Umgebung ein sehr bekannter E-Mail-Filter, der höchstwahrscheinlich auf Ihrem System installiert sein wird. Falls nicht, erhalten Sie auf der procmail Homepage weitere Informationen. Um procmail einzurichten (benötigt einen für procmail konfigurierten MDA (z. B. sendmail, postfix, exim oder qmail)), kann die Datei .procmailrc.dist aus dem OTRS-Homeverzeichnis verwendet werden. Kopieren Sie .procmailrc.dist nach .procmailrc und nehmen Sie folgende Änderungen vor: SYS_HOME=$HOME PATH=/bin:/usr/bin:/usr/local/bin # -- # Pipe all email into the PostMaster process. # -- :0 : | $SYS_HOME/bin/PostMaster.pl Alle an den lokalen OTRS-Benutzer gesendeten E-Mails werden an bin/PostMaster.pl weitergeleitet und dadurch im Ticket System gespeichert. Um E-Mails von Ihrem Mailserver via POP3 oder IMAP für den OTRS-Rechner/lokalen OTRS-Benutzer und procmail abzuholen, benutzen Sie fetchmail. Voraussetzung ist eine funktionierende SMTP-Konfiguration auf dem OTRS-Rechner. Eine Beispielkonfiguration finden Sie in der Datei .fetchmailrc.dist im Homeverzeichnis von OTRS. Kopieren Sie diese Datei nach .fetchmailrc und erweitern Sie die Datei um die Daten Ihrer POP3/IMAP Accounts. #poll (mailserver) protocol POP3 user (user) password (password) is (localuser) poll mail.example.com protocol POP3 user joe password mama is otrs Vergessen Sie nicht, die Zugriffsrechte von .fetchmailrc auf 710 zu setzen. Wird das Kommando "fetchmail -a ausgeführt (ggf. via cron), werden alle E-Mails auf das lokale OTRS-Konto weitergeleitet und mit Hilfe von procmail an bin/PostMasterPOP3.pl übergeben. bin/PostMasterPOP3.pl sorgt wiederum dafür, dass die neuen Mails in das Ticket System gelangen. Falls die bin/PostMaster.pl oder bin/PostMasterPOP3.pl Methoden verwendet werden, können X-OTRS-Header mit Hilfe der PostMaster-Filtermodule in die eingehenden Mails eingefügt bzw. bereits vorhandene X-OTRS-Header verändert werden. Mit Hilfe von X-OTRS-Headern kann das Ticket System bestimmte Aktionen für Mails ausführen, z. B. diese in eine bestimmte Queue einsortieren, sie einem bestimmten Kunden zuordnen, die Priorität ändern usw. Eine nähere Beschreibung der X-OTRS-Header finden Sie im Kapitel zum Einrichten von POP3-Accounts über den Administrations-Bereich von OTRS. Es gibt verschiedene Standard-Filtermodule. Der Jobname (z. B. $Self->{"PostMaster::PreFilterModule"}->{"Jobname"}) muss eindeutig sein. Kernel::System::PostMaster::Filter::Match ist ein Standard-Modul, um einige E-Mail-Header (z. B. From, To, Subject) zu prüfen und dann den neuen E-Mail-Header zu setzen (z. B. X-OTRS-Ignore: yes oder X-OTRS-Queue: spam). # (block/ignore all spam email with From: noreply@) $Self->{'PostMaster::PreFilterModule'}->{'1-Match'} = { Module => 'Kernel::System::PostMaster::Filter::Match', Match => { From => 'noreply@', }, Set => { 'X-OTRS-Ignore' => 'yes', }, }; # Job Name: 2-Match # (sort emails with From: sales@example.com and Subject: **ORDER** # into queue 'Order') $Self->{'PostMaster::PreFilterModule'}->{'2-Match'} = { Module => 'Kernel::System::PostMaster::Filter::Match', Match => { To => 'sales@example.com', Subject => '**ORDER**', }, Set => { 'X-OTRS-Queue' => 'Order', }, }; Kernel::System::PostMaster::Filter::CMD ist ein Standard-Modul, um die E-Mails an ein externes Kommando zu leiten und, falls das Ergebnis aus STDOUT true ist, den neuen E-Mail-Header zu setzen (z. B. X-OTRS-Ignore: yes oder X-OTRS-Queue: spam). # Job Name: 5-SpamAssassin # (SpamAssassin example setup, ignore spam emails) $Self->{'PostMaster::PreFilterModule'}->{'5-SpamAssassin'} = { Module => 'Kernel::System::PostMaster::Filter::CMD', CMD => '/usr/bin/spamassassin | grep -i "X-Spam-Status: yes"', Set => { 'X-OTRS-Ignore' => 'yes', }, }; Natürlich ist es auch möglich, eigene PostMaster-Filtermodule zu entwickeln. In OTRS werden einige Aktionen abhängig von der aktuellen Systemzeit ausgelöst. Von den Zeiteinstellungen betroffen sind die Berechnung der Eskalationszeit und die eigentliche Eskalation von Tickets. Weiterhin hängt die Zusendung von Benachrichtigungen für eskalierte Tickets bzw. für Erinnerungs-Tickets, die den Erinnerungszeitpunkt erreicht haben, ab. Ebenfalls wird die automatische Freigabe von Tickets durch diese Einstellungen beeinflusst. Mit Hilfe der Parameter TimeWorkingHours , TimeVacationDays und TimeVacationDaysOneTime können die für das System relevanten Zeiten entweder über das grafische Konfigurations Frond-end oder direkt über die Datei Kernel/Config.pm eingestellt werden. Die Stunden, in denen Ihre Agenten aktiv am system arbeiten, können folgendermaßen in der Datei Kernel/Config.pm festgelegt werden: $Self->{'TimeWorkingHours'} = { Mon => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ], Tue => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ], Wed => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ], Thu => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ], Fri => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ], Sat => [ ], Sun => [ ], }; Nur während dieser Stunden können Tickets eskalieren, Benachrichtigungen zu Erinnerungs-Tickets versendet oder Tickets automatisch freigegeben werden. Weiterhin werden auch nur diese Stunden in die Berechnung der Eskalationszeit und der Zeit für die automatische Freigabe mit einbezogen. Feiertage deren Datum jedes Jahr gleich ist, können dem System folgendermaßen in der Datei Kernel/Config.pm bekannt gemacht werden: $Self->{'TimeVacationDays'} = { 1 => { 1 => 'New Year\'s Eve!', }, 5 => { 1 => '1 St. May', }, 12 => { 24 => 'Christmas', 25 => 'First Christmas Day', 26 => 'Second Christmas Day', 31 => 'Silvester', }, }; Während der hier festgelegten Tage werden keine zeitabhängigen Aktionen oder Berechnungen auf Tickets im system ausgeführt. Freie oder Feiertage, für die sich jährlich das Datum ändert, können folgendermaßen in der Datei Kernel/Config.pm angegeben werden: $Self->{'TimeVacationDaysOneTime'} = { 2005 => { 9 => { 3 => 'German Unification Day' }, 12 => { 27 => 'Anual closing', 28 => 'Anual closing', 29 => 'Anual closing', 30 => 'Anual closing', }, }, 2006 => { 6 => { 12 => 'Anual works outing', }, }, }; Während der hier festgelegten Tage werden keine zeitabhängigen Aktionen oder Berechnungen auf Tickets im system ausgeführt. Gesperrte Tickets können automatisch vom System freigegeben werden. Diese Funktion kann z. B. dann nützlich sein, wenn sich ein Agent im Urlaub befindet und noch Tickets gesperrt hat, die bearbeitet werden sollen / müssen. Die Zeit, nach der gesperrte Tickets automatisch freigegeben werden, kann in den Einstellungen jeder Queue festgelegt werden. Mit Hilfe des Moduls bin/UnlockTickets.pl, das als cron-Job regelmäßig ausgeführt werden sollte, wird die automatische Freigabe von Tickets umgesetzt. Tickets werden nur während der in TimeWorkingHours festgelegten Stunden automatisch freigegeben. An mit TimeVacationDays und TimeVacationDaysOneTime festgelegten Tagen, werden keine Tickets automatisch freigegeben. Benachrichtigungen über automatisch freigegebene Tickets werden an die Agenten versendet, die die Queue mit dem automatisch freigegebenen Ticket in "Meine Queues" aufgenommen haben und bei denen in den Benutzereinstellungen die Benachrichtigung für vom System freigegebene Tickets aktiviert ist. In der nachfolgenden Tabelle werden die Unlock-Zyklen der bisherigen OTRS Versionen verglichen. "Freigabe" (unlock) Eigenschaften 1.2.x 1.3.x 2.0.x 2.1.1 - 2.1.5 2.1.6 - 2.1.x 2.2.x Ein Ticket wird "freigegeben" (unlocked) wenn... a) für die Queue, in der sich das Ticket befindet, eine Unlockzeit gesetzt ist. b) die in den Queue Einstellungen hinterlegte Unlockzeit abgelaufen ist. c) das Ticket von einem Agenten gesperrt ist. d) sich das Ticket in einem "offen" Status befindet. Wenn ein "pending" Status gesetzt ist, wird die Unlockzeit ausgesetzt. x x x x x x Die Unlockzeit wird zurück gesetzt, wenn ein Agent einen extenen Artikel am Ticket erstellt. Als externer Artikel gelten im OTRS Standard Produkt alle Artikel mit dem Artikel-Typ "email-external", "phone", "fax", "sms", oder "note-ext". x x - - x x Die Unlockzeit wird zurück gesetzt, wenn ein Ticket durch einen Agenten gesperrt wird. In diesem Moment läuft die in den Queue-Settings definierte Zeit, solange sich das Ticket in einem offen Status befindet. Wechselt das Ticket in einen Pending-Status, wird die Unlock-Time angehalten. x x x x x x Die Unlockzeit wird zurück gesetzt, wenn ein Agent einen extenen Artikel am Ticket erstellt. Als externer Artikel gelten im OTRS Standard Produkt alle Artikel mit dem Artikel-Typ "email-external", "phone", "fax", "sms", "note-ext". x x - - x x Die Unlockzeit wird zurück gesetzt, wenn ein Kunde ein "Follow-Up" auf ein Ticket sendet und der letzte Artikel von einem Agenten stammt. x x - - x x Mit OTRS ist es möglich Erinnerungs Tickets zu erstellen. Es kann ein Zeitpunkt festgelegt werden, zu dem das System eine Nachricht verschickt, in der es an ein vorher gesperrtes Ticket erinnert. Diese Funktion ist z. B. dann nützlich, wenn man daran erinnert werden will einen Kunden zu kontaktieren, dieser Kunde aber für die nächsten 2 Wochen im Urlaub ist. Benachrichtigungen für Erinnerungs Tickets werden legidlich während der Stunden versendet, die in TimeWorkingHours festgelegt wurden. Das Modul bin/PendingJobs.pl, welches regelmäßig mit Hilfe eines cron-Jobs ausgeführt werden sollte, löst den Versand der Benachrichtigungen aus. OTRS bietet die Möglichkeit der Eskalation von Tickets. Nachdem ein Ticket eskaliert ist, wird die Anzeige aller anderen Tickets in derselben Queue oder in der Queue-Ansicht so lange blockiert, bis das eskalierte Ticket gesperrt wird. Durch die Ticket-Eskalation kann also gewährleistet werden, dass Tickets die ein bestimmtes Alter überschreiten, auf jeden Fall beachtet werden müssen. Die Eskalationszeit kann in den Einstellungen jeder Queue festgelegt werden. Mit Hilfe des GenericAgents werden Benachrichtigungen über eskalierte Tickets an die Agenten versendet, die die Queue mit dem eskalierten Tickets in "Meine Queues" aufgenommen haben und für die in den Benutzereinstellungen die Benachrichtigung über eskalierte Tickets aktiviert ist. In der Datei Kernel/Config/GenericAgent.pm ist bereits ein Job eingetragen, über den der GenericAgent, regelmäßig durch einen cron-Job ausgeführt, Benachrichtigungen über eskalierte Tickets an die Agenten verschickt. Öffnen Sie diese Datei und entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen: %Jobs = ( # -- # [name of job] -> send escalation notifications # -- 'send escalation notifications' => { Escalation => 1, # new ticket properties New => { Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue', }, }, # insert your jobs (see Kernel/Config/GenericAgent.pm.examples) ); Wird ein neues Ticket in einer Queue gespeichert für die eine Eskalationszeit festgelegt wurde, wird zunächst der positive Wert für die eingestellte Eskalationszeit angezeigt. Die Anzeige bleibt auf den für die Queue eingestellten Wert stehen, wenn das System sich nicht in den in TimeWorkingHours festgelegten Stunden befindet oder wenn aktuell ein in TimeVacationDays bzw. TimeVacationDaysOneTime definierter Tag ist, außerhalb der für das System relevanten Zeiten findet keine Berechnung der Eskalationszeit statt. Befindet sich das System in einem für die Berechnung relevanten Zeitfenster, wird die Eskalationszeit heruntergezählt. Wird der Wert 0 erreicht, eskaliert das Ticket. Im weiteren Verlauf wird der Wert negativ, das Ticket hat die Eskalationszeit überschritten. Bei der nächsten Ausführung des GenericAgent-Jobs für das Versenden der Eskalationsbenachrichtigungen an die Agenten, werden die entsprechenden Mails verschickt, das eskalierte Ticket blockiert die Anzeige der anderen Tickets in der Queue. Auch wenn das eskalierte Ticket gesperrt und bearbeitet wird, wird der angezeigte Wert für die Eskalationszeit immer kleiner, der eigentliche Eskalationszeitpunkt rückt immer weiter in die Vergangenheit. An diesem Verhalten ändert sich nichts, so lange das Ticket sich in einem offenen Status befindet (open, new, pending, usw.). Erst wenn das Ticket geschlossen wird, also sich der Status von offen auf geschlossen ändert (closed), wird auch die Eskalationszeit zurück gesetzt. Wird dasselbe Ticket z. B. durch ein Follow-up wieder in einen offenen Status gebracht, beginnt das Herunterzählen der Eskalationszeit erneut beim für die Queue eingestellten positiven Wert. Tickets können nur eskalieren, wenn folgende Eigenschaften erfüllt sind: Das Ticket befindet sich im Status-Typ "offen" (dazu zählen "neu", "offen", "warten zur Erinnerung", ...). Das Ticket ist nicht von einem Agenten gesperrt ("frei"). In der nachfolgenden Tabelle werden die Eskalationszyklen der bisherigen OTRS Versionen verglichen. Eskalations Eigenschaften 1.2.x 1.3.x 2.0.x 2.1.x 2.2.x Ein Ticket eskaliert... a) wenn für die Queue, in der sich das Ticket befindet, eine Eskalationszeit gesetzt ist. b) Wenn die in den Queue Einstellungen hinterlegte Eskalationszeit abgelaufen ist. c) Wenn das Ticket nicht von einem Agenten gesperrt ist. d) Wenn sich das Ticket in einem "offen" Status befindet. Wenn ein "pending" Status gesetzt ist, wird die Eskalationszeit ausgesetzt. x x x x x Die Eskalationszeit (Startpunkt) wird zurückgesetzt, wenn ein Kunde einen Artikel am Ticket erstellt (z. B. durch Email-FollowUp). Das Ticket muss dabei nicht wiedereröffnet werden. Ist bereits der letzte Artikel von einem Kunden, wird die Eskalationszeit (Startpunkt) nicht zurück gesetzt, da sich hier die Eskalation verzögern würde. x x - x x Die Eskalationszeit (Startpunkt) wird zurückgesetzt, wenn ein Agent einen externen Artikel (z. B. eine Email an einen Kunden oder eine Telefon-Notiz) anlegt. x x - x x Seit OTRS 2.1 ist es möglich, neben einem Ticket-Besitzer auch eine verantwortliche Person für ein Ticket zu definieren. Weiterhin können die Aktivitäten rund um ein Ticket beobachtet werden. Diese beiden Funktionalitäten werden durch das TicketResponsible- und das TicketWatcher-Feature realisiert und erleichtern die Aufgabenverteilung und das Arbeiten innerhalb hirarchischer Teamstrukturen. Das Ticket-Verantwortlichkeits-Feature ermöglicht die volle Bearbeitung eines Tickets durch einen Agenten, welcher das Ticket nicht besitzt. In der Praxis könnte also z. B. ein Agent, der ein Ticket gesperrt hat, die Verantwortlichkeit für das Ticket an einen zweiten Agenten übertragen, der nicht Besitzer des Tickets ist, z. B. damit der zweite Agent eine Anfrage eines Kunden beantworten kann. Nachdem die Anfrage beantwortet wurde, kann der erste Agent die Verantwortlichkeit für das Ticket den zweiten Agent wieder entziehen. Mit Hilfe des Konfigurations Parameters Ticket::Responsible kann das Ticket-Verantwortlichkeits-Feature aktiviert werden. TODO: ticket-zoom-responsible.pmg: Screenshot von TicketZoom mit Schalter für Verantwortlicher einfügen Ein Verantwortlicher für ein Ticket kann festgelegt werden, indem der Inhalt des Tickets aufgerufen und im Menü für die verschiedenen Aktionen für das Ticket der "Verantwortlicher"-Schalter betätigt wird. TODO: ticket-responsible.pmg: TicketResponsible-Bildschirm einfügen Über die Ticket-Verantwortlicher-Maske kann dem neuen verantwortlichen Agenten ebenfalls eine Nachricht übermittelt werden. TODO: responsible-tickets.pmg: Screenshot von Notification über "Watched Tickets" einfügen Die Liste aller Tickets für die ein Agent verantwortlich ist wird über die "Verantwortlicher"-Benachrichtigung erreicht. Diese wird im oberen Bereich der OTRS-Oberfläche eingeblendet, sobald das Ticket-Verantwortlichkeits-Feature aktiviert ist. Sollen innerhalb des Ticket-Systems lediglich bestimmte Tickets z. B. von einem Abteilungsleiter beobachtet und nicht selbst bearbeitet werden, so kann dies seit OTRS 2.1 mit Hilfe des TicketWatcher-Features realisiert werden. Das TicketWatcher-Feature kann mit Hilfe des Konfigurations-Parameters Ticket::Watcher aktiviert werden. Weiterhin können über Ticket::WatcherGroup eine oder mehrere Benutzergruppen festgelegt werden, die die ERlaubnis haben sollen Tickets zu beobachten. TODO: ticket-subscribe.pmg: Screenshots von Ticket-Zoom mit subscribe einfügen Um ein Ticket zu beobachten, muss der Inhalt des Tickets aufgerufen und im Menü für die verschiedenen Aktionen für das Ticket der "Subscribe"-Schalter betätigt werden. TODO: ticket-unsubscribe.pmg: Screenshot von TicketZoom mit unsubscribe-Schalter einfügen Die Beobachtung eines Tickets wird aufgehoben, indem in der Inhaltsanzeige eines Tickets im Menü für die möglichen Aktionen der "Unsubscribe"-Schalter gedrückt wird. TODO: watched-tickets.pmg: Screenshot von Notification über "Watched Tickets" einfügen Die Liste aller zur Beobachtung ausgewählten Tickets wird über die "Watched Tickets"-Benachrichtigung erreicht. Diese wird im oberen Bereich der OTRS-Oberfläche eingeblendet, sobald das TicketWatcher-Feature aktiviert ist. Seit OTRS 2.1 ist es möglich, PDF-Dateien für die Ausgabe von Suchergebnissen, Statistiken und vom Ticketverlauf (Ticket-Inhalt -> Drucken) generieren zu lassen. Prinzipiell werden alle Ausgaben, bei denen die Möglichkeit des Druckens besteht, also dieses Ausgabeformat als Option verfügbar ist, als PDF ausgegeben. Das Feature wird über dem Konfigurationsparameter PDF eingeschaltet, standardmäßig ist es aktiviert. Weiterhin kann mit PDF::LogoFile ein Pfad zu einer Grafik-Datei angegeben werden, die als Logo in jede generierte PDF-Datei eingebunden werden soll. Mit PDF::PageSize lässt sich die Standard-Seitengröße der PDF-Datei einstellen. Schließlich kann mit PDF::MaxPages die maximale Anzahl an Seiten festgelegt werden, die eine PDF-Datei höchstens beinhalten soll. Für die Generieerung von PDF-Dateien müssen die CPAN-Module PDF::API2 und Compress::Zlib installiert werden. Bei vielen Distributionen sind diese als Paket verfügbar und können bequem über den jeweiligen Paketmanager installiert werden, falls dies jedoch nicht möglich ist muss der direkte Weg über CPAN gewählt werden. Das Kapitel "Installation der für OTRS benötigten perl-Module beschreibt wie die Installation der Perl-Module durchzuführen ist. OTRS ist in der Lage, mit verschiedenen Kundendaten (insbesondere Login, E-Mail, Telefon) umzugehen. Diese Informationen können im Agenten-Interface angezeigt und für das Kunden-Interface verwendet werden. Weiterhin werden die Daten für die Authentifizierung der Kunden am System benötigt. Die benutzten/angezeigten Kundendaten sind frei konfigurierbar, es gibt jedoch drei benötigte Optionen die unbedingt vorhanden sein müssen, damit OTRS ordnungsgemäß funktioniert: Benutzer-Login, Benutzer-E-Mail und Benutzer-Kunden-ID Wenn Sie die Kundendaten (z. B. Firma, Name, eMail, ...) in Ihrem Agenten-Interface anzeigen möchten, benutzen Sie die folgenden Konfigurations-Optionen und fügen Sie diese in die Datei Kernel/Config.pm ein. # Ticket::Frontend::CustomerInfo* # (show customer user info on Compose (Phone and Email), Zoom and # Queue view) $Self->{'Ticket::Frontend::CustomerInfoCompose'} = 1; $Self->{'Ticket::Frontend::CustomerInfoZoom'} = 1; $Self->{'Ticket::Frontend::CustomerInfoQueue'} = 0; Es existieren zwei Kundenbenutzer Back-ends, DB und LDAP. Falls Sie bereits ein Kundenverzeichnis (z. B. SAP, ...) haben, ist es natürlich möglich, dafür ein eigenes Back-end zu schreiben. Dies ist ein Beispiel für die Konfiguration eines Back-ends, welches die Kundendaten in der normalen OTRS Datenbank verwaltet. # CustomerUser # (customer user database backend and settings) $Self->{CustomerUser} = { Name => 'Datenbank Quelle', Module => 'Kernel::System::CustomerUser::DB', Params => { # if you want to use an external database, add the # required settings # DSN => 'DBI:odbc:yourdsn', # DSN => 'DBI:mysql:database=customerdb;host=customerdbhost', # User => '', # Password => '', Table => 'customer_user', }, # customer uniq id CustomerKey => 'login', # customer # CustomerID => 'customer_id', CustomerValid => 'valid_id', CustomerUserListFields => ['first_name', 'last_name', 'email'], CustomerUserSearchFields => ['login', 'last_name', 'customer_id'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 250, CustomerUserPostMasterSearchFields => ['email'], CustomerUserNameFields => ['salutation','first_name','last_name'], CustomerUserEmailUniqCheck => 1, # # show now own tickets in customer panel, CompanyTickets # CustomerUserExcludePrimaryCustomerID => 0, # # generate auto logins # AutoLoginCreation => 0, # AutoLoginCreationPrefix => 'auto', # # admin can change customer preferences # AdminSetPreferences => 1, # # just a read only source # ReadOnly => 1, Map => [ # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [ 'UserSalutation', 'Salutation', 'salutation', 1, 0, 'var', '', 0 ], [ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ], [ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ], [ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ], [ 'UserPassword', 'Password', 'pw', 0, 1, 'var', '', 0 ], [ 'UserEmail', 'Email', 'email', 0, 1, 'var', '', 0 ], # [ 'UserEmail', 'Email', 'email', 1, 1, # 'var','$Env{"CGIHandle"}?Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=$Data{"ArticleID"}', 0 ], [ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ], # [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ], [ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ], [ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ], ], # default selections Selections => { UserSalutation => { 'Mr.' => 'Mr.', 'Mrs.' => 'Mrs.', }, }, }; Falls Sie die Kundendaten anpassen möchten, ändern Sie in der Datenbank die Tabellenspalten oder fügen Sie weitere hinzu (im folgenden Beispiel wird ein Feld für die Telefonnummer hinzugefügt) linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 116 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD phone VARCHAR (250); Query OK, 1 rows affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~# Danach fügen Sie Ihre eigenen Spalten dem MAP Array in der Datei Kernel/Config.pm hinzu: # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [...] [ 'UserPhone', 'Phone', 'phone', 0, 1, 'var', '', 0 ], Natürlich können Sie all diese Kundeninformationen dann auch über das Admin-Interface bzw. die Kundenverwaltung pflegen. Es ist möglich, einem Kunden mehr als nur eine Kundennummer zuzuweisen. Dies kann z. B. dann sinnvoll sein, wenn ein Kunde auf Tickets anderer Kunden zugreifen muss, z. B. der Abteilungsleiter auf die Tickets der Mitarbeiter seiner Abteilung. Hat ein Kunde Zugriff auf Tickets anderer Kunden, verwendet man in OTRS das sog. Firmen Ticket Feature. Im Kunden-Interface können diese Tickets über den "Firmen Ticket" Link eingesehen werden. Um Firmen Tickets zu verwenden, muss die customer_user Tabelle in der OTRS Datenbank um eine Spalte erweitert werden, in die später die Kundennummern eingetragen werden, auf die ein Kunde zusätzlich zu den eigenen Tickets Zugriff haben soll: linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 124 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD customer_ids VARCHAR (250); Query OK, 1 rows affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~# Danach fügen Sie die neue Spalte dem MAP Array in der Datei Kernel/Config.pm hinzu: # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [...] [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ], Die Spalte für die Multi-Kundennummern kann ab nun über das Admin-Interface bzw. über die Kundenverwaltung gepflegt werden. Um nun den Zugriff für einen Kunden auf die Tickets anderer Kunden zu ermöglichen, tragen Sie in die neue Spalte die IDs der Kunden ein, auf deren Tickets der Zugriff ermöglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon. Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von Firmen Tickets über das Kunden-Interface Zugriff auf die Tickets von B und C haben, B und C sollen jedoch jeweils nur ihre eigenen Tickets einsehen und bearbeiten können. Um dieses Setup zu realisieren, ändern Sie wie oben beschrieben die customer_user Tabelle in der OTRS Datenbank und das Mapping in Kernel/Config.pm. Anschließend laden Sie über die Kundenverwaltung die Einstellungen des Kunden A und tragen bei "Kundennummern" die Werte "B;C;" ein. Falls Sie ein existierendes LDAP Verzeichnis mit Ihren Kundenbenutzern haben, können Sie dieses auch mit OTRS nutzen. Dies ist ein Beispiel für ein Kunden Back-end, welches seine Daten aus einem LDAP Verzeichnis bezieht. # CustomerUser # (customer user ldap backend and settings) $Self->{CustomerUser} = { Name => 'LDAP Datenquelle', Module => 'Kernel::System::CustomerUser::LDAP', Params => { # ldap host Host => 'bay.csuhayward.edu', # ldap base dn BaseDN => 'ou=seas,o=csuh', # search scope (one|sub) SSCOPE => 'sub', # # The following is valid but would only be necessary if the # # anonymous user does NOT have permission to read from the LDAP tree UserDN => '', UserPw => '', # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' AlwaysFilter => '', # if your frontend is e. g. iso-8859-1 and the charset of your # ldap server is utf-8, use this options (if not, ignore it) # SourceCharset => 'utf-8', # DestCharset => 'iso-8859-1', # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) Params => { port => 389, timeout => 120, async => 0, version => 3, }, }, # customer uniq id CustomerKey => 'uid', # customer # CustomerID => 'mail', CustomerUserListFields => ['cn', 'mail'], CustomerUserSearchFields => ['uid', 'cn', 'mail'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 250, CustomerUserPostMasterSearchFields => ['mail'], CustomerUserNameFields => ['givenname', 'sn'], # show now own tickets in customer panel, CompanyTickets CustomerUserExcludePrimaryCustomerID => 0, # add a ldap filter for valid users (expert setting) # CustomerUserValidFilter => '(!(description=gesperrt))', # admin can't change customer preferences AdminSetPreferences => 0, Map => [ # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [ 'UserSalutation', 'Title', 'title', 1, 0, 'var', '', 0 ], [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ], [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ], [ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ], [ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ], [ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ], # [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ], [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ], [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ], [ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ], ], }; Falls Sie in Ihrem LDAP Verzeichnis weitere Informationen zu Ihren Kunden gespeichert haben und mit OTRS darauf zugreifen möchten, erweitern Sie das MAP Array in Kernel/Config.pm bzw. entfernen nicht gewünschte Einträge: # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [...] [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ], Es ist möglich, einem Kunden mehr als nur eine Kundennummer zuzuweisen. Dies kann z. B. dann sinnvoll sein, wenn ein Kunde auf Tickets anderer Kunden zugreifen muss, z. B. der Abteilungsleiter auf die Tickets der Mitarbeiter seiner Abteilung. Hat ein Kunde Zugriff auf Tickets anderer Kunden, verwendet man in OTRS das sog. Firmen Ticket Feature. Im Kunden-Interface können diese Tickets über den "Firmen Ticket" Link eingesehen werden. Um Firmen Tickets zu verwenden, muss das LDAP Verzeichnis um ein Feld erweitert werden, in das die Kundennummern eingetragen werden können, auf die später ein Kunde zusätzlich zu den eigenen Tickets Zugriff haben soll, z. B. um das Feld CustomerIDs. Danach fügen Sie die neue Spalte dem MAP Array in der Datei Kernel/Config.pm hinzu: # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [...] [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ], Das Feld für die Multi-Kundennummern muss direkt im LDAP Verzeichnis gepflegt und kann von OTRS aus nicht direkt verwaltet werden. Um nun den Zugriff für einen Kunden auf die Tickets anderer Kunden zu ermöglichen, tragen Sie innerhalb des LDAP Verzeichnisses in das neue Feld die IDs der Kunden ein, auf deren Tickets der Zugriff ermöglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon. Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von Firmen Tickets über das Kunden-Interface Zugriff auf die Tickets von B und C haben, B und C sollen jedoch jeweils nur ihre eigenen Tickets einsehen und bearbeiten können. Um dieses Setup zu realisieren, ändern Sie wie oben beschrieben das LDAP Verzeichnis und das Mapping in Kernel/Config.pm. Anschließend tragen Sie im LDAP Verzeichnis innerhalb der Einstellungen für den Kunden A für CustomerIDs die Werte "B;C;" ein. Soll mehr als nur ein Back-end mit verschiedenen Kundendaten verwendet werden (z. B. gleichzeitig DB und LDAP), so ist dies ebenfalls mit OTRS möglich. In einem solchen Fall muss der CustomerUser Parameter für jedes Back-end um eine Nummer erweitert werden, z. B. "CustomerUser1", "CustomerUser2", usw. In der folgenden KOnfiguration verwendet OTRS gleichzeitig ein DB und ein LDAP Kunden Back-end. # 1. Customer user backend: DB # (customer user database backend and settings) $Self->{CustomerUser1} = { Name => 'Datenbank Quelle', Module => 'Kernel::System::CustomerUser::DB', Params => { # if you want to use an external database, add the # required settings # DSN => 'DBI:odbc:yourdsn', # DSN => 'DBI:mysql:database=customerdb;host=customerdbhost', # User => '', # Password => '', Table => 'customer_user', }, # customer uniq id CustomerKey = 'login', # customer # CustomerID = 'customer_id', CustomerValid = 'valid_id', CustomerUserListFields => ['first_name', 'last_name', 'email'], CustomerUserSearchFields => ['login', 'last_name', 'customer_id'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 250, CustomerUserPostMasterSearchFields => ['email'], CustomerUserNameFields => ['salutation','first_name','last_name'], CustomerUserEmailUniqCheck => 1, # # show now own tickets in customer panel, CompanyTickets # CustomerUserExcludePrimaryCustomerID => 0, # # generate auto logins # AutoLoginCreation => 0, # AutoLoginCreationPrefix => 'auto', # # admin can change customer preferences # AdminSetPreferences => 1, # # just a read only source # ReadOnly => 1, Map => [ # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [ 'UserSalutation', 'Salutation', 'salutation', 1, 0, 'var', '', 0 ], [ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ], [ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ], [ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ], [ 'UserPassword', 'Password', 'pw', 0, 1, 'var', '', 0 ], [ 'UserEmail', 'Email', 'email', 0, 1, 'var', '', 0 ], # [ 'UserEmail', 'Email', 'email', 1, 1, # 'var','$Env{"CGIHandle"}?Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=$Data{"ArticleID"}', 0 ], [ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ], # [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ], [ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ], [ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ], ], # default selections Selections => { UserSalutation => { 'Mr.' => 'Mr.', 'Mrs.' => 'Mrs.', }, }, }; # 2. Customer user backend: LDAP # (customer user ldap backend and settings) $Self->{CustomerUser2} = { Name => 'LDAP Datenquelle', Module => 'Kernel::System::CustomerUser::LDAP', Params => { # ldap host Host => 'bay.csuhayward.edu', # ldap base dn BaseDN => 'ou=seas,o=csuh', # search scope (one|sub) SSCOPE => 'sub', # # The following is valid but would only be necessary if the # # anonymous user does NOT have permission to read from the LDAP tree UserDN => '', UserPw => '', # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' AlwaysFilter => '', # if your frontend is e. g. iso-8859-1 and the charset of your # ldap server is utf-8, use this options (if not, ignore it) # SourceCharset => 'utf-8', # DestCharset => 'iso-8859-1', # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) Params => { port => 389, timeout => 120, async => 0, version => 3, }, }, # customer uniq id CustomerKey => 'uid', # customer # CustomerID => 'mail', CustomerUserListFields => ['cn', 'mail'], CustomerUserSearchFields => ['uid', 'cn', 'mail'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 250, CustomerUserPostMasterSearchFields => ['mail'], CustomerUserNameFields => ['givenname', 'sn'], # show now own tickets in customer panel, CompanyTickets CustomerUserExcludePrimaryCustomerID => 0, # add a ldap filter for valid users (expert setting) # CustomerUserValidFilter => '(!(description=gesperrt))', # admin can't change customer preferences AdminSetPreferences => 0, Map => [ # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [ 'UserSalutation', 'Title', 'title', 1, 0, 'var', '', 0 ], [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var', '', 0 ], [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var', '', 0 ], [ 'UserLogin', 'Username', 'uid', 1, 1, 'var', '', 0 ], [ 'UserEmail', 'Email', 'mail', 1, 1, 'var', '', 0 ], [ 'UserCustomerID', 'CustomerID', 'mail', 0, 1, 'var', '', 0 ], # [ 'UserCustomerIDs', 'CustomerIDs', 'second_customer_ids', 1, 0, 'var', '', 0 ], [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '', 0 ], [ 'UserAddress', 'Address', 'postaladdress', 1, 0, 'var', '', 0 ], [ 'UserComment', 'Comment', 'description', 1, 0, 'var', '', 0 ], ], }; Es können bis zu 10 Kunden Back-ends gleichzeitig eingebunden werden. Über die Kundenverwaltung in OTRS ist der Zugriff auf die verschiedenen Back-ends möglich. OTRS bietet die Möglichkeit Agenten und Kunden über verschiedene Back-ends zu authentifizieren. Die verschiedenen Konfigurationsmöglichkeiten werden in den folgenden Abschnitten näher beschrieben. Das Back-end für die Authentifizierung von Agenten, welches OTRS standardmäßig verwendet, ist die OTRS-Datenbank. Die Agenten können innerhalb des Admin-Bereiches in der Benutzerverwaltung angelegt und bearbeitet werden. $Self->{'AuthModule'} = 'Kernel::System::Auth::DB'; Falls ein LDAP Verzeichnis mit Ihren Agenten-Benutzerdaten verfügbar ist, können Sie das LDAP Modul für die Authentifizierung Ihrer Agenten nutzen. Dieses Modul greift nur lesend auf die Daten im LDAP Verzeichnis zu, d.h. die Daten können nicht mit OTRS bearbeitet werden, es können also keine Agenten mit Hilfe der Benutzerverwaltung von OTRS angelegt oder bearbeitet werden. # This is an example configuration for an LDAP auth. backend. # (take care that Net::LDAP is installed!) $Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP'; $Self->{'AuthModule::LDAP::Host'} = 'ldap.example.com'; $Self->{'AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com'; $Self->{'AuthModule::LDAP::UID'} = 'uid'; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group xyz to use otrs) $Self->{'AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com'; $Self->{'AuthModule::LDAP::AccessAttr'} = 'memberUid'; # for ldap posixGroups objectclass (just uid) # $Self->{'AuthModule::LDAP::UserAttr'} = 'UID'; # for non ldap posixGroups objectclass (with full user dn) # $Self->{'AuthModule::LDAP::UserAttr'} = 'DN'; # The following is valid but would only be necessary if the # anonymous user do NOT have permission to read from the LDAP tree $Self->{'AuthModule::LDAP::SearchUserDN'} = ''; $Self->{'AuthModule::LDAP::SearchUserPw'} = ''; # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' $Self->{'AuthModule::LDAP::AlwaysFilter'} = ''; # in case you want to add a suffix to each login name, then # you can use this option. e. g. user just want to use user but # in your ldap directory exists user@domain. # $Self->{'AuthModule::LDAP::UserSuffix'} = '@domain.com'; # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, }; Mit den folgenden Konfigurationsparametern können die Benutzerdaten der Agenten aus dem LDAP in die lokale OTRS Datenbank synchronisiert werden. Dies reduziert die Zugriffe auf ihr LDAP Verzeichnis, entlastet den Server mit den LDAP Daten und beschleunigt die Anmeldung an OTRS. Die Synchronisierung der Daten findet bei der ersten Anmeldung des Agenten statt, trotz der synchronisierten Daten bleibt ihr LDAP Verzeichnis die letzte Instanz bei der Anmeldung. D.h. wird ein User im LDAP Verzeichnis gelöscht oder deaktiviert, klappt die Anmeldung an OTRS nicht. Ebenfalls müssen die Daten für einen Agenten weiterhin direkt im LDAP Verzeichnis gepflegt werden. # UserSyncLDAPMap # (map if agent should create/synced from LDAP to DB after login) $Self->{UserSyncLDAPMap} = { # DB -> LDAP Firstname => 'givenName', Lastname => 'sn', Email => 'mail', }; # UserSyncLDAPGroups # (If "LDAP" was selected for AuthModule, you can specify # initial user groups for first login.) $Self->{UserSyncLDAPGroups} = [ 'users', ]; # UserTable $Self->{DatabaseUserTable} = 'system_user'; $Self->{DatabaseUserTableUserID} = 'id'; $Self->{DatabaseUserTableUserPW} = 'pw'; $Self->{DatabaseUserTableUser} = 'login'; Falls Sie eine "single sign on"-Lösung für Ihre Agenten implementieren möchten, benutzen Sie http basic authentication (für alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth Modul (kein OTRS-Login mehr für Kunden benötigt!). # This is an example configuration for an apache ($ENV{REMOTE_USER}) # auth. backend. Use it if you want to have a singe login through # apache http-basic-auth $Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth'; # Note: # # If you use this module, you should use as fallback # the following config settings if user isn't login through # apache ($ENV{REMOTE_USER}) $Self->{LoginURL} = 'http://host.example.com/not-authorised-for-otrs.html'; $Self->{LogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html'; Mit den folgenden Einstellungen kann die Authentifizierung von Agenten gegen einen Radius-Server realisiert werden. # This is example configuration to auth. agents against a radius server $Self->{'AuthModule'} = 'Kernel::System::Auth::Radius'; $Self->{'AuthModule::Radius::Host'} = 'radiushost'; $Self->{'AuthModule::Radius::Password'} = 'radiussecret'; Das Back-end für die Authentifizierung von Kunden, welches OTRS standardmäßig verwendet, ist die OTRS-Datenbank. Die Kundendaten können über das Interface zur Verwaltung von Kunden angelegt und bearbeitet werden. # This is the auth. module againt the otrs db $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB'; $Self->{'Customer::AuthModule::DB::Table'} = 'customer_user'; $Self->{'Customer::AuthModule::DB::CustomerKey'} = 'login'; $Self->{'Customer::AuthModule::DB::CustomerPassword'} = 'pw'; # $Self->{'Customer::AuthModule::DB::DSN'} = "DBI:mysql:database=customerdb;host=customerdbhost"; # $Self->{'Customer::AuthModule::DB::User'} = "some_user"; # $Self->{'Customer::AuthModule::DB::Password'} = "some_password"; Falls ein LDAP Verzeichnis mit Ihren Kundenbenutzern verfügbar ist, können Sie das LDAP Modul für die Authentifizierung Ihrer Kunden nutzen. Dieses Modul greift nur lesend auf die Daten im LDAP Verzeichnis zu, d.h. die Daten können nicht mit OTRS bearbeitet werden, es können also keine Kunden mit Hilfe der Kundenverwaltung von OTRS angelegt oder bearbeitet werden. # This is an example configuration for an LDAP auth. backend. # (take care that Net::LDAP is installed!) $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LDAP'; $Self->{'Customer::AuthModule::LDAP::Host'} = 'ldap.example.com'; $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com'; $Self->{'Customer::AuthModule::LDAP::UID'} = 'uid'; # Check if the user is allowed to auth in a posixGroup # (e. g. user needs to be in a group xyz to use otrs) $Self->{'Customer::AuthModule::LDAP::GroupDN'} = 'cn=otrsallow,ou=posixGroups,dc=example,dc=com'; $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'memberUid'; # for ldap posixGroups objectclass (just uid) $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'UID'; # for non ldap posixGroups objectclass (full user dn) # $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN'; # The following is valid but would only be necessary if the # anonymous user do NOT have permission to read from the LDAP tree $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} = ''; $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = ''; # in case you want to add always one filter to each ldap query, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)' $Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = ''; # in case you want to add a suffix to each customer login name, then # you can use this option. e. g. user just want to use user but # in your ldap directory exists user@domain. # $Self->{'Customer::AuthModule::LDAP::UserSuffix'} = '@domain.com'; # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP) $Self->{'Customer::AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, }; Falls Sie eine "single sign on"-Lösung für Ihre Kunden implementieren möchten, benutzen Sie HTTPBasic Authentication (für alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth Modul (kein OTRS-Login mehr benötigt!). # This is an example configuration for an apache ($ENV{REMOTE_USER}) # auth. backend. Use it if you want to have a singe login through # apache http-basic-auth $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth'; # Note: # If you use this module, you should use the following # config settings as fallback, if user isn't login through # apache ($ENV{REMOTE_USER}) $Self->{CustomerPanelLoginURL} = 'http://host.example.com/not-authorised-for-otrs.html'; $Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-for-using-otrs.html'; Mit den folgenden Einstellungen kann die Authentifizierung von Kunden gegen einen Radius-Server realisiert werden. # This is a example configuration to auth. customer against a radius server $Self->{'Customer::AuthModule'} = 'Kernel::System::Auth::Radius'; $Self->{'Customer::AuthModule::Radius::Host'} = 'radiushost'; $Self->{'Customer::AuthModule::Radius::Password'} = 'radiussecret'; Es ist möglich, die Kunden-Selbstanmeldung für neue Kunden über "customer.pl" anzupassen. Somit können Sie mehr optionale oder benötigte Felder (z. B. Adresse, Ort, Telefonnummer) hinzufügen. In folgenden Beispiel wird ein benötigtes Feld für die Telefonnummer hinzugefügt. Damit im Webinterface das zusätzliche Feld für die Telefonnummer angezeigt wird, muss die zuständige dtl-Datei angepasst werden. Editieren Sie Kernel/Output/HTML/Standard/CustomerLogin.dtl und fügen Sie in Zeile 128 das gewünschte Feld hinzu. [...] <tr> <td>$Text{"Phonenumber"}: </td> <td><input type="text" name="Phone" value="$QData{"UserPhone"}" size="20" maxlength="50"></td> </tr> [...] Zusätzlich muss das Kunden-Mapping um den Eintrag für die Telefonnummer erweitert werden. Dazu werden zuerst die Einstellungen für "CustomerUser" aus der Datei Kernel/Config/Defaults.pm in die Datei Kernel/Config.pm übertragen. Anschließend wird das Kunden-Mapping umdas Phone-Feld erweitert. # CustomerUser # (customer user database backend and settings) $Self->{CustomerUser} = { Name => 'Database Backend', Module => 'Kernel::System::CustomerUser::DB', Params => { # if you want to use an external database, add the # required settings # DSN => 'DBI:odbc:yourdsn', # DSN => 'DBI:mysql:database=customerdb;host=customerdbhost', # User => '', # Password => '', Table => 'customer_user', }, # customer uniq id CustomerKey => 'login', # customer # CustomerID => 'customer_id', CustomerValid => 'valid_id', CustomerUserListFields => ['first_name', 'last_name', 'email'], # CustomerUserListFields => ['login', 'first_name', 'last_name', 'customer_id', 'email'], CustomerUserSearchFields => ['login', 'last_name', 'customer_id'], CustomerUserSearchPrefix => '', CustomerUserSearchSuffix => '*', CustomerUserSearchListLimit => 250, CustomerUserPostMasterSearchFields => ['email'], CustomerUserNameFields => ['salutation', 'first_name', 'last_name'], CustomerUserEmailUniqCheck => 1, # # show now own tickets in customer panel, CompanyTickets # CustomerUserExcludePrimaryCustomerID => 0, # # generate auto logins # AutoLoginCreation => 0, # AutoLoginCreationPrefix => 'auto', # # admin can change customer preferences # AdminSetPreferences => 1, # # just a read only source # ReadOnly => 1, Map => [ # note: Login, Email and CustomerID needed! # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly [ 'UserSalutation', 'Salutation', 'salutation', 1, 0, 'var', '', 0 ], [ 'UserFirstname', 'Firstname', 'first_name', 1, 1, 'var', '', 0 ], [ 'UserLastname', 'Lastname', 'last_name', 1, 1, 'var', '', 0 ], [ 'UserLogin', 'Username', 'login', 1, 1, 'var', '', 0 ], [ 'UserPassword', 'Password', 'pw', 0, 1, 'var', '', 0 ], [ 'UserEmail', 'Email', 'email', 0, 1, 'var', '', 0 ], # [ 'UserEmail', 'Email', 'email', 1, 1, 'var','$Env{"CGIHandle"}?Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=$Data{"ArticleID"}', 0 ], [ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ], # [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ], [ 'UserComment', 'Comment', 'comments', 1, 0, 'var', '', 0 ], [ 'UserPhone', 'Phone', 'phone', 1, 0, 'var', '', 0 ], [ 'ValidID', 'Valid', 'valid_id', 0, 1, 'int', '', 0 ], ], # default selections Selections => { UserSalutation => { 'Mr.' => 'Mr.', 'Mrs.' => 'Mrs.', }, }, }; Abschließend muss eine neue Spalte zur "customer_user" Tabelle in der OTRS Datenbank hinzugefügt werden, in der die Telefonnummer gespeichert werden kann. linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 6 to server version: 5.0.18-Debian_7-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> ALTER TABLE customer_user ADD phone VARCHAR (200); Query OK, 3 rows affected (0.01 sec) Records: 3 Duplicates: 0 Warnings: 0 mysql> quit Bye linux:~# Alle benötigten Anpassungen sind durchgeführt und das Feld für die Telefonnummer sollte nun im Kunden-Interface (customer.pl) angezeigt und verwendet werden können. Wird mod_perl eingesetzt, muss der Webserver neu gestartet werden um die Änderungen zu übernehmen. OTRS erlaubt es Ihnen, die Ticket-Status zu verändern oder neue Status hinzuzufügen. Hierbei gibt es zwei wichtige Optionen. Zum Einen den Namen des Status "state-name" und zum Zweiten den Type des Status "state-type". Die standardmäßig voreingestellten Status lauten: 'neu', 'offen', 'erfolgreich geschlossen', 'erfolglos geschlossen', 'merged', 'entfernt', 'warten auf erfolgreich schließen', 'warten auf erfolglos schließen' und 'warten zur Erinnerung'. Jeder Status besteht aus einem Namen ("state-name") und einem Typen ("state-type"). Der Name ist frei wählbar und kann über das Admin-Interface von OTRS angepasst werden, die Statustypen müssen direkt in der Datenbank geändert werden. Im Admin-Interface können Sie innerhalb der Einstellungen für "Status" neue Status für die vorhandenen Statustypen hinzufügen oder ändern. Beachten Sie, dass Sie bei Änderungen am Status "neu - new" auch die entsprechenden Änderungen in der Konfigurationsdatei Kernel/Config.pm bzw. mit Hilfe des grafischen Konfigurations-Front-End vornehmen müssen. [...] # PostmasterDefaultState # (The default state of new tickets.) [default: new] $Self->{PostmasterDefaultState} = 'new'; # CustomerDefaultState # (default state of new customer tickets) $Self->{CustomerDefaultState} = 'new'; [...] Auch bei Änderungen am Status "offen - open" sind Änderungen in Kernel/Config.pm bzw. mit Hilfe des grafischen Konfigurations-Front-End von Nöten! [...] # default phone new state $Self->{'Ticket::Frontend::PhoneNextState'} = 'open'; # PostmasterFollowUpState # (The state if a ticket got a follow up.) [default: open] $Self->{PostmasterFollowUpState} = 'open'; [...] Möchten Sie einen neuen Statustyp hinzufügen, müssen Sie zuerst die ticket_status-type-Tabelle in der OTRS Datenbank mit Hilfe eines entsprechenden Datenbankclient anpassen. linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 23 to server version: 5.0.16-Debian_1-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> insert into ticket_state_type (name,comments) values ('own','Own state type'); Query OK, 1 row affected (0.00 sec) mysql> quit Bye linux:~# Nun können Sie über das Admin-Interface innerhalb der Einstellungen für "Status" neue Ticketstatus hinzufügen, die als Statustyp "own" enthalten. Anschließend müssen Sie noch in Kernel/Config.pm oder über das grafische Konfigurations-Front-end einstellen, an welchen Stellen im System der neue Status verwendet werden soll, z.B.: [...] # Ticket::DefaultNextMoveStateType # default move next state $Self->{'Ticket::DefaultNextMoveStateType'} = ['open', 'closed']; # next possible states after phone $Self->{'Ticket::PhoneDefaultNextStateType'} = ['open', 'pending auto', 'pending reminder', 'closed']; # default next state $Self->{'Ticket::Frontend::PhoneNextState'} = 'closed successful'; # default next state [default: open] $Self->{'Ticket::Frontend::PhoneNewNextState'} = 'open'; # next possible states after email $Self->{'Ticket::EmailDefaultNextStateType'} = ['own-state', 'open', 'pending auto', 'pending reminder', 'closed']; # default next state $Self->{'Ticket::Frontend::EmailNewNextState'} = 'open'; # (default note next state) $Self->{'Ticket::DefaultNextNoteStateType'} = ['new', 'open', 'closed']; # Ticket::DefaultNextOwnerStateType # (default note next state) $Self->{'Ticket::DefaultNextOwnerStateType'} = ['open', 'closed']; # default compose next state $Self->{'Ticket::DefaultNextComposeType'} = 'open'; # next possible states for compose message $Self->{'Ticket::DefaultNextComposeStateType'} = ['open', 'closed', 'pending auto', 'pending reminder']; # default bounce next state $Self->{'Ticket::Frontend::BounceState'} = 'closed successful'; # next possible states for bounce message $Self->{'Ticket::DefaultNextBounceStateType'} = ['open', 'closed']; # next possible states for forward message $Self->{'Ticket::DefaultNextForwardStateType'} = ['open', 'closed']; # Ticket::ViewableStateType # (see http://yourhost/otrs/index.pl?Action=AdminState -> StateType) $Self->{'Ticket::ViewableStateType'} = ['new', 'open', 'pending reminder', 'pending auto']; # Ticket::UnlockStateType # (Tickets which can be unlocked by bin/UnlockTickets.pl # (see http://yourhost/otrs/index.pl?Action=AdminState -> StateType) $Self->{'Ticket::UnlockStateType'} = ['open', 'new']; [...] Fügen Sie einfach bei den Konfigurationsparametern, bei denen Ihr neuer Statustyp mit aufgeführt werden soll, Ihren neuen Statustyp mit hinzu. Wenn Sie die Ticket-Priorität anpassen / ändern möchten, arbeiten Sie bitte die nächsten Schritte ab. Derzeit gibt es hierzu leider keine Maske im Web-Interface. Verbinden Sie sich mit Hilfe eines MySQL-Clients mit Ihrem MySQL-Server und wählen Sie die OTRS-Datenbank aus: linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 10 to server version: 5.0.18-Debian_4-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> USE otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> So erhalten Sie die aktuellen Prioritäten: mysql> SELECT id,name FROM ticket_priority; +----+-------------+ | id | name | +----+-------------+ | 1 | 1 very low | | 2 | 2 low | | 3 | 3 normal | | 4 | 4 high | | 5 | 5 very high | +----+-------------+ 5 rows in set (0.00 sec) mysql> Das Attribut "id" bestimmt die Reihenfolge der Prioritäten. => 1 entspricht dem Minimum und 5 (oder höher) repräsentiert das Maximum. Die Nummer im Namen der Priorität wird für die Umsetzung der korrekten Reihenfolge innerhalb der Prioritäten verwendet. Anpassen/Ändern der Prioritäten via SQL. Z.B.: mysql> UPDATE ticket_priority SET name = '3 default' WHERE id = 3; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> Wenn Sie diesen SQL-Befehl ausführen, wird die Priorität "3 normal" in Zukunft "3 default" lauten. Beachten Sie bitte, dass Sie die Änderungen bezüglich der Priorität auch in der Konfigurationsdatei (Kernel/Config.pm) oder über das grafische Konfigurations-Frond-End nachpflegen müssen. [...] # PostmasterDefaultPriority # (The default priority of new tickets.) [default: '3 normal'] $Self->{PostmasterDefaultPriority} = '3 default'; [...] # Ticket::Frontend::EmailPriority # default priority for email tickets [default: 3 normal] $Self->{'Ticket::Frontend::AgentTicketEmail'}->{'Priority'} = '3 default'; [...] # default phone priority [default: 3 normal] $Self->{'Ticket::Frontend::AgentTicketPhone'}->{'Priority'} = '3 default'; [...] # CustomerDefaultPriority # (default priority of new customer tickets) $Self->{'Ticket::Frontend::CustomerTicketMessage'}->{'PriorityDefault'} = '3 default'; [...] Wenn Sie eine neue Priorität hinzufügen möchten, passen Sie die ticket_priority-Tabelle in der OTRS Datenbank entsprechend an. Achten Sie darauf, dass Sie die ID und die Nummer im Namen der Priorität entsprechend der Dringlichkeit vergeben. Für OTRS können verschiedene Themes angelegt werden, also verschiedene Layouts zur Gestaltung der Web-Oberfläche. Dazu müssen Sie die vorhandenen Templates ändern und Ihren Wünschen entsprechend anpassen. Mehr Informationen über die Syntax und den Aufbau von Templates finden Sie im Entwickler-Handbuch auf http://doc.otrs.org innerhalb des Kapitels zu den Templates . Um ein neues Theme namens "Company" anzulegen, gehen sie bitte nach folgendem Schema vor: Erstellen Sie das Verzeichnis Kernel/Output/HTML/Company und kopieren Sie die Dateien, die Sie für das Company-Theme anpassen möchten, aus Kernel/Output/HTML/Standard in das neu erstellte Directory. Passen Sie die Dateien im Verzeichnis Kernel/Output/HTML/Company Ihren Wünschen entsprechend an. Um das neue Theme OTRS bekannt zu machen, müssen Sie die Datenbank händisch ändern. Gehen Sie hier zu mit MySQL folgendermaßen vor: linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 26 to server version: 5.0.22-Debian_2-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> INSERT INTO theme -> (theme, valid_id, create_time, create_by, change_time, change_by) -> VALUES -> ('Company', 1, current_timestamp, 1, current_timestamp, 1); mysql> Ab nun sollten sie das neue Theme nutzen und über Ihre persönlichen Einstellungen aktivieren können. Nehmen Sie keine Änderungen an den Theme-Dateien vor, die mit OTRS installiert wurden. Kopieren Sie vielmehr die Dateien des Standard-Themes und führen Sie die zuvor erklärten Schritte durch, um ein eigenes Theme zu erstellen, das bei einem Update nicht überschrieben wird. Das OTRS Webfrontend unterstützt verschiedene Sprachen. Die Übersetzungen befinden sich in den Dateien, die unter Kernel/Language/*.pm zu finden sind. Wie der Lokalisationsmechanismus des OTRS Frameworks arbeitet und welche Möglichkeiten er bietet, entnehmen Siie bitte dem Kapitel "Language Translations" aus dem Developer Handbuch auf http://doc.otrs.org . Dieses Kapitel beschreibt, wie eigene Übersetzungen eingepflegt und komplett neue Sprachen hinzugefügt werden können. In OTRS können ausgehende E-Mails mit Hilfe von PGP signiert oder verschlüsselt werden. Ebenfalls ist es möglich verschlüsselte Nachrichten zu entschlüsseln. Die Ver- und Entschlüsselung mit PGP wird mit Hilfe des GPL-Werkzeugs GnuPG vorgenommen. Zur Einrichtung sind die folgenden Schritte notwendig: Erste Aufgabe ist es, das entsprechende GnuPG-Software-Paket zu installieren, welches bei den meisten Linux-Distributionen mitgeliefert wird. Dies sollte mit Hilfe des jeweiligen Paketmanagers leicht durchgeführt werden können. Im zweiten Schritt muss das soeben installierte GnuPG zur Benutzung für OTRS konfiguriert werden. Dies geschieht auf der Kommandozeilenebene durch einen Aufruf von GnuPG, der die notwendigen Verzeichnisse anlegt und den privaten Schlüssel erzeugt. Der Aufruf muss als otrs-Benutzer (bzw. als der Benutzer, mit dessen Rechten das Ticket-System läuft) durchgeführt werden. linux:~# su otrs linux:/root$ cd linux:~$ pwd /opt/otrs linux:~$ gpg --gen-key gpg (GnuPG) 1.4.2; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. gpg: directory `/opt/otrs/.gnupg' created gpg: new configuration file `/opt/otrs/.gnupg/gpg.conf' created gpg: WARNING: options in `/opt/otrs/.gnupg/gpg.conf' are not yet active during t his run gpg: keyring `/opt/otrs/.gnupg/secring.gpg' created gpg: keyring `/opt/otrs/.gnupg/pubring.gpg' created Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: Ticket System Email address: support@example.com Comment: Private PGP Key for the ticket system with address support@example.com You selected this USER-ID: "Ticket System (Private PGP Key for the ticket system with address support@examp le.com) <support@example.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. Passphrase: secret Repeat passphrase: secret We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++.+++++++++++++++++++++++++....+++++.+++++...+++++++++++++++++++++++++. +++++++++++++++++++++++++.+++++.+++++.+++++++++++++++++++++++++>++++++++++>+++++ .......>+++++<+++++................................+++++ Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 280 more bytes) ++++++++++.+++++..++++++++++..+++++....++++++++++++++++++++.+++++++++++++++.++++ ++++++++++++++++++++++++++.++++++++++.+++++++++++++++.++++++++++.+++++++++++++++ ..+++++>.+++++....>+++++........................................................ ...........................................................>+++++<+++++......... .............+++++^^^ gpg: /opt/otrs/.gnupg/trustdb.gpg: trustdb created gpg: key 7245A970 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024D/7245A970 2006-02-03 Key fingerprint = 2ED5 BC36 D2B6 B055 7EE1 5833 1D7B F967 7245 A970 uid Ticket System (Private pgp key for ticket system with addre ss support@example.com) <support@example.com> sub 2048g/52B97069 2006-02-03 linux:~$ Wie man sehen kann, genügt es bei den meisten Fragen die Vorgabe mit <EINGABE> zu bestätigen. Lediglich die Angabe zur ``Person'' des Schlüsselbesitzers ist zu vervollständigen bzw. zum Ende hin ist an der mit (passphrase) gekennzeichneten Stelle die Passphrase für den zu generierenden Schlüssel einzugeben. Hier ist zu beachten, dass die Passphrase den üblichen Anforderungen für ein hinreichend sicheres Passwort genügt. Im nächsten Schritt muss OTRS auf die Verwendung von PGP vorbereitet werden. Suchen Sie in SysConfig nach ``PGP'' und wähen Sie danach dan die Untergruppe Crypt::PGP aus. In der nun angezeigten Maske sollte zum einen " PGP aktiviert werden (die erste Option). Danach sollte überprüft werden, ob der voreingestellte Pfad zum Programm gpg der tatsächlichen Installation entspricht. Die nächste Einstellung ( PGP::Options ) muss ggf. modifiziert werden. Es handelt sich um die Parameter, mit denen OTRS das Programm gpg aufruft. Hier ist insbesondere die Option für die Lage des GnuPG-Konfigurationsverzeichnisses des OTRS-Benutzers otrs wichtig. Im Beispiel ist dies: /opt/otrs/.gnupg). Dieses Verzeichnis wurde im Schritt 1 automatisch von GnuPG angelegt. über die letzte Option können die Schlüssel-Werte-Paare für die ID(s) und Passphrase(n) der eigenen PGP-Schlüssel dem Ticket System bekannt gemacht werden. Noch einmal genauer: da andere Kommunikationspartner an das Ticket-System (oder besser: an den Mail-Eingang des Systems E-Mails mit dessen öffentlichen Schlüssel verschlüsselt schicken, kann OTRSmit dem/n in dieser Option angegebenen privaten Schlüssel(n) solchermaßen verschlüsselte Mails entschlüsseln. Woher bekommt man die ID des eigenen Schlüssels? Die ID steckt schon in der Ausgabe der Schlüsselgenerierung (siehe Schritt 1). Man kann die ID aber auch als Benutzer otrs jederzeit über die Kommandozeile ermitteln: linux:~# su otrs linux:/root$ cd linux:~$ pwd /opt/otrs linux:~$ gpg --list-keys /opt/otrs/.gnupg/pubring.gpg ---------------------------- pub 1024D/7245A970 2006-02-03 uid Ticket System (Private pgp key for ticket system with address support@example.com) <support@example.com> sub 2048g/52B97069 2006-02-03 linux:~$ Die ID des Schlüssels befindet sich in der Zeile, die mit sub beginnt und ist eine 8-stellige hexadezimale Kennung (im Beispiel lautet sie "52B97069". Die für die Option geforderte Passphrase ist dieselbe, die beim Schlüsselgenerieren in Schritt 1 verwendet wurde. Nach Eingabe all dieser Angaben können sie mit dem Aktualisieren-Button gespeichert werden. OTRS ist jetzt für das Empfangen mit PGP verschlüsselter E-Mails konfiguriert. Der letzte Schritt ist der Import des öffentlichen PGP-Schlüssels eines Kunden. Dadurch wird sicher gestellt, dass aus OTRS heraus verschlüsselte Mails an den jeweiligen Kunden gesendet werden können. Es bestehen zwei Möglichkeiten für den Import. Zum einem können über das Modul zur Verwaltung der Kunden die öffentlichen PGP-Schlüssel beim anlegen/bearbeiten des jeweiligen Kunden im System hinterlegt werden. Die zweite Möglichkeit bietet das System in den PGP-Einstellungen innerhalb des Admin-Bereiches. In dieser Konfigurationsmaske ist im rechten Teil eine Liste der bereits dem System zur Verfügung stehenden öffentlichen Schlüssel zu sehen. Im Regelfall sollte nach der obigen Einrichtung hier schon der öffentliche Schlüssel des Ticket-Systems selbst zu sehen sein. Im linken Teil besteht neben der Suche die Möglichkeit, neue Schlüssel als Schlüsseldatei ins System zu laden. Nach dem Laden eines neuen Schlüssels wird dieser in der Liste auf der rechten Seite angezeigt, und gleichzeitig erhält man oberhalb der Maske eine Statusmeldung, die über das Laden des Schlüssels informiert. Sowohl für das Hinzufügen eines Schlüssels über die Kunden- als auch über die PGP-Verwaltung gilt, dass die Dateien mit den Schlüsseln PGP/GnuPG-konforme Schlüssel sein müssen. I.d.R. wird der Schlüssel als ``ASCII armored key''-Datei vorliegen, welches problemlos von OTRS verarbeitet werden kann. Die Einrichtung der Verschlüsselung mit S/MIME scheint auf den ersten Blick ein bisschen komplizierter als die PGP-Einrichtung zu sein, da für das OTRS-System erst einmal eine Certification Authority (CA) eingerichtet werden muss. Ansonsten ist das Vorgehen ähnlich wie bei PGP, OTRS konfigurieren, eigenes Zertifikat einrichten, ggf. fremde Public-Zertifikate importieren, usw. Die S/MIME-Konfiguration geschieht zu einem großen Teil außerhalb der OTRS-Web-Oberfläche und sollte als otrs-Benutzer (bzw. als der Benutzer mit dessen Rechten OTRS läuft) in einer Shell durchgeführt werden. Da die MIME-Konfiguration unter Linux im wesentlichen auf SSL (openssl basiert, sollte zuerst sichergestellt werden, dass das openssl-Paket installiert ist. Mit dem openssl-Paket kommt ein Skript, CA.pl, mit welchem die wichtigsten Schritte zur Zertifikatserstellung bewältigt werden können. Damit dieser Vorgang einfacher wird, sollte zuerst herausgefunden werden, wo sich das Skript CA.pl im Dateisystem befindet. Danach sollte diese Stelle der Einfachheit halber temporär in den Suchpfad der Shell übernommen werden. otrs@linux:~> rpm -ql openssl | grep CA /usr/share/ssl/misc/CA.pl otrs@linux:~> export PATH=$PATH:/usr/share/ssl/misc otrs@linux:~> which CA.pl /usr/share/ssl/misc/CA.pl otrs@linux:~> mkdir tmp; cd tmp otrs@linux:~/tmp> Im Beispiel sieht man auch, dass ein temporäres Verzeichnis ~/tmp angelegt wurde, in welchem die Zertifikatsgenerierung durchgeführt wird. Im einzelnen sind zur Zertifikatserzeugung folgende Schritte durchzuführen, die einzelnen Schritte sind in der Kommandozeile auszuführen. Sollte ein beglaubigtes SSL-Zertifikat für die Verschlüsselung bereits vorhanden sein, so sollte natürlich dieses verwendet werden. Dann können die nun folgenden Schritte übersprungen werden. Der beschriebene Ablauf geht davon aus, dass der OTRS-Administrator sich das SSL-Zertifikat zu Test- und Lernzwecken selbst anlegen muss. Anlegen einer eigenen Certification Authority für SSL. Diese wird benötigt, um die Anfrage für ein eigenes SSL-Zertifikat zu beglaubigen. otrs@linux:~/tmp> CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Generating a 1024 bit RSA private key ...++++++ ......++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:OTRS-state Locality Name (eg, city) []:OTRS-town Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your company Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:OTRS Admin Email Address []:otrs@your-domain.tld otrs@linux:~/tmp> ls -la demoCA/ total 8 -rw-r--r-- 1 otrs otrs 1330 2006-01-08 17:54 cacert.pem drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 certs drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 crl -rw-r--r-- 1 otrs otrs 0 2006-01-08 17:53 index.txt drwxr-xr-x 2 otrs otrs 48 2006-01-08 17:53 newcerts drwxr-xr-x 2 otrs otrs 80 2006-01-08 17:54 private -rw-r--r-- 1 otrs otrs 17 2006-01-08 17:54 serial otrs@linux:~/tmp> Erzeugen der Zertifikatsanfrage. otrs@linux:~/tmp> CA.pl -newreq Generating a 1024 bit RSA private key ..........................................++++++ ....++++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:DE\keyreturn State or Province Name (full name) [Some-State]:OTRS-state Locality Name (eg, city) []:OTRS-town Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your company Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:OTRS admin Email Address []:otrs@your-domain.tld Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request (and private key) is in newreq.pem otrs@linux:~/tmp> ls -la total 4 drwxr-xr-x 6 otrs otrs 232 2006-01-08 17:54 demoCA -rw-r--r-- 1 otrs otrs 1708 2006-01-08 18:04 newreq.pem otrs@linux:~/tmp> Die Zertifikatsanfrage durch die CA signieren lassen. Die Zertifikatsanfrage kann entweder durch die selbst angelegte CA signiert (= beglaubigt) werden. Allerdings ist es natürlich seriöser, wenn das eigene SSL-Zertifikat von einer fremden, externen und ihrerseits beglaubigten CA beglaubigt wird. otrs@linux:~/tmp> CA.pl -signreq Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: fd:85:f6:9f:14:07:16:c8 Validity Not Before: Jan 8 17:04:37 2006 GMT Not After : Jan 8 17:04:37 2007 GMT Subject: countryName = DE stateOrProvinceName = OTRS-state localityName = OTRS-town organizationName = Your Company commonName = OTRS administrator emailAddress = otrs@your-domain.tld X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 01:D9:1E:58:C0:6D:BF:27:ED:37:34:14:D6:04:AC:C4:64:98:7A:22 X509v3 Authority Key Identifier: keyid:10:4D:8D:4C:93:FD:2C:AA:9A:B3:26:80:6B:F5:D5:31:E2:8E:DB:A8 DirName:/C=DE/ST=OTRS-state/L=OTRS-town/O=Your Company/ CN=OTRS admin/emailAddress=otrs@your-domain.tld serial:FD:85:F6:9F:14:07:16:C7 Certificate is to be certified until Jan 8 17:04:37 2007 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Signed certificate is in newcert.pem otrs@linux:~/tmp> Mit der signierten Zertifikatsanfrage das eigene Zertifikat und alle dazugehörigen Dateien erzeugen. otrs@linux:~/tmp> CA.pl -pkcs12 "OTRS Certificate" Enter pass phrase for newreq.pem: Enter Export Password: Verifying - Enter Export Password: otrs@linux:~/tmp> ls -la total 12 drwxr-xr-x 6 otrs otrs 328 2006-01-08 18:04 demoCA -rw-r--r-- 1 otrs otrs 3090 2006-01-08 18:13 newcert.p12 -rw-r--r-- 1 otrs otrs 3791 2006-01-08 18:04 newcert.pem -rw-r--r-- 1 otrs otrs 1708 2006-01-08 18:04 newreq.pem otrs@linux:~/tmp> Nach der Durchführung dieser Schritte ist es notwendig die Einrichtung von S/MIME in OTRS abzuschließen. Die OTRS-seitige Einrichtung erfolgt aus dem Admin-Bereich, Block System über den Punkt "SMIME" . Falls die generelle S/MIME-Unterstützung in OTRS noch nicht aktiviert wurde, weist die Maske den OTRS-Administrator beim Aufruf darauf hin und bietet einen bequemen Link zur Einrichtung. Über die SysConfig kann die generelle S/MIME-Unterstützung eingeschaltet und konfiguriert werden. Diese Einrichtung findet man unter der SysConfig-Gruppe "Crypt::SMIME". Neben einem ``Ein-Schalter'' für die S/MIME-Unterstützung können hier die Pfade zum openssl-Befehl , als auch das Verzeichnis mit den Zertifikaten eingestellt werden. Dies bedeutet insbesondere, dass die zu Beginn dieses Abschnitts erzeugten Schlüsseldatei in den hier angegebenen Verzeichnissen liegen müssen, um von OpenSSL verwendet werden zu können. Im nächsten Schritt geht es (zurück) zur S/MIME-Konfiguration im Admin-Bereich. Dort können nun sowohl der private Schlüssel(Key) bzw. die privaten Schlüssel des OTRS-Systems, als auch die öffentlichen Schlüssel anderer Kommunikationspartner ins System importiert werden. Tragen Sie hier den öffentlichen Schlüssel ein, der zu Beginn dieses Abschnitts erzeugt und dann in OTRS hinzugefügt wurde. Selbstverständlich können aber auch alle öffentlichen S/MIME-Schlüssel der Kommunikationspartner über das Modul zur Kundenverwaltung beim anlegen/bearbeiten der jeweiligen Person, in das System importiert werden. Seit OTRS 2.0 gibt es die Möglichkeit, zusätzlich zum Framework, weitere Applikationen aus einem Online-Verzeichnis über das Admin-Interface (Paket Manager) zu installieren. Dies ist ein Kalender, in dem man Termine benutzerabhängig eintragen kann. Es werden private und öffentliche Termine unterstützt. Kalender Mit dem Contentmanager können Webseiten online über die Web-Oberfläche erstellt und verwaltet werden. Mit dem Dateimanager kann auf ein Verzeichnis des Rechners, auf dem OTRS installiert ist, über die Web-Oberfläche zugegriffen und Dateien hochgeladen, gelöscht und angesehen werden. Dateimanager Das Web-Mail-Programm ermöglicht das Abrufen von Mails über einen IMAP-Server, das Verfassen von neuen Nachrichten bzw. die Beantwortung von vorhandenen E-Mails über die Web-Oberfläche. Webmailer Mit Hilfe des FAQ-Systems, welches seit OTRS 2.1 ein eigenes externes Modul ist, kann eine Knowletge-Database aufgebaut und verwaltet werden. Einträge lassen sich nur intern oder auch extern, d.h. für alle Kunden oder komplett öffentlich, freischalten. Einträge können nach Sprache oder nach Kategorien erstellt und sortiert werden. TODO: Screenshot(s) vom FAQ-Modul einfügen. Dies ist eine System-Status-Übersicht für den OTRS-Administrator, die im Admin-Interface von OTRS zu finden ist. Es können eigene Befehle integriert werden, deren Ausgabe über die Web-Oberfläche dargestellt werden. Systemstatus Dies ist ein Modul zum Testen der Leistung Ihres Systems bezogen auf OTRS. Es wird die Performance verschiedener Datenbankoperationen getestet. Eine erschöpfende Liste verschiedener Techniken, um das Maximum an Leistung aus Ihrem OTRS System herauszuholen: Konfiguration, Programmierung, Speichernutzung und mehr. Im folgenden finden Sie Optionen, die Leistung des Systems via OTRS selbst zu verbessern. Zur Verfügung stehen zwei Hintergrundmodule für den Ticket Index. Kernel/Config.pm [...] $Self->{TicketIndexModule} = 'Kernel::System::Ticket::IndexAccelerator::RuntimeDB'; [...] Kernel::System::Ticket::IndexAccelerator::RuntimeDB (Standard), generiere jede Queue-Ansicht dynamisch aus der Ticket Tabelle. Sie werden keine Probleme mit der Leistung bekommen bis zu etwa 60.000 Tickets (oder 6000 offenen) in Ihrem System. Kernel::System::Ticket::IndexAccelerator::StaticDB, das leistungsfähigste Modul. Es sollte ab 80.000 Tickets oder mehr als 6000 offenen eingesetzt werden. Benutzt eine extra ticket_index Tabelle, arbeitet wie eine Ansicht (View). Führen Sie bin/RebuildTicketIndex.pl zum erstmaligen Aufbau des Index aus. Es stehen zwei Module für das Speichern der Tickets und Artikel bereit. Kernel/Config.pm [...] $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStorageDB'; [...] Kernel::System::Ticket::ArticleStorageDB (Standard), speichere Anhänge & Co. in der Datenbank. Merke: Benutzen Sie diese Option nicht für größere Systeme. Pro: Ist der Benutzer, unter dem der Webserver läuft, nicht der OTRS Benutzer, können Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden. Contra: Es ist nicht wirklich nett, Anhänge in Ihrer Datenbank zu speichern. Achten Sie darauf, dass Ihre Datenbank das kann. Für MySQL setzen Sie in dessen Konfiguration bspw. "set-variable = max_allowed_packet=8M", um 8 MB große Objekte zu speichern (Standard ist 2M). Kernel::System::Ticket::ArticleStorageFS, speichere Anhänge & Co. im lokalen Filesystem ab. Merke: Benutzen Sie dies für große Installationen. Pro: Schneller! Contra: Der Benutzer, unter dem der Webserver läuft, sollte der OTRS Benutzer sein (Dateisystemberechtigungen!). Note: Ab OTRS 1.2 oder höher, kann man das TicketStorageModule im Betrieb ändern! Einstellungen sind immer spezifisch für die jeweils eingesetzte Datenbank. Bei Problemen lesen Sie die Dokumentation und fragen Sie Ihren Datenbankadministrator. Wenn Sie den Tabellentyp MyISAM (Standard) benutzen, und einen großen Teil einer Tabelle gelöscht haben, oder wenn Sie sehr viele Änderungen an einer Tabelle mit Zeilen variabler Länge vorgenommen haben (Tabellen mit VARCHAR, BLOB oder TEXT Spalten), sollten Sie die Datendateien mit dem "optimize" Kommando behandeln. Dies bietet sich an, wenn MySQL viel CPU Zeit braucht. Optimieren Sie die Tabellen ticket, ticket_history und article. shell$ mysql -u user -p datbase mysql$ optimize table ticket; mysql$ optimize table ticket_history; mysql$ optimize table article; PostgreSQL konfigurieren Sie am besten in der postgresql.conf Datei in Ihrem PostgreSQL Datenverzeichnis. Hier gibt es Hilfe dazu: http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html Ist die Leistung immer noch nicht genügend, empfehlen wir, Fragen auf der "PostgreSQL Performance Mailing Liste" zu stellen. Die Teilnehmer der PostgreSQL Liste sind sehr freundlich und können wahrscheinlich helfen. http://www.postgresql.org/lists.html. Natürlich empfehlen wir mod_perl 2.0 ( http://perl.apache.org/). Es ist sehr viel schneller (etwa um den Faktor 100) als pures CGI, braucht aber auch mehr Speicher. Ihr httpd wird mit mod_perl also größer sein. Sie können die Datenbankverbindung bereits beim Start des httpd-Prozeß herstellen lassen - dies spart ebenso Zeit (siehe auch README.webserver). Nutzen Sie das Start Skript scripts/apache-perl-startup.pl (mod_perl 1.0) bzw. scripts/apache2-perl-startup.pl (mod_perl 2.0), um die Perl Module vorzuladen (siehe README.webserver). Standardmäßig wird Apache::Reload (mod_perl 1.0) bzw. Apache2::Reload (mod_perl 2.0) in scripts/apache2-httpd.include.conf eingesetzt. Deaktivieren Sie es und die Geschwindigkeit steigt um etwa 8%. Ab nun müssen Sie den Webserver neu starten, wenn Sie irgendetwas ändern! Wichtig, es hat dadurch zur Folge, dass der OTRS-Paket-Manager nicht mehr über das Web-Interface bedient werden kann (nur noch über CMD - bin/opm.pl). Bei wirklich großen Installationen (über 1000 neue Tickets am Tag, über 40 Agenten) ist es eine sehr gute Idee, den Artikel "Choosing the Right Strategy" (in englisch) zu lesen (http://perl.apache.org/docs/1.0/guide/strategy.html). Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_gzip für Apache1 (http://www.schroepl.net/projekte/mod_gzip/) bzw. mod_deflate für Apache2 (default Modul in Apache2). Eine HTML-Seite von 45k wird mod_gzip/mod_deflate auf etwa 7k zusammendrücken - nett. Um http DoS (Denial of Service) Angriffe zu blocken kann mod_dosevasive benutzt werden (leider nur für Apache1 verfügbar). (http://www.nuclearelephant.com/projects/dosevasive/). In diesem Kapitel wird beschrieben, wie alle relevanten Daten der OTRS-Installation gesichert und wieder hergestellt werden können. Bei einem Backup gibt es zwei Arten von Datensicherung, die Applikation (z.B. /opt/otrs/) und die Datenbank. Um Backups zu vereinfachen, wird ein "scripts/backup.pl" mitgeliefert, das alle benötigten Komponenten sichert. linux:/opt/otrs# cd scripts/ linux:/opt/otrs/scripts# ./backup.pl --help backup.pl <Revision 1.1> - backup script Copyright (c) 2001-2005 Martin Edenhofer <martin@otrs.org> usage: backup.pl -d /data_backup/ [-c bzip2|gzip] [-r 30] [-t nofullbackup] linux:/opt/otrs/scripts# Ein Backup kann also z.B. mit folgendem Befehl erstellt werden: linux:/opt/otrs/scripts# ./backup.pl -d /backup/ Backup /backup//2005-09-12_14-28/Config.tar.gz ... done Backup /backup//2005-09-12_14-28/Application.tar.gz ... done Dump MySQL rdbms ... done Compress SQL-file... done linux:/opt/otrs/scripts# Alle Daten wurden in das Verzeichnis /backup/2005-09-12_14-28/ gesichert und dort, getrennt nach Art der Daten, in einzelne .tar.gz-Dateien gespeichert. linux:/opt/otrs/scripts# ls /backup/2005-09-12_14-28/ Application.tar.gz Config.tar.gz DatabaseBackup.sql.gz linux:/opt/otrs/scripts# Das Backupskript kennt diverse Optionen: linux:/opt/otrs/scripts# backup.pl --help backup.pl <Revision 1.1> - backup script Copyright (c) 2001-2005 Martin Edenhofer <martin@otrs.org> usage: backup.pl -d /data_backup/ [-c bzip2|gzip] [-r 30] So kann mit Hilfe des Schalters -d angegeben werden in welches Verzeichnis das Backup geschrieben werden soll. Gleichzeitig lässt sich mit -c entweder bzip2 oder gzip zum platzsparenden Backupen nutzen. Damit man bequem Backups, die ein gewisses Alter erreicht haben löschen kann, wartet das Skript mit dem Schalter -r auf. Die darauffolgende Zeitangabe muss in Tagen erfolgen. Um ein Backup wieder einzuspielen, müssen die Applikation (z.B. nach /opt/otrs/) und die Datenbank wieder hergestellt werden. Um Backups einspielen zu können, wird ein "scripts/restore.pl" mitgeliefert, das die benötigten Komponenten wieder zurück sichert. Es unterstützt MySQL und PostgreSQL. linux:/opt/otrs/scripts# ./restore.pl --help restore.pl <Revision 1.1> - restore script Copyright (c) 2001-2005 Martin Edenhofer <martin@otrs.org> usage: restore.pl -b /data_backup/<TIME>/ -d /opt/otrs/ linux:/opt/otrs/scripts# Daten, die im Verzeichnis /backup/2005-09-12_14-28/ gesichert wurden, können bei einer OTRS-Installation in /opt/otrs folgendermaßen zurück gesichert werden. linux:/opt/otrs/scripts# ./restore.pl -b /backup/2005-09-12_14-28 -d /opt/otrs/ Restore /backup/2005-09-12_14-28//Config.tar.gz ... Restore /backup/2005-09-12_14-28//Application.tar.gz ... create MySQL decompresses SQL-file ... cat SQL-file into MySQL database compress SQL-file... linux:/opt/otrs/scripts# Wir unterstützen Sie mit den aktuellsten Informationen über OTRS und geben Ihnen die Möglichkeit, uns mit Feedback zu versorgen. Die OTRS Community finden Sie unter http://www.otrs.org/ . Hier gibt es aktuelle Infos zum Projekt und Software. Homepage OTRS.org Die folgende Tabelle gibt einen Überblick darüber, welche Community-Mailinglisten es derzeit für OTRS gibt und wie diese zu erreichen sind: Name Beschreibung Homepage announce at otrs.org Ankündigungen zu OTRS (neue Versionen, Updates, ...) mit wenig Verkehr. http://lists.otrs.org/cgi-bin/listinfo/announce otrs at otrs.org Benutzer-Fragen und -Diskussionen rund um OTRS (englischsprachig) mit mittel bis viel Verkehr. http://lists.otrs.org/cgi-bin/listinfo/otrs otrs-de at otrs.org Benutzer-Fragen und -Diskussionen rund um OTRS (deutschsprachig) mit mittel bis viel Verkehr. http://lists.otrs.org/cgi-bin/listinfo/otrs-de dev at otrs.org Mailingliste für die Entwickler von OTRS mit wenig Verkehr. http://lists.otrs.org/cgi-bin/listinfo/dev doc-de at otrs.org Deutsche Diskussion über die OTRS-Dokumentation mit wenig Verkehr. http://lists.otrs.org/cgi-bin/listinfo/doc-de i18n at otrs.org Mailingliste mit Fragen zur Internationalisierung von OTRS mit wenig Verkehr. http://lists.otrs.org/cgi-bin/listinfo/i18n cvs-log at otrs.org Benachrichtigungen über geänderte CVS-Dateien im Quellcode von OTRS mit sehr viel Verkehr. http://lists.otrs.org/cgi-bin/listinfo/cvs-log Um eine Liste zu abonnieren besuchen Sie folgenden Link: http://lists.otrs.org/ Um uns Fehler in OTRS mitzuteilen, besuchen Sie uns unter: http://bugs.otrs.org/ . Es ist uns bewusst, das bugzilla manchmal nicht sehr komfortabel ist. Es ist aber derzeit das beste Fehlerverfolgungssystem, das wir finden konnten. Fehlerverfolgungssystem Indem Sie uns Fehler aufzeigen, helfen Sie uns sehr die Software weiter zu entwickeln und zu verbessern. Wir bitten Sie um Ihre Mithilfe! Neben der Unterstützung aus der Open Source Community können Sie auch Gebrauch vom kommerziellen Teil des OTRS- Projekts, der OTRS AG, machen (Support, Consulting und Training). OTRS AG, Europaring 4, 94315 Straubing (Germany), Web: http://otrs.com/ Description Value Description: Wird diese Option aktiviert, kann der Web-Installer (installer.pl) nicht genutzt werden. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'SecureMode'} = '0'; Description Value Description: Im WebFrontend angezeigter Name der Software. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'ProductName'} = 'OTRS'; Description Value Description: Identifikationsnummer f?r das installierte System. Jede Ticketnummer und ID einer http-Session beginnt mit dieser Nummer. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'SystemID'} = '10'; Description Value Description: Vollst?ndiger Domain Name des Systems. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'FQDN'} = 'yourhost.example.com'; Description Value Description: Legen Sie hier fest, ob das http- oder https-Protokoll innerhalb des Systems genutzt werden soll. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'HttpType'} = 'http'; Description Value Description: ScriptAlias zur Datei index.pl, wie in der Webserver-Konfiguration festgelegt. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'ScriptAlias'} = 'otrs/'; Description Value Description: Emailadresse des Systemadministrators. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'AdminEmail'} = 'admin@example.com'; Description Value Description: Firma bzw. Name der Organisation. Jede ausgehende Nachricht wird mit einem X-Header-Eintrag f?r die Organisation und dem angegebenen Namen als Wert versehen. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'Organization'} = 'Example Company'; Description Value Description: Standard-Zeichensatz des Frontends. W?hlen Sie "utf-8", wenn verschiedene Zeichens?tze f?r die Anzeige ben?tigt werden. Wird nur ein Zeichensatz eingesetzt (z. B. "iso-8859-1"), nutzen Sie bitte diese Einstellung. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultCharset'} = 'iso-8859-1'; Description Value Description: Standard Frontend Sprache. M?gliche Werte sind bg, cz, da, de, en, el, es, fi, fr, hu, it, nb, nl, pl, pt, ru, th und sv. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultLanguage'} = 'en'; Description Value Description: Abk?rzung f?r die Zuordnung der verschiedenen Sprachen (Abk?rzung = Vollst?ndiger Name und Datei). Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultUsedLanguages'} = { 'pt' => 'Portugu&ecirc;s', 'sk_SK' => 'Slovak', 'es' => 'Espa&ntilde;ol', 'da' => 'Dansk', 'ru' => 'Russian', 'fr' => 'Fran&ccedil;ais', 'bg' => 'Bulgarian', 'sv' => 'Svenska', 'it' => 'Italiano', 'hu' => 'Hungarian', 'zh_CN' => 'Simplified Chinese', 'nb_NO' => 'Norsk bokm&aring;l', 'pl' => 'Polski', 'fa' => 'Persian', 'cz' => 'Czech', 'nl' => 'Nederlands', 'fi' => 'Suomi', 'en' => 'English', 'de' => 'Deutsch', 'el' => 'Greek', 'pt_BR' => 'Portugu&ecirc;s Brasileiro' }; Description Value Description: Standard Design der Weboberfl?che (Standard oder Lite). Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultTheme'} = 'Standard'; Description Value Description: OTRS bietet die M?glichkeit individuelle Themes f?r Kunden und Agents festzulegen. Diese k?nnen unter anderem durch den Aufruf einer extra daf?r geschaffenen Domain angezeigt werden. Dabei enth?lt das Feld "Schl?ssel" eine Domain oder eine RegExp die eine Domain matched. Das zugeh?rige Theme wird im Feld "Inhalt" angegeben. Group: Framework SubGroup: Core Valid: 0 Required: 0 Config-Setting: $Self->{'DefaultTheme::HostBased'} = { 'host2\\.example\\.com' => 'SomeTheme2', 'host1\\.example\\.com' => 'SomeTheme1' }; Description Value Description: Soll der MX-Record von Emailadressen vor dem Versenden ?berpr?ft werden? Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'CheckMXRecord'} = '1'; Description Value Description: Sollen Emailadressen auf korrekte Syntax ?berpr?ft werden? Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'CheckEmailAddresses'} = '1'; Description Value Description: Regul?rer Ausdruck f?r syntaktisch nicht korrekte Mailadressen, die aber trotzdem im System verwendet werden sollen, z. B. "root@localhost". Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'CheckEmailValidAddress'} = '^(root@localhost|admin@localhost)$'; Description Value Description: Regul?rer Ausdruck f?r nicht zul?ssige Emailadressen. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'CheckEmailInvalidAddress'} = '@(aa|aaa|aaaa|aaaaa|abc|any|anywhere|anonymous|bar|demo|example|foo|hello|hallo|nospam|nowhere|null|some|somewhere|test|teste.|there|user|xx|xxx|xxxx)\\.(..|...)$'; Description Value Description: Logprefix f?r die CGI-Skripte des Systems. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'CGILogPrefix'} = 'OTRS-CGI'; Description Value Description: Demosystem aktivieren? Wenn diese Einstellung aktiviert wird, k?nnen Agenten nur f?r die aktuelle Sitzung ihre Sprache oder das Anzeige-Schema ausw?hlen. Weiterhin k?nnen keine Kennw?rter ge?ndert werden. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'DemoSystem'} = '0'; Description Value Description: Dem Administrator erlauben sich ?ber die Benutzerverwaltung mit dem Zugang eines Benutzers anzumelden. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'SwitchToUser'} = '0'; Description Value Description: Absendername f?r Benachrichtigungsemails verwendet. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'NotificationSenderName'} = 'OTRS Notification Master'; Description Value Description: Emailadresse die beim Versenden von Benachrichtigungsmails verwendet wird. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'NotificationSenderEmail'} = 'otrs@<OTRS_CONFIG_FQDN>'; Description Value Description: Die unterschiedlichen Zugriffsrechte der Agenten innerhalb des Systems (m?glich sind zus?tzlich note, close, pending, customer, freetext, forward und bounce - rw sollte das letzte in der Aufz?hlung bleiben). Group: Framework SubGroup: Core::Ticket Valid: 1 Required: 1 Config-Setting: $Self->{'System::Permission'} = [ 'ro', 'move_into', 'create', 'owner', 'priority', 'rw' ]; Description Value Description: Die verschiedenen Zugriffsrechte f?r die Kunden. Group: Framework SubGroup: Core Valid: 1 Required: 1 Config-Setting: $Self->{'System::Customer::Permission'} = [ 'ro', 'rw' ]; Description Value Description: Logmodul f?r das System. "File" schreibt in eine anzugebende Datei, "SysLog" logt mit Hilfe des systemspezifischen Logdaemons, z. B. syslogd. Group: Framework SubGroup: Core::Log Valid: 1 Required: 1 Config-Setting: $Self->{'LogModule'} = 'Kernel::System::Log::SysLog'; Description Value Description: Wenn f?r LogModule der Wert "SysLog" ausgew?hlt wurde, kann hier ein spezielles Log-Facility angegeben werden. Group: Framework SubGroup: Core::Log Valid: 1 Required: 1 Config-Setting: $Self->{'LogModule::SysLog::Facility'} = 'user'; Description Value Description: Wenn "SysLog" f?r LogModule ausgew?hlt wurde, kann hier der Zeichensatz festgelegt werden, der f?r das Schreiben der Logeintr?ge benutzt werden soll. Group: Framework SubGroup: Core::Log Valid: 1 Required: 1 Config-Setting: $Self->{'LogModule::SysLog::Charset'} = 'iso-8859-1'; Description Value Description: Wenn "File" f?r LogModul ausgew?hlt wurde, muss eine Logdatei angegeben werden. Diese wird automatisch vom System angelegt, falls sie noch nicht existiert. Group: Framework SubGroup: Core::Log Valid: 1 Required: 1 Config-Setting: $Self->{'LogModule::LogFile'} = '/tmp/otrs.log'; Description Value Description: Soll f?r jeden Logeintrag das Datum und die aktuelle Zeit mit protokolliert werden? Group: Framework SubGroup: Core::Log Valid: 1 Required: 1 Config-Setting: $Self->{'LogModule::LogFile::Date'} = '0'; Description Value Description: Gr??e des Caches f?r Admin System Log (in KBytes). Group: Framework SubGroup: Core::Log Valid: 0 Required: 0 Config-Setting: $Self->{'LogSystemCacheSize'} = '4096'; Description Value Description: Pfad zum Konvertierungsprogramm, um Microsoft Excel Dateien ?ber die Web-Oberfl?che anzuzeigen. Group: Framework SubGroup: Core::MIME-Viewer Valid: 0 Required: 0 Config-Setting: $Self->{'MIME-Viewer'}->{'application/excel'} = 'xlhtml'; Description Value Description: Pfad zum Konvertierungsprogramm, um Microsoft Word Dateien ?ber die Web-Oberfl?che anzuzeigen. Group: Framework SubGroup: Core::MIME-Viewer Valid: 0 Required: 0 Config-Setting: $Self->{'MIME-Viewer'}->{'application/msword'} = 'wvWare'; Description Value Description: Pfad zum Programm, um PDF Dateien ?ber die Web-Oberfl?che anzuzeigen. Group: Framework SubGroup: Core::MIME-Viewer Valid: 0 Required: 0 Config-Setting: $Self->{'MIME-Viewer'}->{'application/pdf'} = 'pdftohtml -stdout -i'; Description Value Description: Pfad zum Konvertierungsprogramm, um XML Dateien in der Web-Oberfl?che anzuzeigen. Group: Framework SubGroup: Core::MIME-Viewer Valid: 0 Required: 0 Config-Setting: $Self->{'MIME-Viewer'}->{'text/xml'} = '<OTRS_CONFIG_Home>/scripts/tools/xml2html.pl'; Description Value Description: PDF Ausgabe aktivieren? Es wird das CPAN Modul PDF::API2 ben?tigt. Ist dieses nicht installiert, wird die PDF Ausgabe automatisch deaktiviert. Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF'} = '1'; Description Value Description: Datei f?r das Logo, das im Seitenkopf angezeigt wird (gif|jpg|png, 700 x 100 Pixel). Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::LogoFile'} = '<OTRS_CONFIG_Home>/var/logo-otrs.png'; Description Value Description: Standard-Seitengr??e von PDF Seiten Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::PageSize'} = 'a4'; Description Value Description: Maximale Anzahl von Seiten pro PDF Datei Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::MaxPages'} = '100'; Description Value Description: Pfad und TTF-Schriftdatei um proportianale Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::TTFontFile'}->{'Proportional'} = 'DejaVuSans.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um fette, proportianale Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::TTFontFile'}->{'ProportionalBold'} = 'DejaVuSans-Bold.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um kursive, proportianale Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 0 Required: 0 Config-Setting: $Self->{'PDF::TTFontFile'}->{'ProportionalItalic'} = 'DejaVuSans-Oblique.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um fette, kursive, proportianale Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::TTFontFile'}->{'ProportionalBoldItalic'} = 'DejaVuSans-BoldOblique.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um monospaced Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 1 Required: 1 Config-Setting: $Self->{'PDF::TTFontFile'}->{'Monospaced'} = 'DejaVuSansMono.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um fette, monospaced Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 0 Required: 0 Config-Setting: $Self->{'PDF::TTFontFile'}->{'MonospacedBold'} = 'DejaVuSansMono-Bold.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um kursive, monospaced Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 0 Required: 0 Config-Setting: $Self->{'PDF::TTFontFile'}->{'MonospacedItalic'} = 'DejaVuSansMono-Oblique.ttf'; Description Value Description: Pfad und TTF-Schriftdatei um fette, kursive, monospaced Schrift in PDF Dokumente zu verarbeiten. Group: Framework SubGroup: Core::PDF Valid: 0 Required: 0 Config-Setting: $Self->{'PDF::TTFontFile'}->{'MonospacedBoldItalic'} = 'DejaVuSansMono-BoldOblique.ttf'; Description Value Description: File Upload im WebFrontend der Paket-Verwaltung aktivieren? Group: Framework SubGroup: Core::Package Valid: 1 Required: 1 Config-Setting: $Self->{'Package::FileUpload'} = '1'; Description Value Description: Online-Quelle, ?ber die zus?tzliche Pakete bezogen werden k?nnen. Die Quelle, die zuerst erfolgreich abgefragt werden kann, wird verwendet. Group: Framework SubGroup: Core::Package Valid: 1 Required: 0 Config-Setting: $Self->{'Package::RepositoryRoot'} = [ 'http://ftp.otrs.org/pub/otrs/misc/packages/repository.xml', 'http://otrs.org/repository.xml' ]; Description Value Description: Liste der zur Verf?gung stehenden Online-Quellen (es koennen z. B. auch andere Installationen als Online-Quellen verwendet werden mit der Verwendung von Key="http://example.com/otrs/public.pl?Action=PublicRepository&File=" and Content="Ein Name"). Group: Framework SubGroup: Core::Package Valid: 0 Required: 0 Config-Setting: $Self->{'Package::RepositoryList'} = { 'ftp://ftp.example.com/pub/otrs/misc/packages/' => '[Example] ftp://ftp.example.com/' }; Description Value Description: IP RegExp fuer lokale Online-Quelle. Sie muessen dies aktivieren um den Zugriff auf die lokale Online-Quelle zu haben. Package::RepositoryList ist Voraussetzung am entfernten Rechner. Group: Framework SubGroup: Core::Package Valid: 0 Required: 0 Config-Setting: $Self->{'Package::RepositoryAccessRegExp'} = '127\\.0\\.0\\.1'; Description Value Description: Timeout f?r das Herunterladen von zus?tzlichen Paketen (in Sekunden). Group: Framework SubGroup: Core::Package Valid: 1 Required: 1 Config-Setting: $Self->{'Package::Timeout'} = '15'; Description Value Description: Laden von zus?tzlichen Paketen ?ber einen Proxyserver. Group: Framework SubGroup: Core::Package Valid: 0 Required: 0 Config-Setting: $Self->{'Package::Proxy'} = 'http://proxy.sn.no:8001/'; Description Value Description: PerformanceLog aktivieren um Seiten-Antwortzeiten zu protokollieren. Achtung, dies benoetigt System-Resourcen (es muss auch Frontend::Module###AdminPerformanceLog aktiviert werden!). Group: Framework SubGroup: Core::PerformanceLog Valid: 1 Required: 0 Config-Setting: $Self->{'PerformanceLog'} = '0'; Description Value Description: Logdatei des PerformanceLog. Group: Framework SubGroup: Core::PerformanceLog Valid: 1 Required: 1 Config-Setting: $Self->{'PerformanceLog::File'} = '<OTRS_CONFIG_Home>/var/log/Performance.log'; Description Value Description: Maximale groesse in MB der Logdatei. Group: Framework SubGroup: Core::PerformanceLog Valid: 1 Required: 1 Config-Setting: $Self->{'PerformanceLog::FileMax'} = '15'; Description Value Description: Der Benutzername um die SOAP Schnitstelle benutzen zu koennen (bin/cgi-bin/rpc.pl). Group: Framework SubGroup: Core::SOAP Valid: 0 Required: 0 Config-Setting: $Self->{'SOAP::User'} = 'some_user'; Description Value Description: Das Passwort um die SOAP Schnitstelle benutzen zu koennen (bin/cgi-bin/rpc.pl). Group: Framework SubGroup: Core::SOAP Valid: 0 Required: 0 Config-Setting: $Self->{'SOAP::Password'} = 'some_pass'; Description Value Description: Modul zum Versenden von Emails. "Sendmail" verwendet das sendmail-Binary Ihres Betriebssystems. "SMTP" versendet die Nachrichten ?ber einen externen Mailserver. Group: Framework SubGroup: Core::Sendmail Valid: 1 Required: 1 Config-Setting: $Self->{'SendmailModule'} = 'Kernel::System::Email::Sendmail'; Description Value Description: Wenn "Sendmail" als SendmailModule ausgew?hlt wurde, m?ssen Sie dem System den Pfad zu Ihrem sendmail-Binary und die ben?tigten Optionen mitteilen. Group: Framework SubGroup: Core::Sendmail Valid: 1 Required: 1 Config-Setting: $Self->{'SendmailModule::CMD'} = '/usr/sbin/sendmail -i -f'; Description Value Description: Wenn Sie f?r SendmailModule "SMTP" ausgw?hlt haben, m?ssen Sie hier den Mailserver angeben, der zum Versenden von Nachrichten genutzt werden soll. Group: Framework SubGroup: Core::Sendmail Valid: 1 Required: 1 Config-Setting: $Self->{'SendmailModule::Host'} = 'mail.example.com'; Description Value Description: Wenn Sie f?r SendmailModule den Wert "SMTP" ausgew?hlt haben, k?nnen Sie hier den Port angeben, auf dem Ihr Mailserver Mails entgegennimmt. Group: Framework SubGroup: Core::Sendmail Valid: 0 Required: 0 Config-Setting: $Self->{'SendmailModule::Port'} = '25'; Description Value Description: Wenn Sie f?r SendmailModule den Wert "SMTP" ausgew?hlt haben und sich an Ihrem Mailserver anmelden m?ssen, geben Sie hier bitte den Benutzernamen f?r die Authentifizierung an. Group: Framework SubGroup: Core::Sendmail Valid: 0 Required: 0 Config-Setting: $Self->{'SendmailModule::AuthUser'} = 'MailserverLogin'; Description Value Description: Wenn Sie f?r SendmailModule den Wert "SMTP" ausgew?hlt haben und sich an Ihrem Mailserver anmelden m?ssen, geben Sie hier das Passwort f?r die Authentifizierung an. Group: Framework SubGroup: Core::Sendmail Valid: 0 Required: 0 Config-Setting: $Self->{'SendmailModule::AuthPassword'} = 'MailserverPassword'; Description Value Description: Alle ausgehenden Nachrichten werden via BCC ('Blind Copy') an die angegebene Adresse gesendet. Bitte nutzen Sie diese Funktionalit?t nur aus Gr?nden der Datensicherung. Group: Framework SubGroup: Core::Sendmail Valid: 1 Required: 0 Config-Setting: $Self->{'SendmailBcc'} = ''; Description Value Description: Die hier angegebene Adresse wird f?r ausgehende Benachrichtigungen als envelope from Header genutzt. Wird keine Adresse angegeben, bleibt der envelope from Header leer. Group: Framework SubGroup: Core::Sendmail Valid: 0 Required: 0 Config-Setting: $Self->{'SendmailNotificationEnvelopeFrom'} = ''; Description Value Description: Modul zum Speichern der Session-Daten. "DB" hat den Vorteil, dass die Web-Oberfl?che und die Datenbank auf verschiedenen Maschinen installiert werden kann, "FS" oder "IPC" sind hingegen viel schneller. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionModule'} = 'Kernel::System::AuthSession::DB'; Description Value Description: Name der Session-Kennung. Z. B. Session, SessionID oder OTRS. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionName'} = 'Session'; Description Value Description: Wird das System z. B. ?ber eine Proxy-Farm oder ?ber eine Einw?hlverbindung angesprochen, kann sich die IP-Adresse f?r die einzelnen Anfragen oft ?ndern. Schalten Sie in diesem Fall diese ?berpr?fung ab. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionCheckRemoteIP'} = '1'; Description Value Description: Session bei falscher IP Adresse l?schen? Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionDeleteIfNotRemoteID'} = '1'; Description Value Description: G?ltigkeitsdauer einer Session (in Sekunden). Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionMaxTime'} = '36000'; Description Value Description: Eine Session wird beendet und der Benutzer automatisch abgemeldet, wenn er f?r die hier angegebene Zeit in Sekunden inaktiv war (in Sekunden). Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionMaxIdleTime'} = '18000'; Description Value Description: Sollen Anfragen f?r Sessions automatisch gel?scht werden, wenn diese Sessions bereits schon lange abgelaufen sind? Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionDeleteIfTimeToOld'} = '1'; Description Value Description: Sessionmanagement mit Cookies? Wenn Cookies deaktiviert sind oder werden vom verwendeten Browser keine Cookies unterst?tzt, wird die SessionID automatisch per Link ?bermittelt. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionUseCookie'} = '1'; Description Value Description: Cookies nach dem Schlie?en des Browsers nicht l?schen? Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionUseCookieAfterBrowserClose'} = '0'; Description Value Description: Wenn "FS" f?r SessionModule ausgew?hlt wurde, muss ein Verzeichnis zum Zwischenspeichern der Session-Daten angegeben werden. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionDir'} = '<OTRS_CONFIG_Home>/var/sessions'; Description Value Description: Wenn "DB" als SessionModule ausgew?hlt wurde, muss eine Tabelle in der Datenbank zum Speichern der Session-Daten, angegeben werden. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionTable'} = 'sessions'; Description Value Description: Wenn "DB" als SessionModule ausgew?hlt wurde, muss ein Feld f?r die ID innerhalb der Tabelle f?r die Sessions angegeben werden. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionTableID'} = 'session_id'; Description Value Description: Wenn "DB" als SessionModule ausgew?hlt wurde, muss ein Feld f?r die Werte innerhalb der Session-Tabelle angegeben werden. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'SessionTableValue'} = 'session_value'; Description Value Description: Kennung f?r Kunden-Sitzungen. Group: Framework SubGroup: Core::Session Valid: 1 Required: 1 Config-Setting: $Self->{'CustomerPanelSessionName'} = 'CSID'; Description Value Description: Aktivieren oder deaktivieren der Rechtschreibhilfe. Group: Framework SubGroup: Core::SpellChecker Valid: 1 Required: 1 Config-Setting: $Self->{'SpellChecker'} = '1'; Description Value Description: Installieren Sie ispell oder aspell, um auf eine Rechtschreibhilfe zur?ckgreifen zu k?nnen. Bitte geben Sie hier den Pfad zum Binary von ispell oder aspell an. Group: Framework SubGroup: Core::SpellChecker Valid: 1 Required: 1 Config-Setting: $Self->{'SpellCheckerBin'} = '/usr/bin/ispell'; Description Value Description: Standard W?rterbuch f?r die Rechtschreibpr?fung. Group: Framework SubGroup: Core::SpellChecker Valid: 1 Required: 1 Config-Setting: $Self->{'SpellCheckerDictDefault'} = 'english'; Description Value Description: Folgende W?rter werden von der Rechtschreibpr?fung standardm??ig ignoriert. Group: Framework SubGroup: Core::SpellChecker Valid: 1 Required: 1 Config-Setting: $Self->{'SpellCheckerIgnore'} = [ 'www', 'webmail', 'https', 'http', 'html', 'rfc' ]; Description Value Description: Hiermit kann der Statistik-Identifikator gesetzt werden. Group: Framework SubGroup: Core::Stats Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::StatsHook'} = 'Stat#'; Description Value Description: Startzahl, ab der die Statistiknummern hochgez?hlt werden. Group: Framework SubGroup: Core::Stats Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::StatsStartNumber'} = '10000'; Description Value Description: Maximale Anzahl in die ein Zeitraum auf der X-Achse skaliert werden darf. Group: Framework SubGroup: Core::Stats Valid: 0 Required: 0 Config-Setting: $Self->{'Stats::MaxXaxisAttributes'} = '100'; Description Value Description: Hier k?nnen Sie festlegen, ob das Statistik-Modul auch Statistiken ?ber Tickets generieren darf. Group: Framework SubGroup: Core::Stats Valid: 1 Required: 0 Config-Setting: $Self->{'Stats::DynamicObjectRegistration'}->{'Ticket'} = { 'Module' => 'Kernel::System::Stats::Dynamic::Ticket' }; Description Value Description: Abstand von oben zum Diagramm Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::t_margin'} = '10'; Description Value Description: Linker Abstand zum Diagramm. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::l_margin'} = '10'; Description Value Description: Abstand von unten zum Diagramm. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::b_margin'} = '10'; Description Value Description: Rechter Abstand zum Diagramm. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::r_margin'} = '20'; Description Value Description: Hintergrundfarbe vom Bild. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::bgclr'} = 'white'; Description Value Description: Soll das Bild transparent sein? Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::transparent'} = '0'; Description Value Description: Rahmenfarbe des Diagramms. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::fgclr'} = 'black'; Description Value Description: Hintergrundfarbe des Diagramms. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::boxclr'} = 'white'; Description Value Description: Rahmenfarbe der Legende. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::accentclr'} = 'black'; Description Value Description: Textfarbe der Legende. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::legendclr'} = 'black'; Description Value Description: Textfarbe vom Diagramm (z. B. Titel). Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::textclr'} = 'black'; Description Value Description: Farben f?r die Graphen. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::dclrs'} = [ 'red', 'green', 'blue', 'yellow', 'black', 'purple', 'orange', 'pink', 'marine', 'cyan', 'light gray', 'light blue', 'light yellow', 'light green', 'light red', 'light purple', 'light orange', 'light brown' ]; Description Value Description: Linienst?rke der Graphen. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::line_width'} = '1'; Description Value Description: Platzierung der Legende. Es handelt sich hierbei um einen Schl?ssel bestehend aus zwei Buchstaben in der Form 'B[LCR]|R[TCB]'. Der erste Buchstabe gibt die Platzierung an. Der zweite die Ausrichtung der Legende. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::legend_placement'} = 'BC'; Description Value Description: Abstand der Legenden. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::legend_spacing'} = '4'; Description Value Description: Breite der Legende. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::legend_marker_width'} = '12'; Description Value Description: H?he der Legende. Group: Framework SubGroup: Core::Stats::Graph Valid: 1 Required: 1 Config-Setting: $Self->{'Stats::Graph::legend_marker_height'} = '8'; Description Value Description: Benutztes Datumseingabeformat in Formularen (Auswahl- oder Eingabefelder). Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeInputFormat'} = 'Option'; Description Value Description: Aktivieren eines Kalender-Fensters bei Datumsauswahlen. Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeCalendarLookup'} = '1'; Description Value Description: Zeitangaben immer im ausf?hrlichen (Tag, Stunden, Minuten) oder im kurzen Format (Tag, Stunden) anzeigen. Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeShowAlwaysLong'} = '0'; Description Value Description: Einstellen der Zeitzone. Standardm??ig wird die lokale Systemzeit verwendet, (+ / - 0). Group: Framework SubGroup: Core::Time Valid: 0 Required: 0 Config-Setting: $Self->{'TimeZone'} = '+0'; Description Value Description: Einstellen der Zeitzone pro Benutzer (Voraussetzung ist UTC unter der Option TimeZone). Standardm??ig wird die lokale Systemzeit verwendet, (+ / - 0). Group: Framework SubGroup: Core::Time Valid: 1 Required: 0 Config-Setting: $Self->{'TimeZoneUser'} = '0'; Description Value Description: Einstellen der Zeitzone pro Benutzer basierent auf der Java Script / Browser "Time Offset" funktionalitaet zur Loginzeit. Group: Framework SubGroup: Core::Time Valid: 1 Required: 0 Config-Setting: $Self->{'TimeZoneUserBrowserAutoOffset'} = '1'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar1 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar1Name'} = 'Calendar Name 1'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar1 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar1'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar1 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar1'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar1 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar1'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar1 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar1'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar2 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar2Name'} = 'Calendar Name 2'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar2 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar2'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar2 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar2'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar2 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar2'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar2 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar2'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar3 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar3Name'} = 'Calendar Name 3'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar3 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar3'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar3 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar3'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar3 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar3'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar3 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar3'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar4 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar4Name'} = 'Calendar Name 4'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar4 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar4'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar4 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar4'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar4 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar4'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar4 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar4'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar5 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar5Name'} = 'Calendar Name 5'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar5 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar5'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar5 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar5'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar5 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar5'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar5 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar5'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar6 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar6Name'} = 'Calendar Name 6'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar6 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar6'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar6 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar6'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar6 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar6'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar6 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar6'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar7 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar7Name'} = 'Calendar Name 7'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar7 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar7'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar7 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar7'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar7 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar7'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar7 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar7'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar8 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar8Name'} = 'Calendar Name 8'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar8 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar8'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar8 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar8'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar8 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar8'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar8 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar8'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: Kalender Name. Group: Framework SubGroup: Core::Time::Calendar9 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar9Name'} = 'Calendar Name 9'; Description Value Description: Zeitzone der Queue. Group: Framework SubGroup: Core::Time::Calendar9 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeZone::Calendar9'} = '0'; Description Value Description: Hinterlegen Sie hier Ihre permanenten Feiertage im System. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar9 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDays::Calendar9'} = { '1' => { '1' => 'New Year\'s Eve!' }, '12' => { '25' => 'First Christmas Day', '24' => 'Christmas', '26' => 'Second Christmas Day', '31' => 'Silvester' }, '5' => { '1' => '1 St. May' } }; Description Value Description: Einmalige Feiertage im System hinterlegen. Benutzen Sie bitte f?r Januar bis Septemper einstellige Zahlen (1-9), ebenso f?r Monatstage kleiner zehn. Group: Framework SubGroup: Core::Time::Calendar9 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeVacationDaysOneTime::Calendar9'} = { '2004' => { '1' => { '1' => 'test' } } }; Description Value Description: Wochentage und Stunden f?r die die Arbeitszeit erfasst werden soll. Group: Framework SubGroup: Core::Time::Calendar9 Valid: 1 Required: 1 Config-Setting: $Self->{'TimeWorkingHours::Calendar9'} = { 'Mon' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Tue' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Fri' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Wed' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ], 'Sun' => [], 'Sat' => [], 'Thu' => [ '8', '9', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20' ] }; Description Value Description: URL Bildverzeichnis der Icons fuer Navigation. Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'Frontend::ImagePath'} = '/otrs-web/images/Standard/'; Description Value Description: Nach dieser Anzahl an Zeichen wird in Textnachrichten automatisch eine neue Zeile begonnen. Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultViewNewLine'} = '85'; Description Value Description: Anzahl der Zeilen bei der Vorschau von Textnachrichten (z. B. bei Tickets in der Queue-Ansicht). Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultPreViewLines'} = '18'; Description Value Description: Anzahl der Zeilen f?r Textnachricht (z. B. im QueueZoom). Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'DefaultViewLines'} = '6000'; Description Value Description: Anzeige von Dateianh?nge f?r Tickets im Browser (inline), oder als Download anbieten (attachment). Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'AttachmentDownloadType'} = 'attachment'; Description Value Description: Maximale Dateigr??e f?r Dateiuploads ?ber den Browser (in Bytes). Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'WebMaxFileUpload'} = '5242880'; Description Value Description: W?hlen Sie das Modul, welches Uploads ?ber die Web-Oberfl?che speichert. "DB" benutzt die Datenbank zum Speichern der Uploads, "FS" legt die Daten im Dateisystem ab. Group: Framework SubGroup: Core::Web Valid: 1 Required: 1 Config-Setting: $Self->{'WebUploadCacheModule'} = 'Kernel::System::Web::UploadCache::DB'; Description Value Description: Ein Filter f?r den HTML-Inhalt innerhalb der Applikation. Mit Hilfe des Filters kann z. B. die Anzeige von Javaapplets oder Javascript unterdr?ckt werden. Group: Framework SubGroup: Core::Web Valid: 0 Required: 0 Config-Setting: $Self->{'Frontend::Output::PostFilter'}->{'ActiveElementFilter'} = { 'Debug' => '0', 'Module' => 'Kernel::Output::HTML::OutputFilterActiveElement' }; Description Value Description: PGP aktivieren? Group: Framework SubGroup: Crypt::PGP Valid: 1 Required: 1 Config-Setting: $Self->{'PGP'} = '0'; Description Value Description: Pfad zum PGP Binary. Group: Framework SubGroup: Crypt::PGP Valid: 1 Required: 1 Config-Setting: $Self->{'PGP::Bin'} = '/usr/bin/gpg'; Description Value Description: Optionen f?r das PGP Binary. Group: Framework SubGroup: Crypt::PGP Valid: 1 Required: 1 Config-Setting: $Self->{'PGP::Options'} = '--homedir /opt/otrs/.gnupg/ --batch --no-tty --yes'; Description Value Description: Kennwort f?r PGP-Schl?ssel. Group: Framework SubGroup: Crypt::PGP Valid: 1 Required: 1 Config-Setting: $Self->{'PGP::Key::Password'} = { '488A0B8F' => 'SomePassword', 'D2DF79FA' => 'SomePassword' }; Description