Request Tracker, souvent surnommé rt, est un gestionnaire de tickets.
Fichiers
Configuration
Dans RT_SiteConfig.d/11-local-options
, on définit 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ée 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 :
- Se connecter à RT en tant que
root
. Le mot de passe est enregistré dans Keyringer. - Aller sous
Tools/Configuration/Queues/Create
. Ce menu, tout en haut de la page, n'apparaît que si vous avez activé JavaScript. - Les cas échéant, créer les adresses mails correspondantes dans
/etc/aliases
. N'oubliez pas de lancernewaliases
puis de commettre la configuration dansetckeeper
.
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 prise 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 → Spam → Reported.
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 → Spam → Recent. 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.