Utilisation

Comme tout outil, RT[1] nécessite donc une procédure d'utilisation à laquelle les utilisateurs devront adhérer. Cette procédure relève de l'organisation interne mais a une forte incidence sur le bon usage de l'outil.

Cette partie n'est donc pas tant technique qu'organisationnelle. Mais elle n'en est pas moins importante comme nous allons le voir dans deux exemples de mise en œuvre qui, s'ils se ressemblent, ressemblent surtout aux organisations dans lesquelles RT s'insère.

Faire passer les demandes par RT

La première condition à l'utilisation de RT est... son utilisation (j'adore enfoncer des portes ouvertes). Ce qui signifie que les équipes intervenantes devront a minima créer les tickets au fur et à mesure des coups de fils des demandeurs. Mais le plus simple reste de leur demander (soit directement, soit par le biais de leur hiérarchie), de passer par RT en envoyant un mail à la bonne adresse.

Le bon argument pour vendre RT aux demandeurs potentiels est le fait qu'en passant par le mail, ils sont sûrs que leur demande sera prise en compte à partir du moment où ils réceptionnent l'accusé de réception de la demande.

Une fois que le message est passé, à savoir utiliser RT par le mail, l'autre point est la diffusion des adresses. Une page web est intéressante, mais dans une entité importante, cela suppose que cette même page soit connue de tous. L'avantage de la page web est que l'on pourra aussi y détailler, dans le cas d'un RT multi-entrées, les cas d'utilisation d'une file ou d'une autre.

Mais la solution reste de se faire renseigner dans l'annuaire de la messagerie de l'entité. Ce qui peut poser problème, car entrées d'annuaire et adresses sur la sus-dite messsagerie sont souvent liées. Et l'avantage d'avoir obtenu une délégation de sous-domaine de messagerie peut s'effacer devant la nécessité de s'intégrer à l'annuaire. Pas de solution miracle, mais un éventuel problème d'œuf et de poule auquel songer à la mise en place d'un serveur RT.

De l'intérêt de bien utiliser RT

Rappelons le but recherché : voir ce qu'il y a à faire, éviter le travail en double, historisation et capitalisation, vue de la charge de travail courante, voire statistiques à plus long terme.

Il est donc important que les intervenants s'attachent autant que faire se peut à suivre ce qui suit.

Exemple d'utilisation : un environnement centralisé

Contexte et paramétrage associé

RT peut être paramétré de nombreuses façons : depuis une file unique jusqu'à de nombreuses files réparties par équipes et par typologies d'évènements traités.

Le plus difficile est sans doute de trouver un juste milieu. Compte tenu des contraintes techniques inhérentes, la séparation minimum à faire est technique : une file par comportement (workflow, droit, ...) à mettre en place est le minimum. Mélanger dans une seule file sera sans doute aussi ingérable au final que d'avoir trop de files différentes entre lesquelles on devra jongler. Il faudra donc trouver le bon compromis.

Un exemple de paramétrage peut être :

Flux de travaux (workflow)

Une cinématique possible dans le cadre d'un RT simple est :

• à la réception d'un ticket, l'opérateur en charge de la surveillance de RT attribue le ticket à la personne compétente (cela peut être lui-même) et, le cas échéant, le déplace dans la file qui lui semble adéquate (incident, SGBD, etc.).

• au moment de traiter la demande, la personne compétente ouvre le ticket ;

• toutes les recherches, diagnostics, manipulations faites sont ajoutées en tant que commentaire afin de permettre un suivi de l'intervention ;

• toute la correspondance avec l'utilisateur est faite avec la fonction « répondre » et, quand le responsable du ticket attend une réponse, il passe le ticket en mode bloqué. Le ticket repassera automatiquement en mode ouvert sur réception d'un nouveau mail ;

• Une fois la demande réalisée, le responsable répond au demandeur en lui demandant de valider l'intervention. Il passe à nouveau le ticket en mode bloqué ;

• Si le demandeur valide l'intervention, le responsable résoud le ticket.

• Régulièrement, les tickets bloqués depuis plus d'un certain temps (un mois parait un bon délai) sont recherchés et résolus d'office avec un petit message aux demandeurs : « sans nouvelle de votre part depuis 1 mois, nous fermons votre ticket ».

L'état bloqué peut aussi être utilisé uniquement pour les tickets dont le temps de latence (depuis le dernier échange ou commentaire) s'allonge. De même, il est tout aussi concevable de fermer un ticket par défaut, sachant que le mécanisme de base de RT est de réouvrir le ticket sur réception d'une réponse sur un ticket résolu. Cela s'accompagnera aussi d'un message signifiant la possibilité de réouverture du ticket si la résolution n'est pas satisfaisante.

Exemple d'utilisation : des équipes connexes

Contexte

Nous allons voir une organisation plus simple, s'appliquant par exemple à des équipes techniques pouvant avoir à faire entre elles en plus de clients extérieurs (exploitation, voire utilisateurs).

