Admin. sys. Nos oignons (version publique) > Services > Request Tracker > Installation de Request Tracker

Installation réalisée sur bulbe.nos-oignons.net le 8 juin 2013.

Une installation sérieuse de Request Tracker nécessite une base de données SQL. On commence donc par mettre en place PostgreSQL.

Installation des logiciels

On installe les paquets Debian :

apt-get install request-tracker4 rt4-db-pgsql

Ensuite, on nous demande quel nom doit avoir l'instance de RT. rt.nos-oignons.net semble un bon choix.

On laisse le soin au paquet de gérer les permissions de RT_SiteConfig.pm.

Pour la base de données, on va aussi demander au paquet de s'en occuper. Il fera ça, très bien.

Une fois l'installation finie, on va déplacer les quelques donnés qui ne sont dans la base SQL vers /srv :

mv /var/lib/request-tracker4 /srv
ln -ns /srv/request-tracker4 /var/lib/request-tracker4

Interface web

Parmis les divers modes d'intégration possible avec le serveur web, on va utiliser FCGI. Il faut donc installer le paquet Perl qui va bien :

apt-get install libfcgi-perl

Pour configurer l'accès à l'interface web, on va modifier la configuration de notre VirtualHost Apache /etc/apache2/sites-available/default-ssl pour ajouter :

Include /etc/request-tracker4/apache2-fcgid.conf

La configuration qui s'y trouve par du principe qu'on accède à l'interface via un chemin en /rt ce qui est exactement ce que nous voulons.

Par contre, il va falloir modifier dans ce fichier les autorisations pour l'interface mail. À la fin du fichier, on se retrouve avec :

<Location /rt/REST/1.0/NoAuth>
    Order Allow,Deny
    Allow from 127.0.0.1 ::1
    Allow from 91.224.149.171 2a01:6600:8081:ab00::1
</Location>

On peut ensuite se connecter à l'interface web. Yeah. :)

Configuration de base

Pour ajuster les réglages généraux, on modifie /etc/request-tracker4/RT_SiteConfig.d/50-debconf. Le fichier devient :

# THE BASICS:

Set($rtname, 'rt.nos-oignons.net');
Set($Organization, 'nos-oignons.net');

Set($CorrespondAddress , 'rt@nos-oignons.net');
Set($CommentAddress , 'rt-comment@nos-oignons.net');

# THE WEBSERVER:

Set($WebPath , "/rt");
Set($WebDomain , "nos-oignons.net");
Set($WebPort, 443);
Set($WebBaseURL , "https://nos-oignons.net");

Pour regénérer ensuite le fichier de configuration après cette modification, il faut faire :

update-rt-siteconfig

Il faut aussi changer l'URL à laquelle le client en ligne de commande se connecte. Dans /etc/request-tracker4/rt.conf :

server https://nos-oignons.net/rt

Interface avec les mails

