Les besoins

Les gens qui font du développement ont leurs outils de recensement des bogues, et des traitements qui sont réservés à ces bogues (corrections, « ce n'est pas un bogue, mais une fonctionnalité », etc.) Ces outils sont souvent spécifiques aux besoins des développeurs, et sont difficilement adaptables à un contexte autre, comme celui du suivi de la production d'un système d'information.

Dans un service de production, les gens ont besoin de savoir :

• Ce qu'il y a à faire ;

• Ce qui est en train d'être fait ;

• Ce qui va arriver sur la plate-forme ;

• Comment tout ça a été, est, ou sera fait.

Cela implique le suivi des modifications de la plate-forme, tant en amont qu'en aval du point de vue projet, mais aussi du point de vue opérationnel : quels sont les actes techniques qui vont avoir lieu, pour quelle raison, avec quels impacts éventuels, etc.

Cela peut se faire de plusieurs manières, comme par exemple avec des réunions de revue des changements prévus, qui vont forcément oublier de prévenir quelqu'un, ou par le biais d'un outil aussi simple que la messagerie, ce qui peut permettre de regrouper les gens par le biais d'un outil connaissant les compétences de chacun, leurs besoins, et qui les arrose sur les sujets en attente de validation technique.

Suivi des demandes

Le besoin principal lorsque l'on fait de la production est donc le suivi de celle-ci. En particulier de ce qui sort des prévisions comme les incidents de production, mais aussi et surtout les demandes d'évolutions, petites et grandes.

Cela amène rapidement (d'autant plus que le nombre de clients augmente, que le parc augmente) la nécessité d'avoir un outil de gestion d'incidents, dont la portée se verra étendue au suivi de toutes les tâches prévues (ou non) sur le maintien en conditions opérationnelles du SI.

Ce que sait faire RT

Le choix de Request Tracker s'est imposé naturellement de par son intégration facile dans un environnement professionnel (ou même personnel) : il suffit de savoir envoyer et recevoir des mails.

En effet, RT s'intègre naturellement à la messagerie, de façon à permettre aux demandeurs d'adresser leurs demandes à une boîte aux lettres unique (il peut aussi y en avoir plusieurs), de la même façon qu'ils spammaient votre service ou votre chef auparavant. La courbe d'apprentissage est donc quasiment nulle : il suffit de leur communiquer la nouvelle adresse mail où envoyer leurs demandes. Ne pas oublier à ce sujet d'ajouter les adresses servies par RT à votre annuaire d'entreprise.

Le gros avantage de RT sur votre boîte aux lettres ou celle de votre chef est qu'il ne part jamais en vacances, qu'il répond automatiquement pour dire qu'il a bien pris en compte la demande, et qu'il ne l'oubliera pas en chemin.

Vos utilisateurs le comprendront rapidement, et pour les aider, il suffit de leur dire : « envoie ta demande à rt@example.com, après on discute ». Péremptoire, certes, mais ça marche. Même dans un environnement légèrement bureaucratique comme une banque. Et imparable car tous savent envoyer des mails (enfin, presque tous, il reste quelques cas isolés).

Ensuite, RT peut aussi permettre aux utilisateurs une gestion de type « self-service » où ils retrouvent dans l'interface graphique la liste de leurs tickets, les échanges avec les acteurs du support, l'historique de leurs tickets passés et fermés, etc.

Pour les power-users, sachez que RT dispose aussi d'une interface en ligne de commande, et qu'il est scriptable en Perl en utilisant l'API disponible avec un simple use RT;.

Autre point important en faveur de RT : il est possible d'ajouter des informations supplémentaires au travers de l'utilisation de champs personnalisés. Cela permet par exemple de formaliser la liste des informations nécessaires à tant la résolution d'un problème qu'aux statistiques sur les types de demandes faites par les utilisateurs.

Enfin, RT est paramétrable à l'envi, tant dans son interface web que dans ses comportements, grâce à ses scrips (qui régissent le comportement de RT, nous les définirons dans le prochain article) et à ses extensions (des modules étendant les capacités de RT).

Ce que RT ne sait pas faire

Nous serons tentés d'écrire : « le café », mais il n'est pas dit qu'avec un peu d'astuce, voire d'espièglerie, un petit scrip ne nous permettrait pas de piloter ça.

Plus sérieusement, dans son contexte, RT est très polyvalent. Il est largement adaptable, ne serait-ce du point de vue de la présentation (modèles, feuilles de style) que des fonctionnalités (extensions et variantes comme RTIR ou Asset Tracker, etc.).

Si deux services très différents disposent chacun d'un RT, et qu'ils sont amenés à s'échanger des messages, il y a fort à parier que certains réglages seront à trouver pour éviter les rebonds entre serveurs, surtout si des envois de messages automatisés sont programmés. Il existe un mécanisme anti-rebond mais ... «mieux vaut prévenir que guérir. »

Cependant, l'exploitation des données de RT pour générer des tableaux de bord à fournir à nos décideurs pressés est clairement un point faible, bien que toute l'infrastructure existe pour la comptabilisation du temps de travail, des durées des intervention, etc. Pour ce point particulier, il existe un module nommé Statistics[5], qui fournit le minimum minimorum. Des volontaires pour l'étendre ? Actuellement, une équipe travaille sur ce projet mais pour l'instant ... motus ! Seuls les développeurs ont accès aux sources. Des mises à jours sont néanmoins publiées régulièrement.

Enfin, il ne faut pas perdre de vue que ce n'est pas le rôle d'un outil que de régler un problème d'organisation. Il ne faut pas se jeter sur RT, si excellent soit-il, en pensant que tout sera possible, voire facile.

Notons par ailleurs que certains centres d'appels de grandes entités ont quelques avantages non négligeables : leur système de téléphonie est couplé à leur outil de gestion des demandes, lui-même relié à un outil d'inventaire, ce qui permet d'identifier l'appelant, et de présenter ensuite directement la fiche technique de son poste.

Il existe cependant des moyens d'interconnecter un PABX basé sur Asterisk et RT, en interrogeant un service web fourni par Asterisk.

Installation de Request Tracker

Pré-requis pour RT

La procédure d'installation de RT est un peu plus compliquée car RT s'appuie sur une grande quantité de modules Perl. RT utilise aussi une base de données, est développé avec MySQL, mais peut aussi s'utiliser avec Oracle ou PostgreSQL. MySQL reste le SGBD préféré.

Sans vouloir reprendre la totalité de la procédure, abordons les sujets qui fâchent.

Tout d'abord, certains modules Perl vont avoir besoin de compiler du C. Il va donc falloir un compilateur, les bibliothèques afférentes, et aussi, pour les quelques modules Apache pré-requis :

• mod_perl, qui doit être normalement fourni dans votre distribution ;

• si vous préférez utiliser FastCGI, il faudra FastCGI, sans mod_perl, et le module adéquat : FCGI.

• le paquetage contenant le source d'Apache (apache-source), si vous utilisez la version d'Apache contenue dans votre distribution Linux préférée, ou la boule de goudron (tarball) d'Apache si vous l'avez compilé vous-même, de même que le paquetage de développement d'Apache (apache-devel) ;

• les paquetages de développement de MySQL, si les paquetages des modules Perl DBD::MySQL ne sont pas installés par la distribution ;

• les paquetages de développement de Perl (perl-devel) ;

• du temps et un œil sur les logs d'Apache (multitail rulez).

Si vous êtes sous Debian, une alternative est de faire un apt-get :

  # apt-get install request-tracker3.4

Et là, vous devriez tout avoir.

Sinon, commencez par éclater l'archive rt.tar.gz. Soit rt-3.4.3.tar.gz à l'heure où ces lignes sont écrites.

./configure

Avant de lancer directement la trilogie ./configure, make, make install, prenez le temps de lancer ./configure --help, cela vous apportera quelques renseignements intéressants.

Sachez aussi qu'il est possible de casser bien des choses en lançant make sur une installation existante. Du calme, donc. D'autant qu'un make upgrade existe pour ce genre de manipulations.

Les options qui nous intéressent sont les suivantes :

  --with-bin-owner=OWNER  Propriétaire des binaires de RT
                          (« root » par défaut)
  --with-libs-owner=OWNER Propriétaire des bibliothèques de RT
                          (« root » par défaut)
  --with-libs-group=GROUP Groupe des binaires de RT
                          (« bin » par défaut)
  --with-db-type=TYPE     Type de base de données à utiliser
                          (« mysql » par défaut)
                          (« mysql », « Pg », « Oracle », « Informix »
                          et « SQLite » sont acceptés)
  --with-db-host=HOSTNAME Nom complet (FQDN) du serveur de bases de données
                          (« localhost » par défaut)
  --with-db-port=PORT     Port TCP d'écoute du serveur de bases de données
  --with-db-rt-host=HOSTNAME
                          Nom complet (FQDN) du serveur RT qui se connecte
                          au serveur de bases de données
                          (« localhost » par défaut)
  --with-db-dba=DBA       Nom de l'administrateur de la base de données
                          (« root » par défaut)
  --with-db-database=DBNAME
                          Nom de la base de données
                          (« rt3 » par défaut)
  --with-db-rt-user=DBUSER
                          Nom de l'utilisateur de la base de données
                          (« rt_user » par défaut)
  --with-db-rt-pass=PASSWORD
                          Mot de passe de l'utilisateur de la base de données
                          (« rt_pass » par défaut)
  --with-web-user=USER    Utilisateur qui exécute le serveur web
                          (« www » par défaut)
  --with-web-group=GROUP  Groupe d'exécution du serveur web
                          (« www » par défaut)
  --with-rt-group=GROUP   Groupe de tous les fichiers
                          (« rt » par défaut)
  --with-my-user-group    Tous les utilisateurs et groupes seront identiques
                          à l'utilisateur/groupe en cours
  --with-apachectl        Emplacement d'« apachectl »
  --with-devel-mode       Active les traces de développement qui peuvent faire
                          mal en production

Utilisant par ailleurs des machines Solaris, et ayant standardisé l'installation de produits tiers dans /opt, nous avons choisi d'installer RT dans le répertoire par défaut, à savoir /opt/rt3. Donc point de préfixe à utiliser. Si vous désirez utiliser une disposition de l'installation sur disque, jetez un coup d'œil au fichier config.layout et choisissez la disposition qui vous sied. Ce fichier, que l'on peut retrouver avec un contenu différent dans les archives sources d'Apache, contient la liste des dispositions disponibles et les valeurs des options de configuration associées. Bien évidemment, vous pouvez aussi le modifier en y ajoutant une disposition particulière, de façon à éviter de devoir retaper toutes les options de type --prefix.

Sur Mandriva (pas de troll, SVP), l'utilisateur du serveur web est apache. RT, tournant dans mod_perl ou FastCGI a besoin d'écrire sur disque, ne serait-ce que ses journaux applicatifs. On spécifie donc cet utilisateur, ainsi que le groupe système rt.

  ./configure --with-web-user=apache --with-web-group=apache    \
              --with-db-database=rt  --with-db-rt-user=rt       \
              --with-rt-group=rt     --with-db-rt-pass='blah2blah'

On spécifie le nom de la base de données ainsi que le moyen d'y accéder parce que RT va créer la base. L'avantage de RT par rapport à d'autres procédures d'installation de logiciels est qu'il fait la différence entre l'administrateur de la base (root par défaut avec MySQL), et l'utilisateur applicatif qui y accède (rt). Il est possible de ne pas spécifier le mot de passe sur la ligne de commande en remplaçant --with-db-rt-pass='blah2blah' par --prompt-for-dba-password.

Une fois que configure a été lancé, il ne faut toujours pas lancer le make install de suite. D'ailleurs, un simple make vous le confirmera :

  $ make
  Please read RT's readme before installing. Not doing so could
  be dangerous.

Installation des modules CPAN pré-requis

On vérifie d'abord la présence des modules avec la commande make testdeps. Avec la version 2 de RT, il fallait analyser la sortie du make testdeps et installer les modules manquants, en acceptant d'installer les dépendances engendrées (ce que votre serviteur continue de faire).

L'installation des modules se fait depuis votre miroir CPAN préféré (le nôtre en l'occurrence). Ça se fait comme décrit dans l'article de Philippe du numéro 50 de Linux Magazine France :

 # perl -MCPAN -eshell 'install DBDx::DataSource'

Dans la version 3, il existe un nouveau mécanisme qui permet d'installer les dépendances. Pour les curieux, le script s'occupant de tester voire d'installer les dépendances, rt-x.y.z/sbin/rt-test-dependencies dans la distribution, s'appuie simplement sur une liste de modules avec leurs versions. Un eval "use $module $version ()" est fait, et la variable $@ ($EVAL_ERROR, cf. perlvar(1)) est testée. L'installation, est ensuite réalisée, si elle a été demandée, par le biais du module CPAN. Les utilisateurs de CPANPLUS utiliseront la solution qui fonctionnait avec RT2, à savoir :

 # make testdeps | perl -lane 'print $F[0] if /MISSING/'

Et pour installer :

 # make testdeps | perl -MCPANPLUS -lane 'CPANPLUS::install $F[0] if /MISSING/'

Quand tous les modules sont installés, ce qui peut prendre un certain temps, surtout si vous avez activé les tests avec CPANPLUS, nous pouvons continuer l'installation de RT.

Fin de l'installation, base de données

Une fois que les dépendances de RT sont installées, on peut (enfin) passer à RT lui-même :

 $ make install

Le make initialize-database installera ensuite le schéma de la base. Ne pas oublier de créer l'utilisateur rt_user dans la base MySQL, en lui assignant un mot de passe. C'est cet utilisateur que RT utilisera ensuite pour accéder à la base de données.

Le mot de passe de l'administrateur du SGBD (root@localhost pour MySQL) vous sera demandé afin d'installer le schéma de la base.

Cette étape terminée avec succès, RT est enfin installé. En cas de problème (dépendances insatisfaites sur les modules Perl, par exemple), il est possible de recommencer au début du make install en lançant la commande :

 # make dropdb

Pour résoudre les problèmes, tout se joue maintenant dans les journaux d'Apache, puisque l'utilisation de RT va faire appel à des modules pas encore chargés par Mason.

Mais pour que Mason puisse entrer en action, encore faut-il que notre serveur web soit configuré pour faire tourner RT.

Configuration du serveur web

Apache pour mod_perl, avec RT

En fonction de votre environnement et de la façon dont vous voulez procéder, il existe plusieurs façons d'arriver au résultat pour ce qui est de l'installation de mod_perl.

mod_perl sur un Apache dédié, avec un Apache reverse-proxy frontal

La version d'Apache fournie par Mandriva, Advanced Extranet Server, était séparée en deux daemons pour les serveurs utilisant mod_perl (dont RT fait partie). Le premier daemon est le daemon classique pour servir les pages statiques, de même que les pages PHP. Le second fonctionne lui en mode proxy, et ce uniquement pour les pages Perl.

La configuration des deux daemons est située dans le répertoire /etc/httpd/conf, dans les fichiers httpd.conf et httpd-perl.conf.

Un mod_perl (version 2) directement dans Apache

L'installation avec mod_perl nécessite sous Mandriva 2006.0 les paquetages suivants :

 apache-base-2.0.54-13mdk
 apache-conf-2.0.54-12mdk
 apache-devel-2.0.54-13mdk
 apache-doc-2.0.54-2mdk
 apache-mod_authz_ldap-2.0.54_0.26-3mdk
 apache-mod_cache-2.0.54-13mdk
 apache-mod_disk_cache-2.0.54-13mdk
 apache-mod_fcgid-2.0.54_1.04-2mdk
 apache-mod_perl-2.0.54_2.0.1-6mdk
 apache-mod_perl-devel-2.0.54_2.0.1-6mdk
 apache-mod_php-2.0.54_5.0.4-4mdk
 apache-mod_proxy-2.0.54-13mdk
 apache-mod_ssl-2.0.54-6mdk
 apache-modules-2.0.54-13mdk
 apache-mpm-prefork-2.0.54-13mdk
 apache-ssl-devel-1.3.33_1.55-1mdk
 perl-Apache-DBI-0.98-1mdk
 perl-Apache-Test-1.25-2mdk

Notez la présence du paquetage emballant le module Apache::DBI. Celui-ci permet l'utilisation d'une connexion DBI persistante vers la base de données lors de l'utilisation de mod_perl version 2.

On met alors en place l'application dans Apache :

/etc/httpd/webapps.d/rt.conf :

 Alias /rt "/opt/rt3/share/html"
 PerlModule Apache::DBI
 PerlRequire /opt/rt3/bin/webmux.pl

 <Location /rt>
     AddDefaultCharset UTF-8
     Options +FollowSymLinks

     SetHandler perl-script
     PerlHandler RT::Mason

     RewriteEngine On
     RedirectMatch permanent (.*)/$ $1/index.html

     Order Deny,Allow
     Allow from all
 </Location>

On peut aussi y ajouter les lignes suivantes afin d'éviter le traitement par le handler Perl des images et de la feuille de style HTML :

 <Location /rt/NoAuth/images>
     SetHandler default-handler
 </Location>
 
 <Files "/rt/NoAuth/webrt.css">
     SetHandler default-handler
 </Files>

FastCGI et Apache

Request Tracker est également utilisable à travers FastCGI, utilisé sous forme de module dans un serveur web Apache.

Installation du module FastCGI

Si vous utilisez un serveur web apache précompilé, vous aurez certainement des paquets séparés pour FastCGI. Recherchez dans la liste des paquets de votre distribution (urpmf ou smart pour Mandriva, apt-cache pour Debian GNU/Linux, etc.). Sinon, vous pourrez récupérer les sources de FastCGI et les compiler. Il vous faudra aussi les paquets de développement d'Apache pour cela.

Vous devrez avoir aussi le module Perl CGI::Fast[6]. Ce module permet de dialoguer avec FastCGI.

Dans Debian, le module qui permet de dialoguer avec FastCGI (qui n'est pas, rappelons-le, le mode de fonctionnement par défaut de RT) est disponible dans un paquet qui s'appelle libcgi-fast-perl.

 # apt-get install libcgi-fast-perl libapache-mod-fastcgi

Comme il n'existe pas de paquet préconfiguré pour le partage de moteur, il faut récupérer les sources de RT depuis la page de téléchargement de Best Practical.

Ensuite, il faut s'assurer que le module FastCGI sera chargé dans Apache. L'un des fichiers de configuration inclus doit contenir quelque chose comme :

 LoadModule fastcgi-module /usr/lib/apache/1.3/mod_fastcgi.so

Ensuite, il faut prendre en compte les scripts FastCGI :

 AddHandler fastcgi-script fcgi

Après l'inclusion du module, une petite vérification pour s'assurer que tout va bien :

 # apachectl configtest && apachectl graceful

Utilisation du module FastCGI

L'utilisation de FastCGI est encore plus simple que celle de mod_perl. Il suffit de créer un pseudo-serveur FastCGI dans la configuration du serveur web en spécifiant :

• l'emplacement d'une configuration de pseudo-serveur FastCGI ;

• un alias de script pour disposer d'un chemin virtuel facilement utilisable ;

• une clause Directory pour autoriser l'exécution de scripts CGI ;

En pratique, le reste de l'installation est identique à celle d'un RT utilisant mod_perl. Seule la configuration d'apache varie.

Pour déclarer un serveur FastCGI avec un alias /rt, c'est aussi simple que ça :

 FastCgiServer   /opt/rt1/bin/mason_handler.fcgi
 ScriptAlias     /rt /opt/rt3/bin/mason_handler.fcgi
 <Directory "/opt/rt3" >
     Options FollowSymLinks ExecCGI
     AllowOverride None
 </Directory>

La première ligne spécifie un emplacement du fichier de description du serveur FastCGI. Le script mason_handler.fcgi est fourni dans une installation standard de RT.

Pour valider la configuration et recharger le serveur web :

 # apachectl configtest && apachectl graceful

Si vous souhaitez disposer d'un alias de script dans des serveurs virtuels, vous pouvez inclure les clauses Directory et ScriptAlias dans un bloc VirtualHost mais vous devrez impérativement sortir la clause FastCgiServer. En cas d'erreur au démarrage, consultez les journaux du serveur web, ils vous le confirmeront.

Quel choix technique faire ?

mod_perl est censé être plus rapide que FastCGI, mais FastCGI offre d'autres avantages comme le fait de pouvoir redémarrer plus rapidement en tuant simplement (mais salement) le serveur FastCGI sans redémarrer Apache ce qui peut prendre du temps. Jusqu'à il y a peu, FastCGI restait le seul moyen d'utiliser RT sur un Apache version 2. En effet, les versions avant mod_perl 2.0.1 ne permettaient pas de faire tourner RT. C'est corrigé depuis, et la rapidité est au rendez-vous. Quant à la vitesse de redémarrage de RT, elle est impressionnante sur un serveur un tant soit peu récent comme un Xeon 3 GHz.

FastCGI garde cependant un avantage sur mod_perl, qui est la possibilité d'offrir un fonctionnement multi-instances (plusieurs RT séparés sur le même serveur), ce que nous verrons bientôt.

Bref le choix se portera d'abord sur la technologie que vous connaissez le mieux, à commencer par le système d'exploitation et les possibilités qu'il offre en standard.

Il est toujours déplaisant de tomber sur une version de Perl un peu ancienne (i.e. avant Perl 5.8.4) et de devoir tout recompiler (Perl, Apache, FastCGI ou mod_perl, ainsi que les dépendances bases de données) pour une version plus récente de Perl. Mieux vaut passer à un système plus moderne et plus récent, quitte à réinstaller ce système. Ce qui vous permettra de documenter le moins de choses possibles, puisque documenter les compilations d'outils interdépendants prendra plus de temps que d'installer un OS récent où tout sera livré en standard ou presque.

Vérifiez que la configuration d'Apache est bonne

Pointez votre navigateur préféré sur l'URL définie pour RT sur votre serveur, et connectez-vous en tant que root, mot de passe password, et modifiez-le immédiatement dans les préférences.

Si vous avez le message « You're are almost there! », c'est que vous n'êtes plus très loin de faire fonctionner RT. Il manque juste quelques coups de tournevis dans la configuration d'Apache pour activer le moteur applicatif.

Si vous ne trouvez pas quel est le problème, n'oubliez pas de regarder les journaux d'Apache (l'error_log en particulier, par exemple /var/log/httpd/error_log) en cas de problème. C'est là que mod_perl écrit ses messages d'erreur. Si vous utilisez Debian, ce sera plutôt dans /var/log/apache/error.log.

Configuration technique de RT

Une fois RT installé, la base initialisée, et Apache configuré, il ne reste que quelques derniers petits détails à régler : les menues options de RT présentes dans le fichier /opt/rt3/etc/RT_Config.pm.

Ce fichier ne doit pas être modifié, mais copié en l'état sur un fichier RT_SiteConfig.pm dans le même répertoire. Ce fichier est en fait un module Perl, la syntaxe du fichier devra donc être vérifiée par :

    perl -c RT_SiteConfig.pm

La plupart des valeurs par défaut conviennent tout à fait, voyons cependant les variables (car il s'agit de code Perl) qu'il est indispensable de modifier.

La première de ces valeurs, $rtname, est le petit nom du système RT que vous êtes en train de mettre en place. Il est conseillé, mais pas obligatoire, de mettre le nom de domaine de votre entité, comme example.com. Ce nom permettra de composer le timbre qui apparaîtra au côté du numéro de ticket dans le sujet des mails entrants et sortants de RT. Ce timbre permettra à RT de rattacher un message entrant au ticket correspondant.

La deuxième valeur, $Organisation, semble apparentée, et servira à composer les liens entre tickets dans la base de données. Le but étant de construire des URI, il faut y mettre un nom de domaine DNS identifiant de façon unique le système RT. Et ce d'autant si vous utilisez plusieurs RT différents.

Le fuseau horaire ($Timezone) est lui aussi important car il permet de savoir où se situe RT, et dans le cas d'organisations ayant des correspondants dans le monde entier, il permet de remettre les messages dans le bon ordre.

Vient ensuite la configuration de la base de données, avec des informations qui ont normalement été communiqués lors de la phase ./configure. Un pour améliorer les performances : laissez $DatabaseHost vide si vous utilisez MySQL et que le serveur MySQL est sur le même serveur que RT. Les autres variables ($DatabaseType, $DatabaseRTHost, $DatabasePort, $DatabaseUser, $DatabasePassword, $DatabaseName) sont simple à saisir.

Viennent ensuite les paramètres de la messagerie électronique. Tout d'abord, comme pour un MTA, il faut définir qui va recevoir les messages d'erreurs. Par défaut, $OwnerEmail est root, mais vous pouvez le changer. Pour les autres paramètres de messagerie entrante, vous pouvez les laisser tels quels.

Pour la messagerie sortante, seules les adresses de correspondance et de commentaire par défaut sont à configurer. Vous les positionnerez aux adresses de la file entrante dans le cas où seule une file sera visible de l'extérieur, ou à celles d'une file « balai » dans le cas où plusieurs files seront accessibles de l'extérieur. Dans le premier cas, cela vous permettra de ne voir que l'adresse de la file entrante quelle que soit la file où se traite un ticket. Dans le second cas, cela vous permettra de recevoir quand même des réponses à un ticket si vous aviez oublié de spécifier les adresses de messagerie d'une file ou d'une autre.

Après les options régissant l'envoi des messages ($Sendmail.*), qu'il est sain de conserver en l'état, nous arrivons à la définition des adresses des correspondants sur les messages sortant, que l'on peut tout aussi conserver en l'état.

Les deux paramètres intéressants sont $NotifyActor et $RecordOutgoingEmail. Le premier est faux par défaut, le second vrai. Le premier détermine si l'initiateur d'une action reçoit la notification de cette action. Cela peut être intéressant au début de la mise en place de RT pour vérifier que tout se passe bien, mais il est toujours troublant de recevoir des mails qu'on sait avoir envoyé. Le second permet de mettre en place un archivage de tous les messages émis par RT.

Nous passerons rapidement sur les options de journalisation ($LogTo*). Sachez simplement que RT utilise Log::Dispatch, lui-même utilisant des niveaux de priorités semblables à ceux utilisés par le syslog BSD. Donc si vous voulez avoir tous les messages, positionnez le niveau à debug sur la sortie choisie.

La suite au prochain épisode

Après avoir vu l'installation (qui peut se révéler sportive) de RT, nous verrons la prochaine fois comment commencer à le configurer, ce qui va nous prendre encore un peu de temps. En attendant, vous pouvez commencer à regarder le fichier RT_SiteConfig.pm. La suite se passera dans l'interface graphique, où la configuration fonctionnelle nous attendra avec son lot de sueur, de sang et de larmes.

Nous verrons enfin comment l'utiliser dans différents contextes de production, ce qui nous montrera que l'outil n'est pas tout, et que l'organisation et les hommes seront parties prenantes dans le succès de l'outil.

Liens et livres

Les auteurs

• Laurent Gautrot - <l.gautrot@free.fr>

  Laurent est administrateur de systèmes GNU/Linux et UNIX au Ministère de l'Équipement. Utilisateur et prosélyte de logiciels libres depuis une dizaine d'années.

• Jérôme Fenal - <jfenal@free.fr>

  Jérôme est utilisateur de GNU/Linux depuis 1994, de divers Unix ou Unix-like depuis un peu plus longtemps.

Merci aux Mongueurs de toute la Francophonie qui ont assuré la relecture de cet article.