C'est aussi une organisation qui permet de démarrer rapidement sans trop se poser de question, de façon à appréhender l'outil. Au fur et à mesure de la prise en main de l'outil, et de l'adhésion des personnes l'utilisant, une réorganisation vers un guichet unique pourra ensuite se faire.

Ce qu'on veut donc mettre en place permet de déployer RT pour des équipes de façon relativement autonomes entre elles, au moins au départ. Cette façon de faire permet de déployer RT là où aucun outil n'est mis en œuvre.

Nous avons donc plusieurs équipes, de plusieurs disciplines, travaillant éventuellement ensemble : OS, SGBD, intégration applicative, supervision, etc.

Les tickets sont ouverts par les membres et les responsables des équipes, et uniquement pour des tâches de type projet. Cela suppose une certaine autonomie dans l'utilisation de RT, ainsi que vous avez pu le voir au travers du grand nombre de droits donnés.

Configuration

La configuration de chaque file est relativement indépendante, à son adresse mail, et chaque file a son groupe associé, comme présenté dans l'article précédent. La chose à retenir au départ, c'est une file = un groupe (deux si vous voulez séparer les spammés des personnes exemptes de notifications sur les tickets, un über-chef d'équipe, par exemple).

Flux de travaux (workflow)

Les tickets arrivent donc, et sont pris au fur et à mesure par les membres de l'équipe. Il peut éventuellement y avoir des assignations entre membres, de façon à limiter autant que faire se peut les tickets non assignés.

Dès que le travail commence sur un ticket, celui-ci est ouvert par l'intervenant.

À chaque étape dans la réalisation de la demande, des commentaires sont écrits dans le ticket avec les temps de travail afférants, des correspondances ont lieu entre demandeur et intervenant. Le but est d'avoir le maximum de renseignements sur la demande afin de pouvoir la documenter.

La réponse finale prévient obligatoirement le demandeur de la nature de la résolution de sa demande et de sa clôture. Si besoin était, le comportement par défaut de RT est de réouvrir la demande sur réception d'un courier, ce qui permet de reprendre le ticket.

S'il est besoin de transférer un ticket entre équipes, comme par exemple des allers-retours entre stockage et système, il est nécessaire de mettre en œuvre deux mécanismes : donner le droit aux intervenants de ces files de voir les files associées, afin de pouvoir transférer le ticket, et mettre en place un scrip d'alerte sur le changement de file d'un ticket, afin que les intervenants de la nouvelle file soient prévenus de l'arrivée du ticket.

Un problème par rapport à un guichet unique est l'absence de responsabilité bien définie sur les tickets non directement traitables. Nécessitant des requalifications, il convient aussi de définir le traitement qui leur sera donné : poubellisation ou non. Mais cela reste un problème d'organisation pure.

D'autre part, cela nécessite que les demandeurs connaissent exactement les attributions des différentes équipes, et leur adressent des demandes de travaux précises, correspondant à leurs compétences. Les demandes génériques, adressées à plus d'une file s'exposeront à des pertes d'information. En effet, RT considérera qu'un seul mail à plusieurs adresses constitue une erreur, et le ticket sera créé dans une seule file.

De l'importance de l'encadrement

De par l'absence d'un premier niveau qui relancera les demandes oubliées, il conviendra d'avoir équipe par équipe un responsable de l'avancement des tickets, de façon à ne pas laisser s'accumuler les tickets non encore ouverts, ou ouverts, résolus, mais non notifiés comme tels.

Les évolutions

Il se peut qu'au cours de la vie de votre RT vous vouliez changer la façon dont sont faites certaines choses. Un exemple en est la file pour l'équipe gérant le stockage mutualisé de l'entité, dont les demandes arrivant de l'extérieur ne sont pas pertinentes, ni suffisamment qualifiées. Elles devraient idéalement rester confinées aux seules équipes systèmes et stockage. Mais on ne le sait pas forcément au début...

Après quelques allers-retours sur chaque demande, et plutôt que de demander aux clients de faire leurs demandes d'espace disque directement à l'équipe stockage, on se rend compte qu'il revient plutôt aux différentes équipes systèmes de prendre en compte ces types de demandes, de composer avec les réserves déjà attribuées aux serveurs, et seulement lorsque celles-ci ne suffisent pas, de demander l'attribution de LUN supplémentaires.

Cela passe donc par à la fois un changement organisationnel (qui enregistre la demande, et donc qui est en mesure de facturer), un changement dans le workflow (qui fait la demande au stockage), et seulement après par un changement de configuration de l'outil. Cela impose donc d'interdire la création de ticket dans la file de l'équipe Stockage par quiconque n'appartenant pas aux équipes Unix, Mainframe ou Windows. Quand vous en arriverez à ce point, allez jeter un coup d'œil à RTx::RightsMatrix dont on parle plus bas, ça vous aidera ;-).

Exploitation de RT

Comme toute application, il est nécessaire de mettre en place un cadre d'exploitation de cette application. Ce n'est pas parce que cette application n'est utilisée (apparemment) que par les gens de la production qu'elle ne doit pas rentrer dans le cycle de vie normal d'une application au sein de votre système d'information.

Nous avons déjà vu l'administration applicative, ce qui suppose que vous avez une file Support (la file par défaut General rebaptisée ?) avec des gens derrière. En effet, il y aura toujours à prendre en compte les départs et les arrivées de personnels dans les services intervenant sur les files, voire des créations de files (comme par exemple une file par application du SI), bref, il faut gérer RT.

Mais après cette administration applicative, il ne faudra pas non plus oublier l'administration du socle technique. Ce que nous vous proposons de voir rapidement :

Sauvegarde, restauration, migration de base

La sauvegarde / restauration de RT tient en trois points : RT et sa configuration (RT_SiteConfig.pm), les personnalisations de l'interface (arborescence /opt/rt3/local), et le contenu de la base de données.

En ce qui concerne la base de données, ne l'ayant utilisé qu'avec MySQL, pas de gros souci à se faire. L'utilisation régulière de mysqldump fera très bien l'affaire,

Faites cependant attention si vous avez à passer d'un serveur MySQL 4.0 à 4.1 ou supérieur : certaines colonnes de certaines tables, comme la table Links, ont des longueurs importantes (240 caractères). Or comme MySQL 4.1 gère maintenant les encodages, et que souvent l'encodage par défaut de nos distributions est UTF-8, la tentation est grande de créer la base en UTF-8. Erreur. Non seulement la taille maximale d'un enregistrement en InnoDB (le type de stockage demandé par RT) est limité à 1024 octets (et avec la taille maximale d'un caractère UTF-8 qui peut aller jusque 4 octets, je vous laisse faire le calcul), mais en plus il y a des effets de bord à la sauvegarde / restauration.

