Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

cool:request_tracker

Request Tracker

Diese Anleitung ist gespickt mit allerlei Hinweisen in dieser optisch hervorgehobenen Form. Beachte sie. Lies sie. Wir fragen das im Support gegebenenfalls ab. ;-)

Request Tracker oder kurz RT ist ein Ticketsystem zur Verwaltung und Bearbeitung von Anfragen, typischerweise solchen die per Mail reinkommen, aber auch eine Webinterface-basierte Nutzung ist möglich. Es ist eines der bekanntesten FOSS Ticketsysteme überhaupt und auch das Ticketsystem mit dem wir bei Uberspace arbeiten. Entwickelt wird RT von Best Practical, die auch allerhand Dienstleistungen rund um RT anbieten. Es gibt sogar ein Buch über RT.

RT ist zwar nicht gerade ein kleines Softwareprojekt, aber es lässt sich durchaus in einem Uberspace installieren und betreiben. Bedenke aber, dass dies nur für kleine Projekte wirklich lange funktionieren wird. Mit einem größeren Projekt würdest Du mit Deiner RT-Installation relativ schnell an die Limits Deines Uberspaces stoßen, sowohl was RAM als auch was Speicherplatz angeht. (Unser eigener RT läuft zwar technisch gesehen auch in einem Uberspace, überzieht aber gnadenlos die Ressourcenlimits die für normale Uberspace-Accounts gelten. Quod licet Iovi, non licet bovi.)

Lucas, einer unserer User, hat sich RT installiert, wir haben ihm dabei ein bißchen geholfen und damit von dem was er und wir dabei gelernt haben auch andere profitieren können, wollen wir hier schildern, wie es geht und gleich noch ein paar Erfahrungen die wir mit RT gemacht haben einfließen lassen.

RT ist komplex und die folgende Anleitung ist es auch. Wir gehen hier auch nur auf die Installation selbst und ein paar Handgriffe ein, das ersetzt aber nicht die Einarbeitung in RT. Wir leisten auch keinen Support für RT. Diese Anleitung ist lediglich dafür gedacht, Interessierten zu helfen ein paar Hürden bei der Installation leichter zu nehmen, mit RT wirst Du Dich aber trotzdem intensiv auseinandersetzen müssen.

Überlegungen vor der Installation

Datenbank

Eine Sache über die Du Dir vor einer Installation Gedanken machen solltest ist, ob Du die Volltextsuchfunktion von RT eher selten bis gar nicht oder häufiger benötigen wirst. Wenn Du sie eher selten bis gar nicht benötigen wirst, kannst Du RT mit MySQL verwenden. Solltest Du aber erwarten häufiger oder gar regelmäßig auf die Volltextsuchfunktion zurückzugreifen, dann solltest Du über PostgreSQL nachdenken, denn dieses Datenbanksystem beherrscht Volltextsuche von sich aus. (Bei MySQL kann eine Drittanbietersoftware für Volltextsuche nachgerüstet werden – das geht aber nicht bei Uberspace.)

Volltextsuchen bei MySQL (ohne die erwähnte Drittanbietersoftware) dauern lange und belasten die Datenbank. Da Du Dir die Ressourcen des Hosts auf dem Dein Uberspace liegt mit den anderen Usern auf diesem Host teilst, solltest Du von dieser Funktion äußerst sparsam Gebrauch machen, wenn überhaupt.

Domain und URI

