Request Tracker, souvent surnommé rt, est un gestionnaire de tickets.

Fichiers

Configuration

Dans RT_SiteConfig.d/11-local-options, on défini les options suivantes :

# Ne pas révéler l'identité des gens qui traitent les tickets.
Set($UseFriendlyFromLine, 0);
Set($UseOriginatorHeader, 0);

/etc/request-tracker4/rt.conf

Fichier de configuration de l'interface en ligne de commande. Cf. rt(1).

/etc/aliases

Pour chaque adresse e-mail utilisée par RT, on a un alias correspondant.

Confinement et lancement

Request Tracker doit tourner sous un utilisateur propre. Il faut donc créer l'utilisateur et lui donner possession des bons fichiers :

adduser --system --group --home /srv/request-tracker4 rt4
chgrp rt4 /etc/request-tracker4/RT_SiteConfig.pm \
    /etc/request-tracker4/RT_SiteConfig.d/*
chmod 0640 /etc/request-tracker4/RT_SiteConfig.pm \
    /etc/request-tracker4/RT_SiteConfig.d/*
chown -R rt4 /srv/request-tracker4
chown -R rt4:rt4 /var/log/request-tracker4
chown -R rt4 /var/cache/request-tracker4

Le service lui-même est géré via deux unit files systemd ; l'un décrit le socket où le service est joignable, l'autre décrit le service lui-même :

rt4-fcgi.socket

[Unit]
Description=FastCGI socket for RT4

[Socket]
SocketUser=www-data
SocketGroup=www-data
SocketMode=0600
ListenStream=/run/%p.sock

[Install]
WantedBy=sockets.target

rt4-fcgi.service

[Unit]
Description=FastCGI spawner for rt4
After=syslog.target

[Service]
StandardInput=socket
SyslogIdentifier=%p
EnvironmentFile=-/etc/default/%p
User=rt4
ExecStart=/usr/share/request-tracker4/libexec/rt-server.fcgi
Restart=on-failure
RestartSec=5

# The service gets its own instance of {/var,}/tmp
PrivateTmp=true
# Makes /usr, /boot and /etc read-only
ProtectSystem=full
# Prevents access to /home, /root and /run/user
ProtectHome=true

# sendmail is sadly incompatible with NoNewPrivileges
NoNewPrivileges=false
CapabilityBoundingSet=
InaccessibleDirectories=/srv/association /srv/awstats /srv/git /srv/http
InaccessibleDirectories=/srv/ikiwiki /srv/mailman
InaccessibleDirectories=/srv/postgresql /srv/schleuder


[Install]
WantedBy=multi-user.target
Also=rt4-fcgi.socket

Données

En plus de la base de données SQL, des données se trouvent dans /srv/request-tracker4.

Base de données SQL

Request Tracker utilise la base rtdb dans PostgreSQL. Cette dernière est accédé grâce au compte dédié rtuser.

Note : la maintenance de la base et du compte lié est prise en charge par le paquet Debian.

Files

Une file (queue en anglais) se crée de la façon suivante :

  1. Se connecter à RT en tant que root. Le mot de passe est enregistré dans Keyringer.
  2. Aller sous Tools/Configuration/Queues/Create. Ce menu, tout en haut de la page, n'apparaît que si vous avez activé JavaScript.
  3. Les cas échéant, créer les adresses mails correspondantes dans /etc/aliases. N'oubliez pas de lancer newaliases puis de commettre la configuration dans etckeeper.

abuse

Cette file reçoit directement les mails envoyés à abuse@.

N'importe qui (même non enregistré) peut créer un ticket sur abuse@, le commenter et y répondre.

Un « scrip action » (sic) y est associé, pour notifier le groupe abuse lors de la création d'un ticket. L'action est créée comme suit :

 rt-email-group-admin --create 'Notify abuse team' --group abuse

Il faut ensuite créer un script minimaliste (via l'interface web) :

Condition: On Create
Action:    Notify abuse team
Template:  Corresp
Stage:     TransactionCreate

De plus, un script notifie la personne prenant en charge un ticket, lorsqu'une réponse est reçue :

Condition: On Correspond
Action:    Notify owner
Template:  Corresp
Stage:     TransactionCreate

Ces deux scrips font référence au patron Corresp, spécifique à la file abuse.

Après beaucoup trop d'essais pénibles, on va aussi créer un script général pour prévenir l'équipe en cas de prise d'un ticket :

Condition: User Defined
Action:    Notify abuse team
Template:  Transaction
Stage:     TransactionCreate

return 0 unless $self->TicketObj->QueueObj->Name eq "abuse";
return 0 unless $self->TransactionObj->Type eq "Set";
return 0 unless $self->TransactionObj->Field eq "Owner";
return 1;

contact

L'objet de cette file est de recevoir directement les mails envoyés à contact@.

Elle n'est pour l'instant pas associée à l'adresse mail en question, le temps que nous nous « rodions » sur abuse@.

adminsys

Il s'agit d'une file pour les tâches des administrateurs systèmes.
Elle a pour objet de contenir les tâches (périodiques ou non) des administrateurs et permettre d'en suivre l'évolution.

Son interface mail est sur les adresses rt-adminsys{,-comment}@nos-oignons.net.

Elle est dotée, comme abuse, d'un scrip de notification ; de plus, ce scrip utilise un template personnalisé.

Il utilise une action créée manuellement (rt-email-group-admin ne permet pas l'envoi de messages à des adresses ne correspondant pas à des utilisateurs RT). Cette action (Send Email) permet l'envoi d'un courriel se comformant à un template, qui peut spécifier des en-têtes, dont le champ To.
Cette action est créée comme suit :

cat > SendEmailAction << EOF
    @ScripActions = (
        { Name        => 'Send Email',
          Description => 'Sends a message to those specified in the template',
          ExecModule  => 'SendEmail',
          Argument    => '' },
    );
EOF
sudo rt-setup-database --action insert --datafile SendEmailAction

Le template utilisé spécifie donc un envoi à abuse@nos-oignons.net, en spécifiant l'objet, et en transmettant les pièces jointes (RT-Attach-Message). Le template est basé sur le template global par défaut Transaction.

To: adminsys@nos-oignons.net
Subject: {$Ticket->Subject}
RT-Attach-Message: yes


{$Transaction->CreatedAsString}: Request {$Ticket->id} was acted upon.
 Transaction: {$Transaction->Description}
       Queue: {$Ticket->QueueObj->Name}
     Subject: {$Transaction->Subject || $Ticket->Subject || "(No subject given)"}
       Owner: {$Ticket->OwnerObj->Name}
  Requestors: {$Ticket->RequestorAddresses}
      Status: {$Ticket->Status}
      Ticket: {RT->Config->Get('WebURL')}Ticket/Display.html?id={$Ticket->id}


{$Transaction->Content()}

Ajouter un utilisateur

Pour ajouter un nouvel utilisateur, il faut se connecter en root, avec le mot de passe stocké dans le trousseau services de keyringer, puis tout se fait à l'aide de l'interface web. Attention à ne pas oublier de l'ajouter dans les groupes adéquats au passage si nécessaire.

Rejeter automatiquement les messages de robots

Conformément à notre politique, on ne répond pas aux abus envoyés par des robots s'il n'y a pas d'humain derrière. Certains tickets sont donc automatiquement passé à l'état « rejeté » s'ils proviennent de robots connus.

Pour ajouter l'adresse d'un robot, il faut modifier l'expression rationnelle qui se trouve dans le Scrip qui s'appelle 11. Reject tickets from robots en se connectant en root à Request Tracker.

Utilisation du dispositif anti-spam

L'analyse des messages se fait automatiquement lorsqu'ils sont envoyés à une adresse pris en charge par Request Tracker.

Les messages qui sont indubitablement du spam (score supérier à 5) ne seront pas transmis à RT et dispraissent donc pûrement et simplement.

Les nouveaux tickets qui semblent être du spam (score supérieur à 2) sont automatiquement marqué comme spam et passé en statut « rejeté ». On peut ensuite revenir sur ces messages afin de confirmer leur statut de spam ou au contraire de les reconsidérer comme ham.

Examiner les messages classés comme spam

On peut vérifier que les tickets qui ont été automatiquement rejetés sont bien des spams en utilisant la page fournie par SpamReports qui est accessible dans le menu Outils → SpamReported.

Si le message est bien un spam, cliquer sur le S confirmera le message comme tel et passera le ticket en état « éffacé ».

Si le message n'est pas pas un spam, il faut changer son état pour tout autre état que « rejeté » ou « effacé ». Le message sera utilisé pour entraîner le filtre baysien le lendemain matin, et il ne sera alors plus visible comme spam.

Gérer un afflux de spam

En cas de vague de spams, on peut faire un apprentissage massif en utilisant la page Outils → SpamRecent. Cliquer sur le S marquera le message comme spam et passera le ticket en état « éffacé ». Il sera ensuite utilisé pour entraîner le filtre baysien.