Donc si vous devez créer la base de RT à la main, créez-la avec l'encodage ISO-8859-1, voire sans spécifier d'encodage (ce qui revient à l'avoir créé en ISO-8859-1). Un simple create database rt3 suffit donc.

Vous vous exposez à deux problèmes :

• perdre de l'information à la restauration, comme le contenu des pièces jointes qui sera altéré de façon définitive, ou comme la perte des accents ;

• perdre le contenu des pièces jointes dès leur insertion soit par messagerie, soit par l'interface. Là, vous êtes sûr d'avoir vos utilisateurs sur le dos...

Vous êtes prévenus.

Mise à jour de RT

Au sein de la version 3

Passons rapidement sur les migrations entre versions de RT. Entre versions mineures au sein de la version 3 de RT, les migrations sont relativement simples. Il suffit effectivement de mettre à jour les modules Perl de CPAN le nécessitant (comme DBIx::SearchBuilder, publié par Jesse et qui semble avoir RT comme seule dépendance), de mettre à jour RT lui-même (par make upgrade, et en vérifiant les surcharges locales), et enfin de mettre à jour le schéma de la base de données via les fichiers SQL correspondants dans rt-x.y.z/etc/upgrade/version-seuil/.

Le seul inconvénient est que cette mise à jour n'est pas automatisée.

Encore que... Des procédures de mise à jour sont fournies pour vous assister. Consultez les fichiers UPGRADING et README de la distribution sur la marche à suivre.

Pour corriger, si besoin est, la base de données de manière incrémentale en répétant pour chaque version inférieure à la version vous pouvez utiliser quelque chose comme :

 sbin/rt-setup-database \ --action schema \ --datadir
 etc/upgrade/<version>

 /rt/rt-3.4.2/sbin/rt-setup-database \ --action acl \ --datadir
 etc/upgrade/<version>
 
 /rt/rt-3.4.2/sbin/rt-setup-database \ --action insert \ --datadir
 etc/upgrade/<version>

pour chaque version trouvée dans etc/upgrade des sources. Si vous êtes très joueur, vous pouvez même automatiser la mise à jour à l'aide d'une boucle for en shell :

 cd etc/upgrade/ for VERSION in * ; do for ACTION in schema acl insert ;
 do sbin/rt-setup-database \ --action $ACTION \ --datadir $VERSION done
 done

Mais seulement si vous êtes joueur... ;oP

De la version 2 à la version 3

A contrario, si vous avez une version 2 de RT déjà en production, les choses seront un peu plus compliquées. Il vous faudra déjà un nouveau serveur pour RT, avec un perl plus récent que celui de la version 2 (qui devait être un 5.6 ou 5.6.1). Idem pour tous les modules CPAN, pour Apache, mod_perl ou FastCGI, donc changement de serveur quasi obligatoire...

Ensuite, les modifications internes de RT étant trop importantes pour permettre une mise à jour toute simple, il vous faudra télécharger sur le site de Best Practical l'utilitaire rt2-to-rt3[2]. Un utilitaire rt-2.0-to-dumpfile à faire tourner sur l'ancien serveur extrait tous les tickets de la base de RT2, à raison d'un fichier par ticket, plus les informations annexes (utilisateurs, files, etc.).

L'extraction peut prendre un certain temps, une demi-heure sur un (vieux) Pentium III 666 MHz pour environ 6000 tickets.

Une fois l'arborescence de fichiers contenant les tickets transférée sur le nouveau serveur (vive rsync), l'utilitaire dumpfile-to-rt-3.0 permet de les réintégrer dans le nouveau serveur RT3. À noter que cela prend quasiment plus de temps que l'extraction, même si la machine est censée deux fois plus rapide... Patience, donc.

Il vous restera ensuite à réintégrer les modifications de l'interface, modifications qui risquent d'être lourdes tant cette interface web a changé de la version 2 à la version 3 (et oui, les couleurs sont plus jolies en version 3 qu'en version deux :-) Et ça devrait être encore mieux en version 3.6, qui ne devrait pas tarder à passer en version beta au moment où ces lignes sont écrites.

Automatismes et améliorations

Dans le cadre des tâches d'administration, un certain nombre de celles-ci sont des tâches relativement simples qui peuvent (doivent) être automatisées.

Escalade des priorités

Il est facile d'oublier les tickets peu importants au moment où ils arrivent. Sans mécanisme pour les remonter à notre attention ou à celle de l'équipe qui suit une file, ils seront perdus dans les profondeurs d'un classement où n'apparaîtront que des perdants.

Heureusement, il est possible d'automatiser l'élévation des priorités. Pour cela, il vous faudra vous assurer que vous avez bien défini sur vos files les limites basse et haute des priorités des tickets, ainsi que le temps alloué à la résolution d'un ticket.

Plusieurs exemples de script automatisant cette escalade des priorités existent sur le wiki de Best Practical, mais la solution de Tim Bishop de l'université du Kent[3] est la plus sympathique.

Une amélioration que vous aimerez peut-être y faire est non pas de spécifier la liste des files sur lesquelles lancer l'escalade, mais plutôt de spécifier celles sur lesquelles ne pas la lancer. Afin d'éviter d'alourdir l'article, cela vous est laissé en exercice... :-)

Requêtes CLI

Pour ceux qui en ont le besoin (scripts ou liaison très bas débit), il est possible d'utiliser (mais franchement moins facilement) RT au travers de la ligne de commande, grâce à la commande rt fournie et installée dans la distribution. Cette possibilité est citée pour assurer la complétude de l'article, nous vous laisserons expérimenter si cela vous tente. Mais franchement, l'interface graphique est tout de même plus simple à utiliser.

Liens RSS dans les requêtes

RT est capable de fournir des alimentations RSS. Le seul inconvénient est qu'il manque juste dans les pages le petit bout de code qui va bien pour ajouter dans votre Firefox préféré les liens dynamiques au travers du petit bouton orange à largueur sur vos favoris.

Qu'à cela ne tienne, nous allons le rajouter, puisque il s'agit d'une seule ligne de code (HTML) à rajouter au bon endroit.

Mais il faut d'abord trouver le morceau de page où le rajouter. La page en question est Results.html. La ligne qui nous intéresse est la suivante :

  <a href="<%$RT::WebPath%>/Search/Results.rdf<%$ShortQueryString%>"><&|/l&>RSS</&></a>

Rien de bien sorcier, juste la syntaxe de Mason avec ses « % ». Nous allons le réutiliser quasiment tel quel avec la balise HTML <LINK>. Mais avant de la rajouter, n'oubliez pas de copier Results.html dans la partie locale de l'installation de RT :

  cd    /opt/rt3/share/html/Search mkdir /opt/rt3/local/html/Search cp
  Results.html /opt/rt3/local/html/Search cd
  /opt/rt3/local/html/Search vi Results.html

Ajoutez ensuite, où vous voulez dans la page (et c'est tant mieux, parce que ce fichier étant composé avec Mason, nous n'avons pas facilement accès à la balise <HEAD> du HTML) ce qui suit :

  <link rel="alternate" title="RT search"
        href="<%$RT::WebPath%>/Search/Results.rdf<%$ShortQueryString%>"
        type="application/rss+xml">

Redémarrez RT, rechargez la page, et vous verrez apparaître le petit bouton d'inscription à un flux RSS. Cela vous permettra par exemple de voir l'évolution de la charge de travail de vos collaborateurs avec la file des tickets qu'ils ont pris.

RT Multi-instances : Hébergement

Dans le contexte de RT, il est possible d'avoir des groupes d'utilisateurs et des files différentes. Il est aussi possible de personnaliser pratiquement tout, de l'interface aux actions automatisées, en écrivant des « scrips » ou en développant des modules supplémentaires.

Les questions qui peuvent se poser sont :

• Comment personnaliser une ou plusieurs files et pas les autres ?

• Que faire si la base de données grossit de manière incontrôlable et que seules quelques files posent problème ?

• Comment mettre à jour un RT en le testant au préalable en place ?

• Comment personnaliser un RT pour certaines files seulement ?

• Comment déléguer intégralement l'administration d'un RT ?

À certaines de ces questions, une solution possible est d'utiliser les listes de contrôle d'accès (Access Control Lists ou ACL) du système, mais l'administration peut devenir lourde et complexe --comme avec toutes les mises en œuvres d'ACL, cette problématique n'est pas propre à RT. On peut néanmoins utiliser les groupes et les droits globaux pour factoriser les droits dans une certaine mesure.

Cependant, la personnalisation des RT n'est pas possible avec les ACL. En tout cas, en version 3.4.2.

Pour l'administration déléguée, il est possible de créer plusieurs comptes « superutilisateur » qui ont un accès complet, et d'en conserver un pour d'éventuels dépannages.

On peut aussi installer plusieurs RT et démarrer plusieurs serveurs web qui écoutent sur des ports TCP différents, mais cette solution est très coûteuse, et au-delà de 65000 sites, ça va commencer à être difficile. Oui, il faudra déjà une belle machine pour faire fonctionner un truc pareil, objection retenue.

Une solution élégante et efficace consiste à mettre en place un seul moteur RT et des instances indépendantes avec leurs bases de données propres et leurs personnalisations.

On peut même pousser plus en avant ce système pour tester des versions différentes de moteurs avant un passage en production, et le tout de manière transparente aux utilisateurs.

L'utilisation de mod_perl n'est alors plus possible, parce que les espaces de noms sont partagés entre plusieurs instances. On utilise alors FastCGI qui permet une séparation des espaces de noms et le passage de variables d'environnement.

La modification des RT en multi-instances doit s'accompagner d'une politique de suivi de versions et de sécurité. Il est important de se fixer des règles simples dès le départ, et en particulier des règles de nommage (emplacement des fichiers, des bases de données, etc.).

Règles de nommage

Les règles suivantes sont appliquées sur la plate-forme d'hébergement mutualisée pour Request Tracker. Par la suite, vous constaterez l'usage massif des variables (${MA_VARIABLE}).

Installation d'un moteur RT

Vous devez avoir installé mod_fastcgi et l'avoir chargé. Vous devez par conséquent avoir au moins deux lignes ressemblant à celles-ci dans votre configuration :

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

L'installation d'un moteur RT consiste d'abord à récupérer les sources, et les décompresser :

 REP_MOTEURS=/opt/rt3 mkdir ${REP_MOTEURS} tar -C ${REP_MOTEURS} -xvzf
 rt-3.4.2.tar.gz

Il faut ensuite les modifier à l'aide du patch RT-3.4.2-multi-instances.diff.

Ce patch modifie les sources de RT (webmux.pl, RT.pm.in, rt-setup-database.in) pour supporter les variables d'environnement qui permettront de découpler les moteurs RT et les instances en spécifiant l'emplacement des fichiers de configuration. Il ajoute aussi la protection des noms de bases de données MySQL contenant un caractère « - » (tiret).

Le patch initial pour le support des variables d'environnement est disponible en ligne sur le wiki de bestpractical.com[4].

 cd rt-3.4.2 && \ patch -p1 < ../RT-3.4.2-multi-instances.diff
 ./configure --prefix=${REP_MOTEURS}/rt-3.4.2

Il suffit ensuite de lancer make et make install pour installer RT dans le répertoire de notre choix ($REP_MOTEURS/rt-3.4.2).

 make sudo make install

Installation d'un site RT

Cette opération consite à créer une structure vide de répertoires et d'y placer les personnalisations. Dans notre cas, la seule personnalisation que nous utiliserons est la configuration de base et éventuellement un logo.

Nous reviendrons plus tard sur la personnalisation pour ajouter des modules supplémentaires de statistiques.

Les opérations à réaliser sont :

• La création de l'arborescence vide avec les bons propriétaires (apache doit pouvoir écrire dans un répertoire) ;

   REP_INSTANCES=/opt/rt3-sites/ INSTANCE=mon-rt sudo mkdir -p \
   ${REP_INSTANCES}/${INSTANCE}/etc \
   ${REP_INSTANCES}/${INSTANCE}/var/mason_data/{obj,cache} \
   ${REP_INSTANCES}/${INSTANCE}/var/mason_data/obj/standard
   
   sudo chown -R www-data \ ${REP_INSTANCES}/${INSTANCE}/var/mason_data

• L'Édition de la configuration de l'instance dans le fichier ${REP_INSTANCES}/${INSTANCE}/etc/RT_SiteConfig.pm. Le compte rtuser est utilisé pour se connecter au serveur de bases de données MySQL ;

• La création d'une base vierge avec affectation des droits au compte mysql défini dans (nécessite le mot de passe de l'administrateur du serveur MySQL) ;

   cd ${REP_MOTEURS}/rt-3.4.2 && \ sudo sbin/rt-setup-database
   ${REP_INSTANCES}/${INSTANCE} \ --action=init \ --dba root \
   --prompt-for-dba-password

  Remarque : si l'on dispose d'une base de données RT vierge, il est possible d'utiliser les commandes d'administration (mysqladmin, mysqldump, etc.) de MySQL pour dupliquer cette base, en substitution à l'opération précédente. cf. Alternative à rt-setup-database.

  Re-remarque : Vous avez certainement noté l'apparition du premier paramètre sur la ligne de commande ${REP_INSTANCES}/${INSTANCE}. Ce paramètre facultatif est ajouté par le patch RT-3.4.2-multi-instances.diff. Il permet de spécifier l'emplacement de la configuration, et en particulier la racine à partir de laquelle on trouverta le RT_SiteConfig.pm qui contient les paramètres de connexion à la base de données.