Außerdem solltest Du Dir jetzt überlegen, unter welcher Domain Du RT betreiben willst und ob Du es unter einer Subdomain betreiben willst oder in einem Ordner unter dieser Domain, denn beides lässt sich später nicht mehr einfach umstellen. Wenn Du RT unter einer Deiner Domains betreiben willst, solltest Du Dir auf jeden Fall vorher ein TLS-Zertifikat besorgen und von uns einrichten lassen, damit Du den Zugriff auf RT verschlüsseln kannst (sonst gehen Deine Zugangsdaten und alles was Du mit dem RT machst unverschlüsselt über's Netz – keine gute Idee).

Wir schildern in diesem Artikel wie Du RT in einem Ordner unter Deiner Uberspace-Domain einrichten kannst, denn dafür haben wir auf unseren Servern bereits passende TLS-Zertifikate installiert. Wir gehen auch kurz darauf ein, was Du bei einer Installation unter einer eigenen Domain ggf. anders machen müsstest. Überleg Dir am besten jetzt, wie Du es in Zukunft gerne haben möchtest, das später umzustellen ist wie gesagt nicht trivial und wir gehen darauf hier nicht weiter ein (weil wir es selbst nicht getestet haben).

Installation

RT wird beständig weiterentwickelt und erhält regelmäßig Updates, darunter auch häufiger wichtige Sicherheitsupdates. Du solltest Deine RT-Installation regelmäßig updaten. Um über Updates auf dem Laufenden zu bleiben, kannst Du die Mailingliste rt-announce abonnieren (die anderen Mailinglisten sind auch einen Blick wert, gerade für neue User).
Da RT sich beständig weiterentwickelt kann diese Anleitung mitunter zügig altern, wir empfehlen daher dringend zuerst die offizielle Installationsanleitung der jeweiligen RT-Version zu lesen (die findest Du in der README-Datei im RT-Softwarepaket) und dann diese Anleitung und dabei ein wachsames Auge für Dinge zu haben, die wir anders machen. Diese Anleitung ist so gesehen mehr ein Leitfaden und sollte auch als solcher gelesen werden.
Noch ein Hinweis vorab: Wenn wir im folgenden Befehle für die Kommandozeile angeben die nicht mit einem $ beginnen, dann kannst Du die einfach so in die Shell kopieren und ausführen. Ist ein $ vorangestellt, dann folgt darauf der eigentliche Befehl (den Du wiederum kopieren sollst) und in den folgenden Zeilen kommt ein Beispiel der Ausgabe, die Du nach dem Befehl erhältst. Du solltest weder das $ noch die Ausgabe in den folgenden Zeilen mitkopieren. In allen Fällen gilt: mit Kopieren meinen wir wirklich Copy&Paste, wenn Du es lieber abtippst, dann achte darauf, wo wir einfache und doppelte Anführungszeichen und Akzente verwenden, die haben jeweils unterschiedliche Bedeutungen, weil wir bewußt Variablen verwenden die bei der Ausführung interpoliert werden, z.B. um Deinen Usernamen einzufügen.
  1. Schau bei Best Practical nach welche RT-Version gerade aktuell ist.
  2. Logge Dich auf Deinem Uberspace ein und lade sie herunter, z.B.:
    wget https://download.bestpractical.com/pub/rt/release/rt-4.4.1.tar.gz
  3. Lege eine Datenbank für den RT an (es bietet sich wirklich an, eine eigene Datenbank für den RT zu haben), für MySQL geht das z.B. so:
    mysql -e "CREATE DATABASE ${USER}_rt4"
  4. RT ist in Perl geschrieben und hat eine Menge Abhängigkeiten. Um diese möglichst bequem zu erfüllen empfehlen wir local::lib oder perlbrew. Im folgenden zeigen wir, wie es mit perlbrew geht.
    Vergewissere Dich zunächst welches Perl-Paket Du derzeit verwendest:
    $ which perl
    /usr/bin/perl

    Wenn Du hier als Ergebnis nicht /usr/bin/perl erhältst, dann ist Dein Perl-Setup nicht mehr so wie bei einem frischen Uberspace und die im folgenden beschriebenen Schritte passen wahrscheinlich nicht mehr. In diesem Fall bist Du auf Dich allein gestellt.

  5. Lass Dir von perlbrew auflisten, welche Perl-Version zur Verfügung steht:
    $ perlbrew list
      perl-5.14.2
      perl-5.22.0
  6. Sag perlbrew, welche Version (eine aus der vorherigen Ausgabe, im einfachsten Fall die einzige aus dieser Ausgabe) es verwenden soll, z.B.:
    perlbrew use perl-5.14.2
  7. Richte perlbrew ein:
    $ perlbrew lib create local
    lib 'perl-5.14.2@local' is created.
  8. Lass Dir erneut auflisten, welche Perl-Versionen zur Verfügung stehen:
    $ perlbrew list
    * perl-5.14.2
      perl-5.14.2@local
  9. Wechsle auf die soeben eingerichtete Perl-Version:
    perlbrew switch perl-5.14.2@local
  10. Prüfe noch einmal das Ergebnis:
    $ perlbrew list
      perl-5.14.2
    * perl-5.14.2@local

    Das Sternchen bzw. der Asterisk sollte gewandert sein, wenn nicht, ist etwas schief gegangen.

  11. Richte CPAN ein (beantworte alle Fragen mit yes, dann gib noch o conf prerequisites_policy follow und o conf commit ein, dann beende wenn alles fertig ist mit quit):
    $ perl -MCPAN -e shell
     
    CPAN.pm requires configuration, but most of it can be done automatically.
    If you answer 'no' below, you will enter an interactive dialog for each
    configuration option instead.
     
    Would you like to configure as much as possible automatically? [yes] yes
     
    Autoconfigured everything but 'urllist'.
     
    Now you need to choose your CPAN mirror sites.  You can let me
    pick mirrors for you, you can select them from a list or you
    can enter them by hand.
     
    Would you like me to automatically choose some CPAN mirror
    sites for you? (This means connecting to the Internet) [yes] yes
    Trying to fetch a mirror list from the Internet
    Fetching with LWP:
    http://www.perl.org/CPAN/MIRRORED.BY
     
    Looking for CPAN mirrors near you (please be patient)
    ....................... done!
     
    New urllist
      http://mirror.rise.ph/cpan/
      http://mirror.neolabs.kz/CPAN/
      http://cpan.excellmedia.net/
     
    Autoconfiguration complete.
     
    commit: wrote '/home/rttest/.cpan/CPAN/MyConfig.pm'
     
    You can re-run configuration any time with 'o conf init' in the CPAN shell
     
    cpan shell -- CPAN exploration and modules installation (v1.9800)
    Enter 'h' for help.
     
    cpan[1]> o conf prerequisites_policy follow
        prerequisites_policy [follow]
    Please use 'o conf commit' to make the config permanent!
     
     
    cpan[2]> o conf commit
    commit: wrote '/home/rttest/.cpan/CPAN/MyConfig.pm'
     
     
    cpan[3]> quit
    Lockfile removed.
  12. Dann installier erstmal manuell Starman, der von RT mittlerweile nicht mehr automatisch als Abhängigkeit mitinstalliert wird:
    cpan Starman
  13. Entpacke nun das vorhin runtergeladene RT-Softwarepaket:
    tar xzvf rt-4.4.1.tar.gz
  14. Wechsle in den soeben entpackten Ordner:
    cd rt-4.4.1
  15. Konfiguriere die Installation, für MySQL z.B. so:
    ./configure --with-my-user-group --with-web-handler=fastcgi,standalone --with-db-type=mysql --enable-gpg --enable-gd --prefix=$HOME/rt4 --with-db-rt-user=$USER --with-db-database=${USER}_rt4 --with-db-dba=$USER

    für PostgreSQL hingegen z.B. so:

    ./configure --with-my-user-group --with-web-handler=fastcgi,standalone --with-db-type=Pg --enable-gpg --enable-gd --prefix=$HOME/rt4 --with-db-rt-user=$USER --with-db-database=${USER}_rt4 --with-db-dba=$USER
  16. Prüfe ob alle Abhängigkeiten von RT erfüllt sind (das wird beim ersten Mal nicht der Fall sein, also nicht wundern):
    make testdeps
  17. Lass Abhängigkeiten installieren (hol Dir am besten jetzt ein stimulierendes Getränk Deiner Wahl geh Mittagessen, das dauert!):
    make fixdeps
  18. Manchmal klappt nicht gleich alles beim ersten Durchgang, deshalb: Wiederhole die beiden vorangegangenen Schritte so lange, bis alle Abhängigkeiten installiert wurden (erkennst Du daran, dass make testdeps meldet: All dependencies have been found.).
  19. Derzeit gibt es bei der Abhängigkeit GD einen Bug der die automatisierte Installation durch make fixdeps verhindert. Wenn Du mit make fixdeps nicht mehr weiterkommst und nur noch GD und ein paar Module für GD fehlen, dann installiere GD manuell:
    cpan -f -i GD

    (Neuere CPAN-Versionen verstehen auch den Parameter -T, dem dann gegenüber -f -i der Vorzug gewährt werden sollte.)

  20. Prüfe das Ergebnis nochmal (wenn hier noch was klemmt, zurück zu Schritt 17):
    make testdeps
  21. Jetzt kannst Du RT installieren:
    make install
  22. Nun musst Du die Config des RT anpassen, damit dieser die Datenbank benutzen kann. Dabei ist zu beachten: die Datei ~/rt4/etc/RT_Config.pm gehört zum RT-Paket und enthält alle Config-Optionen mit ihren Default-Werten. Verändere in dieser Datei nichts, sie wird bei einem Update ohne Nachfrage überschrieben. Such Dir statt dessen aus ~/rt4/etc/RT_Config.pm alles raus was Du anpassen möchtest und trage das dann in ~/rt4/etc/RT_SiteConfig.pm ein.
    Mach am besten zunächst eine Kopie des Ursprungszustands:
    cp ~/rt4/etc/RT_SiteConfig.pm ~/rt4/etc/RT_SiteConfig.pm.bak

    Ein paar Einstellungen solltest Du auf jeden Fall vornehmen, das hier wäre ein Anfang (in dem Du aber einige Werte abändern müsstest, weil wir da Platzhalter einsetzen):

    cat <<__EOF__ > ~/rt4/etc/RT_SiteConfig.pm
    # Any configuration directives you include  here will override 
    # RT's default configuration file, RT_Config.pm
    #
    # To include a directive here, just copy the equivalent statement
    # from RT_Config.pm and change the value. We've included a single
    # sample value below.
    #
    # This file is actually a perl module, so you can include valid
    # perl code, as well.
    #
    # The converse is also true, if this file isn't valid perl, you're
    # going to run into trouble. To check your SiteConfig file, use
    # this comamnd:
    #
    #   perl -c /path/to/your/etc/RT_SiteConfig.pm
    #
    # You must restart your RT service after making changes to this file.
    # Like this:
    #   svc -du ~/service/rt4
     
    # taucht in Mails auf, empfohlen wird ein Domainname, ist später nicht mehr leicht zu ändern
    Set( \$rtname, '$USER.`hostname`' );
     
    # empfohlen wird ein Domainname, kann später nicht mehr geändert werden, ohne Ticket-Links zu zerstören
    Set( \$Organization, 'illuminaten.va' );
     
    # Default-Adressen, können pro Queue überschrieben werden
    Set( \$CorrespondAddress, 'geheime.weltregierung@illuminaten.va' );
    Set( \$CommentAddress, 'geheime.weltregierung-comment@illuminaten.va' );
     
    # bei Uberspace muss hier der Domainname drin stehen über den RT erreicht wird, da RT selbst an localhost gebunden wird und daher diesen Namen nicht herleiten kann
    Set( \$WebDomain, '$USER.`hostname`' );
     
    # bei Uberspace muss hier Port 443 angegeben sein, da RT selbst an einen anderen Port gebunden wird, würde er sonst fälschlicherweise auf diesen anderen Port weiterleiten
    Set( \$WebPort, 443 );
     
    # da wir RT in einem Ordner unter $USER.`hostname` installieren, muss RT das wissen
    Set( \$WebPath, '/rt4' );
     
    # Zeitzone Deiner Wahl, wir gehen mal von Kontinentaleuropa aus
    Set( \$Timezone, "Europe/Berlin" );
     
    # prinzipiell möglich sind bei Uberspace 'mysql' und 'Pg', wobei Postgresql noch eigens dafür eingerichtet werden muss:
    # https://wiki.uberspace.de/database:postgresql
    Set( \$DatabaseType, 'mysql' );
     
    # DB User
    Set( \$DatabaseUser, '$USER' );
     
    # DB Passwort
    Set( \$DatabasePassword, '`my_print_defaults client | grep -- --password | awk -F = '{ print $2 }'`' );
     
    # DB Name
    Set( \$DatabaseName, '${USER}_rt4' );
     
    # LogToSyslog bitte unbedingt so lassen, Dein RT verstopft uns sonst das Syslog!
    Set( \$LogToSyslog, undef );
    # das landet im Log der daemontools, Du hast folgende Loglevel zur Auswahl:
    #   debug info notice warning error critical alert emergency
    Set( \$LogToSTDERR, "notice" );
     
    # an diese Adresse wendet sich RT, wenn es Probleme gibt, Du solltest diese Mails abrufen
    Set( \$OwnerEmail, 'reptilienkoenigin@illuminaten.va' );
     
    # RT läuft bei Uberspace hinter einem ReverseProxy, also
    Set( \$CanonicalizeRedirectURLs, 1 );
     
    # nur anschalten, wenn nur per HTTPS auf RT zugegriffen wird -- was wir bei Uberspace empehlen
    Set( \$WebSecureCookies, 1 );
     
    # Diesen Wert auf keinen Fall höher als 8 stellen, bevor das Default-Passwort von root ('password' = 8 Zeichen) geändert wurde! Die Installation schlägt sonst fehl.
    # Bedenke, dass Passwörter mit weniger als 10 Zeichen trivial zu knacken sind
    Set( \$MinimumPasswordLength, 8 );
     
    # You must install Plugins on your own, this is only an example
    # of the correct syntax to use when activating them.
    # There should only be one @Plugins declaration in your config file.
    #Set(@Plugins,(qw(RT::Extension::QuickDelete RT::Extension::CommandByMail)));
     
    1;
    __EOF__

    Wir gehen hier bewußt nicht auf die Details ein, denn was Du hier sonst noch eintragen musst hängt sehr stark davon ab, was Du mit RT tun willst. Spätestens hier musst Du in die offizielle Dokumentation und das Wiki von RT schauen, insbesondere in die Dokumentation zur Konfiguration, sonst fällst Du auf die Nase. Dieser Schritt kann nicht übersprungen oder auf später verschoben werden.

  23. Wenn Du den vorherigen Schritt erledigt hast, kann es nun weitergehen mit der Installation: RT geht normalerweise davon aus, dass bei der Installation root-Zugriff auf die Datenbank verfügbar ist. Das ist bei Uberspace aber nicht der Fall. Lustigerweise kann RT durchaus mit dieser Situation umgehen, bietet das in seinem Makefile aber nicht an. Um das zu ändern, patchen wir einfach das Makefile. Dazu lade Dir den Patch runter:
    wget -O ~/rt-Makefile-db-skip-create.patch https://uberspace.de/dokuwiki/_media/cool:rt-makefile-db-skip-create.patch

    Und wende ihn an:

    $ patch < ~/rt-Makefile-db-skip-create.patch
    patching file Makefile
  24. Anschließend können wir die Funktion die wir dem Makefile soeben verpasst haben nutzen:
    $ make initialize-database-skip-create
    /package/host/localhost/perlbrew/perls/perl-5.14.2/bin/perl -I/home/rttest/rt4/local/lib -I/home/rttest/rt4/lib sbin/rt-setup-database --action init --skip-create
    Working with:
    Type:   mysql
    Host:   localhost
    Port:   
    Name:   rttest_rt4
    User:   rttest
    DBA:    rttest (No DBA)
    Now populating database schema.
    Done.
    Now inserting RT core system objects.
    Done.
    Now inserting data.
    Done inserting data.
    Done.
  25. Falls Du die daemontools bisher nicht genutzt hast, wird es jetzt Zeit sie einzurichten:
    test -d ~/service || uberspace-setup-svscan
  26. Nun leg Ordner für einen Job unter den daemontools an:
    mkdir -p ~/etc/run-rt4/log
  27. Anschließend leg das run-Skript an:
    cat <<__EOF__ > ~/etc/run-rt4/run
    #!/bin/sh
     
    PORT=8${UID}
     
    export HOME=$HOME
    export USER=$USER
     
    export PERLBREW_ROOT=/package/host/localhost/perlbrew
    source $PERLBREW_ROOT/etc/bashrc
     
    exec 2>&1
    # this will start rt-server with Starman
    # Starman is a high-performance preforking PSGI perl web server, you can learn more about it on CPAN
    exec $HOME/rt4/sbin/rt-server --server Starman --port \$PORT
    __EOF__

    Schau Dir die fertige Datei bitte jetzt nochmal mit einem Editor Deiner Wahl an. Wir benutzen im obrigen Befehl Deine UID um einen Port zu definieren, an den sich RT später binden soll. Es ist nicht garantiert, dass dieser Port noch frei ist, das solltest Du also nochmal prüfen (z.B. mit netstat -tulpen) Es ist ebenfalls nicht garantiert, dass Deine UID dreistellig ist. Sollte sie vierstellig sein, kommt eine Portnummer dabei raus, die es nicht gibt, dann musst Du das noch korrigieren, also einen anderen Port eintragen. (Generell geht es hier nur um einen Port an den sich RT intern bindet, Du musst uns nicht darum bitten, den Port auf der Firewall zu öffnen.)

  28. Dann leg noch das run-Skript für das Log an:
    cat <<__EOF__ > ~/etc/run-rt4/log/run
    #!/bin/sh
    exec multilog t s65536 n10 '!/bin/gzip' ./main
    __EOF__
  29. Mach beide Skripte ausführbar:
    chmod +x ~/etc/run-rt4/run ~/etc/run-rt4/log/run
  30. Lege nun einen Ordner in Deinem DocumentRoot an, z.B.:
    mkdir /var/www/virtual/$USER/html/rt4
  31. Und lege darin eine passende .htaccess-Datei an, z.B.:
    cat <<__EOF__ > /var/www/virtual/$USER/html/rt4/.htaccess
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteCond %{ENV:HTTPS} !=on
    RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
    RewriteRule (.*) http://localhost:8${UID}/\$1 [P]
    __EOF__

    Aufgepasst: Hier muss wieder der Port eingetragen werden, den Du auch im run-Skript stehen hast. Wenn das mit dem Ableiten des Ports von Deiner UID vorhin geklappt hat, kannst Du das auch hier wieder so lassen, falls nicht musst Du es hier genauso ändern wie im run-Skript.

  32. Schließe nun die Einrichtung von RT unter den daemontools ab:
    ln -s ~/etc/run-rt4 ~/service/rt4
  33. Schau nach ob der Dienst läuft, also führe den Befehl
    svstat ~/service/rt4

    mehrmals aus und schau, ob die Uptime die der Dienst hat kontinuierlich ansteigt und größer wird als 10 Sekunden. Wenn nicht, dann stimmt etwas nicht mit der Konfiguration, dann konsultiere das Logfile unter ~/service/rt4/log/main/current.

  34. Wenn der Dienst läuft, solltest Du jetzt auf Deinen RT zugreifen können und zwar – abhängig von Deinem Usernamen und dem Host auf dem Dein Account liegt – unter einer URL wie dieser hier: https://dolores.dementia.uberspace.de/rt4/ oder dieser hier: https://anton.amnesia.uberspace.de/rt4/
  35. Achtung: Der root-User von RT heißt (wenig überraschend) root und sein Default-Passwort ist password. Log Dich jetzt sofort damit in Deinem RT ein und ändere als erstes dieses Passwort!
  36. Wenn Du im vorherigen Schritt dein Passwort nicht geändert hast, kehre nun zu diesem Schritt zurück und führe ihn aus.

Geschafft! Jetzt läuft RT schonmal und kann benutzt werden. – Bedenke aber, dass Du damit erst arbeiten kannst nachdem Du mindestens die Queues konfiguriert, Privilegierte User angelegt, und die Rechte die sie haben sollen genau eingestellt hast. Wenn Du Mails empfangen willst, musst Du das ebenfalls erst noch einrichten.

In jedem Fall solltest Du für Dich selbst einen Admin-Account einrichten und nicht den Root-Account dafür verwenden.

Unterschiede bei einer Installation mit eigener Domain

Wenn Du RT nicht in einem Ordner und unter Deiner Uberspace-Subdomain betreiben möchtest, sondern unter einer eigenen Domain oder einer Subdomain, dann brauchst Du ein TLS-Zertifikat und müsst bei der Installation ein paar Dinge anders machen.

  • Zunächst wäre da die Konfiguration von RT selbst, hier müsstest Du die folgenden Einstellungen abweichend vornehmen:
    Set( $rtname, 'rt.illuminaten.va' );
    Set( $WebDomain, 'rt.illuminaten.va' );
    Set( $WebPath, '' );
  • Dann müsstest Du einen anderen Ordner in Deinem DocumentRoot anlegen:
    mkdir /var/www/virtual/$USER/rt.illuminaten.va
  • Und schließlich müsste die .htaccess-Datei dann dementsprechend auch in diesem Ordner erstellt werden.

So geht's weiter

Für die weitere Konfiguration solltest Du Dich zunächst eingehend mit der Config und der Administration von RT beschäftigen. Anschließend solltest Du Dich im Webinterface umsehen und dort Deine Queues und User einrichten.

Im Wiki zum RT gibt es sogar eine Seite die treffenderweise It's Finally Installed, Now What? heißt.

Richte ein Backup ein.

Setz Dich mit Security auseinander. Mach regelmäßig Updates.

Mailempfang

Wenn Du mit RT Mails entgegen nehmen möchtest, dann musst Du eine Brücke zwischen dem Mailsystem und dem RT schlagen. Dafür ist das Tool rt-mailgate da.

Sagen wir Du hast Dir im RT über das Webinterface bereits eine Queue namens „Geheime Weltregierung“ angelegt und möchtest nun, dass Mails die an geheime.weltregierung@illuminaten.va gehen dort ankommen. Hierfür brauchst Du qmail nur zu sagen, dass es Mails an diese Adresse an rt-mailgate übergeben soll:

cat <<__EOF__ > ~/.qmail-geheime:weltregierung
|${HOME}/rt4/bin/rt-mailgate --queue 'Geheime Weltregierung' --action correspond --url http://${USER}.`hostname`:8${UID}/
__EOF__

Falls Du obendrein ermöglichen möchtest, dass diese Queue auch Kommentare per Mail erhält (das nicht nicht in jedem Setup sinnvoll), dann brauchst Du noch so etwas wie das folgende:

cat <<__EOF__ > ~/.qmail-geheime:weltregierung-comment
|${HOME}/rt4/bin/rt-mailgate --queue 'Geheime Weltregierung' --action comment --url http://${USER}.`hostname`:8${UID}/
__EOF__

Aufgepasst: Hier muss wieder der Port eingetragen werden, den Du auch im run-Skript stehen hast. Wenn das mit dem Ableiten des Ports von Deiner UID vorhin geklappt hat, kannst Du das auch hier wieder so lassen, falls nicht musst Du es hier genauso ändern wie im run-Skript.

Am Ende sollten diese Dateien dann so ähnlich aussehen:

cat ~/.qmail-geheime:weltregierung ~/.qmail-geheime:weltregierung-comment
|/home/xena/rt4/bin/rt-mailgate --queue 'Geheime Weltregierung' --action correspond --url http://xena.xenon.uberspace.de:8542/
|/home/xena/rt4/bin/rt-mailgate --queue 'Geheime Weltregierung' --action comment --url http://xena.xenon.uberspace.de:8542/

Zu Guter Letzt musst Du nun noch im RT konfigurieren, welche User das Recht haben per Mail ein Ticket zu eröffnen. Wenn Du das grundsätzlich allen die an diese Adresse eine Mail schicken erlauben willst, dann musst Du außerdem den RT so konfigurieren, dass er für neue Absender automatisch (unprivilegierte) Useraccounts anlegt.

Datenbankgröße

Bei jeder RT-Installation sollte die Größe der Datenbank im Auge behalten werden, denn je größer die Datenbank wird, desto schwerfälliger werden bestimmte Operationen, insbesondere die Volltextsuche. Bei Uberspace kommt noch hinzu, dass Dir nur 10 GB Speicherplatz zur Verfügung stehen, Deine Datenbanken also nicht beliebig wachsen können.

Was die RT-Datenbank mit der Zeit erheblich anschwellen lässt sind in erster Linie die Tickets selbst, vor allem wenn Du mit RT Mails entgegen nimmst, und zwar aus zwei Gründen:

  1. Anhänge
  2. Spam

Mit Anhängen sind hier nicht nur Dateianhänge an Mails gemeint, sondern auch die Mails selber. Gerade wenn Du es mit Leuten zu tun hast die rigoros TOFU-Mails schreiben (gerade im geschäftlichen Mailverkehr ist das eine unausrottbare Pest) und selbst wenn Du in Deinen Antworten immer so viel vom alten Mailverlauf wegschneidest wie möglich (und das solltest Du tun), wird das Deine RT-Datenbank mit der Zeit sehr anschwellen lassen (und nebenbei viele nutzlose doppelte, dreifache, vierfache, … zigfache Treffer in der Volltextsuche generieren). Aber auch normale Dateianhänge und vor allem gigantische Dateianhänge in Binärformaten stellen ein Problem dar.

Es empfiehlt sich daher

  • die Größe von Anhängen eventuell zu begrenzen (RT hat Einstellungen dafür, aber das hast Du in der Doku bestimmt schon gelesen),
  • einen Spamfilter vor dem RT zu betreiben oder sogar zu moderieren, welche Mails überhaupt in den RT gelassen werden (wenn Deine Arbeitsweise mit dem RT das zulässt),
  • Deine User zu erziehen, keine TOFU-Mails zu schreiben,
  • Deine User zu erziehen, keine unnötig gigantischen Binär-Anhänge zu schicken (keine Screenshots im TIFF- oder BMP-Format, o.ä.),
  • Deine User zu erziehen, auch auf sonstige Binäranhänge (PDFs, Word-Prozessor-Dateien, etc.) wo es geht zu verzichten,
  • Deine User zu erziehen, normale Text-Mails oder allenfalls Rich-Text-Mails zu schicken und keine aufwendig gestalteten HTML-Mails (die RT sowieso nicht darstellen kann),
  • Tickets mit Spam als gelöscht zu markieren und später den RT Shredder darauf loszulassen,
  • eventuell Datei-Anhänge die nicht mehr benötigt werden aus der Datenbank zu entfernen,
  • wenn das alles nicht mehr hilft könntest Du überlegen alte, erledigte Tickets ebenfalls mit dem RT-Shredder zu entfernen.

RT Shredder

Wenn Du Tickets als gelöscht markierst (bzw. auf den Status gelöscht setzt) bleiben sie trotzdem in der Datenbank, sie sind nur über die normalen Suchfunktionen nicht mehr auffindbar. Der Grund dafür ist in erster Linie, dass die Datenbankstruktur von RT kein einfaches Löschen von Tickets aus der Datenbank hergibt. Was den Usern als Tickets präsentiert wird setzt sich aus vielen Stücken zusammen, die verstreut in der Datenbank abgelegt sind, insbesondere dann wenn Tickets obendrein untereinander verknüpft sind oder sogar miteinander vereinigt wurden.

Glücklicherweise gibt es mittlerweile einen offiziellen Weg, um Tickets gefahrlos aus der Datenbank löschen zu können: das Tool RT Shredder.

Du kannst RT Shredder über das Webinterface von RT benutzen, oder auf der Kommandozeile, letzteres eignet sich insbesondere um mit einem Cronjob oder per runwhen regelmäßig alte Tickets zu löschen.

Im Grunde gibst Du RT Shredder einfach nur eine Datenbank-Suchabfrage in die Hand die genau jene Tickets findet, die Du gelöscht haben willst. RT Shredder führt diese Suchabfrage aus und beginnt dann jedes Ticket aus dem Ergebnis bzw. dessen über die Datenbank verstreuten Komponenten vorsichtig aus der Datenbank zu entfernen. Dabei empfiehlt es sich allerdings, niemals allzu viele Tickets auf einmal zu löschen, denn solche komplexen Operationen sind etwas anstrengend für die Datenbank.

Obendrein hat RT Shredder die Fähigkeit, gelöschte Tickets in Form eines SQL-Dumps abzulegen – dadurch besteht später immer noch die Option sie wiederherzustellen.

Hier mal ein Beispiel, wie Du mit runwhen alle zehn Minuten zehn alte, als gelöscht markierte Tickets aus der Datenbank löschen könntest:

#!/bin/sh -e
 
RUNWHEN=",M/10"
 
export USER=xena
export HOME=/home/xena
. $HOME/.bash_profile
 
# The constraint string consists of a sequence of unit constraints. Each unit
# constraint consists of a comma, one of the following letters indicating which
# unit is constrained:
#
#     * y: year.
#     * m: month (in the range 1-12).
#     * d: day of the month (in the range 1-28, 1-29, 1-30, or 1-31, as
#          appropriate for the month in question).
#     * w: day of the week (in the range 0-6, with 0 representing Sunday).
#     * H: hour of the day (in the range 0-23).
#     * M: minute of the hour (in the range 0-59).
#     * S: second of the minute (in the range 0-59). 
#
# and finally one of the following:
#
#     * =n: matches times when the given unit is exactly n.
#     * -n: matches times when the given unit is exactly m, where m+n is one
#           more than the largest value of the unit. (For example, n+m=24 for H,
#           so ,H-1 is equivalent to ,H=23.
#     * /n: matches times when the given unit is divisible by n. 
 
exec 2>&1 \
rw-add n d1S now1s \
rw-match \$now1s $RUNWHEN wake \
sh -c '
  echo "@$wake" | tai64nlocal | sed "s/^/next run time: /"
  exec "$@"' arg0 \
rw-sleep \$wake \
~/rt4/sbin/rt-shredder \
  --sqldump ~/rt4/var/data/RT-Shredder/deleted-tickets-`date +%s`.sql \
  --plugin "Tickets=query,Status = 'Deleted' AND LastUpdated < '30 days ago';limit,10" \
  --force
Aufgepasst: Wenn Du dem obrigen Beispiel folgst, sammeln sich in ~/rt4/var/data/RT-Shredder/ mit der Zeit viele Dateien an. Die wirst Du beizeiten löschen oder mindestens komprimieren wollen.

PGP / GnuPG

RT kann mit Mails umgehen, die mit PGP signiert und verschlüsselt wurden, d.h. es kann Signaturen prüfen, Mails entschlüsseln und natürlich selbst auch wieder signieren und verschlüsseln. Das geht sogar soweit, dass RT seinen Privilegierten Usern (also Dir und allen die richtige Userrechte in RT haben) ebenfalls verschlüsselte Mails schicken kann (wenn passende Public Keys vorliegen), d.h. wenn eine verschlüsselte Mail bei RT eingeht und es so konfiguriert ist, daraufhin bestimmte Privilegierte User anzuschreiben, dann entschlüsselt es die Mail (sie ist ja mit dem Key von RT verschlüsselt) und schickt sie dann an die Privilegierten User, verschlüsselt mit deren jeweiligen Keys. Und es besteht sogar die Möglichkeit, dass RT von Privilegierten Usern Antworten und Kommentare per Mail entgegen nimmt – denn bei einer korrekt signierten (und optional verschlüsselten) Mail kann sich RT hinreichend sicher sein, dass die Mail von jeweiligen Privilegierten User kam und niemand anderem.

Um das nutzen zu können musst Du bereits wissen wie Du PGP benutzt und Du musst Dich in diese Funktionen von RT einarbeiten und sie testen. Wir geben hier nur eine sehr grobe Übersicht:

Zuallererst musst Du den PGP Support in der Config natürlich aktivieren und in Deinem Account GnuPG einrichten.

Du musst RT für jede Queue bei der Du PGP nutzen möchtest einen Key erstellen (der dann auf z.B. für die Adresse geheime.weltregierung@illuminaten.va gültig ist) und das im Webinterface von RT einstellen. Den Public Key solltest Du auf öffentlichen PGP Keyservern hochladen und auf Deiner Webseite verlinken und / oder zum Download anbieten. Wenn du auch Kommentare per Mail entgegen nimmst, muss auch die dazu passende Adresse auf dem Key stehen (also z.B. geheime.weltregierung-comment@illuminaten.va). Außerdem muss RT natürlich mit PGP-Support installiert worden sein.

Wenn Deine Privilegierten User im RT ebenfalls per PGP mit dem RT kommunizieren können sollen, braucht RT von ihnen jeweils die Public Keys. Die musst Du in Deinen GnuPG-Keyring importieren und dann im Webinterface den jeweiligen Usern zuordnen.

Damit RT in der Lage ist zu entschlüsseln musst Du ihm entweder in der Config von RT das Passwort für den jeweiligen PGP Key geben oder den Key über einen Mechanismus wie GPG-Agent entsperren.

Ein paar Erfahrungen die wir gemacht haben:

  • Wenn Du mehrere GPG-Keys verwenden willst (etwa einen für jede Queue), müssen diese entweder alle mit demselben Passwort geschützt sein und dieses in der Config von RT stehen, oder Du musst gpg-agent verwenden. Es gibt anscheinend (bisher) keinen Mechanismus RT mehrere Passwörter zu geben und zu sagen, für welche Keys die sind.
  • Wir waren bisher nicht in der Lage gpg-agent dazu zu bringen unter den daemontools korrekt zu laufen.
  • RT sendet bei PGP-Fehlern Mails an die User. Diese Mails findest Du im Webinterface bei den Mailvorlagen. Sie sind bisher (Stand: RT 4.0.17) nicht übersetzt. Ggf. solltest Du sie für Deine User übersetzen (und bei der Gelegenheit aussagekräftiger und verständlicher formulieren).
  • Die Mails die RT bei PGP-Fehlern versendet kommen immer von der Adresse der Haupt-Queue, egal in welcher Queue der Fehler auftrat, das kann für User u.U. verwirrend sein, wenn sie diesen Absender nicht kennen.
  • RT kann keine angehängten Public Keys verarbeiten. (Weil das in der Logik von PGP auch sinnlos ist. Der Key wird benötigt um die Signatur zu prüfen und sollte daher aus einer anderen Quelle kommen, also nicht aus der Mail selbst, sondern von einem Keyserver oder aus dem Keyring.)
  • Je nachdem ob Du lieber PGP-Inline oder PGP/MIME verwendest und den RT entsprechend konfigurierst, wirst Du mit dem jeweils anderen Format Probleme haben.

Autocomplete auf der Loginseite erlauben

Bei RT ist normalerweise auf der Login-Seite beim Passwort autocomplete=off gesetzt, wodurch einige Browser eventuell vorhandene Passwort-Manager-Funktionen nicht zum Einsatz kommen lassen. Dies lässt sich aber ändern:

  • Lege zunächst parallel zur vorhandenen RT-Ordnerstruktur ~/rt4/share/html/Elements/ eine lokale Variante an:
    mkdir -p ~/rt4/local/html/Elements/Login
  • Kopiere dann die Datei ~/rt4/share/html/Elements/Login dorthin:
    cp ~/rt4/share/html/Elements/Login ''~/rt4/local/html/Elements/Login''
  • Entferne mit einem Editor Deiner Wahl das einzige Vorkommen von autocomplete=off (das müsste etwa auf Zeile 76 sein – Stand: RT 4.2.1) aus der neuen Datei.
  • Anschließend leere den Mason Cache:
    rm -rf ~/rt4/var/mason_data/obj/*
  • Zur Sicherheit solltest Du nach dem Entfernen des Caches RT neustarten:
    svc -du ~/service/rt4

Anschließend sollte RT auf der Login-Seite einen leicht anderen Quelltext vorweisen und der Passwort-Manager Deines Browsers sollte anschlagen.

Dadurch, dass diese Änderung in der Parallel-Ordnerstruktur liegt, wird sie bei Updates von RT nicht überschrieben. Du solltest nach einem Update aber immer nachschauen, ob sich bei RT von dem Autocomplete-Teil abgesehen etwas geändert hat, z.B. so:
diff ~/rt4/share/html/Elements/Login ''~/rt4/local/html/Elements/Login

Versehentliche Ticketvereinigung rückgängig machen

Du kannst in RT Tickets vereinigen (Merge). Dieser Schritt lässt sich über das Webinterface nicht rückgängig machen, sondern nur durch direkte Manipulation der SQL-Datenbank:

Tickets liegen in der Tabelle Tickets in der RT-Datenbank, sie haben eine einzigartige id und eine nicht notwendigerweise einzigartige EffectiveId. Wenn nun zwei Tickets vereinigt werden, erhält eines von diesen beiden Tickets im Feld EffectiveId die id des anderen Tickets. Setzt Du nun die EffectiveId wieder auf die id des Tickets zurück, ist die Vereinigung rückgängig gemacht. Aber die Sache hat noch einen Haken: Die Requestor-Zuordnung kommt dabei durcheinander. Du musst Dich also nochmal (wieder im Webinterface) darum kümmern, hier die Personen die als Klienten, Besitzer und CCs eingetragen sind zu kontrollieren und ggf. zu korrigieren.

Ein Beispiel:

$ mysql
mysql> use xena_rt4
mysql> select id,EffectiveId from Tickets where id = 48990; 
+-------+-------------+
| id    | EffectiveId |
+-------+-------------+
| 48990 |       48872 |
+-------+-------------+
1 row in set (0.00 sec)

mysql> select id,EffectiveId from Tickets where id = 48872;
+-------+-------------+
| id    | EffectiveId |
+-------+-------------+
| 48872 |       48872 |
+-------+-------------+
1 row in set (0.00 sec)
mysql> update Tickets set EffectiveId=48990 where id=48990;
Query OK, 1 row affected (0.03 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql> select id,EffectiveId from Tickets where id = 48990; 
+-------+-------------+
| id    | EffectiveId |
+-------+-------------+
| 48990 |       48990 |
+-------+-------------+
1 row in set (0.00 sec)

Das geht natürlich auch über Adminer und phpMyAdmin.

cool/request_tracker.txt · Zuletzt geändert: 2016/10/27 23:09 von uber