OTRS 2.0 - Admin-Handbuch Copyright (c) 2003-2006 OTRS AG Christian Schoepplein, 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 Auszuegen 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. Alle Warennamen werden ohne Gewaehrleistung der freien Verwendbarkeit benutzt und sind moeglicherweise eingetragene Warenzeichen. Die Firma OTRS AG richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Andere hier genannte Produkte koennen Warenzeichen des jeweiligen Herstellers sein. __________________________________________________________ Inhaltsverzeichnis Vorwort 1. Allgemeines zu Trouble Ticket Systemen 1.1. Was ist ein Trouble Ticket System, wann wird es benoetigt? 1.2. Was ist ein Trouble Ticket? 2. OTRS - Open Ticket Request System 2.1. Allgemeines 2.2. Features 2.3. Hard- und Software-Anforderungen 2.4. Community 2.5. Kommerzieller Support fuer OTRS 3. Installation des OTRS Framework 3.1. Der einfache Weg - Installation fertiger Pakete 3.1.1. Installation des rpm-Softwarepackets auf einer SUSE Linux Distribution 3.1.2. Installation von OTRS auf einer Debian-Distribution 3.1.3. Installation von OTRS unter Microsoft Windows 3.2. Manuelle Installation (Linux, Unix) 3.2.1. Vorbereiten der manuellen Installation 3.2.2. Installation der fuer OTRS benoetigten perl-Module 3.2.3. Konfiguration des apache Webservers 3.2.4. Einrichten der Datenbank 3.2.5. Einrichten der von OTRS benoetigten cron-Jobs 4. Die ersten Schritte in OTRS 4.1. Agenten Weboberflaeche 4.2. Kunden Weboberflaeche 4.3. Public Weboberflaeche 4.4. Die erste Anmeldung am System 4.5. Die Benutzeroberflaeche im Ueberblick 4.6. Was verbirgt sich hinter dem Begriff Queue? 4.7. Benutzereinstellungen 5. Der Administrationsbereich von OTRS 5.1. Allgemeines zum Administrationsbereich 5.2. Benutzer-, Gruppen- und Rollenverwaltung 5.2.1. Benutzer 5.2.2. Gruppen 5.2.3. Rollen 5.3. Kundenbenutzer und -gruppen 5.3.1. Kunden Benutzer 5.3.2. Kundengruppen 5.4. Queues 5.5. Anreden, Signaturen, Anlagen und Antwortvorlagen 5.5.1. Anreden 5.5.2. Signaturen 5.5.3. Anlagen 5.6. Automatische Antworten 5.7. Emailadressen 5.8. Benachrichtigungen 5.9. SMIME 5.10. PGP 5.11. Status 5.12. Die Admin GUI (SysConfig) 5.13. Einrichten von POP3-Konten 5.14. Einrichten von Filterregeln 5.15. Ausfuehren von automatisierten Jobs mit Hilfe des GenericAgents 5.16. Administratoren Email 5.17. Sitzungsverwaltung 5.18. System Log 5.19. SQL Abfragen mit Hilfe der Selectbox 5.20. Paket Verwaltung 6. Konfiguration des Systems 6.1. Die Konfigurationsdateien von OTRS 6.2. Konfiguration des Systems mit Hilfe des grafischen Konfigurations-Frontends 7. Emails versenden/empfangen 7.1. Emails versenden 7.1.1. Via Sendmail (Standard) 7.1.2. Via SMTP relay/smarthost 7.2. Emails empfangen 7.2.1. Via POP3-Konten - der einfache Weg (PostMasterPOP3.pl) 7.2.2. Via Kommandozeilen-Programm und z. B. procmail (PostMaster.pl) 7.2.3. Emails via POP3 oder IMAP und fetchmail fuer PostMaster.pl empfangen 7.2.4. Filterung/Verteilung ueber PostMaster-Module (fuer komplexere Verteilungsszenarien) 8. Zeitabhaengige Funktionen in OTRS 8.1. Relevante Zeiten fuer das System festlegen 8.1.1. TimeWorkingHours 8.1.2. TimeVacationDays 8.1.3. TimeVacationDaysOneTime 8.2. Automatische Freigabe von Tickets 8.3. Erinnerungs Tickets 8.4. Eskalation von Tickets 9. Einbinden externer Back-ends 9.1. Kundenbenutzerdaten 9.2. Kundenbenutzer Back-end 9.2.1. Datenbank (Standard) 9.2.2. LDAP 9.2.3. Verwenden mehrerer Kunden Back-ends 9.3. Back-ends fuer die Authentifizierung von Agenten und Kunden 9.3.1. Authentifizierungs Back-ends fuer Agenten 9.3.2. Authentifizierungs Back-ends fuer Kunden 9.4. Kunden-Selbstanmeldung anpassen 9.4.1. Anpassen der Weboberflaeche 9.4.2. Kunden-Mapping 9.4.3. Anpassen der Kunden-Tabelle 10. Anpassen der Ticket Status und Ticketstatustypen 11. Anpassen der Ticket Prioritaeten 12. Erstellung eigener Themes 13. Uebersetzung in verschiedene Sprachen 14. PGP 15. S/MIME 16. Zusaetzliche Applikationen 16.1. Kalender 16.2. ContentManager 16.3. Dateimanager 16.4. Webmailer 16.5. FAQ 16.6. SystemStatus 16.7. Benchmark 17. Leistungsverbesserung 17.1. OTRS 17.1.1. TicketIndexModule 17.1.2. TicketStorageModule 17.2. Datenbank 17.2.1. MySQL 17.2.2. PostgreSQL 17.3. Webserver 17.3.1. Datenbank Verbindung 17.3.2. Vorgeladene Module - startup.pl 17.3.3. Perl Module bei Aenderung neu laden 17.3.4. Die richtige Strategie waehlen 17.3.5. mod_gzip/mod_deflate 17.3.6. mod_dosevasive 18. Datensicherung 18.1. Backup 18.2. Restore A. Weitere Quellen A.1. Homepage OTRS.org A.2. Mailinglisten A.3. Fehler berichten A.4. Kommerzieller Support B. Config Referenzliste B.1. Framework B.1.1. Core B.1.2. Core::Log B.1.3. Core::MIME-Viewer B.1.4. Core::Package B.1.5. Core::Sendmail B.1.6. Core::Session B.1.7. Core::SpellChecker B.1.8. Core::Time B.1.9. Core::Web B.1.10. Crypt::PGP B.1.11. Crypt::SMIME B.1.12. Frontend::Admin::ModuleRegistration B.1.13. Frontend::Agent B.1.14. Frontend::Agent::Auth::LDAP B.1.15. Frontend::Agent::ModuleNotify B.1.16. Frontend::Agent::ModuleRegistration B.1.17. Frontend::Agent::Preferences B.1.18. Frontend::Customer B.1.19. Frontend::Customer::Auth B.1.20. Frontend::Customer::ModuleNotify B.1.21. Frontend::Customer::ModuleRegistration B.1.22. Frontend::Customer::Preferences B.2. Ticket B.2.1. Core::LinkObject B.2.2. Core::PostMaster B.2.3. Core::Stats B.2.4. Core::Ticket B.2.5. Core::TicketFreeText B.2.6. Frontend::Admin::ModuleRegistration B.2.7. Frontend::Agent B.2.8. Frontend::Agent::ModuleNotify B.2.9. Frontend::Agent::ModuleRegistration B.2.10. Frontend::Agent::NavBarModule B.2.11. Frontend::Agent::Preferences B.2.12. Frontend::Agent::Ticket::ArticleAttachmentMod ule B.2.13. Frontend::Agent::Ticket::ArticleComposeModule B.2.14. Frontend::Agent::Ticket::ArticleViewModule B.2.15. Frontend::Agent::Ticket::ArticleViewModulePre B.2.16. Frontend::Agent::Ticket::MenuModule B.2.17. Frontend::Agent::Ticket::MenuModulePre B.2.18. Frontend::Agent::Ticket::ViewBounce B.2.19. Frontend::Agent::Ticket::ViewClose B.2.20. Frontend::Agent::Ticket::ViewCompose B.2.21. Frontend::Agent::Ticket::ViewEmailNew B.2.22. Frontend::Agent::Ticket::ViewForward B.2.23. Frontend::Agent::Ticket::ViewHistory B.2.24. Frontend::Agent::Ticket::ViewMailbox B.2.25. Frontend::Agent::Ticket::ViewMerge B.2.26. Frontend::Agent::Ticket::ViewMove B.2.27. Frontend::Agent::Ticket::ViewNote B.2.28. Frontend::Agent::Ticket::ViewOwner B.2.29. Frontend::Agent::Ticket::ViewPending B.2.30. Frontend::Agent::Ticket::ViewPhone B.2.31. Frontend::Agent::Ticket::ViewPhoneNew B.2.32. Frontend::Agent::Ticket::ViewQueue B.2.33. Frontend::Agent::Ticket::ViewSearch B.2.34. Frontend::Agent::Ticket::ViewStatus B.2.35. Frontend::Agent::Ticket::ViewZoom B.2.36. Frontend::Customer B.2.37. Frontend::Customer::ModuleRegistration B.2.38. Frontend::Customer::Preferences B.3. FAQ B.3.1. Core B.3.2. Core::LinkObject B.3.3. Frontend::Agent::ModuleRegistration B.3.4. Frontend::Customer::ModuleRegistration B.3.5. Frontend::Public B.3.6. Frontend::Public::ModuleRegistration C. Danksagungen D. GNU Free Documentation License 0. PREAMBLE 1. APPLICABILITY AND DEFINITIONS 2. VERBATIM COPYING 3. COPYING IN QUANTITY 4. MODIFICATIONS 5. COMBINING DOCUMENTS 6. COLLECTIONS OF DOCUMENTS 7. AGGREGATION WITH INDEPENDENT WORKS 8. TRANSLATION 9. TERMINATION 10. FUTURE REVISIONS OF THIS LICENSE How to use this License for your documents Tabellenverzeichnis 3-1. Die von OTRS benoetigten perl-Module 3-2. Die verschiedenen Skripte fuer die cron-Jobs von OTRS 5-1. Standardmaessig vorhandene Gruppen in OTRS 5-2. Berechtigungen in den Benutzergruppen von OTRS 5-3. Ereignistypen fuer automatische Antworten 5-4. Funktion der verschiedenen X-OTRS-Header A-1. Mailinglisten Beispiele 5-1. Aussortierung von Spammails in eine bestimmte Queue 7-1. Beispiel .fetchmailrc 7-2. Beispiel-Jobs fuer das Filtermodul Kernel::System::PostMaster::Filter::Match 7-3. Beispiel-Job fuer das Filtermodul Kernel::System::PostMaster::Filter::CMD 8-1. Festlegen der fuer das System relevanten Arbeitsstunden 8-2. Festlegen von regelmaessig wiederkehrenden Feiertagen 8-3. Festlegen von unregelmaessig wiederkehrenden Feiertagen 8-4. GenericAgent Job zum Versand von Eskalations Benachrichtigungen 9-1. Konfiguration eines DB Kunden Back-ends 9-2. Firmen Tickets mit einem DB Back-end 9-3. Konfiguration eines LDAP Kunden Back-ends 9-4. Firmen Tickets mit einem LDAP Back-end 9-5. Gleichzeitige Einbindung mehrerer verschiedener Kunden Back-ends 9-6. Agentenauthentifizierung gegen ein DB Back-end 9-7. Agentenauthentifizierung gegen ein LDAP Back-end 9-8. Agentenauthentifizierung ueber HTTPBasic 9-9. Agentenauthentifizierung gegen ein Radius Back-end 9-10. Kundenauthentifizierung gegen ein DB Back-end 9-11. Kundenauthentifizierung gegen ein LDAP Back-end 9-12. Kundenauthentifizierung ueber HTTPBasic 9-13. Kundenauthentifizierung gegen ein Radius Back-end __________________________________________________________ Vorwort 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 fuer 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 Vollstaendigkeit. Mit Sicherheit haben sich Fehler eingeschlichen, wurden manche Dinge umstaendlich erklaert oder sind einige wichtige Dinge komplett vergessen worden. Mit Sicherheit werden auch manche Kapitel noch mal ueberarbeitet bzw. neue Kapitel oder Abschnitte hinzugefuegt werden. Da das Buch versucht, sich an den Beduerfnissen von OTRS Administratoren und OTRS Neulingen zu orientieren und da die Qualitaet der folgenden Kapitel so hoch wie moeglich sein soll, sind wir auf Ihr Feedback angewiesen. Bitte teilen Sie uns mit, wenn Sie Abschnitte in diesem Buch vermissen, wenn Dinge fuer Sie unverstaendlich erklaert sind oder auch wenn Sie Rechtschreib-, Tipp oder Grammatikfehler in diesem Buch entdecken. Jede Art von Rueckmeldung ist ausdruecklich erwuenscht und sollte durch einen Eintrag auf http://bugs.otrs.org an uns gerichtet werden, da sie so nicht verloren geht und direkt beim zustaendigen Ansprechpartner landet. Wir bedanken uns schon jetzt fuer jede Art von Mithilfe! __________________________________________________________ Kapitel 1. Allgemeines zu Trouble Ticket Systemen In diesem Abschnitt soll kurz die grundlegende Idee, die hinter Trouble Tickets im Allgemeinen und Trouble Ticket Systemen im Speziellen steht, erlaeutert werden. An einem kleinen Beispiel wird gezeigt, wofuer Trouble Ticket Systeme in der Praxis verwendet werden koennen und wo die Vorteile dieser Systeme liegen. __________________________________________________________ 1.1. Was ist ein Trouble Ticket System, wann wird es benoetigt? Das folgende Beispiel soll verdeutlichen, was ein Trouble Ticket System ist und wie damit in der Praxis Zeit und Geld eingespart werden koennen. Nehmen wir an, dass Max Mustermann Fabrikant ist und Videorekorder produziert. Da die Programmierung der Videorekorder sehr unuebersichtlich und kompliziert ist, wenden sich die Kunden von Herrn Mustermann gerne und haeufig 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 muessen, bis die Antwort mit der rettenden Loesung bei ihnen eintrifft. Manchen Kunden dauert dies jedoch zu lange, eine weitere Email mit dem gleichen Inhalt wird an Herrn Mustermann geschickt. Die Emails mit den Supportanfragen werden alle in eine INBOX weitergeleitet, wie sie von fast allen Emailprogrammen verwendet wird. An manchen Tagen ist die Anfragewelle besonders gross und Herr Mustermann sieht sich ausserstande, 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 Emails 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. Darueber hinaus hat Herr Mustermann keinen Einblick darueber, welcher Mitarbeiter wann was welchem Kunden gesagt hat, welche Probleme besonders haeufig auftreten und wie gross sein gesamter Aufwand fuer den Kundensupport ist. Von einem Kollegen erfaehrt Herr Mustermann schliesslich, dass es Trouble Ticket Systeme gibt, die genau die Probleme loesen, die Herr Mustermann mit dem Support fuer seine Kunden hat. Herr Mustermann entscheidet sich fuer das offene Trouble Ticket Request System OTRS und installiert dieses System auf einem Rechner, der ueber einen Webserver sowohl fuer seine Mitarbeiter als auch ueber das Internet erreichbar ist. Von nun an werden die Hilferufe der Kunden nicht mehr laenger an seine private INBOX, sondern direkt an den Mail-Account fuer OTRS weitergeleitet. OTRS hat eine Schnittstelle zur INBOX fuer die Supportanfragen, so dass alle ankommenden Emails automatisch ins Trouble Ticket System eingespeist werden. Unabhaengig ob Herr Mustermann nun gerade anwesend ist oder nicht, generiert OTRS eine automatische Antwort und teilt dem Kunden mit, dass seine Email angekommen ist und so schnell wie moeglich bearbeitet wird. Dabei wird eine eindeutige Trouble Ticket Nummer vergeben. Der Kunde ist gluecklich, dass sein Flehen schnell erhoert wurde und wartet gespannt auf eine Antwort. Sowohl Herr Mustermann als auch die Entwickler Meier und Schulze koennen nun ueber einen beliebigen Internetbrowser und die Weboberflaeche 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 Loesungsmail am folgenden Tag. Herr Meier ist jedoch gerade mit anderen Dingen beschaeftigt, so dass sich Herr Mustermann der Sache annimmt. Ueber die History-Funktion von OTRS kann er jetzt auf alle vergangenen Emails von Herrn Schmidt und Herrn Meier zugreifen, deren Inhalt abfragen und eine ausfuehrlichere Antwort versenden. Herr Schmidt erhaelt nun die Loesung fuer sein Problem, weiss aber nicht, dass diese von unterschiedlichen Personen stammt. Natuerlich ist dies nur ein sehr kleiner Einblick in die Funktionalitaeten von Trouble Ticket Systemen. Da Herr Mustermann eine kleine Firma fuehrt, erhaelt er vielleicht nur wenige Emails mit Supportanfragen pro Tag, die er vielleicht noch ganz ueberschaulich 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. Spaetestens dann rechnet sich der Einsatz von Trouble Ticket Systemen wie OTRS. Der Einsatz von Trouble Ticket Systemen kann also fuer solche Umgebungen grosse Vorteile bringen, in denen viele Anfragen per Email oder Telefon anfallen und wo die Anfragen von verschiedenen Mitarbeitern bearbeitet werden. Trouble Ticket Systeme helfen dabei, Supportaufgaben zu strukturieren und zu beschleunigen, ebenfalls koennen Arbeitsablaeufe abgebildet werden. Durch Systeme wie OTRS laesst 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. __________________________________________________________ 1.2. Was ist ein Trouble Ticket? Ein Trouble Ticket laesst 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 traegt nun seine Diagnose sowie die verordnete Therapie und Medikation ein und dokumentiert deren Erfolg. Das Krankenblatt gibt nun einen schnellen Ueberblick, gewaehrleistet 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 Krankenblaetter aus dem obigen Beispiel, als normale Emails behandelt und gespeichert. Schickt z. B. ein Kunde eine Anfrage an das Trouble Ticket System, wird das Krankenblatt eingerichtet, ein neues Ticket wird geoeffnet. 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 Veraenderung oder Erweiterung des Krankheitsbildes. Ein Ticket gilt als erledigt bzw. geschlossen, wenn eine Antwort auf die Anfrage an den Kunden zurueckgesendet wurde oder das Ticket ueber das System als geschlossen markiert wird. Antwortet ein Kunde auf ein bereits geschlossenes Ticket, so wird es erneut geoeffnet und die neuen Informationen ergaenzt. 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 Emails ist es moeglich, dass diese auch Email-Anhaenge enthalten koennen. Zusaetzlich zu den normalen Informationen einer Email lassen sich beliebige Notizen zu jedem Ticket hinzufuegen. Die Tickets selbst werden auf der Festplatte bzw. in einer Datenbank archiviert, ebenso zusaetzliche 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 ueber den Datenbestand wird mit Hilfe aller vorhandenen Informationen zu den Tickets realisiert. __________________________________________________________ Kapitel 2. OTRS - Open Ticket Request System In diesem Abschnitt werden die Features des Open Ticket Request Systems (OTRS) vorgestellt. Des Weiteren wird naeher auf die Systemanforderungen von OTRS eingegangen und erlaeutert, wie Kontakt zur OTRS-Community aufgenommen werden kann bzw. wie kommerzieller Support erhaeltlich ist. __________________________________________________________ 2.1. Allgemeines 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 moeglich, das System nicht nur ueber einen PC, sondern auch von Mobiltelefonen und anderen Handcomputern, welche HTML unterstuetzen, zu benutzen. Als Client kann jedes Betriebssystem eingesetzt werden. OTRS ist in mehrere Komponenten aufgeteilt. Als Basis wird ein Framework benoetigt, der alle grundlegenden Funktionen des Systems und das Trouble Ticket System enthaelt. An zusaetzlichen Komponenten koennen ein Webmailer, ein Dateimanager, ein Contentmanager, ein Kalender und ein Modul zur Ausgabe verschiedener Systemstatus bequem ueber die Weboberflaeche nachinstalliert werden. __________________________________________________________ 2.2. Features OTRS bietet viele verschiedene Features. Die folgende Aufzaehlung gibt einen Ueberblick ueber die wichtigsten Eigenschaften und Faehigkeiten des zentralen OTRS-Frameworks. Die Features von OTRS * Webinterface: + Leichte und intuitive Bedienung ueber einen HTML-Browser. + Auf aktive Inhalte wie Flash oder Java-Applets wird in der Weboberflaeche bewusst verzichtet. Das System kann somit mit nahezu allen Browsern benutzt werden, auch von Mobiltelefonen oder Handcomputern aus. + Eine Weboberflaeche zur Administration des Systems ist vorhanden. + Ein Webinterface fuer die Mitarbeiter (Agenten) zur Bearbeitung von Kundenanfragen ist verfuegbar. + Eine Weboberflaeche fuer Kunden, ueber die Nachrichten an zustaendige Agenten geschickt werden koennen und der Status eigener Tickets abgerufen werden kann, ist vorhanden. + Unterstuetzung fuer verschiedene Oberflaechen-Layouts (themes). + Unterstuetzung von vielen Sprachen. + Eigene Anpassungen der Ausgabe-Vorlagen sind moeglich (dtl). + Mehrfach-Anhaenge sind ueber die Weboberflaeche moeglich. * Email-Schnittstelle: + Unterstuetzung fuer Email-Anhaenge (MIME support). + Automatische Umwandlung von HTML- in reine Text-Nachrichten (hoehere Sicherheit vor schaedlichen Inhalten und schneller durchsuchbar). + Filterung von Emails ueber eigene X-Header-Eintraege oder Mailadressen, z. B. fuer die Aussortierung von Spam. + PGP-Support, Erstellung und Import eigener Zertifikate, verschluesselter und signierter Mails, Anzeige von verschluesselten und signierten Nachrichten. + Unterstuetzung fuer die Verschluesselung und Anzeige von SMIME-Nachrichten. + Automatisierte Antworten (auto responder) fuer die Benachrichtigung von Kunden, abhaengig von der Queue konfigurierbar. + Email-Benachrichtigungen fuer Agenten ueber neue Tickets, Follow-ups oder freigegebene Tickets. + Follow-ups an Hand von Reference- oder In-Reply-To-Headern. * Tickets: + Erweiterte Queue-Ansicht, Uebersicht ueber alle Anfragen innerhalb einer Queue. + Sperren von Tickets. + Erstellung eigener Antwortvorlagen. + Erstellung eigener auto responder, abhaengig von der Queue. + Ticket-History, Uebersicht ueber die komplette Entwicklung eines Tickets, Aenderungen der Ticketstatus, Uebersicht ueber die verschidenen Aktionen fuer ein Ticket usw. + Druckansicht fuer Tickets. + Hinzufuegen eigener (interner oder externer) Notizen zu einem Ticket (eigener Text und Dateianhaenge). + Moeglichkeit zum Zoomen von Tickets. + Definition von ACL's (access control lists) fuer Tickets. + Tickets koennen an andere Email-Adressen weiter- oder umgeleitet werden (forwarding, bouncing). + Verschieben von Tickets zwischen verschiedenen Queues. + Festlegen der Prioritaet fuer Tickets. + Erfassung der Bearbeitungsdauer fuer Tickets. + Anstehende Aufgaben fuer ein Ticket festlegen (pending features). + Massenoperationen auf Tickets sind moeglich (bulk features). + Automatische und zeitgesteuerte Aktionen koennen mit Hilfe eines sog. Generic-Agenten auf Tickets ausgefuehrt werden. + Volltextsuche ueber den gesamten Ticketbestand. * System: + OTRS laeuft unter vielen Betriebssystemen (Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x, Microsoft Windows). + Unterstuetzung von ASP (active service providing). + Verknuepfung von Objekten wie z. B. Tickets, FAQ-Eintraegen o.ae. innerhalb des Systems. + Einbindung externer Datenquellen fuer die Kundendaten, z. B. ueber AD, eDirectory oder OpenLDAP). + Festlegen einer eigenen Kennzeichnung fuer Tickets, z. B. Cal#, Ticket#, Request# o.ae. + Festlegen einer eigenen Nummerierung fuer Tickets. + Unterstuetzung verschiedener Datenbanktypen fuer die zentrale Datenbank von OTRS (MySQL, PostgreSQL, SAPDB, Oracle usw.). + Framework fuer die Erstellung von Statistiken. + utf-8-Unterstuetzung fuer Front- und Back-End. + Die Authentifikation fuer Agenten oder Kunden kann unabhaengig voneinander ueber eine Datenbank, LDAP, HTTPAuth oder Radius realisiert werden. + Unterstuetzung von Benutzer-Accounts, Benutzergruppen und Rollen. + Unterstuetzung verschiedener Zugriffsrechte, z. B. auf Queues oder Systembereiche. + Die Erstellung von Standardantworten ist moeglich. + Unter-Queues werden unterstuetzt. + Anreden und Signaturen koennen abhaengig von der Queue definiert werden. + Email-Benachrichtigungen fuer Administratoren. + Bekanntgabe von Informationen zu Updates ueber die Weboberflaeche oder via Email. + Festlegen von Ablauffristen fuer problematische Tickets. + Unterstuetzung fuer verschiedene Zeitzonen. + Einfache Einbindung eigener Addons und Module mit Hilfe der OTRS API. + Einfache Erstellung eigener Front-Ends, z. B. X11, Console usw. __________________________________________________________ 2.3. Hard- und Software-Anforderungen OTRS kann unter vielen Betriebssystemen installiert werden. Neben Linux und den verschiedenen Unix-Derivaten (z. B. OpenBSD oder FreeBSD), laeuft OTRS auch unter allen Windows-Versionen. Bezueglich der Hardware empfiehlt es sich, mindestens einen 2 GHz Pentium Xeon oder vergleichbare CPU, 2 GB RAM und eine 160 GB Festplatte zu verwenden. Fuer den Betrieb von OTRS werden einige externe Software-Komponenten benoetigt. Ein Web- sowie ein Datenbankserver und eine funktionierende perl-Installation mit einigen Zusatzmodulen sind die Grundvorraussetzungen fuer ein funktionierendes System. Der Webserver und perl muessen auf der gleichen Maschine installiert sein, auf der spaeter auch OTRS ausgefuehrt werden soll. Das Datenbank-Back-End kann auf der lokalen oder auf einer entfernten Maschine installiert werden. Fuer den Webserver wird empfohlen, auf apache 1.3.x oder apache 2.x zurueck 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 Ausfuehrung von perl-Skripten unterstuetzt, fuer den Betrieb von OTRS geeignet sein. Als Datenbank-Back-End eignen sich besonders MySQL ab Version 3.1.x oder PostgreSQL. Grundsaetzlich sollten jedoch alle Datenbankserver zusammen mit OTRS verwendet werden koennen, die SQL als Datenbanksprache unterstuetzen. Ein Vorteil der Benutzung von MySQL ist, dass OTRS ueber einen Webinstaller die Datenbank und Tabellen automatisch anlegen kann. Fuer perl gilt mindestens die Version 5.8 zu verwenden. Es werden einige Zusatzmodule benoetigt, die Sie entweder direkt ueber die Shell von perl und CPAN oder mit Hilfe des Paketmanagers (yast, apt-get) Ihres Betriebssystems einspielen muessen. Im Abschnitt fuer die manuelle Installation der fuer OTRS benoetigten perl-Module wird beschrieben, wie Sie perl-Module manuell einspielen koennen. Wenn Sie ein bereits vorgefertigtes OTRS-Paket fuer Ihr Betriebssystem zur Installation verwenden (rpm, Windows-Installer), sollten die benoetigten perl-MOdule automatisch installiert werden. __________________________________________________________ 2.4. Community Um OTRS hat sich in den letzten Jahren eine grosse Community gebildet. Ueber 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 koennen ueber ein Bug-Tracking-System gemeldet werden und erreichen so die zustaendigen Entwickler bzw. gehen nicht verloren, so dass schnell Fixes bereit gestellt werden koennen. [homepage-otrs.png] Die Community ist ueber die Homepage http://www.otrs.org zu erreichen. __________________________________________________________ 2.5. Kommerzieller Support fuer OTRS Neben der Unterstuetzung aus der Open Source Community auf http://www.otrs.org ist auch kommerzieller Support rund um OTRS erhaeltlich. Ueber 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 fuer OTRS und richtet sich an den Mittelstand, Behoerden, Institutionen und grosse Konzerne. Von der professionellen Beratung zum Einsatz des Trouble Ticket Systems bis hin zur kompletten Installation und Wartung mit 24-Stunden Rueckrufservice sind verschiedene Supportpakete erhaeltlich. 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 koennen ueber die Mailadresse sales at otrs.com erfragt werden. __________________________________________________________ Kapitel 3. Installation des OTRS Framework Dieser Abschnitt beschreibt die Installation und die grundlegende Einrichtung des zentralen OTRS Frameworks. Dabei wird auf die Installation von bereits fertigen Paketen fuer die Betriebssysteme Linux und Microsoft Windows eingegangen, aber auch die manuelle Installation direkt ueber die Quellen erklaert, wodurch eine Installation auch auf anderen, hier nicht naeher beschriebenen, Betriebssystemen uebertragbar 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 lauffaehiges OTRS auf Ihrem Betriebssystem installiert sein, an dessen Weboberflaeche Sie sich bereits als OTRS-Administrator anmelden koennen. __________________________________________________________ 3.1. Der einfache Weg - Installation fertiger Pakete Der einfachste und komfortableste Weg ein lauffaehiges OTRS zu installieren ist sicherlich, auf bereits vorgefertigte Pakete zurueck zu greifen. Viele bereits vorgefertigte Installations-Pakete sind im Download-Bereich unter http://www.otrs.org zu finden. Da der Aufwand viel zu gross waere, die Installation aller dort aufgefuehrten Pakete in dieser Dokumentation anzufuehren, soll im Folgenden nur naeher auf die Installation von OTRS unter SUSE Linux, Debian und Microsoft Windows eingegangen werden. Sehen Sie unter der o.g. URL nach, ob auch fuer Ihr Betriebssystem ein fertiges Installations-Paket vorhanden ist und greifen Sie nur auf die manuelle Installation zurueck, wenn Sie keine andere Moeglichkeit haben. __________________________________________________________ 3.1.1. Installation des rpm-Softwarepackets auf einer SUSE Linux Distribution Dieser Abschnitt beinhaltet die Anleitung fuer 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 benoetigt, die nicht standardmaessig in einer typischen SUSE-Installation enthalten sind. yast sollte die bessere Wahl sein, da es alle Abhaengikeiten automatisch beachtet und aufloesen kann. Sollten Sie den Weg ueber die Kommandozeile mit rpm bevorzugen, so muessen 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|star t-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 Aenderungen in der Konfiguration zu uebernehmen. linux:~ # rcapache restart Shutting down httpd done Starting httpd [ PERL ] done linux:~ # Der naechste Schritt ist das Aufsetzen der Datenbank. Wenn sie MySQL als Datenbankserver verwenden, koennen 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.png] [installer1.png] Warnung Es ist niemals eine gute Idee, Standardpasswoerter zu verwenden! Bitte aendern Sie deshalb unbedingt das von OTRS standardmaessig gesetzte Passwort! [installer2.png] [installer3.png] [installer4.png] 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. don e 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 <<-- don e don e linux:~ # Die Installation von OTRS ist beendet, Sie sollten das System nun verwenden koennen. Um sich in die Weboberflaeche des Trouble Ticket Systems einloggen zu koennen, 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 Wuenschen entsprechend. Als Benutzername verwenden Sie root@localhost, das Passwort lautet root. Warnung Bitte aendern Sie auch dieses Passwort schnellstmoeglich! Es handelt sich auch hier um ein Standardpasswort! __________________________________________________________ 3.1.2. Installation von OTRS auf einer Debian-Distribution Eine ausfuehrliche Beschreibung zur Installation von OTRS auf Debian-Systemen wurde dankenswerter Weise vom Maintainer des OTRS-Pakets, Torsten Werner, bereit gestellt. Sie kann ueber den Link http://www.writely.com/View.aspx?docid=drm3kmx_0cbr3x9 eingesehen werden. __________________________________________________________ 3.1.3. Installation von OTRS unter Microsoft Windows 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. Anschliessend fuehren Sie den Installer einfach aus und folgen den einzelnen Installationsschritten. Wichtig Der Windows-Installer fuer OTRS beinhaltet bereits alle Komponenten, die fuer den Betrieb von OTRS benoetigt werden. D.h., es wird zusaetzlich zum eigentlichen OTRS der apache2 Webserver, MySQL, perl mit den fuer OTRS benoetigten Modulen und cron fuer Windows installiert. Aus diesem Grund ist es empfehlenswert OTRS ueber den Installer nur auf solchen Windowssystemen zu installieren, auf denen noch kein apache2 bzw. ein anderer Webserver und MySQL laeuft. __________________________________________________________ 3.2. Manuelle Installation (Linux, Unix) 3.2.1. Vorbereiten der manuellen Installation Wenn Sie OTRS manuell ueber die Quellen installieren moechten oder muessen, 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 spaeter nicht mit root-Rechten laufen sollen, muss im naechsten Schritt ein Benutzer fuer 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 hinzugefuegt werden. linux:/opt# useradd -d /opt/otrs/ -c 'OTRS user' otrs linux:/opt# usermod -G nogroup otrs linux:/opt# Im naechsten 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 fuer 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 ] Laeuft 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. __________________________________________________________ 3.2.2. Installation der fuer OTRS benoetigten perl-Module Fuer den Betrieb von OTRS werden einige perl-Module benoetigt. Wenn Sie OTRS manuell einrichten, muessen Sie wahrscheinlich einige dieser Module per Hand nachinstallieren. Dies koennen Sie entweder ueber den Paketmanager ihrer Distribution erledigen (yast, apt-get), oder, wie in diesem Kapitel beschrieben, direkt ueber die Shell von perl und CPAN. Die folgenden perl-Module werden von OTRS benoetigt. Tabelle 3-1. Die von OTRS benoetigten perl-Module Name Beschreibung CGI Mit diesem Modul wird die Darstellung der OTRS-Oberflaeche als Webinterface ermoeglicht. Date::Pcalc Dieses Modul enthaelt Berechnungsgrundlagen zum gregorianischen Kalender und wird in OTRS z. B. fuer die zeitspezifischen Berechnungen auf Tickets benoetigt. DBI Dieses Modul wird von OTRS fuer die Verbindung zum Datenbank-Backend benoetigt. DBD::mysql Modul zum Verbindungsaufbau zum MySQL-Datenbank-Backend. Digest::MD5 Ermoeglicht 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 fuer die Verarbeitung von Nachrichten mit MIME-Teil. Mail::Internet Modul fuer die Bearbeitung von Emails nach RFC 822 Net::DNS Schnittstelle zum Domain Name System (DNS). Net::POP3 Modul mit Funktionen fuer den Zugriff auf einen POP3-Server. Net::LDAP Modul zur Verarbeitung von Anfragen an ein LDAP-Directory. Dieses Modul wird nur benoetigt, 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. fuer die Anmeldung an Mailservern benoetigt. GD Schnittstelle zur Gd Graphics Library. Wird nur benoetigt, wenn das Statistikmodul von OTRS verwendet werden soll. GD::Text, GD::Graph, GD::Graph::lines, GD::Text::Align Text- und Grafikwerkzeuge fuer die Benutzung zusammen mit der GD Graphics Library. Diese Komponenten werden nur benoetigt, wenn das Statistikmodul von OTRS verwendet werden soll. XML::Parser Dieses Modul wird benoetigt, um Konfigurationsparameter aus XML-Files auszulesen bzw. Konfigurationen in XML-Dateien zu schreiben. Die grafische Administrations-Oberflaeche von OTRS greift auf diese Mechanissmen zurueck. Um eines der oben aufgefuehrten 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, koennen Sie die fuer OTRS benoetigten Module mit Hilfe des Kommandos install gefolgt vom Modulnamen einrichten. CPAN weist darauf hin, wenn Abhaengigkeiten zwischen einzelnen Modulen nicht erfuellt sind und schlaegt automatisch die zusaetzlich benoetigten Module fuer die Installation vor. Nachdem Sie alle perl-Module installiert haben, koennen Sie mit Hilfe des Skriptes otrs.checkModules ueberpruefen, ob OTRS wirklich alle benoetigten 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 DBI ... ok DBD::mysql ... ok Digest::MD5 ... 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 linux:/opt/otrs/bin# Fuehren 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, verfuegt Ihre perl-Installation ueber alle von OTRS benoetigten Module und Sie koennen im naechsten 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# __________________________________________________________ 3.2.3. Konfiguration des apache Webservers In diesem Abschnitt wird beschrieben, wie der apache Webserver grundlegend fuer OTRS eingerichtet werden muss. Der Webserver solte cgi- bzw. perl-Skripte ausfuehren koennen, anderenfalls ist kein Betrieb von OTRS moeglich. Ueberpruefen Sie die Konfigurationsdateien Ihres Webservers und stellen Sie fest, ob das cgi-Modul geladen wird: Wenn Ihr Webserver die Ausfuehrung von cgi-Skripten unterstuetzt, sollte eine Zeile aehnlich der folgenden zu finden sein. LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so Um die Oberflaeche von OTRS bequem erreichen zu koennen, wird ein Alias- und ein ScriptAlias-Eintrag angelegt. Fuer 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 oeffnen 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 # AllowOverride None Options +ExecCGI -Includes Order allow,deny Allow from all AllowOverride None Order allow,deny Allow from all Speichern Sie die Datei, schliessen Sie den Editor und starten Sie Ihren Webserver neu, um die neue Konfiguration zu laden. Auf den meisten Systemen laesst sich der Webserver ueber 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 fuer OTRS. Im naechsten Schritt kann die Datenbank eingerichtet werden. __________________________________________________________ 3.2.4. Einrichten der Datenbank 3.2.4.1. Einrichtung der Datenbank mit Hilfe des Webinstallers (nur fuer MySQL) Wenn Sie MySQL als Datenbankserver einsetzen, koennen 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.png] [installer1.png] Warnung Es ist niemals eine gute Idee, Standardpasswoerter zu verwenden! Bitte aendern Sie deshalb unbedingt das von OTRS standardmaessig gesetzte Passwort! [installer2.png] [installer3.png] [installer4.png] Die OTRS Datenbank wurde aufgesetzt. Im naechsten Schritt werden die cron-Jobs eingerichtet, die von OTRS benoetigt werden. __________________________________________________________ 3.2.4.2. Manuelle Installation der OTRS Datenbank Wenn Sie den Webinstaller nicht einsetzen koennen, kann die Datenbank fuer 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# Fuer die verschiedenen Datenbanktypen sind mehrere .sql-Dateien vorhanden, die nacheinander abgearbeitet werden muessen. Um die Datenbank anzulegen, gehen Sie folgendermassen vor: Die verschiedenen Schritte fuer die manuelle Erstellung der Datenbank 1. Anlegen der Datenbank fuer OTRS: Legen Sie mit Hilfe Ihres Datenbankinterfaces bzw. Ihrer Datenbankoberflaeche die Datenbank an, die spaeter von OTRS verwendet werden soll. 2. Erstellen der Tabellen: Mit Hilfe der otrs-schema.Datenbanktyp.sql-Dateien (z. B. otrs-schema.oracle.sql, otrs-schema.postgresql.sql, usw.) koennen Sie die Tabellen innerhalb der OTRS Datenbank erzeugen. 3. Einfuegen der vom System benoetigten Daten: Damit OTRS richtig funktioniert, muessen 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. 4. Erzeugen von "foreign keys" auf andere Tabellen: Abschliessend muessen noch die "foreign keys" erstellt werden, ueber die die verschiedenen Tabellen in der OTRS Datenbank voneinander abhaengen. 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 dafuer 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 moeglich sein dies mit Hilfe Ihres Datenbankinterfaces bzw. Ihrer Datenbankoberflaeche zu erledigen. Wurden die noetigen Einstellungen fuer die Datenbank vorgenommen, muss nun noch dem Ticket System mitgeteilt werden, welche Datenbank es verwenden soll. Oeffnen Sie die Datei Kernel/Config.pm innerhalb des Homeverzeichnisses des OTRS Benutzers und passen Sie die dafuer 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, koennen im naechsten Schritt die verschiedenen cron-Jobs fuer OTRS eingerichtet werden. __________________________________________________________ 3.2.5. Einrichten der von OTRS benoetigten cron-Jobs Damit OTRS voll funktioniert, werden einige cron-Jobs benoetigt. Die cron-Jobs sollten mit denselben Benutzerrechten ausgefuehrt werden, die auch fuer die restlichen OTRS-Skripte vergeben wurden, d.h. die cronJobs sollten in die crontab des OTRS-Benutzers eingetragen werden. Alle Skripte fuer 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 zunaechst 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 Uebersicht ueber die Aufgabe der verschiedenen Skripte, die als cron-Job in der crontab des OTRS-Benutzers installiert werden sollten. Tabelle 3-2. Die verschiedenen Skripte fuer die cron-Jobs von OTRS Skript Aufgabe aaa_base Ueber dieses Skript werden die grundlegenden Einstellungen fuer die crontab des OTRS-Benutzers festgelegt. fetchmail Falls Nachrichten mit Hilfe von fetchmail in das System eingespeisst werden sollen, kann dieses Skript verwendet werden. generic_agent Mit Hilfe dieses Skripts werden die Jobs des GenericAgents ausgefuehrt, die ueber eigene Konfigurationsdateien festgelegt wurden. generic_agent-database Mit Hilfe dieses Skripts werden die Jobs des GenericAgents ausgefuehrt, die ueber dem Administrations-Bereich innerhalb von "GenericAgent" angelegt wurden. pending_jobs Mit Hilfe dieses Skripts wird das System auf "wartende" (pending) Tickets ueberprueft. postmaster Mit Hilfe dieses Skripts wird die Nachrichten-Warteschlange von OTRS ueberprueft 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 fuer die Queue-Ansicht neu erzeugt, wodurch die Anzeige beschleunigt wird. session Ueber dieses Skript werden alte und nicht mehr gueltige Session-IDs entfernt. unlock Mit Hilfe dieses Skripts wird die Freigabe von Tickets innerhalb des Systems ermoeglicht. Fuer 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 uebergeben werden. Dieser Parameter legt fest, ob die cron-Jobs installiert, deinstalliert oder neu gestartet werden. Es sind folgende Parameter zulaessig. Cron.sh { start } { stop } { restart } [ OTRS-Benutzer ] Da die cron-Jobs fuer den OTRS-Benutzer angelegt werden sollen, muss das Skript von diesem Benutzer ausgefuehrt werden. Sind Sie z. B. als Benutzer root am System angemeldet, koennen Sie mit Hilfe des Kommandos su otrs zum OTRS-Benutzer wechseln. Nehmen Sie also die Installation wie folgt vor. Warnung Bitte beachten Sie, dass durch die Verwendung von Cron.sh evtl. andere Cron-Jobs des OTRS-Benutzers ueberschrieben bzw. geloescht werden. Um weitere, nicht von OTRS benoetigte Cron-Jobs fuer 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.14 $> Copyright (c) 2002 Martin Edenhofer (using /opt/otrs) done linux:~/bin$ exit exit linux:/opt/otrs/bin# Mit Hilfe des Kommandos crontab -l -u otrs, das Sie als root ausfuehren koennen, wird die crontab-Datei des OTRS-Benutzers angezeigt und Sie koennen ueberpruefen, ob alle Eintraege vorhanden sind. linux:/opt/otrs/bin# crontab -l -u otrs # -- # cron/aaa_base - base crontab package # Copyright (C) 2002-2003 Martin Edenhofer # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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::GenericAgentMo ve" >> /dev/null # -- # cron/generic_agent - GenericAgent.pl cron of the OTRS # Copyright (C) 2001-2004 Martin Edenhofer # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 >> /de v/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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 # -- # $Id: installation-and-basic-configuration.xml,v 1.14 2006/08/21 13:08: 14 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 koennen das System nun ueber dessen Weboberflaeche weiter an Ihre Beduerfnisse anpassen und benutzen. __________________________________________________________ Kapitel 4. Die ersten Schritte in OTRS Dieser Abschnitt soll einen ersten Ueberblick ueber die Funktionsweise von OTRS und den Aufbau der Weboberflaeche des Systems geben. Es werden die Unterschiede zwischen Mitarbeitern (Agents), Kunden (Customer) und Administratoren erklaert. Anschliessend wird die erste Anmeldung als OTRS-Administrator durchgefuehrt und erlaeutert, was mit Hilfe der Benutzereinstellungen fuer jeden Account innerhalb des Systems festgelegt werden kann. __________________________________________________________ 4.1. Agenten Weboberflaeche Die Mitarbeiter bearbeiten ueber die Weboberflaeche des Systems die Anfragen der Kunden, erstellen neue Tickets fuer andere Mitarbeiter oder Kunden, legen Tickets ueber Telefongespraeche mit Kunden an, schreiben FAQ-Eintraege, bearbeiten Kundendaten usw. [login.png] Angenommen, Ihr Host mit der OTRS-Installation ist ueber die Domain http://www.example.com erreichbar, so kann der Login-Bildschirm fuer die Mitarbeiter und somit auch fuer den OTRS-Administrator ueber die URL http://www.example.com/otrs/index.pl aufgerufen werden. __________________________________________________________ 4.2. Kunden Weboberflaeche Kunden koennen ueber das speziell fuer sie vorhandene Webinterface von OTRS einen eigenen Kundenaccount anlegen, die eigenen Tickets einsehen, Tickets erstellen und bearbeiten, die Account-Einstellungen anpassen usw. [customer-login.png] Angenommen, Ihr Host mit der OTRS-Installation ist ueber die Domain http://www.example.com zu erreichen, so kann der Login-Bildschirm fuer die Kunden ueber die URL http://www.example.com/otrs/customer.pl geladen werden. __________________________________________________________ 4.3. Public Weboberflaeche Neben diesen beiden Bereichen der Weboberflaeche verfuegt OTRS weiterhin ueber ein Interface, mit dem die FAQ des Systems durchsucht werden kann und welches oeffentlich, also ohne Anmeldung, zugaenglich ist. [public-interface.png] Das oeffentliche Web-Interface ist ueber die URL http://www.example.com/otrs/faq.pl erreichbar. Ebenfalls ist ein Zugriff auf die FAQ ueber die URL http://www.example.com/otrs/public.pl moeglich. __________________________________________________________ 4.4. Die erste Anmeldung am System Wie im Abschnitt ueber die Agenten Weboberflaeche beschrieben, erreichen Sie den Bildschirm fuer die Anmeldung am System ueber die URL http://www.example.com/otrs/index.pl. [login.png] Hier haben Sie die Moeglichkeit, einen Benutzernamen und ein Kennwort anzugeben. Um sich als OTRS-Administrator anzumelden, verwenden Sie als Benutzername "root@localhost" und als Kennwort "root". Warnung Diese Zugangsdaten werden bei jeder OTRS-Installation standardmaessig vergeben. Da das Kennwort fuer den OTRS-Administrator somit oeffentlich bekannt ist, sollten Sie es schnellstmoeglich aendern! Sie koennen dies nach der Anmeldung als OTRS-Administrator ueber 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 dafuer vorgesehenen Eingabefelder ein. Mit Hilfe der Listbox unterhalb der Eingabefelder fuer den Benutzernamen und das Kennwort koennen Sie weiterhin die Sprache auswaehlen, die Sie innerhalb der Oberflaeche von OTRS verwenden moechten. Falls Sie einmal ihr Kennwort vergessen haben sollten, koennen Sie sich automatisch vom System ein neues Kennwort an die Mailadresse schicken lassen, die fuer 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 ueber den dafuer vorgesehenen Schalter ab. Kurze Zeit spaeter sollte sich in Ihrem Postfach eine Mail vom OTRS-System befinden, die das neu vergebene Kennwort enthaelt. __________________________________________________________ 4.5. Die Benutzeroberflaeche im Ueberblick Nachdem Sie sich erfolgreich am System angemeldet haben, wird die Oberflaeche von OTRS geladen. Sie befinden sich nach einer Anmeldung standardmaessig in der sog. Queue-Ansicht. Die Queue-Ansicht vermittelt einen schnellen Ueberblick ueber die Tickets in den verschiedenen Queues. Sie werden auf neue Nachrichten hingewiesen, die Anzahl ihrer gesperrten Tickets wird angezeigt usw. [first-screen.png] Um die Uebersichtlichkeit zu erhoehen, wurde die Oberflaeche 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 ueber den die Oberflaeche neu geladen werden kann. Im weissen Balken darunter, der sog. Navigationsleiste, werden verschiedene Schaltflaechen dargestellt, ueber die die Navigation im System oder die Aktivierung bestimmter Aktionen moeglich ist. Der Balken unterteilt sich in drei Abschnitte. Der linke Bereich enthaelt Schaltflaechen zur Abmeldung vom System, zur Aktivierung der Queue-Ansicht, einen Schalter, um auf das Kunden-Backend zuzugreifen oder einen Schalter zum Laden der Maske fuer die Volltextsuche ueber die im System gespeicherten Tickets. Ueber die Schalter "Phone-Ticket" und "Email-Ticket" kann ein neues Telefon- oder Email-Ticket angelegt werden. Mit Hilfe des Schalters "Statistik" wird der Bildschirm zur Ausgabe verschiedener Systemstatistiken geladen, ueber "Einstellungen" gelangen Sie in den Bereich zur Anpassung Ihrer eigenen Account-Einstellungen. "Bulk-Action" laedt den Bildschirm fuer die Ausfuehrung verschiedener Aktionen auf markierte Tickets. Hiermit koennen z.B. mehrere Tickets auf einmal geschlossen oder verschoben werden. Im mittleren Bereich des weissen Balkens werden die Schalter zur Navigation im System angezeigt. Nach der ersten Anmeldung als OTRS-Administrator ist hier nur die Schaltflaeche "Admin" aufgefuehrt. Werden spaeter weitere Module wie z.B. der Kalender oder der Dateimanager installiert, tauchen die Schalter fuer diese Komponenten ebenfalls in diesem Bereich auf. An der rechten Seite des Balkens wird angezeigt, ob neue Nachrichten fuer Sie vorhanden sind bzw. wie viele Tickets Sie gesperrt haben, d.h. von wie vielen Tickets Sie der Eigentuemer 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 durchgefuehrt werden sollten. Wurde das Kalender-Modul installiert, werden innerhalb dieses Balkens z.B. die naechsten Termine angezeigt. Der darunter liegende schwarze Balken enthaelt die gerade selektierte Queue bzw. zeigt an, dass "Meine Queues" ausgewaehlt wurde. Hinter dem Begriff "Meine Queues" verbergen sich alle Queues, die Sie fuer sich als wichtig erachten und genauer ueberwachen moechten. Sie koennen in Ihren Benutzereinstellungen die Queues auswaehlen, die Sie in "Meine Queues" aufnehmen moechten. Unter dem Bereich mit der gerade selektierten Queue wird ein grauer Balken angezeigt, der einen Ueberblick ueber die im System verfuegbaren Tickets gibt. Innerhalb des naechsten Balkens wird eine Uebersicht fuer die verschiedenen Queues und deren Anzahl an offenen Tickets praesentiert. 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. [raw-queue.png] Wenn Sie nun die Queue "Raw" auswaehlen, wird die Oberflaeche neu aufgebaut und der Inhalt dieser Queue angezeigt. Im unteren Bereich des Bildschirms erscheinen nun noch die zusaetzlichen Informationen fuer 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 fuer die Bulk-Action markiert werden kann. In der naechsten Zeile, die grau dargestellt wird, sind die Eigenschaften bzw. die Aktionen aufgefuehrt, die auf das Ticket angewendet werden koennen ("Sperren", "Inhalt", "History" usw.). In der gleichen Zeile ist rechts eingerueckt das Erstellungsdatum und die Erstellungszeit des Tickets zu erkennen. Im weiteren Verlauf teilt sich die Oberflaeche in zwei Bereiche auf. Auf der linken Seite wird in weisser 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 Prioritaet oder der aktuelle Status des Tickets angezeigt. Weiterhin kann eingesehen werden, ob das Ticket bereits einem Kunden zugeordnet wurde. Ueber verschiedene Schaltflaechen koennen 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 fuer die Erstellung eines Telefontickets. __________________________________________________________ 4.6. Was verbirgt sich hinter dem Begriff Queue? 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 naeher erklaert werden, was sich hinter dem Begriff Queue verbirgt. Normalerweise werden Emails in einer INBOX gespeichert und verwaltet. Eine INBOX ist eine grosse Datei, in der alle Emails aneinandergereiht werden. Neue Emails werden einfach an das Ende der INBOX angehaengt. Das Email-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 Email mitten aus der INBOX-Datei geloescht wird) und bereitet den Inhalt fuer Sie als Nutzer auf. Eine Queue in OTRS ist ein Mechanismus, mit dessen Hilfe viele Tickets gespeichert und verwaltet werden koennen, also auch eine Art INBOX. Als Anwender ist es voellig 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), koennen nun Tickets zwischen den Queues verschieben! Warum aber sollten sie das tun? Gehen wir zur praktischeren Erklaerung noch mal von Max Mustermanns Unternehmen aus dem Abschnitt ein Beispiel fuer ein Trouble Ticket System aus. Max Mustermann hat nach seinem anfaenglichen Support-Chaos OTRS installiert, und er und seine Mitarbeiter nutzen das System zur Bearbeitung der Anfragen fuer 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 Geraet laufen immer mehr Anfragen in das Ticket System und die Verwaltung der Emails mit einer Queue wird immer unuebersichtlicher. Deshalb entschliesst 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 laenger 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 Mueller als sog. Dispatcherin taetig 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 kuemmert sich weiter wie gewohnt um alle Arten von Anfragen und darf auf alle drei Queues zugreifen, die Moeglichkeiten der Vergabe von Zugriffsrechten innerhalb von OTRS macht es moeglich. Das Sortieren von Mails in verschiedene Queues schafft also Ordnung und mehr Uebersicht in der taeglichen Mailflut, deshalb sind Queues sehr wichtig fuer 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 koennen Sie die Struktur Ihres Unternehmens abbilden bzw. einzelne Geschaeftsvorgaenge abgrenzen. So koennte Max Mustermann neben seinem Support-Queues fuer die verschiedenen Geraete fuer 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 muessen dafuer aufgebracht werden. Queues und Unter-Queues helfen bei der Strukturierung bzw. bei der Abbildung von Ablaeufen. __________________________________________________________ 4.7. Benutzereinstellungen Die Einstellungen eines Accounts lassen sich mit Hilfe der Benutzereinstellungen den eigenen Wuenschen entsprechend anpassen. Dabei spielt keine Rolle, ob man als Mitarbeiter, Kunde oder Administrator am System angemeldet ist. Die Benutzereinstellungen sind ueber den Link "Einstellungen" sowohl innerhalb des Interfaces fuer Mitarbeiter bzw. Administratoren als auch der Oberflaeche fuer Kunden erreichbar. [customer-preferences.png] Fuer Kunden-Accounts gilt, dass die Oberflaechensprache, die maximale Anzahl an angezeigten Tickets pro Seite und die Aktualisierungszeit fuer das Kunden-Webinterface angepasst werden kann. Weiterhin ist es moeglich, das persoenliche Kennwort zu aendern und die Anzeige von geschlossenen Tickets an- bzw. abzuschalten. [agent-preferences.png] In den Benutzereinstellungen eines Mitarbeiters kann ebenfalls die Oberflaechensprache, das Anzeigeschema, das Standardwoerterbuch fuer die Rechtschreibpruefung und die Ansicht fuer die Queues ausgewaehlt werden. Weiterhin kann eingestellt werden, in welchem Zeitintervall die Oberflaeche 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 koennen Ihr Kennwort aendern und festlegen, bei welchen Ereignissen Sie vom System per Mail benachrichtigt werden moechten. Benachrichtigungen koennen verschickt werden, wenn ein neues Ticket in "Meine Queues" verfuegbar ist, wenn Sie eine Nachfrage auf ein von Ihnen gesperrtes Ticket erhalten (also wenn Sie der Eigentuemer 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 moechten, koennen Sie ebenfalls in Ihren Benutzereinstellungen auswaehlen. Sie sollten in "Meine Queues" nur die Queues aufnehmen, die fuer Sie am wichtigsten sind und die Sie besonders aufmerksam ueberwachen moechten. __________________________________________________________ Kapitel 5. Der Administrationsbereich von OTRS 5.1. Allgemeines zum Administrationsbereich Der Administrationsbereich von OTRS ist die zentrale Anlaufstelle fuer den Administrator des Ticket Systems. Innerhalb dieses Bereiches koennen alle wichtigen Einstellungen der Systemkonfiguration eingesehen bzw. geaendert und das System auf die eigenen Beduerfnisse angepasst werden. Die Administrationsoberflaeche kann ueber den Link "Admin" innerhalb der Navigationsleiste des Agent-Interfaces geladen werden. Damit dieser Link in der Navigationsleiste ueberhaupt sichtbar ist, muessen Sie als OTRS-Administrator am System angemeldet sein bzw. ueber Administrationsrechte im System verfuegen. Nach einer Standardinstallation koennen Sie sich mit dem Benutzernamen "root@localhost" und dem Kennwort "root" als OTRS-Admin am System anmelden. Warnung Bitte aendern Sie schnellstmoeglich ueber die Benutzereinstellungen das Kennwort fuer root@localhost, da es sich hierbei um ein standardmaessig vergebenes Kennwort handelt, das allgemein bekannt ist. [adminarea.png] __________________________________________________________ 5.2. Benutzer-, Gruppen- und Rollenverwaltung 5.2.1. Benutzer Ueber den Link "Benutzer" gelangen Sie in die Benutzerverwaltung von OTRS. Hier koennen Sie Benutzer anlegen, bearbeiten und deaktivieren. Weiterhin lassen sich einige grundlegende Einstellungen fuer den Benutzer festlegen, z. B. die Oberflaechensprache oder das Anzeigeschema. [admin-users.png] Anmerkung Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, koennen 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 fuer "Gueltig" auf "ungueltig" bzw. "ungueltig-temporaer". 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 fuer die Zuweisung eines Benutzers in Gruppen weitergeleitet. __________________________________________________________ 5.2.2. Gruppen Jeder Mitarbeiter mit einem Account im OTRS, sollte mindestens einer Benutzergruppe angehoeren. Ueber den Link "Gruppen" gelangen Sie in die Gruppenverwaltung von OTRS. [admin-groups.png] Anmerkung Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, koennen einmal im System angelegte Gruppen nicht entfernt werden. Um eine Gruppe zu deaktivieren, setzen Sie in den Einstellungen der entsprechenden Gruppe in der Listbox fuer "Gueltig" den Wert entweder auf "ungueltig" bzw. "ungueltig-temporaer". Nach einer Standard-Installation sind bereits vier Gruppen im System verfuegbar. Tabelle 5-1. Standardmaessig vorhandene Gruppen in OTRS Gruppe Beschreibung admin Gruppe fuer die Benutzer mit Administrationsrechten. Nach einer Installation ist in dieser Gruppe nur der Benutzer "root@localhost". faq Benutzer in dieser Gruppe duerfen lesend (ro) oder schreibend (rw) auf das FAQ-System von OTRS zugreifen. Standardmaessig befindet sich nach einer Installation kein Benutzer in dieser Gruppe, auch nicht "root@localhost". stats Benutzer in dieser Gruppe duerfen lesend (ro) oder schreibend (rw) auf das Statistikmodul von OTRS zugreifen, d.h. sie koennen 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 fuer die Mitarbeiter das normale Arbeiten im System ermoeglicht, 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 aendern, kann der Link "Benutzer <-> Gruppen" im Administrationsbereich genutzt werden. [admin-users-and-groups.png] Im unteren Bereich des Bildschirms wird eine Uebersicht angezeigt, die alle Benutzer und Gruppen auflistet. Indem Sie auf einen Benutzernamen klicken, bekommen Sie dessen Gruppenzugehoerigkeiten angezeigt und koennen diese aendern. 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, koennen einem Benutzer verschiedene Rechte pro Gruppe zugewiesen werden. Nach einer Standardinstallation sind in jede Gruppe die folgenden Rechte vorhanden. Tabelle 5-2. Berechtigungen in den Benutzergruppen von OTRS Berechtigung Beschreibung ro Nur Lesezugriff auf die Tickets bzw. Beitraege dieser Gruppe bzw. der Gruppe zugewiesenen Queues oder Bereiche. Verschieben in (move into) Recht zum Verschieben von Tickets oder Beitraegen innerhalb der Queues bzw. Bereiche dieser Gruppe. Erstellen (create) Recht zum Erstellen von Tickets oder Beitraegen in den Queues, bzw. Bereichen dieser Gruppe. Besitzer (owner) Recht zum Aendern des Eigentuemers von Tickets, bzw. Beitraegen in den der Gruppe zugewiesenen Queues bzw. Bereiche. Prioritaet (priority) Recht zum Aendern der Prioritaet von Tickets, bzw. Beitraegen in den der Gruppe zugewiesenen Queues bzw. Bereiche. rw Voller Lese- und Schreibzugriff auf alle Inhalte der dieser Gruppe zugewiesenen Queues, bzw. Bereiche. __________________________________________________________ 5.2.3. Rollen Rollen sind ein sehr nuetzliches und maechtiges Feature in OTRS, um schnell und einfach die Vergabe von Zugriffsrechten fuer viele Benutzer vorzunehmen. Vor allem bei grossen 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 enthaelt und in der die Support-Anfragen Ihrer Kunden landen. Die restlichen Queues des Systems sind fuer die 90 Supporter nicht zugaenglich, dies wurde durch Gruppenzugriffsrechte so festgelegt. Die uebrigen 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 zusaetzlich eine Abteilung eroeffnet, die Produkte verkaufen soll. Es muessen Angebote, Auftragsbestaetigungen 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 taetig werden und Sie als OTRS-Administrator haben nun die Aufgabe die neuen Queues anzulegen, die erweiterten Zugriffsrechte anzupassen und diese fuer die einzelnen Benutzer zu aendern. Da es muehsam und viel zu umstaendlich waere, fuer einen Teil aller 100 Benutzer einzeln die Zugrifssrechte zu aendern, richten Sie Rollen ein die mit Hilfe von Gruppenberechtigungen die verschiedenen Zugriffsrechte regeln. Anschliessend aendern Sie fuer die entsprechenden Benutzer auf einmal die Zugriffsberechtigungen, indem Sie diese der entsprechenden Rolle zuweisen. Beim Anlegen neuer Benutzer muessen Sie nicht mehr einzeln die Gruppen und Zugrifssrechte einstellen, auch hier genuegt die Verknuepfung des neuen Benutzers mit einer Rolle. [admin-roles.png] Anmerkung Um die Konsistenz der von OTRS verwalteten Daten sicher zu stellen, koennen 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 fuer "Gueltig" auf "ungueltig" oder "ungueltig-temporaer". [admin-roles-users.png] [admin-roles-groups.png] Um die Zugriffsrechtevergabe einer Rolle naeher zu spezifizieren, koennen die Links "Rollen <-> Benutzer" bzw. "Rollen <-> Gruppen" genutzt werden. Mit Hilfe dieser beiden Links koennen Sie sich eine Uebersicht ueber die 1:n und n:1 Beziehungen der Rolle zu den einzelnen im System vorhandenen Benutzer oder Gruppen anzeigen lassen und diese aendern. __________________________________________________________ 5.3. Kundenbenutzer und -gruppen 5.3.1. Kunden Benutzer OTRS unterstuetzt, wie bereits erwaehnt, verschiedene Arten von Benutzern. Ueber den Link "Kunden Benutzer", den Sie im Admin-Bereich von OTRS finden, koennen Sie die Benutzerdaten der im System angelegten Kunden verwalten. Ein Kunde kann sich mit Hilfe seines Accounts in das vom Ticket-System bereitgestellte Webinterface fuer Kunden einloggen, um dort die eigenen Tickets einzusehen, neue Tickets zu verfassen, usw. Weiterhin wird ein Kunden-Account vom System fuer die Historie von Tickets benoetigt. [admin-customer.png] Neben der Moeglichkeit in der Datenbank nach einem bestimmten Kunden zu suchen, kann das Backend umgestellt werden, ueber 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 fuer 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, muessen ausgefuellt werden. Neben den ueblichen Daten wie Vor- und Nachname, Mailadresse, den Einstellungen fuer die Oberflaeche, usw. muss ein Benutzername und ein Kennwort angegeben werden, wodurch die Anmeldung am System ermoeglicht wird. Desweiteren ist eine Angabe fuer "Kunden#" erforderlich, die eine eindeutige Kennung darstellt, ueber die das System den Kunden ansprechen kann bzw. identifiziert. Fuer "Kunden#" kann also z. B. eine Kundennummer oder auch die Mailadresse des Kunden eingetragen werden. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" bzw. "ungueltig-temporaer". __________________________________________________________ 5.3.2. Kundengruppen Genau wie Agenten, koennen in OTRS auch Kundenbenutzer verschiedenen Gruppen zugewiesen werden. Dieses Feature kann z. B. dann interessant sein, wenn Sie mehrere Kundenbenutzer einer Firma anlegen moechten, die alle ueber das Kundeninterface nur Tickets in eine oder mehrere bestimmte Queues senden sollen. Legen Sie hierzu zuerst ueber die Gruppenverwaltung die Gruppe an, in der alle Kundenbenutzer der Firma aufgenommen werden sollen. Anschliessend erstellen Sie im Verwaltungsbereich fuer queues die Queues und ordnen diese der gerade angelegten Gruppe zu. Im naechsten Schritt aktivieren Sie mit Hilfe des Konfigurationsparameters CustomerGroupSupport die Unterstuetzung fuer Kundengruppen. Mit Hilfe des Parameters CustomerGroupAlwaysGroups legen Sie fest, welchen Gruppen ein neu angelegter Kundenbenutzer automatisch zugeordnet werden soll. [admin-customer-groups.png] Ueber den Link "Kunden Benutzer <-> Gruppen" koennen Sie nun die Zuordnung der Kundenbenutzer in die gewuenschten Gruppen vornehmen. Je nachdem, welche Queues zu welchen Gruppen gehoeren, werden spaeter im Webinterface fuer Kunden auch nur die entsprechenden Queues zur Verfuegung gestellt. __________________________________________________________ 5.4. Queues Ueber den Link "Queue" innerhalb des Admin-Bereiches von OTRS koennen 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. [admin-queue.png] Ueber das Formular auf der rechten Bildschirmseite kann eine neue Queue angelegt werden. Zusaetzlich zum Namen der neuen Queue kann angegeben werden, fuer 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 koennen Sie mit Hilfe des Freigabezeit-Intervalls festlegen, wann ein Ticket wieder automatisch vom System freigegeben werden soll. So koennen auch die anderen Mitarbeiter wieder auf dieses Ticket zugreifen und es bearbeiten. Geben Sie fuer Eskalationszeit einen Wert an, so blockieren Tickets, die aelter als die angegebene Zeit sind, die Bearbeitung neuerer Tickets. Diese Einstellung stellt also sicher, dass aeltere Tickets ab einem bestimmten Alter bevorzugt bearbeitet werden muessen, neuere Tickets werden dann nicht mehr in der Queue angezeigt. Weiterhin koennen Sie festlegen, dass bei einem Follow-Up auf ein Ticket wieder der Mitarbeiter Eigentuemer dieses Tickets wird, der zuletzt als Eigentuemer im System fuer dieses Ticket vermerkt war. Dies stellt sicher, dass die Nachfrage eines Kunden zuerst bei demselben Mitarbeiter landet, der sich zuletzt um dieses Ticket gekuemmert hat. Der Parameter fuer die Systemadresse legt fest, mit welcher Absenderadresse Mails aus dieser Queue versendet werden sollen. Mit Hilfe der Parameter fuer Anrede und Signatur kann eingestellt werden, welche Vorgaben hier standardmaessig bei Antworten auf Tickets in dieser Queue genutzt werden. In den Abschnitten Emailadressen Anreden und Signaturen erfahren Sie mehr ueber die Einrichtung dieser Parameter. Mit Hilfe der verschiedenen Kundeninfo-Parameter koennen Sie schliesslich festlegen, bei welchen Ereignissen ein Kunde ueber die Aenderungen bei einem Ticket in dieser Queue informiert werden soll. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" bzw. "ungueltig-temporaer". Alle gerade beschriebenen Konfigurationsmoeglichkeiten fuer Queues, gelten auch fuer Unter-Queues. Somit lassen sich mit Hilfe der Queues in OTRS z. B. die einzelnen Abteilungen Ihres Betriebes oder die verschiedenen Phasen eines Geschaeftsvorgangs (Anfrage, Angebot, Bestellung, usw.) abbilden. Dies sollten Sie sich bei der Strukturierung Ihres OTRS zu Nutze machen. __________________________________________________________ 5.5. Anreden, Signaturen, Anlagen und Antwortvorlagen Um das Antworten auf Tickets zu beschleunigen und das Aussehen beantworteter Tickets zu vereinheitlichen, koennen in OTRS Antwortvorlagen erstellt werden. Jede Antwortvorlage kann einer oder mehreren Queues bzw. Unter-Queues zugeordnet werden, es koennen mehrere Antwortvorlagen fuer 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 durchgefuehrt werden. Nach einer Standardinstallation ist fuer jede Queue die Antwortvorlage "empty answer" vorhanden. Im Admin-Bereich kann ueber den Link "Antworten" auf die im System gespeicherten Antwortvorlagen zugegriffen und diese bearbeitet werden. [admin-response.png] [admin-response-queue.png] 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 koennen Sie nun die Queue oder die Antwortvorlage auswaehlen, um die Zuordnung zu bearbeiten. Wenn Sie zum Beantworten eines Tickets, z. B. in der Queue-Ansicht, auf den Link fuer eine Antwortvorlage klicken, koennen 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 standardmaessig so angeordnet, dass beim Antworten zuerst die Anrede, danach der zitierte Text des zu beantwortende Ticket, anschliessend ggf. der Text der Antwortvorlage und zum Schluss die Signatur ausgegeben wird. __________________________________________________________ 5.5.1. Anreden Ein Textbaustein fuer eine Antwortvorlage ist die Anrede. Anreden koennen einer Queue zugeordnet werden, wie im Abschnitt zu den Queues beschrieben, nur so werden Sie bei Antworten fuer Tickets aus dieser Queue verwendet. Ueber den Link "Anreden" innerhalb des Admin-Bereiches, koennen Sie die verschiedenen Anreden Ihres Systems verwalten. [admin-salutation.png] 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 koennen, also Inhalte, die sich bei jeder Anrede aendern, koennen verschiedene Variablen in den Anredentext eingebaut werden. Der in der Variable gespeicherte Text wird beim Antworten automatisch in den Text eingefuegt. Ein variabler Textteil koennte z.b. der Name oder die Mailadresse der Person sein, auf deren Ticket sie antworten. Im unteren Teil der Bildschirmmaske zum Aendern oder Anlegen einer Anrede finden Sie die verschiedenen OTRS-Variablen, die Sie fuer die dynamische Aufbereitung eines Anredentextes verwenden koennen. 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 ein, so wird diese spaeter 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. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" bzw. "ungueltig-temporaer". __________________________________________________________ 5.5.2. Signaturen Ein weiterer Textbaustein fuer eine Antwortvorlage, ist die Signatur. Signaturen koennen einer Queue zugeordnet werden, wie im Abschnitt zu den Queues beschrieben, nur so werden Sie bei Antworten fuer Tickets aus dieser Queue verwendet. Ueber den Link "Signaturen" innerhalb des Admin-Bereiches, koennen Sie die verschiedenen Signaturen Ihres Systems verwalten. [admin-signatures.png] 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 koennen dynamische Inhalte eingebaut werden. Dies geschieht, genauso wie bei den Anreden, mit Hilfe verschiedener OTRS-Variablen, die in den Text der Signatur integriert werden koennen. Ein variabler Textteil koennte z.b. der Name des Mitarbeiters sein, der das Ticket beantwortet hat. Im unteren Teil der Bildschirmmaske zum Aendern oder Anlegen einer Signatur finden Sie die verschiedenen OTRS-Variablen, die Sie fuer die dynamische Aufbereitung eines Signaturentextes verwenden koennen. 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 ein, so wird diese spaeter 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. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" oder auf "ungueltig-temporaer". __________________________________________________________ 5.5.3. Anlagen Ein weitere optionaler Teil einer Antwortvorlage kann eine Anlage sein. Diese wird bei der Benutzung einer Antwortvorlage als Anhang an das zu beantwortende Ticket angehaengt, kann aber ueber eine Checkbox im Antworten-Bildschirm fuer Tickets leicht deaktiviert werden. [admin-attachment.png] Ueber den "Anlagen"-Link im Admin-Bereich koennen 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 ueber den Link "Anlagen <-> Antworten" im Admin-Bereich von OTRS erreicht werden. [admin-attachment-response.png] Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" oder "ungueltig-temporaer". __________________________________________________________ 5.6. Automatische Antworten OTRS bietet die Moeglichkeit, 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 zurueckgewiesen wird. Ueber den Link "Auto Antworten" innerhalb des Admin-Bereiches erreichen Sie die Verwaltung der automatischen Antworten. Im Formular zum Aendern oder Anlegen einer automatischen Antwort stellen Sie ueber die Listbox fuer "Typ" das Ereignis ein, das mit der automatischen Antwort verknuepft werden soll. Nach einer Standardinstallation sind folgende Ereignistypen vorhanden. [admin-autoresponse.png] Tabelle 5-3. Ereignistypen fuer automatische 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 geoeffnet wird. auto follow up Dieses Ereignis tritt ein, wenn ein Follow up fuer ein bereits vorhandenes Ticket eintrifft. auto reject Dieses Ereignis tritt ein, wenn ein Ticket vom System zurueckgewiesen wird. auto remove Dieses Ereignis tritt ein, wenn ein Ticket entfernt wird. Fuer 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 ueber die Variable die ersten 5 Zeilen der an das System gesendeten Email in die automatische Antwort eingefuegt, oder durch die From-Zeile. Die Anmerkungen im unterem Bereich der Bildschirmmaske zur Verwaltung der automatischen Antworten listen alle OTRS-Variablen auf, die verwendet werden koennen. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" oder "ungueltig-temporaer". [admin-autoresponse-queue.png] Um eine automatische Antwort einer oder mehreren Queues zuzuweisen, folgen Sie im Admin-Bereich den Link "Auto Antworten <-> Queues". Dort sind fuer jede Queue die verschiedenen Ereignistypen aufgelistet und es kann eine Zuordnung einer Auto-Antwort vom gleichen Ereignistyp durchgefuehrt bzw. entfernt werden. __________________________________________________________ 5.7. Emailadressen Um aus OTRS heraus Emails verschicken zu koennen, benoetigen Sie mindestens eine gueltige Mailadresse. Da in vielen Faellen eine Mailadresse nicht ausreicht, ist OTRS auch in der Lage, mit mehreren Mailadressen zu arbeiten. Fuer jede Queue kann mindestens eine Mailadresse festgelegt werden, es ist aber auch moeglich eine Adresse mehreren Queues zuzuordnen. D.h., dass von aussen eine Queue ueber mehrere Mailadressen ereicht werden kann, fuer 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 fuer die ausgehenden Nachrichten der entsprechenden Queue benutzt werden soll. Die Verwaltung der Mailadressen des Systems erreichen Sie, indem sie im Admin-Bereich dem Link "Email Adressen" folgen. [admin-email.png] Im Formular zur Verwaltung der Emailadressen koennen Sie u.a. direkt auswaehlen, mit welcher Queue oder Unter-Queue die neue Mailadresse verknuepft werden soll. Diese Verknuepfung ist wichtig, da so eingehende Mails anhand der Adresse im To: Feld der entsprechenden Queue zugewiesen werden koennen. Anmerkung 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 fuer "Gueltig" den Wert entweder auf "ungueltig" oder "ungueltig-temporaer". __________________________________________________________ 5.8. Benachrichtigungen Kunden und Mitarbeiter koennen im Einstellungs-Bereich ihres Accounts festlegen, bei welchen Ereignissen Sie automatisch vom System per Mail benachrichtigt werden wollen. [admin-notification.png] Ueber den "Benachrichtigungen"-Link im Admin-Bereich erreichen Sie die Verwaltung der Benachrichtigungen. Sie koennen die Betreffzeile und den Text einer Benachrichtigung anpassen, indem Sie die entsprechende Benachrichtigung aus der Listbox auswaehlen und deren Einstellung ueber den "Aendern"-Schalter laden. Am Namen einer Benachrichtigung erkennen Sie, bei welcher Oberflaechensprache die Benachrichtigung verwendet wird, fuer welches Ereignis die Benachrichtigung steht und ob sie fuer einen Kunden oder Agenten bestimmt ist. Auch innerhalb der Benachrichtigungen koennen 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 Verfuegung stehenden Variablen und deren Verwendung aufgelistet und naeher erklaert. __________________________________________________________ 5.9. SMIME Mit OTRS ist es moeglich, Tickets mit Hilfe von SMIME zu ent- und verschluesseln bzw. Tickets zu signieren. Bevor SMIME allerdings systemweit genutzt werden kann, muss das Feature mit Hilfe einiger Konfigurationsparameter z. B. ueber die grafische Administrationsoberflaeche des Systems aktiviert und konfiguriert werden [admin-smime.png] Ueber den "SMIME"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung der SMIME-Zertifikate. Es koennen Zertifikate und private Fingerprints hinzugefuegt und entfernt werden und eine Suche in den Zertifikaten ist moeglich. __________________________________________________________ 5.10. PGP Mit OTRS ist es moeglich, Tickets mit Hilfe von PGP zu ent- und verschluesseln bzw. zu signieren. Bevor PGP allerdings systemweit genutzt werden kann, muss das Feature mit Hilfe einiger Konfigurationsparameter z. B. ueber die grafische Administrationsoberflaeche des Systems aktiviert und konfiguriert werden [admin-pgp.png] Ueber den "PGP"-Link im Admin-Bereich von OTRS erreichen Sie die Verwaltung des Schluesselrings Ihres Systems. Es koennen Schluessel und Signaturen hinzugefuegt und entfernt werden und eine Suche innerhalb des Schluesselrings ist moeglich. Das Kapitel Verschluesselung mit PGP beschreibt die einrichtung und Verwendung detaillierter. __________________________________________________________ 5.11. Status Ueber den Link "Status" koennen Sie die Status, die Sie in OTRS verwenden moechten, bearbbeiten. [admin-status.png] 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 standardmaessig die Status-Typen "geschlossen", "merged", "neu", "offen", "pending auto", "warten zur Erinnerung" und "entfernt". __________________________________________________________ 5.12. Die Admin GUI (SysConfig) Seit OTRS 2.0 kann das System nahezu vollstaendig ueber das Webinterface konfiguriert werden und manuelle Anpassungen der Konfigurationsdateien gehoeren der Vergangenheit an. MOeglich wird dies durch das grafische Administrations-Frontend. [admin-sysconfig.png] Ueber den "SysConfig"-Link im Admin-Bereich von OTRS erreichen sie die grafische Administrationsoberflaeche. Ueber diese koennen Sie eigene Konfigurationsdateien in das System integrieren bzw. Ihre persoenlichen Aenderungen an der Standardkonfiguration in eine Datei sichern. Nahezu alle Konfigurationsparameter des OTRS Frameworks und der zusaetzlich installierten Module koennen eingesehen und geaendert werden, die Navigation durch die Vielzahl der Konfigurationsparameter wurde durch die Einteilung in Module und Gruppen uebersichtlich aufgeteilt. Weiterhin ist es moeglich, eine Suche ueber alle Konfigurationsparameter hinweg durchzufuehren, so dass einzelne Parameter schnell aufgefunden und bearbeitet werden koennen. Das Kapitel Naehere Beschreibung der grafischen Administrationsoberflaeche geht ausfuehrlicher auf das grafische Konfigurations-Frontend ein. __________________________________________________________ 5.13. Einrichten von POP3-Konten Es gibt mehrere Moeglichkeiten, Mails in OTRS einzuspeisen. Neben der Nutzung des PostMaster.pl-Skripts, welches die Mails direkt in das System piped, koennen auch POP3-Konten abgefragt werden, an die Mails fuer Ihr Ticket-System gehen. Ueber den Link "PostMaster POP3 Account" innerhalb des Admin-Bereiches erreichen Sie die Verwaltung der POP3-Konten, die OTRS automatisch auf neue Nachrichten ueberpruefen soll. [admin-postmasterpop3.png] Im Kapitel ueber die Mailkonfiguration fuer OTRS wird die Einrichtung der POP3-Konten naeher erlaeutert. __________________________________________________________ 5.14. Einrichten von Filterregeln Damit Sie automatisch Mails vorsortieren koennen bzw. ungewuenschte Mails gar nicht in die Queues des Ticket-Systems gelangen, koennen Filterregeln fuer eingehende Nachrichten festgelegt werden. Dabei spielt es keine Rolle, ob die Mails ueber 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 fuer die Filterregeln auf. [admin-postmasterfilter.png] Eine Filterregel besteht aus einem oder mehreren Kriterien die erfuellt werden muessen, damit die Filterregel greift, und aus einer oder mehreren Aktionen die ausgefuehrt werden, nachdem die Filterkriterien erfuellt wurden. Sie koennen fuer die Kopfzeilen und den Body einer Nachricht Filterregeln festlegen, also z. B. nach bestimmten Headern suchen oder nach Zeichenketten bzw. regulaeren Ausdruecken innerhalb der Mail. Alle Aktionen fuer eine Filterregel werden ueber sog. X-OTRS-Header gesteuert, die in die Mail eingefuegt 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 Prioritaet einer Nachricht geaendert 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 zulaessige Werte und die Bedeutung der einzelnen Header auf. Tabelle 5-4. Funktion der verschiedenen X-OTRS-Header Name Moegliche Werte Beschreibung X-OTRS-Priority: 1 very low, 2 low, 3 normal, 4 high, 5 very high Legt die Prioritaet 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 naechsten 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): Zusaetzlicher Info-Key fuer den Artikel. Speichert einen zusaetzlichen Info-Key fuer den Artikel. X-OTRS-ArticleValue(1|2|3): Zusaetzlicher Info-Value. Speichert einen zusaetzlichen Info-Value fuer 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 fuer das eingehende Ticket fest. X-OTRS-TicketKey(1|2|...|8): Zusaetzlicher Info-Key Speichert einen zusaetzlichen Info-Key fuer das Ticket. X-OTRS-TicketValue(1|2|...|8): Zusaetzlicher Info-Value Speichert einen zusaetzlichen Info-Value fuer 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. Ueber das Formular auf der rechten Seite der Verwaltung fuer die Filterregeln koennen neue Filterregeln hinzugefuegt werden. Sie muessen fuer jede Regel einen Namen vergeben. Darunter legen Sie in der Sektion fuer "Treffer" die verschiedenen Kriterien fest, nach denen gefiltert werden soll. Waehlen Sie aus den Listboxen fuer "Header 1", "Header 2" usw. aus, an welcher Stelle in der eingehenden Nachricht Sie suchen moechten 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 ausgefuehrt werden sollen, wenn die Filterkriterien zutreffen. Hier koennen Sie fuer "Header1", "Header 2" usw. den entsprechenden X-OTRS-Header auswaehlen und rechts daneben den entsprechenden Wert eintragen. Beispiel 5-1. Aussortierung von Spammails in eine bestimmte Queue Eine nuetzliche Filterregel koennte sein, alle Mails, die von spamassassin als Spam markiert wurden, automatisch in die Queue "Junk" einsortieren zu lassen. Spamassassin fuegt bei allen ueberprueften 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 fuer die Filterregel z. B. "spam-mails" ein und waehlen in der Sektion "Treffer" fuer "Header 1" den Header "X-Spam-Flag:" aus der Listbox aus. Rechts daneben fuegen 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, waehlen Sie in der Sektion "Setzen" fuer "Header 1" den Eintrag "X-OTRS-Queue:" aus und tragen als Wert rechts daneben "Junk" ein. Abschliessend wird mit Hilfe des "Hinzufuegen"-Buttons die neue Regel gespeichert und aktiviert, beim naechsten Abruf der POP3-Konten bzw. fuer die naechste an das System gesendete Nachricht wird die Filterregel abgearbeitet. Es gibt weitere Module, die zum Filtern eingehender Emails genutzt werden und bei komplexeren Installationen nuetzlich sein koennen. __________________________________________________________ 5.15. Ausfuehren von automatisierten Jobs mit Hilfe des GenericAgents Der GenericAgent ist ein Tool zum automatischen Ausfuehren von Aufgaben, die normalerweise ein richtiger Agent manuell durchfuehren muesste. Er kann z. B. bestimmte Tickets in einer Queue schliessen oder Benachrichtigungen fuer eskalierte Tickets versenden. [admin-genericagent-new.png] Um einen neuen Job fuer den GenericAgent zu definieren, folgen Sie dem Link "GenericAgent". Es wird eine Tabelle mit den bereits vorhandenen Jobs angezeigt, ueber die Jobs auch manuell ausgefuehrt oder geloescht werden koennen. Zum Hinzufuegen eines neuen Jobs geben Sie den Namen ein und klicken auf "Hinzufuegen". [admin-genericagent.png] Ueber die Bildschirmmaske zum Erstellen eines neuen Jobs kann der Zeitplan fuer die Ausfuehrung des Jobs eingestellt werden. Desweiteren kann ueber verschiedene Kriterien festgelegt werden, welche Tickets vom Job erfasst werden sollen. Schliesslich ist es moeglich, die neuen Eigenschaften der vom Job betroffenen Tickets einzustellen. Nachdem der Job gespeichert wurde, werden alle Tickets aufgefuehrt, die durch den Job veraendert werden. Diese Auflistung dient zur Uebersicht, ob der Job richtig funktioniert, es werden noch keine Veraenderungen vorgenommen. Erst nach der Uebernahme des Jobs in die Job-Liste, wird der Job aktiviert. __________________________________________________________ 5.16. Administratoren Email Um als OTRS-Administrator eine Mail an bestimmte Benutzer (Agents) oder Benutzergruppen im System zu versenden, folgen Sie dem Link "Admin Notification". [admin-email.png] Es wird ein Formular geladen, in das Sie die Absenderadresse, den Betreff und den Inhalt der Administratoren-Mitteilung eintragen koennen. Weiterhin koennen Sie aus der Tabelle auswaehlen, an welche Benutzer und / oder Benutzergruppen die Mitteilung gesendet werden soll. __________________________________________________________ 5.17. Sitzungsverwaltung Um eine Uebersicht ueber die gerade im System angemeldeten Benutzer und deren Sitzungseigenschaften zu erhalten, folgen Sie dem Link "Sitzungsverwaltung". [admin-sessionmanagement.png] 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 Moeglichkeit mit Hilfe des "Alle Sitzungen loeschen"-Schalters die Sitzungen aller angemeldeten Benutzer zu beenden. Weiterhin koennen detaillierte Informationen fuer jede einzelne Sitzung abgerufen und einzelne Sitzungen geloescht werden. __________________________________________________________ 5.18. System Log Der Link "System Log" ermoeglicht es, die letzten Logeintraege des Ticket-Systems ueber die Weboberflaeche einzusehen. [admin-syslog.png] Ein Logeintrag setzt sich aus der Zeit, der Prioritaet, der betroffenen Systemkomponente und der eigentlichen Meldung zusammen. Anmerkung Die System Logs koennen nur auf Unix- oder Linux-Systemen ueber das Web-Interface eingesehen werden, unter Windows-Betriebssystemen steht diese Funktion nicht zur Verfuegung. Die Anzahl der im Web-Interface angezeigten Logeintraege kann ueber den Konfigurationsparameter fuer die Groesse des Systemlog-Caches beeinflusst werden. __________________________________________________________ 5.19. SQL Abfragen mit Hilfe der Selectbox Ueber den Link "Select Box" kann eine Bildschirmmaske aufgerufen werden, die es ermoeglicht direkt mit SQL-Statements den Inhalt von Tabellen der OTRS-Datenbank abzurufen. Es sind nur SELECT-Abfragen moeglich, d.h. die Tabellen koennen auf diesem Weg nicht veraendert werden. [admin-selectbox.png] __________________________________________________________ 5.20. Paket Verwaltung Seit Version 2.0 besteht OTRS aus einem zentralen Framework und mehreren Zusatzpaketen, um die das System wahlweise erweitert werden kann. An zusaetzlichen Paketen stehen z. B. ein web-basierter Filemanager, ein Web-Mailer, ein Content-Manager oder ein Tool zur Ueberwachung von verschiedenen Betriebssystemparametern zur Verfuegung. Um die Installation der verschiedenen Komponenten zu erleichtern, koennen diese mit Hilfe des Paket Managers bequem ueber das Web-Interface von OTRS installiert oder entfernt werden. Die Paket Verwaltung erreichen sie ueber den Link "Paket Verwaltung". [admin-packagemanager.png] Die Pakete, die ueber die Paket Verwaltung hinzugefuegt oder entfernt werden koennen, muessen im sog. opm-Format vorliegen, andere Formate werden nicht unterstuetzt. Es koennen mehrere Installations-Quellen angegeben werden, ueber die die opm-Pakete installiert werden koennen. Steht Ihnen ein Paket lokal zur Verfuegung und kann darauf ueber das Filesystem der Maschine zugegriffen werden, auf der OTRS installiert ist, koennen Sie im Eingabefeld fuer "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 benoetigten 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 zusaetzlichen Module zu haben, empfielt es sich, die Pakete ueber ein Online-Repository einzuspielen. Die neueste Modulliste des Online-Repositorys erhalten Sie, indem Sie aus der Listbox fuer "Quelle" den Server auswaehlen, 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 fuer das Online Repository die Module aufgelistet, die online fuer eine Installation zur Verfuegung stehen. In der rechten Spalte dieser Tabelle koennen Sie den "Installieren"-Schalter verwenden, um das entsprechende Modul in Ihr System zu integrieren. Haengt 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 fuer das lokale Repository uebertragen und dort aufgefuehrt. Das lokale Repository listet also alle Module auf, die sie zusaetzlich ueber die Paket Verwaltung Ihrer Installation hinzugefuegt haben. Benoetigen Sie einmal ein bestimmtes Modul nicht mehr und wollen es entfernen, so ist dies ueber den "deinstallieren"-Schalter rechts vom entsprechenden Modul innerhalb des lokalen Repositorys moeglich. Auch bei diesem Vorgang werden eventuelle Abhaengigkeiten beachtet. __________________________________________________________ Kapitel 6. Konfiguration des Systems 6.1. Die Konfigurationsdateien von OTRS 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 veraendern, da alle anderen Dateien beim Updaten des Systems ueberschrieben werden und so Ihre eigenen Einstellungen verloren gehen. Uebertragen Sie lediglich die Parameter aus den anderen Dateien nach Kernel/Config.pm und passen Sie die Parameter Ihren Wuenschen entsprechend an. Die Datei Kernel/Config/Defaults.pm enthaelt die Konfigurationsparameter fuer den OTRS-Framework. In ihr finden Sie grundlegende Einstellungen wie die Mailkonfiguration, die Datenbankanbindung, Standardsprache o.ae. In der Datei Kernel/Config/Files/Ticket.pm sind alle Konfigurationsparameter fuer das Ticketsystem aufgefuehrt. Das Verzeichnis Kernel/Config/Files enthaelt weitere Konfigurationsdateien, die beim Starten von OTRS eingelesen werden. Sind zusaetzliche 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 fuer jedes Modul vorhanden, da aus Kompatibilitaetsgruenden zu aelteren OTRS-Versionen noch die Einstellungen in den .pm-Dateien benoetigt werden. Die .xml-Dateien werden von der grafischen Administrationsoberflaeche ausgewertet, die seit OTRS 2.0 verfuegbar ist und die es Ihnen ermoeglicht, das System nahezu vollstaendig ueber die Web-Oberflaeche zu konfigurieren. In zukuenftigen Versionen von OTRS wird auf die .pm-Dateien vollstaendig verzichtet und alle Einstellungen aus Kernel/Config/Defaults.pm werden nur noch in Kernel/Config/Files/Framework.xml zu finden sein bzw. alle Einstellungen fuer das Ticketsystem befinden sich dann nur noch in der Datei Kernel/Config/Files/Ticket.xml. Die Konfigurationsparameter werden also in zukuenftigen Versionen komplett in das xml-Format uebertragen. Wird die Web-Oberflaeche von OTRS aufgerufen, werden die xml-Dateien in Kernel/Config/Files in alphabetischer Reihenfolge ausgelesen und die Einstellungen des Frameworks und der evtl. zusaetzlich installierten Applikationen geladen. Anschliessend 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 geaendert 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. __________________________________________________________ 6.2. Konfiguration des Systems mit Hilfe des grafischen Konfigurations-Frontends Seit OTRS 2.0 koennen nahezu alle Konfigurationsparameter des Frameworks oder der ggf. zusaetzlich installierten Applikationen bequem ueber 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. [admin-sysconfig.png] Da OTRS mittlerweile ueber mehr als 600 verschiedene Konfigurationsparameter verfuegt, bietet das Konfigurations-Frontend mehrere Moeglichkeiten zur schnellen Auffindung der gewuenschten Einstellung. Es kann ueber 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, fuer die der Konfigurationsparameter zustaendig ist, also z.B. "Framework" fuer das OTRS-Framework oder "Ticket" fuer das Ticketsystem. Die Untergruppen einer Hauptgruppe koennen eingesehen werden, indem die Gruppe bzw. Applikation aus der dazu vorgesehenen Listbox ausgewaehlt und der "Zeigen"-Knopf gedrueckt wird. Fuer jeden einzelnen Konfigurationsparameter kann ueber eine Checkbox festgelegt werden, ob er vom System beachtet werden soll oder nicht. Wird eine Einstellung veraendert, kann die Aenderung mit Hilfe des "Aktualisieren"-Buttons uebernommen werden. Eine Einstellung kann mit Hilfe des "Ruecksetzen"-Schalters auf ihren Default-Wert zurueckgesetzt werden. Fuer die Sicherung aller von Ihnen vorgenommenen Aenderungen, kann eine .pm-Datei heruntergeladen werden, die alle vom Standard abweichenden Konfigurationsparameter Ihres Systems enthaelt. Die selbe Datei koennen Sie ebenfalls ueber die Konfigurationsoberflaeche eines frisch installierten Systems zurueck spielen und so alle Einstellungen wieder herstellen. Anmerkung Die Einstellungen fuer die Datenbankanbindung koennen aus Sicherheitsgruenden nicht ueber das grafische Konfigurations-Frontend geaendert werden und muessen manuell in die Datei Kernel/Config.pm eingefuegt werden. __________________________________________________________ Kapitel 7. Emails versenden/empfangen 7.1. Emails versenden 7.1.1. Via Sendmail (Standard) OTRS ist in der Lage, Emails 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 ueber die grafische Administrationsoberflaeche 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 '; __________________________________________________________ 7.1.2. Via SMTP relay/smarthost Wenn kein sendmail-Binary zur Verfuegung steht, kann OTRS Emails via SMTP versenden (Simple Mail Transfer Protocol / RFC 821). Diese Moeglichkeit kann hauptsaechlich auf Nicht-Unix-Plattformen (z. B. Win32) genutzt werden. Die Konfiguration kann ueber die grafische Administrationsoberflaeche 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"} = ""; __________________________________________________________ 7.2. Emails empfangen 7.2.1. Via POP3-Konten - der einfache Weg (PostMasterPOP3.pl) OTRS ist in der Lage, Emails von POP3-Konten zu empfangen. Konfigurieren Sie Ihre POP3-Konten im Admin-Bereich von OTRS in der Sektion PostMaster POP3 Account . [admin-postmasterpop3.png] Beim Anlegen eines neuen POP3-Accounts muss der POP3-Server, ein Login und ein Kennwort angegeben werden. Waehlen Sie fuer "Vertraut" den Wert "Ja" aus, dann werden die sog. X-OTRS-Header-Eintraege ausgewertet und angewendet, sofern derartige Header-Eintraege in einer abgerufenen Nachricht vorhanden sind. Da mit Hilfe der X-OTRS-Header einige Dinge am System beeinflusst werden koennen, sollten Sie "Vertraut" nur auf "Ja" setzen, wenn Sie genau wissen, von welchen Absendern die abgerufenen Nachrichten stammen. X-OTRS-Header werden vom Modul fuer die Nachrichtenfilterung in OTRS benutzt, die X-OTRS-Header werden in dieser Tabelle naeher beschrieben. Es spielt keine Rolle, welcher Wert fuer "Vertraut" ausgewaehlt wurde, eventuell eingerichtete Filterregeln fuer eingehende Mails werden trotzdem abgearbeitet. Weiterhin koennen 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. Waehlen Sie "Verteilung nach ausgewaehlter Queue" aus, landen die abgerufenen Mails auf jeden Fall in der Queue, die zusaetzlich in der dafuer vorgesehenen Listbox angegeben werden kann. Dabei spielt keine Rolle, an welche Adresse die Mail geschickt wurde. Waehlen Sie "Verteilung nach To: Feld" aus, wird ueberprueft, welcher Queue die Adresse zugeordnet ist, an die die abgerufene Mail gesendet wurde. Die Zuordnung einer Mailadresse zu einer Queue kann ueber 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 regelmaessig ausgefuehrt. Einen Beispiel-Cronjob finden Sie in der Datei var/cron/postmaster_pop3.dist. Dieser fuehrt bin/PostMasterPOP3.pl alle 10 Minuten aus. Das Kapitel "Einrichten der von OTRS benoetigten cron-Jobs" beschreibt das Zusammenspiel zwischen OTRS und cron ausfuehrlicher. __________________________________________________________ 7.2.2. Via Kommandozeilen-Programm und z. B. procmail (PostMaster.pl) OTRS ist in der Lage, Emails ueber ein Kommandozeilen-Programm (bin/PostMaster.pl) zu empfangen. Das bedeutet, dass Emails im OTRS angezeigt werden, wenn der MDA (mail delivery agent, z. B. procmail) die Emails an bin/PostMaster.pl" weiterleitet. Um bin/PostMaster.pl auf der Kommandozeile ohne MDA zu testen, fuehren 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 Email in der Queue-Ansicht angezeigt, sind Ihre Einstellungen in Ordnung. Procmail ist in der Linux-Umgebung ein sehr bekannter Email-Filter, der hoechstwahrscheinlich auf Ihrem System installiert sein wird. Falls nicht, erhalten Sie auf der procmail Homepage weitere Informationen. Um procmail einzurichten (benoetigt einen fuer 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 Aenderungen 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 Emails werden an bin/PostMaster.pl weitergeleitet und dadurch im Ticket System gespeichert. __________________________________________________________ 7.2.3. Emails via POP3 oder IMAP und fetchmail fuer PostMaster.pl empfangen Um Emails von Ihrem Mailserver via POP3 oder IMAP fuer den OTRS-Rechner/lokalen OTRS-Benutzer und procmail abzuholen, benutzen Sie fetchmail. Anmerkung 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. Beispiel 7-1. Beispiel .fetchmailrc #poll (mailserver) protocol POP3 user (user) password (password) is (loc aluser) 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 ausgefuehrt (ggf. via cron), werden alle Emails auf das lokale OTRS-Konto weitergeleitet und mit Hilfe von procmail an bin/PostMasterPOP3.pl uebergeben. bin/PostMasterPOP3.pl sorgt wiederum dafuer, dass die neuen Mails in das Ticket System gelangen. __________________________________________________________ 7.2.4. Filterung/Verteilung ueber PostMaster-Module (fuer komplexere Verteilungsszenarien) Falls die bin/PostMaster.pl oder bin/PostMasterPOP3.pl Methoden verwendet werden, koennen X-OTRS-Header mit Hilfe der PostMaster-Filtermodule in die eingehenden Mails eingefuegt bzw. bereits vorhandene X-OTRS-Header veraendert werden. Mit Hilfe von X-OTRS-Headern kann das Ticket System bestimmte Aktionen fuer Mails ausfuehren, z. B. diese in eine bestimmte Queue einsortieren, sie einem bestimmten Kunden zuordnen, die Prioritaet aendern usw. Eine naehere Beschreibung der X-OTRS-Header finden Sie im Kapitel zum Einrichten von POP3-Accounts ueber den Administrations-Bereich von OTRS. Es gibt verschiedene Standard-Filtermodule. Anmerkung Der Jobname (z. B. $Self->{"PostMaster::PreFilterModule"}->{"Jobname"}) muss eindeutig sein. Kernel::System::PostMaster::Filter::Match ist ein Standard-Modul, um einige Email-Header (z. B. From, To, Subject) zu pruefen und dann den neuen Email-Header zu setzen (z. B. X-OTRS-Ignore: yes oder X-OTRS-Queue: spam). Beispiel 7-2. Beispiel-Jobs fuer das Filtermodul Kernel::System::PostMaster::Filter::Match # (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 Emails an ein externes Kommando zu leiten und, falls das Ergebnis aus STDOUT true ist, den neuen Email-Header zu setzen (z. B. X-OTRS-Ignore: yes oder X-OTRS-Queue: spam). Beispiel 7-3. Beispiel-Job fuer das Filtermodul Kernel::System::PostMaster::Filter::CMD # 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', }, }; Natuerlich ist es auch moeglich, eigene PostMaster-Filtermodule zu entwickeln. __________________________________________________________ Kapitel 8. Zeitabhaengige Funktionen in OTRS 8.1. Relevante Zeiten fuer das System festlegen In OTRS werden einige Aktionen abhaengig von der aktuellen Systemzeit ausgeloest. Von den Zeiteinstellungen betroffen sind die Berechnung der Eskalationszeit und die eigentliche Eskalation von Tickets. Weiterhin haengt die Zusendung von Benachrichtigungen fuer eskalierte Tickets bzw. fuer 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 koennen die fuer das System relevanten Zeiten entweder ueber das grafische Konfigurations Frond-end oder direkt ueber die Datei Kernel/Config.pm eingestellt werden. __________________________________________________________ 8.1.1. TimeWorkingHours Die Stunden, in denen Ihre Agenten aktiv am system arbeiten, koennen folgendermassen in der Datei Kernel/Config.pm festgelegt werden: Beispiel 8-1. Festlegen der fuer das System relevanten Arbeitsstunden $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 waehrend dieser Stunden koennen 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 fuer die automatische Freigabe mit einbezogen. __________________________________________________________ 8.1.2. TimeVacationDays Feiertage deren Datum jedes Jahr gleich ist, koennen dem System folgendermassen in der Datei Kernel/Config.pm bekannt gemacht werden: Beispiel 8-2. Festlegen von regelmaessig wiederkehrenden Feiertagen $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', }, }; Waehrend der hier festgelegten Tage werden keine zeitabhaengigen Aktionen oder Berechnungen auf Tickets im system ausgefuehrt. __________________________________________________________ 8.1.3. TimeVacationDaysOneTime Freie oder Feiertage, fuer die sich jaehrlich das Datum aendert, koennen folgendermassen in der Datei Kernel/Config.pm angegeben werden: Beispiel 8-3. Festlegen von unregelmaessig wiederkehrenden Feiertagen $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', }, }, }; Waehrend der hier festgelegten Tage werden keine zeitabhaengigen Aktionen oder Berechnungen auf Tickets im system ausgefuehrt. __________________________________________________________ 8.2. Automatische Freigabe von Tickets Gesperrte Tickets koennen automatisch vom System freigegeben werden. Diese Funktion kann z. B. dann nuetzlich sein, wenn sich ein Agent im Urlaub befindet und noch Tickets gesperrt hat, die bearbeitet werden sollen / muessen. 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 regelmaessig ausgefuehrt werden sollte, wird die automatische Freigabe von Tickets umgesetzt. Tickets werdennur waehrend der in TimeWorkingHours festgelegten Stunden automatisch freigegeben. An mit TimeVacationDays und TimeVacationDaysOneTime festgelegten Tagen, werden keine Tickets automatisch freigegeben. Benachrichtigungen ueber 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 fuer vom System freigegebene Tickets aktiviert ist. __________________________________________________________ 8.3. Erinnerungs Tickets Mit OTRS ist es moeglich 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 nuetzlich, wenn man daran erinnert werden will einen Kunden zu kontaktieren, dieser Kunde aber fuer die naechsten 2 Wochen im Urlaub ist. Benachrichtigungen fuer Erinnerungs Tickets werden legidlich waehrend der Stunden versendet, die in TimeWorkingHours festgelegt wurden. Das Modul bin/PendingJobs.pl, welches regelmaessig mit Hilfe eines cron-Jobs ausgefuehrt werden sollte, loest den Versand der Benachrichtigungen aus. __________________________________________________________ 8.4. Eskalation von Tickets OTRS bietet die Moeglichkeit 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 gewaehrleistet werden, dass Tickets die ein bestimmtes Alter ueberschreiten, auf jeden Fall beachtet werden muessen. Die Eskalationszeit kann in den Einstellungen jeder Queue festgelegt werden. Mit Hilfe des GenericAgents werden Benachrichtigungen ueber eskalierte Tickets an die Agenten versendet, die die Queue mit dem eskalierten Tickets in "Meine Queues" aufgenommen haben und fuer die in den Benutzereinstellungen die Benachrichtigung ueber eskalierte Tickets aktiviert ist. Beispiel 8-4. GenericAgent Job zum Versand von Eskalations Benachrichtigungen In der Datei Kernel/Config/GenericAgent.pm ist bereits ein Job eingetragen, ueber den der GenericAgent, regelmaessig durch einen cron-Job ausgefuehrt, Benachrichtigungen ueber eskalierte Tickets an die Agenten verschickt. Oeffnen 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::NotifyAgentGroupOfCu stomQueue', }, }, # insert your jobs (see Kernel/Config/GenericAgent.pm.examples) ); Wird ein neues Ticket in einer Queue gespeichert fuer die eine Eskalationszeit festgelegt wurde, wird zunaechst der positive Wert fuer die eingestellte Eskalationszeit angezeigt. Die Anzeige bleibt auf den fuer 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, ausserhalb der fuer das System relevanten Zeiten findet keine Berechnung der Eskalationszeit statt. Befindet sich das System in einem fuer die Berechnung relevanten Zeitfenster, wird die Eskalationszeit heruntergezaehlt. Wird der Wert 0 erreicht, eskaliert das Ticket. Im weiteren Verlauf wird der Wert negativ, das Ticket hat die Eskalationszeit ueberschritten. Bei der naechsten Ausfuehrung des GenericAgent-Jobs fuer 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 fuer die Eskalationszeit immer kleiner, der eigentliche Eskalationszeitpunkt rueckt immer weiter in die Vergangenheit. An diesem Verhalten aendert 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 aendert (closed), wird auch die Eskalationszeit zurueck gesetzt. Wird dasselbe Ticket z. B. durch ein Follow-up wieder in einen offenen Status gebracht, beginnt das Herunterzaehlen der Eskalationszeit erneut beim fuer die Queue eingestellten positiven Wert. Ein Ticket kann also nur eskalieren, wenn es nicht gesperrt ist und wenn es sich in einem offenen Status befindet. Ist es gesperrt und noch nicht geschlossen, wird die Eskalationszeit immer weiter herunter gezaehlt, das Ticket eskaliert beim Wert 0. Wird das Ticket geschlossen und z. B. durch ein Follow-up erneut durch das System geoeffnet, beginnt der Eskalationsprozess erneut. __________________________________________________________ Kapitel 9. Einbinden externer Back-ends 9.1. Kundenbenutzerdaten OTRS ist in der Lage, mit verschiedenen Kundendaten (insbesondere Login, Email, Telefon) umzugehen. Diese Informationen koennen im Agenten-Interface angezeigt und fuer das Kunden-Interface verwendet werden. Weiterhin werden die Daten fuer die Authentifizierung der Kunden am System benoetigt. Die benutzten/angezeigten Kundendaten sind frei konfigurierbar, es gibt jedoch drei benoetigte Optionen die unbedingt vorhanden sein muessen, damit OTRS ordnungsgemaess funktioniert: Benutzer-Login, Benutzer-Email und Benutzer-Kunden-ID Wenn Sie die Kundendaten (z.B. Firma, Name, eMail, ...) in Ihrem Agenten-Interface anzeigen moechten, benutzen Sie die folgenden Konfigurations-Optionen und fuegen 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; __________________________________________________________ 9.2. Kundenbenutzer Back-end Es existieren zwei Kundenbenutzer Back-ends, DB und LDAP. Falls Sie bereits ein Kundenverzeichnis (z.B. SAP, ...) haben, ist es natuerlich moeglich, dafuer ein eigenes Back-end zu schreiben. __________________________________________________________ 9.2.1. Datenbank (Standard) Beispiel 9-1. Konfiguration eines DB Kunden Back-ends Dies ist ein Beispiel fuer 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&Response ID=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 moechten, aendern Sie in der Datenbank die Tabellenspalten oder fuegen Sie weitere hinzu (im folgenden Beispiel wird ein Feld fuer die Telefonnummer hinzugefuegt) 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 fuegen 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 ], Natuerlich koennen Sie all diese Kundeninformationen dann auch ueber das Admin-Interface bzw. die Kundenverwaltung pflegen. __________________________________________________________ 9.2.1.1. Kunden mit multiblen IDs (Firmen Tickets) Es ist moeglich, 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 koennen diese Tickets ueber 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 spaeter die Kundennummern eingetragen werden, auf die ein Kunde zusaetzlich 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 fuegen 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 fuer die Multi-Kundennummern kann ab nun ueber das Admin-Interface bzw. ueber die Kundenverwaltung gepflegt werden. Um nun den Zugriff fuer einen Kunden auf die Tickets anderer Kunden zu ermoeglichen, tragen Sie in die neue Spalte die IDs der Kunden ein, auf deren Tickets der Zugriff ermoeglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon. Beispiel 9-2. Firmen Tickets mit einem DB Back-end Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von Firmen Tickets ueber 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 koennen. Um dieses Setup zu realisieren, aendern Sie wie oben beschrieben die customer_user Tabelle in der OTRS Datenbank und das Mapping in Kernel/Config.pm. Anschliessend laden Sie ueber die Kundenverwaltung die Einstellungen des Kunden A und tragen bei "Kundennummern" die Werte "B;C;" ein. __________________________________________________________ 9.2.2. LDAP Falls Sie ein existierendes LDAP Verzeichnis mit Ihren Kundenbenutzern haben, koennen Sie dieses auch mit OTRS nutzen. Beispiel 9-3. Konfiguration eines LDAP Kunden Back-ends Dies ist ein Beispiel fuer 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 que ry, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFil ter => '(objectclass=user)' AlwaysFilter => '', # if your frontend is e. g. iso-8859-1 and the charset of yo ur # 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 perldo c 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 moechten, erweitern Sie das MAP Array in Kernel/Config.pm bzw. entfernen nicht gewuenschte Eintraege: # var, frontend, storage, shown (1=always,2=lite), required, storage -type, http-link, readonly [...] [ 'UserPhone', 'Phone', 'telephonenumber', 1, 0, 'var', '' , 0 ], __________________________________________________________ 9.2.2.1. Kunden mit multiblen IDs (Firmen Tickets) Es ist moeglich, 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 koennen diese Tickets ueber 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 koennen, auf die spaeter ein Kunde zusaetzlich zu den eigenen Tickets Zugriff haben soll, z.B. um das Feld CustomerIDs. Danach fuegen 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, 'v ar', '', 0 ], Das Feld fuer die Multi-Kundennummern muss direkt im LDAP Verzeichnis gepflegt und kann von OTRS aus nicht direkt verwaltet werden. Um nun den Zugriff fuer einen Kunden auf die Tickets anderer Kunden zu ermoeglichen, tragen Sie innerhalb des LDAP Verzeichnisses in das neue Feld die IDs der Kunden ein, auf deren Tickets der Zugriff ermoeglicht werden soll. Die einzelnen IDs trennen Sie durch ein Semikolon. Beispiel 9-4. Firmen Tickets mit einem LDAP Back-end Angenommen es sind die Kunden A, B und C im System angelegt. A soll mit Hilfe von Firmen Tickets ueber 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 koennen. Um dieses Setup zu realisieren, aendern Sie wie oben beschrieben das LDAP Verzeichnis und das Mapping in Kernel/Config.pm. Anschliessend tragen Sie im LDAP Verzeichnis innerhalb der Einstellungen fuer den Kunden A fuer CustomerIDs die Werte "B;C;" ein. __________________________________________________________ 9.2.3. Verwenden mehrerer Kunden Back-ends Soll mehr als nur ein Back-end mit verschiedenen Kundendaten verwendet werden (z.B. gleichzeitig DB und LDAP), so ist dies ebenfalls mit OTRS moeglich. In einem solchen Fall muss der CustomerUser Parameter fuer jedes Back-end um eine Nummer erweitert werden, z.B. "CustomerUser1", "CustomerUser2", usw. Beispiel 9-5. Gleichzeitige Einbindung mehrerer verschiedener Kunden Back-ends 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&Response ID=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 que ry, use # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFil ter => '(objectclass=user)' AlwaysFilter => '', # if your frontend is e. g. iso-8859-1 and the charset of yo ur # 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 perldo c 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 koennen bis zu 10 Kunden Back-ends gleichzeitig eingebunden werden. Ueber die Kundenverwaltung in OTRS ist der Zugriff auf die verschiedenen Back-ends moeglich. __________________________________________________________ 9.3. Back-ends fuer die Authentifizierung von Agenten und Kunden OTRS bietet die Moeglichkeit Agenten und Kunden ueber verschiedene Back-ends zu authentifizieren. Die verschiedenen Konfigurationsmoeglichkeiten werden in den folgenden Abschnitten naeher beschrieben. __________________________________________________________ 9.3.1. Authentifizierungs Back-ends fuer Agenten 9.3.1.1. Datenbank (Standard) Das Back-end fuer die Authentifizierung von Agenten, welches OTRS standardmaessig verwendet, ist die OTRS-Datenbank. Die Agenten koennen innerhalb des Admin-Bereiches in der Benutzerverwaltung angelegt und bearbeitet werden. Beispiel 9-6. Agentenauthentifizierung gegen ein DB Back-end $Self->{'AuthModule'} = 'Kernel::System::Auth::DB'; __________________________________________________________ 9.3.1.2. LDAP Falls ein LDAP Verzeichnis mit Ihren Agenten-Benutzerdaten verfuegbar ist, koennen Sie das LDAP Modul fuer die Authentifizierung Ihrer Agenten nutzen. Dieses Modul greift nur lesend auf die Daten im LDAP Verzeichnis zu, d.h. die Daten koennen nicht mit OTRS bearbeitet werden, es koennen also keine Agenten mit Hilfe der Benutzerverwaltung von OTRS angelegt oder bearbeitet werden. Beispiel 9-7. Agentenauthentifizierung gegen ein LDAP Back-end # 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::L DAP) $Self->{'AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, }; Mit den folgenden Konfigurationsparametern koennen 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 geloescht oder deaktiviert, klappt die Anmeldung an OTRS nicht. Ebenfalls muessen die Daten fuer 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'; __________________________________________________________ 9.3.1.3. HTTPBasicAuth fuer Agenten Falls Sie eine "single sign on"-Loesung fuer Ihre Agenten implementieren moechten, benutzen Sie http basic authentication (fuer alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth Modul (kein OTRS-Login mehr fuer Kunden benoetigt!). Beispiel 9-8. Agentenauthentifizierung ueber HTTPBasic # 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'; __________________________________________________________ 9.3.1.4. Radius Mit den folgenden Einstellungen kann die Authentifizierung von Agenten gegen einen Radius-Server realisiert werden. Beispiel 9-9. Agentenauthentifizierung gegen ein Radius Back-end # This is example configuration to auth. agents against a radius ser ver $Self->{'AuthModule'} = 'Kernel::System::Auth::Radius'; $Self->{'AuthModule::Radius::Host'} = 'radiushost'; $Self->{'AuthModule::Radius::Password'} = 'radiussecret'; __________________________________________________________ 9.3.2. Authentifizierungs Back-ends fuer Kunden 9.3.2.1. Datenbank (Standard) Das Back-end fuer die Authentifizierung von Kunden, welches OTRS standardmaessig verwendet, ist die OTRS-Datenbank. Die Kundendaten koennen ueber das Interface zur Verwaltung von Kunden angelegt und bearbeitet werden. Beispiel 9-10. Kundenauthentifizierung gegen ein DB Back-end # 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=cust omerdb;host=customerdbhost"; # $Self->{'Customer::AuthModule::DB::User'} = "some_user"; # $Self->{'Customer::AuthModule::DB::Password'} = "some_password"; __________________________________________________________ 9.3.2.2. LDAP Falls ein LDAP Verzeichnis mit Ihren Kundenbenutzern verfuegbar ist, koennen Sie das LDAP Modul fuer die Authentifizierung Ihrer Kunden nutzen. Dieses Modul greift nur lesend auf die Daten im LDAP Verzeichnis zu, d.h. die Daten koennen nicht mit OTRS bearbeitet werden, es koennen also keine Kunden mit Hilfe der Kundenverwaltung von OTRS angelegt oder bearbeitet werden. Beispiel 9-11. Kundenauthentifizierung gegen ein LDAP Back-end # This is an example configuration for an LDAP auth. backend. # (take care that Net::LDAP is installed!) $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::LD AP'; $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=po sixGroups,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::L DAP) $Self->{'Customer::AuthModule::LDAP::Params'} = { port => 389, timeout => 120, async => 0, version => 3, }; __________________________________________________________ 9.3.2.3. HTTPBasicAuth fuer Kunden Falls Sie eine "single sign on"-Loesung fuer Ihre Kunden implementieren moechten, benutzen Sie HTTPBasic Authentication (fuer alle Ihre Systeme) und aktivieren Sie das HTTPBasicAuth Modul (kein OTRS-Login mehr benoetigt!). Beispiel 9-12. Kundenauthentifizierung ueber HTTPBasic # 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::HTT PBasicAuth'; # 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-author ised-for-otrs.html'; $Self->{CustomerPanelLogoutURL} = 'http://host.example.com/thanks-fo r-using-otrs.html'; __________________________________________________________ 9.3.2.4. Radius Mit den folgenden Einstellungen kann die Authentifizierung von Kunden gegen einen Radius-Server realisiert werden. Beispiel 9-13. Kundenauthentifizierung gegen ein Radius Back-end # 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'; __________________________________________________________ 9.4. Kunden-Selbstanmeldung anpassen Es ist moeglich, die Kunden-Selbstanmeldung fuer neue Kunden ueber "customer.pl" anzupassen. Somit koennen Sie mehr optionale oder benoetigte Felder (z.B. Adresse, Ort, Telefonnummer) hinzufuegen. In folgenden Beispiel wird ein benoetigtes Feld fuer die Telefonnummer hinzugefuegt. __________________________________________________________ 9.4.1. Anpassen der Weboberflaeche Damit im Webinterface das zusaetzliche Feld fuer die Telefonnummer angezeigt wird, muss die zustaendige dtl-Datei angepasst werden. Editieren Sie Kernel/Output/HTML/Standard/CustomerLogin.dtl und fuegen Sie in Zeile 128 das gewuenschte Feld hinzu. [...] $Text{"Phonenumber"}: [...] __________________________________________________________ 9.4.2. Kunden-Mapping Zusaetzlich muss das Kunden-Mapping um den Eintrag fuer die Telefonnummer erweitert werden. Dazu werden zuerst die Einstellungen fuer "CustomerUser" aus der Datei Kernel/Config/Defaults.pm in die Datei Kernel/Config.pm uebertragen. Anschliessend 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_nam e'], 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=$Dat a{"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.', }, }, }; __________________________________________________________ 9.4.3. Anpassen der Kunden-Tabelle Abschliessend muss eine neue Spalte zur "customer_user" Tabelle in der OTRS Datenbank hinzugefuegt 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 benoetigten Anpassungen sind durchgefuehrt und das Feld fuer die Telefonnummer sollte nun im Kunden-Interface (customer.pl) angezeigt und verwendet werden koennen. Wird mod_perl eingesetzt, muss der Webserver neu gestartet werden um die Aenderungen zu uebernehmen. __________________________________________________________ Kapitel 10. Anpassen der Ticket Status und Ticketstatustypen OTRS erlaubt es Ihnen, die Ticket-Status zu veraendern oder neue Status hinzuzufuegen. Hierbei gibt es zwei wichtige Optionen. Zum Einen den Namen des Status "state-name" und zum Zweiten den Type des Status "state-type". * Die standardmaessig voreingestellten Status lauten: 'neu', 'offen', 'erfolgreich geschlossen', 'erfolglos geschlossen', 'merged', 'entfernt', 'warten auf erfolgreich schliessen', 'warten auf erfolglos schliessen' und 'warten zur Erinnerung'. * Jeder Status besteht aus einem Namen ("state-name") und einem Typen ("state-type"). Der Name ist frei waehlbar und kann ueber das Admin-Interface von OTRS angepasst werden, die Statustypen muessen direkt in der Datenbank geaendert werden. Im Admin-Interface koennen Sie innerhalb der Einstellungen fuer "Status" neue Status fuer die vorhandenen Statustypen hinzufuegen oder aendern. Beachten Sie, dass Sie bei Aenderungen am Status "neu - new" auch die entsprechenden Aenderungen in der Konfigurationsdatei Kernel/Config.pm bzw. mit Hilfe des grafischen Konfigurations-Front-End vornehmen muessen. [...] # PostmasterDefaultState # (The default state of new tickets.) [default: new] $Self->{PostmasterDefaultState} = 'new'; # CustomerDefaultState # (default state of new customer tickets) $Self->{CustomerDefaultState} = 'new'; [...] Auch bei Aenderungen am Status "offen - open" sind Aenderungen in Kernel/Config.pm bzw. mit Hilfe des grafischen Konfigurations-Front-End von Noeten! [...] # default phone new state $Self->{'Ticket::Frontend::PhoneNextState'} = 'open'; # PostmasterFollowUpState # (The state if a ticket got a follow up.) [default: open] $Self->{PostmasterFollowUpState} = 'open'; [...] Moechten Sie einen neuen Statustyp hinzufuegen, muessen 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 koennen Sie ueber das Admin-Interface innerhalb der Einstellungen fuer "Status" neue Ticketstatus hinzufuegen, die als Statustyp "own" enthalten. Anschliessend muessen Sie noch in Kernel/Config.pm oder ueber 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 aut o', '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', 'close d']; # 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 remi nder', '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']; [...] Fuegen Sie einfach bei den Konfigurationsparametern, bei denen Ihr neuer Statustyp mit aufgefuehrt werden soll, Ihren neuen Statustyp mit hinzu. __________________________________________________________ Kapitel 11. Anpassen der Ticket Prioritaeten Wenn Sie die Ticket-Prioritaet anpassen / aendern moechten, arbeiten Sie bitte die naechsten 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 waehlen 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-lo g 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 Prioritaeten: 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> Wichtig Das Attribut "id" bestimmt die Reihenfolge der Prioritaeten. => 1 entspricht dem Minimum und 5 (oder hoeher) repraesentiert das Maximum. Die Nummer im Namen der Prioritaet wird fuer die Umsetzung der korrekten Reihenfolge innerhalb der Prioritaeten verwendet. * Anpassen/Aendern der Prioritaeten 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 ausfuehren, wird die Prioritaet "3 normal" in Zukunft "3 default" lauten. * Beachten Sie bitte, dass Sie die Aenderungen bezueglich der Prioritaet auch in der Konfigurationsdatei (Kernel/Config.pm) oder ueber das grafische Konfigurations-Frond-End nachpflegen muessen. [...] # 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::EmailPriority'} = '3 default'; [...] # default phone priority [default: 3 normal] $Self->{'Ticket::Frontend::PhonePriority'} = '3 default'; [...] # CustomerDefaultPriority # (default priority of new customer tickets) $Self->{CustomerDefaultPriority} = '3 default'; [...] Wenn Sie eine neue Prioritaet hinzufuegen moechten, 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 Prioritaet entsprechend der Dringlichkeit vergeben. __________________________________________________________ Kapitel 12. Erstellung eigener Themes Fuer OTRS koennen verschiedene Themes angelegt werden, also verschiedene Layouts zur Gestaltung der Web-Oberflaeche. Dazu muessen Sie die vorhandenen Templates aendern und Ihren Wuenschen entsprechend anpassen. Mehr Informationen ueber 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: 1. Kopieren Sie das Verzeichnis Kernel/Output/HTML/Standard nach Kernel/Output/HTML/Company. 2. Passen Sie die Dateien im Verzeichnis Kernel/Output/HTML/Company Ihren Wuenschen entsprechend an. 3. Um das neue Theme OTRS bekannt zu machen, muessen Sie die Datenbank haendisch aendern. Gehen Sie hier zu mit MySQL folgendermassen 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 ueber Ihre persoenlichen Einstellungen aktivieren koennen. __________________________________________________________ Kapitel 13. Uebersetzung in verschiedene Sprachen Das OTRS Webfrontend unterstuetzt verschiedene Sprachen. Die Uebersetzungen befinden sich in den Dateien, die unter Kernel/Language/*.pm zu finden sind. Wie der Lokalisationsmechanismus des OTRS Frameworks arbeitet und welche Moeglichkeiten er bietet, entnehmen Siie bitte dem Kapitel "Language Translations" aus dem Developer Handbuch auf http://doc.otrs.org . Dieses Kapitel beschreibt, wie eigene Uebersetzungen eingepflegt und komplett neue Sprachen hinzugefuegt werden koennen. __________________________________________________________ Kapitel 14. PGP In OTRS koennen ausgehende Emails mit Hilfe von PGP signiert oder verschluesselt werden. Ebenfalls ist es moeglich verschluesselte Nachrichten zu entschluesseln. Die Ver- und Entschluesselung mit PGP wird mit Hilfe des GPL-Werkzeugs GnuPG vorgenommen. Zur Einrichtung sind die folgenden Schritte notwendig: 1. 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 durchgefuehrt werden koennen. 2. Im zweiten Schritt muss das soeben installierte GnuPG zur Benutzung fuer OTRS konfiguriert werden. Dies geschieht auf der Kommandozeilenebene durch einen Aufruf von GnuPG, der die notwendigen Verzeichnisse anlegt und den privaten Schluessel erzeugt. Der Aufruf muss als otrs-Benutzer (bzw. als der Benutzer, mit dessen Rechten das Ticket-System laeuft) durchgefuehrt 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 = key expires in n days w = key expires in n weeks m = key expires in n months 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 use r ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " Real name: Ticket System Email address: support@example.com Comment: Private PGP Key for the ticket system with address support@exam ple.com You selected this USER-ID: "Ticket System (Private PGP Key for the ticket system with address suppo rt@examp le.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 A9 70 uid Ticket System (Private pgp key for ticket system wi th addre ss support@example.com) sub 2048g/52B97069 2006-02-03 linux:~$ Wie man sehen kann, genuegt es bei den meisten Fragen die Vorgabe mit zu bestaetigen. Lediglich die Angabe zur ``Person'' des Schluesselbesitzers ist zu vervollstaendigen bzw. zum Ende hin ist an der mit (passphrase) gekennzeichneten Stelle die Passphrase fuer den zu generierenden Schluessel einzugeben. Hier ist zu beachten, dass die Passphrase den ueblichen Anforderungen fuer ein hinreichend sicheres Passwort genuegt. 3. Im naechsten Schritt muss OTRS auf die Verwendung von PGP vorbereitet werden. Suchen Sie in SysConfig nach ``PGP'' und waehen Sie danach dan die Untergruppe Crypt::PGP aus. In der nun angezeigten Maske sollte zum einen " PGP aktiviert werden (die erste Option). Danach sollte ueberprueft werden, ob der voreingestellte Pfad zum Programm gpg der tatsaechlichen Installation entspricht. Die naechste 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 fuer 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. ueber die letzte Option koennen die Schluessel-Werte-Paare fuer die ID(s) und Passphrase(n) der eigenen PGP-Schluessel dem Ticket System bekannt gemacht werden. Noch einmal genauer: da andere Kommunikationspartner an das Ticket-System (oder besser: an den Mail-Eingang des Systems Emails mit dessen oeffentlichen Schluessel verschluesselt schicken, kann OTRSmit dem/n in dieser Option angegebenen privaten Schluessel(n) solchermassen verschluesselte Mails entschluesseln. Woher bekommt man die ID des eigenen Schluessels? Die ID steckt schon in der Ausgabe der Schluesselgenerierung (siehe Schritt 1). Man kann die ID aber auch als Benutzer otrs jederzeit ueber 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 wi th address support@example.com) sub 2048g/52B97069 2006-02-03 linux:~$ Die ID des Schluessels befindet sich in der Zeile, die mit sub beginnt und ist eine 8-stellige hexadezimale Kennung (im Beispiel lautet sie "52B97069". Die fuer die Option geforderte Passphrase ist dieselbe, die beim Schluesselgenerieren in Schritt 1 verwendet wurde. Nach Eingabe all dieser Angaben koennen sie mit dem Aktualisieren-Button gespeichert werden. OTRS ist jetzt fuer das Empfangen mit PGP verschluesselter Emails konfiguriert. 4. Der letzte Schritt ist der Import des oeffentlichen PGP-Schluessels eines Kunden. Dadurch wird sicher gestellt, dass aus OTRS heraus verschluesselte Mails an den jeweiligen Kunden gesendet werden koennen. Es bestehen zwei Moeglichkeiten fuer den Import. Zum einem koennen ueber das Modul zur Verwaltung der Kunden die oeffentlichen PGP-Schluessel beim anlegen/bearbeiten des jeweiligen Kunden im System hinterlegt werden. Die zweite Moeglichkeit 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 Verfuegung stehenden oeffentlichen Schluessel zu sehen. Im Regelfall sollte nach der obigen Einrichtung hier schon der oeffentliche Schluessel des Ticket-Systems selbst zu sehen sein. Im linken Teil besteht neben der Suche die Moeglichkeit, neue Schluessel als Schluesseldatei ins System zu laden. Nach dem Laden eines neuen Schluessels wird dieser in der Liste auf der rechten Seite angezeigt, und gleichzeitig erhaelt man oberhalb der Maske eine Statusmeldung, die ueber das Laden des Schluessels informiert. Sowohl fuer das Hinzufuegen eines Schluessels ueber die Kunden- als auch ueber die PGP-Verwaltung gilt, dass die Dateien mit den Schluesseln PGP/GnuPG-konforme Schluessel sein muessen. I.d.R. wird der Schluessel als ``ASCII armored key''-Datei vorliegen, welches problemlos von OTRS verarbeitet werden kann. __________________________________________________________ Kapitel 15. S/MIME Die Einrichtung der Verschluesselung mit S/MIME scheint auf den ersten Blick ein bisschen komplizierter als die PGP-Einrichtung zu sein, da fuer das OTRS-System erst einmal eine Certification Authority (CA) eingerichtet werden muss. Ansonsten ist das Vorgehen aehnlich wie bei PGP, OTRS konfigurieren, eigenes Zertifikat einrichten, ggf. fremde Public-Zertifikate importieren, usw. Die S/MIME-Konfiguration geschieht zu einem grossen Teil ausserhalb der OTRS-Web-Oberflaeche und sollte als otrs-Benutzer (bzw. als der Benutzer mit dessen Rechten OTRS laeuft) in einer Shell durchgefuehrt 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 bewaeltigt werden koennen. 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 temporaer in den Suchpfad der Shell uebernommen 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 temporaeres Verzeichnis ~/tmp angelegt wurde, in welchem die Zertifikatsgenerierung durchgefuehrt wird. Im einzelnen sind zur Zertifikatserzeugung folgende Schritte durchzufuehren, die einzelnen Schritte sind in der Kommandozeile auszufuehren. Sollte ein beglaubigtes SSL-Zertifikat fuer die Verschluesselung bereits vorhanden sein, so sollte natuerlich dieses verwendet werden. Dann koennen die nun folgenden Schritte uebersprungen werden. Der beschriebene Ablauf geht davon aus, dass der OTRS-Administrator sich das SSL-Zertifikat zu Test- und Lernzwecken selbst anlegen muss. 1. Anlegen einer eigenen Certification Authority fuer SSL. Diese wird benoetigt, um die Anfrage fuer 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> 2. 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> 3. Die Zertifikatsanfrage durch die CA signieren lassen. Die Zertifikatsanfrage kann entweder durch die selbst angelegte CA signiert (= beglaubigt) werden. Allerdings ist es natuerlich serioeser, 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> 4. Mit der signierten Zertifikatsanfrage das eigene Zertifikat und alle dazugehoerigen 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 Durchfuehrung dieser Schritte ist es notwendig die Einrichtung von S/MIME in OTRS abzuschliessen. Die OTRS-seitige Einrichtung erfolgt aus dem Admin-Bereich, Block System ueber den Punkt "SMIME" . Falls die generelle S/MIME-Unterstuetzung in OTRS noch nicht aktiviert wurde, weist die Maske den OTRS-Administrator beim Aufruf darauf hin und bietet einen bequemen Link zur Einrichtung. Ueber die SysConfig kann die generelle S/MIME-Unterstuetzung eingeschaltet und konfiguriert werden. Diese Einrichtung findet man unter der SysConfig-Gruppe "Crypt::SMIME". Neben einem ``Ein-Schalter'' fuer die S/MIME-Unterstuetzung koennen 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 Schluesseldatei in den hier angegebenen Verzeichnissen liegen muessen, um von OpenSSL verwendet werden zu koennen. Im naechsten Schritt geht es (zurueck) zur S/MIME-Konfiguration im Admin-Bereich. Dort koennen nun sowohl der private Schluessel(Key) bzw. die privaten Schluessel des OTRS-Systems, als auch die oeffentlichen Schluessel anderer Kommunikationspartner ins System importiert werden. Tragen Sie hier den oeffentlichen Schluessel ein, der zu Beginn dieses Abschnitts erzeugt und dann in OTRS hinzugefuegt wurde. Selbstverstaendlich koennen aber auch alle oeffentlichen S/MIME-Schluessel der Kommunikationspartner ueber das Modul zur Kundenverwaltung beim anlegen/bearbeiten der jeweiligen Person, in das System importiert werden. __________________________________________________________ Kapitel 16. Zusaetzliche Applikationen Seit OTRS 2.0 gibt es die Moeglichkeit, zusaetzlich zum Framework, weitere Applikationen aus einem Online-Verzeichnis ueber das Admin-Interface (Paket Manager) zu installieren. __________________________________________________________ 16.1. Kalender Dies ist ein Kalender, in dem man Termine benutzerabhaengig eintragen kann. Es werden private und oeffentliche Termine unterstuetzt. [calendar.png] __________________________________________________________ 16.2. ContentManager Mit dem Contentmanager koennen Webseiten online ueber die Web-Oberflaeche erstellt und verwaltet werden. __________________________________________________________ 16.3. Dateimanager Mit dem Dateimanager kann auf ein Verzeichnis des Rechners, auf dem OTRS installiert ist, ueber die Web-Oberflaeche zugegriffen und Dateien hochgeladen, geloescht und angesehen werden. [filemanager.png] __________________________________________________________ 16.4. Webmailer Das Web-Mail-Programm ermoeglicht das Abrufen von Mails ueber einen IMAP-Server, das Verfassen von neuen Nachrichten bzw. die Beantwortung von vorhandenen Emails ueber die Web-Oberflaeche. [webmail.png] __________________________________________________________ 16.5. FAQ Das FAQ-System ist derzeit noch keine eigene Applikation und ist noch im Framework enthalten. Es koennen FAQ-Artikel angelegt und bearbeitet werden. Um die Uebersichtlichkeit und Strukturierung zu erhoehen, ist die Einteilung der FAQ-Beitraege in Kategorien und Sprachen moeglich. __________________________________________________________ 16.6. SystemStatus Dies ist eine System-Status-Uebersicht fuer den OTRS-Administrator, die im Admin-Interface von OTRS zu finden ist. Es koennen eigene Befehle integriert werden, deren Ausgabe ueber die Web-Oberflaeche dargestellt werden. [systemstatus.png] __________________________________________________________ 16.7. Benchmark Dies ist ein Modul zum Testen der Leistung Ihres Systems bezogen auf OTRS. Es wird die Performance verschiedener Datenbankoperationen getestet. __________________________________________________________ Kapitel 17. Leistungsverbesserung Eine erschoepfende Liste verschiedener Techniken, um das Maximum an Leistung aus Ihrem OTRS System herauszuholen: Konfiguration, Programmierung, Speichernutzung und mehr. __________________________________________________________ 17.1. OTRS Im folgenden finden Sie Optionen, die Leistung des Systems via OTRS selbst zu verbessern. __________________________________________________________ 17.1.1. TicketIndexModule Zur Verfuegung stehen zwei Hintergrundmodule fuer den Ticket Index. Kernel/Config.pm [...] $Self->{TicketIndexModule} = 'Kernel::System::Ticket::IndexAccelerat or::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 leistungsfaehigste 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). Fuehren Sie bin/RebuildTicketIndex.pl zum erstmaligen Aufbau des Index aus. __________________________________________________________ 17.1.2. TicketStorageModule Es stehen zwei Module fuer das Speichern der Tickets und Artikel bereit. Kernel/Config.pm [...] $Self->{TicketStorageModule} = 'Kernel::System::Ticket::ArticleStora geDB'; [...] * Kernel::System::Ticket::ArticleStorageDB (Standard), speichere Anhaenge & Co. in der Datenbank. Merke: Benutzen Sie diese Option nicht fuer groessere Systeme. Pro: Ist der Benutzer, unter dem der Webserver laeuft, nicht der OTRS Benutzer, koennen Sie mit diesem Modul Dateiberechtigungsprobleme vermeiden. Contra: Es ist nicht wirklich nett, Anhaenge in Ihrer Datenbank zu speichern. Achten Sie darauf, dass Ihre Datenbank das kann. Fuer MySQL setzen Sie in dessen Konfiguration bspw. "set-variable = max_allowed_packet=8M", um 8 MB grosse Objekte zu speichern (Standard ist 2M). * Kernel::System::Ticket::ArticleStorageFS, speichere Anhaenge & Co. im lokalen Filesystem ab. Merke: Benutzen Sie dies fuer grosse Installationen. Pro: Schneller! Contra: Der Benutzer, unter dem der Webserver laeuft, sollte der OTRS Benutzer sein (Dateisystemberechtigungen!). Note: Ab OTRS 1.2 oder hoeher, kann man das TicketStorageModule im Betrieb aendern! __________________________________________________________ 17.2. Datenbank Einstellungen sind immer spezifisch fuer die jeweils eingesetzte Datenbank. Bei Problemen lesen Sie die Dokumentation und fragen Sie Ihren Datenbankadministrator. __________________________________________________________ 17.2.1. MySQL Wenn Sie den Tabellentyp MyISAM (Standard) benutzen, und einen grossen Teil einer Tabelle geloescht haben, oder wenn Sie sehr viele Aenderungen an einer Tabelle mit Zeilen variabler Laenge 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; __________________________________________________________ 17.2.2. PostgreSQL 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_co nf_e.html Ist die Leistung immer noch nicht genuegend, empfehlen wir, Fragen auf der "PostgreSQL Performance Mailing Liste" zu stellen. Die Teilnehmer der PostgreSQL Liste sind sehr freundlich und koennen wahrscheinlich helfen. http://www.postgresql.org/lists.html. __________________________________________________________ 17.3. Webserver Natuerlich 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 groesser sein. __________________________________________________________ 17.3.1. Datenbank Verbindung Sie koennen die Datenbankverbindung bereits beim Start des httpd-Prozess herstellen lassen - dies spart ebenso Zeit (siehe auch README.webserver). __________________________________________________________ 17.3.2. Vorgeladene Module - startup.pl 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). __________________________________________________________ 17.3.3. Perl Module bei Aenderung neu laden Standardmaessig 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 muessen Sie den Webserver neu starten, wenn Sie irgendetwas aendern! Wichtig, es hat dadurch zur Folge, dass der OTRS-Paket-Manager nicht mehr ueber das Web-Interface bedient werden kann (nur noch ueber CMD - bin/opm.pl). __________________________________________________________ 17.3.4. Die richtige Strategie waehlen Bei wirklich grossen Installationen (ueber 1000 neue Tickets am Tag, ueber 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). __________________________________________________________ 17.3.5. mod_gzip/mod_deflate Falls Ihre Bandbreite ein wenig schmal sein sollte, benutzen Sie mod_gzip fuer Apache1 (http://www.schroepl.net/projekte/mod_gzip/) bzw. mod_deflate fuer Apache2 (default Modul in Apache2). Eine HTML-Seite von 45k wird mod_gzip/mod_deflate auf etwa 7k zusammendruecken - nett. __________________________________________________________ 17.3.6. mod_dosevasive Um http DoS (Denial of Service) Angriffe zu blocken kann mod_dosevasive benutzt werden (leider nur fuer Apache1 verfuegbar). (http://www.nuclearelephant.com/projects/dosevasive/). __________________________________________________________ Kapitel 18. Datensicherung In diesem Kapitel wird beschrieben, wie alle relevanten Daten der OTRS-Installation gesichert und wieder hergestellt werden koennen. __________________________________________________________ 18.1. Backup 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 benoetigten Komponenten sichert. linux:/opt/otrs# cd scripts/ linux:/opt/otrs/scripts# ./backup.pl --help backup.pl - backup script Copyright (c) 2001-2005 Martin Edenhofer usage: backup.pl -d /data_backup/ [-c bzip2|gzip] [-r 30] [-t nofullback up] 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 - backup script Copyright (c) 2001-2005 Martin Edenhofer 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 laesst sich mit -c entweder bzip2 oder gzip zum platzsparenden Backupen nutzen. Damit man bequem Backups, die ein gewisses Alter erreicht haben loeschen kann, wartet das Skript mit dem Schalter -r auf. Die darauffolgende Zeitangabe muss in Tagen erfolgen. __________________________________________________________ 18.2. Restore Um ein Backup wieder einzuspielen, muessen die Applikation (z.B. nach /opt/otrs/) und die Datenbank wieder hergestellt werden. Um Backups einspielen zu koennen, wird ein "scripts/restore.pl" mitgeliefert, das die benoetigten Komponenten wieder zurueck sichert. Es unterstuetzt MySQL und PostgreSQL. linux:/opt/otrs/scripts# ./restore.pl --help restore.pl - restore script Copyright (c) 2001-2005 Martin Edenhofer usage: restore.pl -b /data_backup/