• La création d'un lien du handler FastCGI. Comme il n'est pas possible de démarrer plusieurs serveurs FastCGI à partir du même descripteur de serveur FastCGI, il est impératif de le copier ou de le lier (avec un lien symbolique ou direct. Bref, faites comme voulez !) ;

   cd ${REP_MOTEURS}/rt-3.4.2/bin && \ sudo ln -s \ mason_handler.fcgi \
   mason_handler_${INSTANCE}.fcgi

  D'aucuns préfèrent le lien symbolique, plus visible lors d'un listage de répertoire. D'autres préfèrent le lien direct, mais dans ce cas, utilisez si besoin l'option -i de la commande ls.

Configuration de l'application web

Voici la configuration que l'on pourrait trouver dans /etc/apache/conf.d/rt.conf :

 AddHandler fastcgi-script fcgi ErrorLog /var/log/apache/rt-error_log
 CustomLog /var/log/apache/rt-access_log common Include
 /opt/rt3-sites/conf/apache

Chaque instance RT a alors sa configuration dans un fichier séparé dans le répertoire /opt/rt3-sites/conf/apache :

 FastCgiServer /opt/rt3/rt-3.4.2/bin/mason_handler_mon-rt.fcgi
 -initial-env RT_INSTANCE_PATH=/opt/rt3-sites/mon-rt ScriptAlias /mon-rt
 /opt/rt3/rt-3.4.2/bin/mason_handler_mon-rt.fcgi <Directory
 "/opt/rt3-sites/mon-rt/" > Options FollowSymLinks ExecCGI AllowOverride
 None </Directory>