Request Tracker envoie et reçoit des e-mails. On va donc lui créer les adresses nécessaires (histoire qu'il puisse ensuite gérer les bounces). Pour cela, on ajoute dans /etc/aliases les lignes :

rt:         "|/usr/bin/rt-mailgate --queue General --action correspond --url https://nos-oignons.net/rt/"
rt-comment: "|/usr/bin/rt-mailgate --queue General --action comment --url https://nos-oignons.net/rt/"

Ne pas oublier de mettre à jour la version binaire de la base :

newaliases

Filtres anti-spam

/!\ Nous n'utilisons plus spamassassin et sa clique, mais rspamd. /!\

Afin de prémunir RT des spams, il nécessaire de faire analyser les messages à SpamAssassin, de déterminer que faire en fonction des résultats de l'analyse et de disposer d'un mécanisme d'apprentissage pour entraîner les filtres baysiens.

Divers solutions sont présentées sur le wiki de RT.

On va baser notre système sur le fonctionnement du plugin . Ce dernier ajoute au ticket un attribut SpamReports lorsque ces derniers sont du spam. On marquera donc automatiquement les messages reconnus comme étant du spam avec cet attribut, et on utilisera également la présence de cet attribut pour identifier les messages à apprendre.

Il faut s'assurer que le groupe a bien le droit de supprimer les tickets dans la file qui peut recevoir des spams. Ainsi le message passera en état « effacé » lorsqu'on le rapportera comme spam via le bouton ajouté par l'extension ReportSpam.

La procédure d'installation de l'extension est décrite plus bas.

Analyse des messages par SpamAssassin

Afin de faire analyser les messages entrant par SpamAsssasin, on va utiliser le plugin RT::Interface::Email::Filter::SpamAssassin. Ce dernier n'est plus diffusé officiellement avec RT. Plusieurs versions non-officielles circulent mais aucune n'est compatible avec la nouvelle interface de RT 4.4. On bricole donc un plugin en utilisant le hook BeforeDecode qu'on installera dans /usr/local/share/request-tracker4/lib/RT/Interface/Email/Filter/SpamAssassin.pm.

Reste ensuite à configurer le filtre dans /etc/request-tracker4/RT_SiteConfig.d/10-local-plugins.pm en ajoutant :

Set(@MailPlugins, 'Filter::SpamAssassin', 'Auth::MailFrom');

On va aussi indiquer au plugin d'ignorer les messages pour lesquels on n'a aucun doute. Dans le fichier /etc/request-tracker4/RT_SiteConfig.d/13-spamassassin.pm :

Set($RT::SpamAssassinDropThreshold, 5);

Filtrage des messages en fonction du score de SpamAssassin

On va créer un nouveau Scrip afin de filtrer les messages en fonction du score de SpamAsssasin. Concrêtement, si le score est suffisant (supérieur à 2), on marque le ticket comme étant un spam, et on le le passe en statut résolu.

Les détails :

  • Description : 10. Add SpamReports attribute to messages detected as spam
  • Condition : On Create
  • Action : User Defined
  • Template : Blank
  • Stage : Normal

  • Custom action preparation code :

    # if no message attachment - assume web UI
return 0 unless $self->TransactionObj->Attachments->First;

my $spam_level = $self->TransactionObj->Attachments->First->GetHeader('X-Spam-Level');

# exit if there's no spam header
return 0 unless $spam_level;

return 1 if $spam_level =~ /^\*\*/;
return 0;

  • Custom action commit code :

    my $reports = $self->TicketObj->FirstAttribute('SpamReports');
$reports = $reports->Content if $reports;
$reports ||= [];
push @$reports, 0; # default uid
$self->TicketObj->SetAttribute(
    Name    => 'SpamReports',
    Content => $reports,
);
$self->TicketObj->SetStatus('rejected')

Note : Les Scrips sont executés par ordre alphabétique. On peut donc éviter d'envoyer un message de notification pour un message qui a été classé comme spam en s'assurant que les traitements sont faits dans le bon ordre.

Entraînement du filtre baysien

Il est nécessaire de nourrir SpamAssassin de mails légitimes (ham) et de spam afin qu'il puisse affiner ses critères de tri. Pour les mails légitimes, on pendra tous les mails arrivés pour lesquels le ticket est en état « résolu ». Pour les spams, tous les tickets ayant été rapportés comme spam et dont le rapport a été fait par au moins un autre utilisateur de RT que SpamAssassin (uid 0).

Dupliquer les messages reçus

Une fois un message dans la base de données de RT, il n'est plus possible de reconstituer l'original. Afin de pouvoir communiquer les emails à SpamAssassin pour l'apprentissage, on va donc dupliquer tous les messages reçus par RT dans un Maildir dédié.

Pour cela, on commence par créer un compte qui n'aura comme seul et unique but que de recevoir les messages via Postfix :

sudo adduser --system --group --home /srv/rtmailarchive rtmailarchive

On va créer un Maildir pour recevoir les emails :

sudo -u rtmailarchive mkdir -p /srv/rtmailarchive/Maildir/{cur,new,tmp}
sudo chmod 710 /srv/rtmailarchive/Maildir
sudo chmod 700 /srv/rtmailarchive/Maildir/{cur,new,tmp}

Il faut ensuite créer un fichier /srv/rtmailarchive/.procmailrc pour configurer la livraison des emails :

MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR

On peut ensuite modifier /etc/aliases pour ajouter rtmailarchive en copie des messages pris en charge par RT :

rt:         rtmailarchive,"|/usr/bin/rt-mailgate --queue General --action correspond --url https://nos-oignons.net/rt/"
rt-comment: rtmailarchive,"|/usr/bin/rt-mailgate --queue General --action comment --url https://nos-oignons.net/rt/"

Il ne faut pas oublier de lancer newaliases après la modification.

Tri des messages à apprendre

Le script d'apprentissage sort-rtmailarchive-spams sera installé dans /usr/local/bin. Ce dernier regarde les messages qui ont été réçus par le compte rtmailarchive et pour chacun d'eux, regarde la base de données de RT afin de déterminer si c'est un ham ou un spam (selon les critères définis plus haut). Les messages identifiés sont déplacés dans des dossiers dédiés afin d'entraîner SpamAssassin. Pour les messages identifiés comme ham, on va également modifier la base de données pour qu'ils n'apparaissent plus dans la liste des spams.

Ce script sera executé en tant que rtmailarchive afin de pouvoir travailler directement sur les fichiers.

On va donc créer de nouveaux Maildirs pour stocker les messages en attente (on donne accès au groupe pour la phase d'apprentissage) :

sudo -u rtmailarchive mkdir -p /srv/rtmailarchive/Maildir/.{spam,ham}-tolearn/{cur,new,tmp}
sudo chmod 710 /srv/rtmailarchive/Maildir/.{spam,ham}-tolearn
sudo chmod 770 /srv/rtmailarchive/Maildir/.{spam,ham}-tolearn/{cur,new,tmp}

Il faut également donner l'autorisation au compte d'accéder à la base de données :

sudo -u postgres psql rtdb
CREATE ROLE rtmailarchive LOGIN;
GRANT CONNECT ON DATABASE rtdb TO rtmailarchive;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO rtmailarchive;
GRANT UPDATE ON Attributes TO rtmailarchive;

On peut ensuite exécuter le script pour voir s'il fonctionne :

sudo -u rtmailarchive sort-rtmailarchive-spams

Apprentissage par SpamAssassin

Une fois les messages destinés à entraîner SpamAssassin triés dans des dossiers distincts, l'apprentissage lui-même sera fait par le script train-rtmailarchive-spams. Ce dernier doit tourner en tant que debian-spamd afin de pouvoir toucher à la base de SpamAssassin.

Il est nécessaire de pouvoir lire les messages en attente en tant que debian-spamd. On ajoute donc le compte au groupe rtmailarchive :

adduser debian-spamd rtmailarchive

Reste ensuite à créer un nouveau Maildir où seront conservés les messages après l'apprentissage :

sudo -u rtmailarchive mkdir -p /srv/rtmailarchive/Maildir/.{spam,ham}-learned/{cur,new,tmp}
sudo chmod 710 /srv/rtmailarchive/Maildir/.{spam,ham}-learned
sudo chmod 770 /srv/rtmailarchive/Maildir/.{spam,ham}-learned/{cur,new,tmp}

On peut tester le script via :

sudo -u rtmailarchive train-rtmailarchive-spams

Lancement régulier

Histoire de profiter des capacités d'orchestration de systemd, on définit plusieurs units qui lançeront régulièrement nos deux scripts dans le bon ordre et dans le bon environnement :

  • Un timer pour l'éxécution périodique.
  • Une cible (target) afin de démarrer nos deux scripts.
  • Un service pour chacun des scripts. L'ordre des scripts est assuré par une directive After=.

Le timer dans /etc/systemd/system/train-spamfilters.timer :

[Unit]
Description=Train spam filters every hour

[Timer]
Unit=train-spamfilters.target
OnBootSec=30m
OnUnitActiveSec=1h

[Install]
WantedBy=timers.target

La cible, dans /etc/systemd/system/train-spamfilters.target :

[Unit]
Description=Train spam filters
StopWhenUnneeded=true

Le service pour le script de tri, dans /etc/systemd/system/sort-rtmailarchive-spams.service (créer le répertoire) :

[Unit]
Description=Sort hams and spams received by Request Tracker for future
training
Requisite=postgresql@9.6-main.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/sort-rtmailarchive-spams
User=rtmailarchive
Group=rtmailarchive
IOSchedulingClass=idle

[Install]
WantedBy=train-spamfilters.target

Le service pour le script d'apprentissage, dans /etc/systemd/system/train-rtmailarchive-spams.service :

[Unit]
Description=Train spam filters using hams and spams received by Request
Tracker
After=sort-rtmailarchive-spams.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/train-rtmailarchive-spams
User=debian-spamd
Group=debian-spamd
IOSchedulingClass=idle

[Install]
WantedBy=train-spamfilters.target

Pour activer tout ça :

systemctl enable sort-rtmailarchive-spams.service train-rtmailarchive-spams.service
systemctl enable train-spamfilters.timer

Et on démarre le timer :

systemctl start train-spamfilters.timer

Le journal enregistrera le déroulement des différents scripts pour nous.

On peut voir que le timer fonctionne bien via :

systemctl list-timers

Extensions

On va installer deux plugins supplémentaires qui nous seront bien utiles :

Pour ça, on va utiliser le CPAN. Comme c'est la première fois, il faut le configurer. Attention, ça se lance avec un compte non privilégié :

cpan
Would you like to configure as much as possible automatically? [yes]
Would you like me to automatically choose some CPAN mirror
sites for you? (This means connecting to the Internet) [yes]
cpan> o conf make_install_make_command '/usr/bin/sudo /usr/bin/make'
cpan> o conf mbuild_install_build_command '/usr/bin/sudo ./Build'
cpan> o conf prerequisites_policy follow
cpan> o conf commit

Ensuite, on peut installer nos modules :

cpan> install RT::Extension::ReportSpam
Path to directory containing your RT.pm: /usr/share/request-tracker4/lib/RT.pm
cpan> install RT::Extension::RepeatTicket
Path to directory containing your RT.pm: /usr/share/request-tracker4/lib/RT.pm

Une fois cela fait, on les active en créant un nouveau fichier /etc/request-tracker4/RT_SiteConfig.d/10-local-plugins dans lequel on met :

 Set(@Plugins, qw{RT::Extension::ReportSpam RT::Extension::RepeatTicket});

On regénère une nouvelle fois la configuration :

 update-rt-siteconfig