Attention : Il est impératif de sortir la clause FastCgiServer de tout VirtualHost. Pour ceux qui voudraient tout de même l'inclure, sachez que votre serveur web refusera de démarrer ;o).

Si vous souhaitez utiliser malgré tout des serveurs virtuels, votre configuration ressemblera plutôt à :

 NameVirtualHost * FastCgiServer
 /opt/rt3/rt-3.4.2/bin/mason_handler_mon-rt.fcgi -initial-env
 RT_INSTANCE_PATH=/opt/rt3-sites/mon-rt <VirtualHost *> ServerName
 mon-rt.exemple.fr ScriptAlias /mon-rt
 /opt/rt3/rt-3.4.2/bin/mason_handler_mon-rt.fcgi <Directory
 "/opt/rt3-sites/mon-rt/" > Options FollowSymLinks ExecCGI AllowOverride
 None </Directory> </VirtualHost>
 
 FastCgiServer /opt/rt3/rt-3.4.2/bin/mason_handler_ton-rt.fcgi
 -initial-env RT_INSTANCE_PATH=/opt/rt3-sites/ton-rt <VirtualHost *>
 ServerName ton-rt.exemple.fr ScriptAlias /mon-rt
 /opt/rt3/rt-3.4.2/bin/mason_handler_ton-rt.fcgi <Directory
 "/opt/rt3-sites/ton-rt/" > Options FollowSymLinks ExecCGI AllowOverride
 None </Directory> </VirtualHost>

Alternative à rt-setup-database

La méthode standard pour créer une base de données avec un schéma initial est d'utiliser la commande rt-setup-database de la distribution RT.

Si l'on dispose d'une base de données RT fonctionnelle, mais vierge, il est possible d'utiliser les commandes d'administration de MySQL (mysqladmin, mysqldump, etc.) pour dupliquer cette base. Par exemple :

 mysqladmin create rtdb-${INSTANCE} mysqldump rtdb-VIERGE | mysql
 rtdb-${INSTANCE}

Si l'on procède ainsi, il faut explicitement donner au compte rtuser le droit de manipuler la base :

 echo "GRANT SELECT,INSERT,UPDATE,DELETE,INDEX ON `rtdb-${INSTANCE}` TO
 rtuser@localhost ;" | mysql

Pour le reste, c'est par le biais de l'interface web que les réglages sont affinés.

Mise à jour du schéma de la base

Si l'on a une base de données en version 3.0 et que l'on veut basculer dans une version multi-instance d'une version ultérieure, il est alors nécessaire de la mettre à jour à l'aide des scripts fournis dans les sources de RT. Comme le script rt-setup-database est patché pour le passage de l'emplacement du moteur en paramètres, on peut utiliser l'astuce décrite précédemment, en passant simplement le chemin de l'instance en premier paramètre. C'est grâce à ce chemin que l'on trouvera la bonne configuration de la base de données (dans etc/RT_SiteConfig.pm).

 cd etc/upgrade/ for VERSION in * ; do for ACTION in schema acl insert ;
 do sbin/rt-setup-database \ ${REP_INSTANCES}/${INSTANCE} \ --action
 $ACTION \ --datadir $VERSION done done

Mais là, vous ne serez plus joueur. Vous serez directement propulsé « hardcore-gamer ».

Les extensions de RT

RTFM

Que nenni, il ne s'agit pas de la locution anglo-saxonne très fleurie « Read That F*ck*ng Manual », ce n'est que l'acronyme pour « RT FAQ Manager », ou en totalement déroulé : « Request Tracker Frequently asked questions Manager ».

En d'autres termes, il s'agit d'un outil qui se greffe sur RT (à partir de RT 3.0) et lui adjoint des capacités de base de connaissances. Ceci implique que vous devrez avoir une installation fonctionnelle de RT pour pouvoir utiliser RTFM, même si vous n'avez configuré que l'application web, et pas la passerelle vers la messagerie électronique.

RTFM utilise la base de données de RT en ajoutant quelques objets au schéma existant, et en ajoutant quelques pages et quelques nouvelles possibilités qui deviennent accessibles dans les pages d'éditions des tickets (commentaires, réponse, etc.).

Si vous n'avez pas encore mis en place un SPIP (comme présenté dans un article précédent), RTFM peut vous permettre de démarrer une base de connaissance à peu de frais. Et si vous avez déjà mis en place un SPIP, c'est un excellent complément pout indexer des tickets exemplaires quand on manque de temps ou bien ne justifiant pas un article complet.

Installation de RTFM

Il va être difficile de faire plus simple. Vous devrez récupérer l'archive depuis le site de BestPractical, puis la décompresser et l'installer après avoir édité le Makefile pour faire pointer les chemins sur ceux de votre installation de RT (Ha, quand je vous disais que RT est un prérequis !).

Notez que si vous avez utilisé le chemin par défaut, à savoir /opt/rt3, vous n'aurez rien à modifier.

Accrochez-vous :

 cd src wget
 http://download.bestpractical.com/pub/rt/release/RTFM-2.0.4.tar.gz tar
 xvzf RTFM-2.0.4.tar.gz cd RTFM-2.0.4
 # Ci-dessous vous précisez les chemins de RT
 vi Makefile sudo make install

Ayé, c'est installé. Il vous reste juste à redémarrer votre serveur web.

 sudo /etc/init.d/apache restart

Si vous utilisez une Debian. Notez que dans ce cas-là, vous pourriez aussi tirer partie du système APT en utilisant :

 apt-get install rtfm

Si vous utilisez une Mandriva ou une RedHat, alors pour le redémarrage de votre serveur web, ça sera plutôt quelque chose comme :

 sudo service httpd restart

En revanche, pour l'installation, ni les sources officielles, ni les contributions ne fournissent de paquets pour RTFM.

Configuration par l'interface web

Les classes de RTFM sont l'équivalent des files dans RT. Il en faut au moins une pour commencer à écrire des articles. Seul un compte privilégié peut en créer par le Menu « Configuration » / « Classes » / « Nouvelle « classe » / (Saisir un nom de classe et éventuellement une description) / Valider.

Il faut ensuite accorder les droits aux utilisateurs et/ou aux groupes d'écrire des articles dans cette classe, par le menu « Configuration » / « Classes » / (Sélectionner la classe) / « Droits de groupe ». Les droits « AjouterArticle », « ModifierArticle », « VoirClasse » et « AfficherArticle » vous permettront d'éditer des articles dans la classe sélectionnée précédemment.

Comme pour les tickets dans RT, il existe des champs personnalisés dans RTFM. Les droits associés sont gérés de la même façon.

Exemples d'utilisation

En supposant que vous ayez le droit de créer des articles, vous pouvez extraire un article directement à partir de l'historique du ticket à l'aide du lien « Extraire Article » rendu accessible à côté de « Commenter » dans RT. De cette façon, vous pourrez choisir pour chaque transaction du ticket celles que vous voudrez conserver.

Une autre façon de procéder est d'entrer dans le menu « RTFM » et de naviguer jusqu'à « Créer un article». Vous pourrez alors choisir des tickets et intégrer des transactions.

La modification d'un article répond à la logique générale de RT. Il vous suffit de choisir l'article pour pouvoir changer ses attributs (titre, commentaires, tickets liés, etc.).

Si vous avez en outre eu la bonne idée de créer des champs personnalisés textuels, alors vous pourrez enrichir vos articles d'une prose qui ne manquera pas de ravir vos lecteurs.

RTIR

RTIR[5] est l'extension de RT pour la gestion d'une équipe de réponse à des incidents de sécurité (des CERT, en anglais). Ce surensemble logiciel permet donc de gérer les incidents, depuis l'alerte sur un incident, le recensement et le suivi des contre-mesures mises en œuvre jusqu'à la chronologie des investigations.

Nous ne l'avons pas mis en œuvre, le besoin étant relativement restreint et spécifique, mais sachez qu'il existe.

Asset Tracker

Asset Tracker[6] est un projet prometteur qui permet de gérer des biens (assets), comme les serveurs, équipements réseaux, etc. Il permet de gérer une main courante sur chacuns des équipements, ainsi que d'associer ces équipements aux tickets de RT.

Nous ne pourrons en dire plus, sinon que l'installation avec les versions 3.4.3 et 3.4.5 de RT (AT version 1.2.1 et -current) se sont révélées impossibles.

Notons juste que cette association entre les tickets (qui peuvent gérer incidents, changements, problème ou demandes de service) permet d'utiliser RT dans un cadre ITIL, même sans CMDB automatisée.

Les espaces de noms RT::*, RTx::* et RT::Extension::*

L'espace de noms RTx:: est celui qui a été utilisé au départ pour y nommer les petites extensions à RT qui sont diffusées entre autres sur le CPAN. RT::Extension::* est l'espace utilisé pour certaines extensions par Jesse Vincent, l'auteur de RT. Enfin, d'autres extensions ou applications supplémentaires sont publiées dans l'espace de nommage RT::*.

Parmi les principales extensions sont RTx::RightsMatrix de Todd Chapmann (par ailleurs auteur de Asset Tracker) et RTx::Shredder de Ruslan Zakirov, gros contributeur à RT. Jesse Vincent a lui publié plusieurs extensions, dont RT::Extension::MergeUsers, non testé, mais qui doit être pratique en cas de migration de messagerie sur votre infrastructure (Jérôme parle en connaissance de cause). Le répertoire CPAN de Jesse[7] est rempli de choses intéressantes. CPAN Suggest[7] vous aidera à trouver les autres. Mais voyons les deux modules les plus intéressants :

RTx::RightsMatrix

RTx::Shredder

Cité ici pour saluer son existence, ce module permet de contrevenir au premier principe de base de RT : l'histoire est l'histoire, et on y touche pas. Il s'installe comme simple module CPAN où il est publié. N'oubliez pas de faire des sauvegardes avant de jouer avec...

RTx::Statistics

RTx::Statistics est un module Perl qui va s'installer dans l'aborescence de RT comme les précédents. Il a cependant un inconvénient : il n'est pas disponible sur CPAN. Visitez cependant le wiki[8] et vous trouverez l'endroit où le télécharger. Il s'installe manuellement comme tout bon module CPAN (perl Makefile.PL ; make ; make test ; make install). Les tests ne passeront pas si l'utilisateur d'exécution n'a pas les droits de lecture sur la configuration de RT (RT_Config.pm et RT_SiteConfig.pm). Deux dépendances sont à installer : les modules GD et GD::Graph qui eux-même nécessiteront des paquetages de votre distribution, comme gd-devel.

Une fois installé, redémarrez RT, et vous aurez de quoi commencer à analyser la façon dont les tickets arrivent, sont traités, le tout avec de jolis graphiques. De quoi préparer vos réunions hebdomadaires en toute sérennité.

Exemple de graphique (temps moyen de résolution des tickets)

Conclusion

Nous espérons que ce tour d'horizon que nous pensons relativement complet de RT vous aura intéressé. Au vu de l'activité de la part de français sur la liste rt-users nous laisse à penser que cette série aura intéressé au moins une personne :-)

Cela dit, et nous allons encore une fois nous répéter, un outil sans les processus organisationnel n'aidera en rien une entité : cela ne fera qu'alourdir les tâches des différentes personnes, demandeurs ou intervenants. Nous l'avons évoqué, mais ne pouvons aller plus loin, Linux Magazine n'étant pas « Gestion d'équipe Magazine ».

Réfléchissez aussi à savoir si vous devez tout faire passer par RT. Certains d'entre nous connaissent des entités où le suivi du cœur de l'activité se fait par au moins trois outils (plus ou moins interconnectés), libres (bugzilla, Issue Tracker) ou propriétaires, avec RT sur d'autres sujets (comme le helpdesk interne ou le marketing).

Si vous voulez aller plus loin avec RT, n'oubliez pas le livre[9] qui, s'il ne s'étend pas toujours sur les sujets qui fâchent (les approvals, par exemple), sera complété par le wiki[10] que vous pourrez modifier vous-même, pour le plaisir de tous.

Enfin, si RT est largement extensible comme montré sur ce dernier article, sachez que Jesse Vincent travaille sur un nouveau logiciel, Hiveminder[11], et qu'il en a profité pour abandonner Mason, et créer son propre cadriciel web : Jifty[12]. Hiveminder semble avoir les fonctionnalité de RT, mais avec seulement 10% du code. Attendons de voir ce que cela donnera lorsqu'une version beta sortira. Nul doute qu'il faudra revoir notre jugement au sujet de RT.

Liens et livres

Ours

• Nicolas Chuche - <nchuche@barna.be>

  Nicolas Chuche est ingénieur système au ministère de l'Équipement et utilisateur de systèmes GNU/Linux et Unix depuis une dizaine d'années.

• 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 Fenal 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.