fichier

Transcription

fichier

Guide Bugzilla - Version 2.16.4
Matthew P. Barnson
The Bugzilla Team
Romain
Conseil
Adaptation française
Guillaume
Huray
Mickaël
Lagneaux
Guillaume
Tanguy
Yvon
Benoist
Relecture
Guide Bugzilla - Version 2.16.4
by Matthew P. Barnson, and The Bugzilla Team,
Romain
Conseil
Guillaume
Huray
Mickaël
Lagneaux
Guillaume
Tanguy
Yvon
Benoist
Relecture
Published 2003-11-01
Ceci est la documentation de Bugzilla, le système de suivi de bogues de mozilla.org. Bugzilla est un logiciel pour les
entreprises, qui permet à des centaines d’organismes du monde entier de dépister des anomalies par millions.
La maintenance de cette documentation est assurée dans le format DocBook 4.1.2 XML.
La meilleure façon de procéder est de soumettre les modifications sous forme de texte
clair ou de balises XML, joint au bogue archivé dans le système Bugzilla de mozilla.org
(http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation).
La version la plus récente de ce document en version originale est tout le temps disponible sur la page de documentation de Bugzilla (http://www.bugzilla.org/documentation.html).
La
version
française
de
cette
documentation
est
disponible
à
l’adresse
:
http://www.traduc.org/docs/guides/lecture/bugzilla-guide/
(http://www.traduc.org/docs/guides/lecture/bugzillaguide).
Table of Contents
1. A propos de ce guide .................................................................................................................................................1
1.1. Informations sur le Copyright ........................................................................................................................1
1.2. Décharge de responsabilités ...........................................................................................................................1
1.3. Nouvelles Versions .........................................................................................................................................1
1.4. Remerciements ...............................................................................................................................................2
1.5. Conventions du Document .............................................................................................................................3
2. Introduction...............................................................................................................................................................4
2.1. Qu’est-ce que Bugzilla ? ................................................................................................................................4
2.2. Pourquoi utiliser Bugzilla ?............................................................................................................................4
3. Utilisation de Bugzilla...............................................................................................................................................6
3.1. Comment utiliser Bugzilla ?...........................................................................................................................6
3.1.1. Créez un compte Bugzilla..................................................................................................................6
3.1.2. Anatomie d’un bogue ........................................................................................................................6
3.1.3. Recherche de bogues .........................................................................................................................7
3.1.4. Listes de Bogues ................................................................................................................................8
3.1.5. Classement des bogues ......................................................................................................................8
3.2. Trucs et astuces ..............................................................................................................................................8
3.2.1. Création automatique de liens (Autolinkification) ............................................................................9
3.2.2. Quicksearch .......................................................................................................................................9
3.2.3. Commentaires ....................................................................................................................................9
3.2.4. Pièces jointes .....................................................................................................................................9
3.2.5. Classement des bogues ....................................................................................................................10
3.3. Préferences Utilisateurs................................................................................................................................10
3.3.1. Account Settings (Configuration du compte) ..................................................................................10
3.3.2. Email Settings (Configuration des Emails)......................................................................................10
3.3.3. Pied de page.....................................................................................................................................11
3.3.4. Permissions ......................................................................................................................................11
4. Installation ...............................................................................................................................................................12
4.1. Installation étape par étape ...........................................................................................................................12
4.1.1. Introduction......................................................................................................................................12
4.1.2. Liste des logiciels ............................................................................................................................12
4.1.3. MySQL ............................................................................................................................................13
4.1.4. Perl...................................................................................................................................................14
4.1.5. Modules Perl....................................................................................................................................14
4.1.5.1. DBI......................................................................................................................................15
4.1.5.2. Data::Dumper......................................................................................................................15
4.1.5.3. Les modules liés à MySQL .................................................................................................15
4.1.5.4. Modules TimeDate..............................................................................................................15
4.1.5.5. GD (facultatif).....................................................................................................................15
4.1.5.6. Chart::Base (facultatif)........................................................................................................16
4.1.5.7. Template Toolkit .................................................................................................................16
4.1.6. Serveur HTTP ..................................................................................................................................16
4.1.7. Bugzilla............................................................................................................................................17
4.1.8. Configurer la Base de Données MySQL .........................................................................................18
iii
4.1.9. checksetup.pl .............................................................................................................................18
4.1.10. Configurer Bugzilla .......................................................................................................................19
4.2. Configuration supplémentaire facultative.....................................................................................................19
4.2.1. Diagrammes de dépendance ............................................................................................................19
4.2.2. Les graphiques de Bogues ...............................................................................................................20
4.2.3. Le cron plaintif ................................................................................................................................20
4.2.4. Authentification LDAP ....................................................................................................................20
4.2.5. Empêcher les pages de Bugzilla d’exécuter du code Javascript malveillant. ..................................21
4.2.6. Fichiers .htaccess et sécurité.......................................................................................................22
4.2.7. mod_throttle et la sécurité ..........................................................................................................22
4.3. Notes d’installation sur Win32.....................................................................................................................23
4.3.1. Installation sur Win32 : étape par étape...........................................................................................23
4.3.2. Astuces supplémentaires pour Windows .........................................................................................29
4.4. Notes d’installation sous Mac OS X ............................................................................................................30
4.5. Résolution des problèmes.............................................................................................................................30
4.5.1. Bundle::Bugzilla met à niveau Perl à la version 5.6.1.....................................................................30
4.5.2. "DBD::Sponge::db prepare failed" (la préparation de DBD::Sponge::db a échoué).......................30
4.5.3. "cannot chdir(/var/spool/mqueue)" (impossible de faire chdir...)....................................................31
4.5.4. "Your vendor has not defined Fcntl macro O_NOINHERIT" (votre revendeur n’a pas défini ...) ..31
5. Administrer Bugzilla ..............................................................................................................................................33
5.1. Configuration de Bugzilla ............................................................................................................................33
5.2. Administration des utilisateurs.....................................................................................................................34
5.2.1. Créer l’utilisateur par défaut ............................................................................................................35
5.2.2. Gérer les autres utilisateurs..............................................................................................................35
5.2.2.1. Créer de nouveaux utilisateurs ............................................................................................35
5.2.2.2. Modifier les utilisateurs.......................................................................................................35
5.3. Produit, composant, jalon ["Milestone"], et administration de version .......................................................37
5.3.1. Les produits .....................................................................................................................................37
5.3.2. Les composants................................................................................................................................37
5.3.3. Les versions .....................................................................................................................................38
5.3.4. Jalons ...............................................................................................................................................38
5.4. Le vote..........................................................................................................................................................39
5.5. Groupes et sécurité de groupes.....................................................................................................................39
5.6. Sécurité Bugzilla ..........................................................................................................................................40
5.6.1. Ports TCP/IP ....................................................................................................................................41
5.6.2. MySQL ............................................................................................................................................41
5.6.3. Comptes démons..............................................................................................................................42
5.6.4. Contrôles d’accès au serveur Web ...................................................................................................42
5.7. Personnalisation des modèles ["Template Customisation"] .........................................................................43
5.7.1. Ce qu’il faut éditer ...........................................................................................................................44
5.7.2. Comment éditer des modèles...........................................................................................................45
5.7.3. Formats des modèles........................................................................................................................45
5.7.4. Modèles particuliers.........................................................................................................................46
5.8. Mettre à jour avec les nouvelles versions.....................................................................................................47
5.9. Intégrer Bugzilla avec des outils Third-Party...............................................................................................49
5.9.1. Bonsai ..............................................................................................................................................50
5.9.2. CVS..................................................................................................................................................50
iv
5.9.3. Perforce SCM ..................................................................................................................................50
5.9.4. Tinderbox/Tinderbox2 .....................................................................................................................50
A. La foire aux questions de Bugzilla........................................................................................................................51
B. La base de données de Bugzilla.............................................................................................................................63
B.1. Schema de la base de données .....................................................................................................................63
B.2. Introduction à la base de données MySQL de Bugzilla ..............................................................................65
B.2.1. Les rudiments de la base de données de Bugzilla...........................................................................65
B.2.1.1. Les tables de la base de données de Bugzilla .....................................................................66
C. Programmes de correction et utilitaires utiles pour Bugzilla ............................................................................71
C.1. L’excellent mod_rewrite d’Apache ..........................................................................................................71
C.2. Requêtes Bugzilla en ligne de commande ...................................................................................................71
D. Variantes et Concurrents de Bugzilla...................................................................................................................73
D.1. Le Bugzilla de Red Hat ...............................................................................................................................73
D.2. Loki Bugzilla (Fenris) .................................................................................................................................73
D.3. Issuezilla ......................................................................................................................................................73
D.4. Scarab ..........................................................................................................................................................73
D.5. Perforce SCM ..............................................................................................................................................74
D.6. SourceForge.................................................................................................................................................74
E. GNU Free Documentation License .......................................................................................................................75
0. PREAMBLE....................................................................................................................................................75
1. APPLICABILITY AND DEFINITIONS........................................................................................................75
2. VERBATIM COPYING..................................................................................................................................76
3. COPYING IN QUANTITY ............................................................................................................................76
4. MODIFICATIONS..........................................................................................................................................77
5. COMBINING DOCUMENTS ........................................................................................................................78
6. COLLECTIONS OF DOCUMENTS..............................................................................................................78
7. AGGREGATION WITH INDEPENDENT WORKS.....................................................................................78
8. TRANSLATION .............................................................................................................................................79
9. TERMINATION..............................................................................................................................................79
10. FUTURE REVISIONS OF THIS LICENSE ................................................................................................79
How to use this License for your documents ......................................................................................................79
Glossary .......................................................................................................................................................................81
v
List of Figures
4-1. D’autres message d’erreur File::Temp ..................................................................................................................31
4-2. Rustine pour for File::Temp dans Perl 5.6.0..........................................................................................................32
List of Examples
4-1. Installer les modules ppd ActivePerl sur Microsoft Windows ..............................................................................24
4-2. Installer manuellement les modules ppd d’OpenInteract sur Microsoft Windows. ..............................................24
4-3. Suppression de encrypt() dans la version 2.12 et antérieur de Bugzilla, pour Windows NT ................................29
5-1. Mise à niveau avec CVS ........................................................................................................................................47
5-2. Mise à niveau avec l’archive "tar" .........................................................................................................................48
5-3. Mise à niveau avec les programmes de correction ................................................................................................49
vi
Chapter 1. A propos de ce guide
1.1. Informations sur le Copyright
La permission est accordée pour la copie, la distribution et/ou la modification ce document en vertu de la Licence GNU sur la
Documentation libre, en Version 1.1 ou n’importe quelle version plus récente publiée par la Free Software Foundation ; sans
section invariante, sans texte sur le premier de couverture ou sur le dernier de couverture. Une copie de la Licence est inclue
dans l’appendice Appendix E.
—Copyright (c) 2000-2003 Matthew P. Barnson and The Bugzilla Team
Si vous avez des questions concernant ce document, son copyright ou sur la publication de ce document sous une
forme non électronique, veuillez contacter The Bugzilla Team.
1.2. Décharge de responsabilités
Aucune responsabilité quant au contenu de ce document ne peut être acceptée. Vous utilisez les concepts, exemples et
autres contenus du présent document à vos propres risques. Ce document peut contenir des erreurs et des inexactitudes
qui peuvent endommager votre système, causer le départ de votre partenaire, pourrait pousser votre patron à vous
licencier, vos chats à faire pipi sur vos meubles et vos vêtements, et une guerre mondiale thermonucléaire. Agissez
avec prudence.
Chaque copyright concerne exclusivement ceux qui le détiennent, à moins qu’il n’en soit fait mention contraire.
L’utilisation d’un terme dans ce document ne doit pas être considéré comme ayant une incidence sur une marque
déposée ou d’une marque de service.
Nommer des produits particuliers ou des marques ne doit pas être vu comme une recommandation publicitaire, excepté
le terme "GNU/Linux". Nous approuvons sans réserves l’utilisation de GNU/Linux dans chaque situation où il est
approprié. C’est un système d’exploitation extrêmement polyvalent, stable, et robuste qui offre un environnement
idéal de fonctionnement pour Bugzilla.
Nous vous recommandons vivement de faire une sauvegarde de votre système avant l’installation Bugzilla et à intervalles réguliers ensuite. Si il y a une suggestion de ce guide à appliquer, c’est bien celle-là !
Bien que l’équipe de développement Bugzilla ait porté une grande attention pour s’assurer que tous les bogues ou
options facilement exploitables soient documentés ou inscrits dans le code, des trous de sécurité existent sûrement.
Le plus grand soin devra être pris quant à l’installation et à l’utilisation de ce logiciel. Réfléchissez soigneusement
aux implications de l’installation d’autres services de réseau avec Bugzilla. Les membres d’équipe de développement
Bugzilla, Netscape Communications, America Online inc., et tous développeurs ou sponsors affiliés n’assument aucune responsabilité quant à l’usage que vous faites de ce produit. Vous avez le code source de ce produit, et êtes
responsable de le contrôler vous-même pour assurer vos besoins en terme de sécurité.
1.3. Nouvelles Versions
Ceci est la version 2.16.4 du Guide Bugzilla. Il est ainsi nommé pour correspondre à la version de Bugzilla avec
laquelle il est distribué. Si vous lisez ceci depuis une autre source que celles mentionnées plus bas, veuillez vérifiez
1
un de ces miroirs pour être certain que vous lisez une version à jour de ce guide.
On peut toujours trouver la dernière version de ce guide à l’adresse bugzilla.org (http://www.bugzilla.org); y compris
la documentation pour les versions antérieures ainsi que la version actuellement en développement.
On peut également trouver la documentation de la dernière version stable de Bugzilla sur The Linux Documentation
Project (http://www.tldp.org).
On peut toujours aller voir la dernière version de ce document via le serveur CVS. Suivez les instructions
disponibles sur la page CVS de Mozilla (http://www.mozilla.org/cvs.html),et allez dans l’arborescence
mozilla/webtools/bugzilla/docs/
Le Guide de Bugzilla est actuellement disponible seulement en Anglais et en Français. Si vous voulez vous
porter volontaire pour traduire ce guide dans d’autres langues, veuillez entrer en contact avec Dave Miller
(mailto:[email protected]).
1.4. Remerciements
Les personnes énumérées ci-dessous ont apporté d’énormes contributions à la création de ce guide, par leurs écrits,
pour s’être donné pleinement, de nombreuses séances d’aide par E-mails ou IRC, et l’excellente contribution globale
à la communauté de Bugzilla :
Matthew P. Barnson <[email protected]>
pour la tâche Herculéenne qui a consisté à rassembler le guide Bugzilla et le produire en version 2.14.
Terry Weissman <[email protected]>
pour avoir été le premier à écrire Bugzilla et créer le README sur lequel la documentation d’installation d’UNIX
est basée en grande partie.
Tara Hernandez <[email protected]>
Pour avoir maintenu le développement de Bugzilla à un rythme soutenu après le départ de Terry et pour gérer un
site d’enfouissement de déchets.
Dave Lawrence <[email protected]>
pour fournir l’aperçu des différences principales entre le Bugzilla personnalisé de Red Hat, et pour être en grande
partie responsable de la partie Section D.1.
Dawn Endico <[email protected]>
pour être un extraordinaire mordu d’informatique et avoir supporté les incessantes questions et pinaillages de
Matthew sur irc.mozilla.org dans la salle # mozwebtools
Jacob Steenhagen <[email protected]>
pour avoir pris la relève pendant la période de développement de la version 2.17 et pour avoir transposé les
corrections de documentation à cette version 2.16
Enfin, tous les membres du newsgroup news://news.mozilla.org/netscape/public/mozilla/webtools. Sans vos discussions, perspicacité, suggestions, et correctifs, ceci n’aurait jamais pu exister.
2
Les remerciements vont également aux personnes suivantes pour leurs contributions significatives à cette documentation (dans l’ordre alphabétique) : Andrew Pearson, Ben FrantzDale, Eric Hanson, Gervase Markham, Joe Robins,
Kevin Brannen, Ron Teitelbaum, Spencer Smith, Zach Liption .
1.5. Conventions du Document
Ce document utilise les conventions suivantes :
Descriptions
Représentation
Soyez prudents
Caution
Ne courez pas avec des ciseaux!
Conseil
Notes
Avertissements
Tip: Voulez vous un bonbon à la menthe ?
Note: Cher Jean...
Warning
Lisez ceci sinon le chat va le prendre.
Nom de fichier
nom du fichier
Noms des répertoires
Répertoire
Commandes à taper
commande
Noms d’Applications
application
Invite de commande utilisateurs sous l’interpréteur de
bash$
commandes bash
Invite de commande super utilisateur sous l’interpréteur bash#
de commandes bash
Invite de commande utilisateurs sous l’interpréteur de
tcsh$
commandes tcsh
Variables d’environnement
VARIABLE
Mot souligné
mot
Terme trouvé dans le glossaire
Bugzilla
Exemple de code
<para> Début et fin de paragraphe </para>
3
Chapter 2. Introduction
2.1. Qu’est-ce que Bugzilla ?
Bugzilla est un système de suivi de bogues ou d’anomalies. Les systèmes de suivi de bogues permettent à des
développeurs individuels ou en groupes de garder la trace des problèmes marquants qu’ils rencontrent avec leurs
produits. Bugzilla a été au départ écrit par Terry Weissman dans un langage de programmation appelé TCL, pour
remplacer une base de données de dépistage de bogues rudimentaire à usage interne chez Netscape Communications.
Terry a ensuite fait migrer Bugzilla de TCL en Perl, et il est toujours en Perl à ce jour. La plupart des vendeurs de logiciels standards de suivi ont alors facturé d’énormes honoraires de Licence, et Bugzilla est rapidement devenu un favori
chez les tenants des logiciels libres Open-source (avec sa genèse dans le projet de navigateur open-source, Mozilla).
C’est maintenant de-facto le système de suivi de bogues standard par rapport auquel tous les autres se mesurent.
Bugzilla présente beaucoup de caractéristiques avancées. Celles-ci incluent :
•
Un outil de recherche puissant
•
La notification par E-mail configurable par l’utilisateur des corrections des bogues
•
Un historique complet des modifications
•
Des graphiques et suivis de dépendance entre les bogues
•
Une excellente gestion des fichiers joints
•
Un schéma intégré de sécurité, granulaire, basé sur le produit
•
Un système entièrement sécurisé, et qui tourne sous le mode de déboguage de Perl
•
Un RDBMS robuste et stable
•
Des interfaces Web, XML, d’email et de console
•
Une interface utilisateur complètement paramétrable et/ou localisable
•
Possibilité de configuration étendue
•
Moyen de mise à niveau homogène entre les versions
2.2. Pourquoi utiliser Bugzilla ?
Pendant de nombreuses d’années, le logiciel de suivi de défauts est resté principalement le domaine de grandes
maisons de développement de logiciel. Même à cette époque, la plupart des revendeurs ne se préoccupaient jamais
des logiciels de suivi de bogues, et par contre elles comptaient simplement sur les listes de diffusion et l’email pour
suivre l’état des défauts. Ce procédé est sujet à des erreurs et par conséquent, le risque est que les bogues jugés moins
importants par les développeurs soient laissés de côté ou ignorés.
De nos jours, beaucoup de sociétés trouvent que les systèmes de suivi de bogues intégrés réduisent le temps
d’immobilisation, augmentent la productivité et la satisfaction du client par rapport à leurs produits. En même
temps qu’une information complète, un système ouvert de suivi de bogues permet à des constructeurs de rester en
contact avec leurs clients et revendeurs, de communiquer efficacement sur les problèmes d’un bout à l’autre de la
4
Chapter 2. Introduction
chaîne de gestion des données. De nombreuses sociétés ont également découvert que les aides au dépistage des
défauts réduisait les coûts en fournissant un service de support technique qui engage sa responsabilité, des bases
de connaissance de support par téléphone, et un système universel et facile à comprendre pour rendre compte de
problèmes peu courants dans les systèmes et logiciels.
Mais, vous, pourquoi devriez-vous utiliser Bugzilla ?
Bugzilla s’adapte très bien à diverses situations. Les utilisations connues incluent actuellement les files d’attente
pour l’aide technique, la gestion du déploiement de systèmes d’administration, le suivi des problèmes de développement et de conception de microprocesseurs (aussi bien avant qu’après la fabrication), et le suivi de bogues logiciels et matériels pour des sommités tels que Redhat, la NASA, Linux-Mandrake, et VA Systems. Combiné avec des
systèmes tels que CVS (http://www.cvshome.org), Bonsai (http://www.mozilla.org/bonsai.html), ou Perforce SCM
(http://www.perforce.com), Bugzilla fournit une solution puissante et facile à utiliser aux problèmes de reproduction
des bogues et de gestion des configurations.
Bugzilla peut considérablement augmenter la productivité et la responsabilité de chaque employé, en fournissant un
déroulement des opérations documentées et un retour positif en cas de bonne prestation. Est ce que vous ne vous
réveillez pas souvent le matin en vous rappelant que vous êtes censés faire quelque chose dans la journée, mais vous
ne vous rappelez pas quoi exactement ? Mettez le dans Bugzilla, et vous en avez un enregistrement à partir duquel vous
pouvez extrapoler des étapes importantes, prédire des versions du produit pour l’intégration, et suivre l’enchaînement
de la discussion qui a menée aux décisions critiques.
En fin de compte, Bugzilla met entre vos mains la possibilité d’améliorer votre valeur par rapport à votre employeur ou
votre activité tout en fournissant un cadre dédié à votre soucis naturel du détail et fournissant un stock de connaissances
que vous pouvez mettre en valeur.
5
Chapter 3. Utilisation de Bugzilla
3.1. Comment utiliser Bugzilla ?
Cette section contient des informations pour les utilisateurs de Bugzilla. Il y a une installation d’essai de Bugzilla,
appelée Landfill (http://landfill.bugzilla.org/), avec laquel vous êtes invités à jouer (si elle est en disponible). Cependant, toutes les fonctionnalités de Bugzilla n’y sont pas nécessairement accessibles, souvent des versions de pointe de
Bugzilla sont exécutées pour les tester, par conséquent le fonctionnement peut parfois être légèrement différent de ce
qui est mentionné ici.
3.1.1. Créez un compte Bugzilla
Si vous voulez utiliser Bugzilla, vous devez d’abord créer un compte. Renseignez vous auprès de l’administrateur responsable de votre installation de Bugzilla sur l’URL que vous devez utiliser pour y accéder. Si vous utilisez la version
de test de Bugzilla, utilisez cette URL : http://landfill.bugzilla.org/bugzilla-tip/ (http://landfill.bugzilla.org/bugzillatip/)
1. Cliquez sur le lien “Open a new Bugzilla account”, entrez votre adresse email et éventuellement votre nom dans
les espaces prévus à cet effet, puis cliquez sur “Create Account” (Créer un compte).
2. Après quelques instants, vous devriez recevoir un email à l’adresse que vous avez fournie précédemment, qui
contient votre login de connexion (généralement le même que l’adresse email), et un mot de passe que vous
pouvez utiliser pour accéder à votre compte. Ce mot de passe est généré aléatoirement, et peut être remplacé par
un autre plus facile à mémoriser.
3. Cliquez sur le lien “Log In”(s’authentifier) dans la zone jaune en bas de la page dans votre navigateur, entrez
votre adresse email et votre mot de passe dans les espaces prévus, et cliquez sur "Login" (authentification).
“Login”(authentification).
Vous êtes maintenant connecté. Bugzilla utilise les cookies pour l’authentification. Donc, à moins que votre adresse
IP ne change, vous n’aurez pas besoin de vous authentifier à nouveau.
3.1.2. Anatomie d’un bogue
Le noyau de Bugzilla est l’écran qui affiche un bogue particulier. C’est l’endroit idéal pour expliquer quelques concepts de Bugzilla. L’anomalie n◦ 1 de Landfill (http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=1) est un bon
exemple. Notez que les étiquettes de la plupart des champs sont des hyperliens ; cliquer dessus affichera une aide
contextuelle sur ce champ particulier. Les zones marquées d’un * peuvent ne pas être présentes sur chaque installation
de Bugzilla.
1. Product and Component(Produit et composant): Les bogues sont divisés en produits et composants, un produit
étant composé d’un ou plusieurs composants. Par exemple, le produit "Bugzilla" de bugzilla.mozilla.org est composé de plusieurs composants :
Administration: Administration of a Bugzilla installation.
Bugzilla-General: Tout ce qui ne va pas dans les autres composants, ou relatif à plusieurs composants.
6
Creating/Changing Bugs: Créer, modifier, et visualiser les bogues.
Documentation: Documentation de Bugzilla, y compris le guide Bugzilla.
Email: Tout ce qui est en rapport avec un email envoyé par Bugzilla.
Installation: Procédé d’installation de Bugzilla.
Query/Buglist: Fonctions de recherche de bogues et visualisation de la liste des bogues.
Reporting/Charting: Obtenir des comptes-rendus de Bugzilla.
User Accounts: Administration du compte utilisateur selon le point de vue de l’utilisateur. Requêtes sauvegardées, création de com
User Interface: Problèmes d’ordre généraux en relation avec l’interface utilisateur (pas fonctionnalité) comprenant les problèmes
2. Status and Resolution: Ceci définit avec précision quel est l’état du bogue - depuis l’état où il n’est même pas être
confirmé comme bogue, jusqu’à celui où il a été corrigé et où la correction est confirmée par l’Assurance Qualité.
Les différents statuts possibles pour la rubrique Status and Resolution concernant votre installation devraient être
documentées dans l’aide contextuelle relative à ces éléments.
3. Assigned To: Personne étant chargée de corriger le bogue.
4. *URL: Une éventuelle URL associée au bogue.
5. Summary: Problème résumé en une phrase.
6. *Status Whiteboard: (aussi appelé Whiteboard) Zone de texte libre pour ajouter de courtes notes ou des étiquettes
à un bogue.
7. *Keywords: L’administrateur peut définir des mots-clés que vous pouvez employer pour étiqueter et classer les
bogues par catégorie - par exemple The Mozilla Project a des mots-clés comme plantage et régression.
8. Platform and OS: Ceci indiquent l’environnement de travail dans lequel le bogue a été détecté.
9. Version: La zone "version" est habituellement utilisée pour les versions d’un produit qui sont parus et sert à
indiquer quelles versions d’un composant est touchée par le problème dont le compte rendu de bogue fait état.
10. Priority:Le responsable de bogues emploie ce champ pour fixer la priorité de ses bogues. Il faut éviter de le
changer sur les bogues des autres.
11. Severity: Ceci indique la gravité du problème - depuis bloquant ("application unusable" : application inutilisable)
à insignifiant ("minor cosmetic issue" : problème esthétique mineur). Vous pouvez également employer cette zone
pour indiquer si un bogue est une demande d’amélioration.
12. *Target:(aussi intitulé Target Milestone) Version future, dans laquelle le bogue devra être corrigé. Par exemple,
les jalons du projet de Bugzilla pour de futures versions de Bugzilla sont 2.18, 2.20, 3.0, etc... Les jalons ne sont
pas limitées aux nombres, par conséquent vous pouvez utiliser n’importes quelles chaînes de caractères textuelles,
telles que des dates.
13. Reporter: Personne qui a classé l’anomalie.
14. CC list: Liste de personnes à prévenir par email quand le bogue change.
15. Attachments: Vous pouvez joindre des fichiers (par exemple des cas qui constituent des précédents ou des correctifs) aux bogues. S’il y a des pièces jointes, elles sont listées dans cette section.
16. *Dependencies: Si ce bogue ne peut pas être corrigé à moins que d’autres bogues soient eux-mêmes corrigés
(dépend de), ou si ce bogue annule la correction d’autres bogues déjà corrigés (bloque), leurs numéros sont
enregistrés ici.
17. *Votes: Si ce bogue a reçu des votes.
18. Additional Comments: Vous pouvez ajouter votre grain de sel à la discussion sur le bogue ici, si vous avez quelque
chose d’intéressant à dire.
7
3.1.3. Recherche de bogues
La page de recherche de Bugzilla est l’interface où vous pouvez trouver n’importe quel compte-rendu de
bogue, commentaire, ou correctif actuellement dans le système Bugzilla. Vous pouvez jouer avec en allant ici:
landfill.bugzilla.org/bugzilla-tip/query.cgi (http://landfill.bugzilla.org/bugzilla-tip/query.cgi).
La page de recherche propose des commandes pour choisir différentes valeurs possibles pour tous les champs d’un
bogue, comme décrit ci-dessus. Une fois que vous avez défini une recherche, vous pouvez ou l’exécuter, ou
l’enregistrer en tant que requête mémorisée[«Remembered Query»], qui peut éventuellement apparaître dans vos
pieds de page.
Les requêtes hautement avancées sont exécutées en utilisant des diagrammes booléens, qui ont leur propre aide
contextuelle (http://landfill.bugzilla.org/bugzilla-tip/booleanchart.html) .
3.1.4. Listes de Bogues
Si vous lancez une recherche, une liste de bogues correspondants vous sera retournée. La recherche par défaut doit
renvoyer toute les anomalies répertoriées sur le système - n’essayez pas d’exécuter cette recherche sur une installation
de Bugzilla qui a beaucoup de bogues !
Le format de la liste est configurable. Par exemple, il peut être trié en cliquant sur les en-têtes de colonne. D’autres
fonctionnalités utile sont accessibles en utilisant les liens en bas de la liste :
Long Format: ceci vous donne une grande page avec un résumé qui ne peut pas être édité des champs de chaque bogue.
Change Columns: Pour modifier les attributs des bogues qui apparaissent dans la liste.
Change several bugs at once: Si votre compte possède l’habilitation suffisante, vous pouvez appliquer la même modification à tous les
Send mail to bug owners: Envoie un email aux propriétaires de tous les bogues sur la liste.
Edit this query: Si vous n’avez pas obtenu exactement les résultats que vous recherchiez, vous pouvez retourner à la page de requête v
3.1.5. Classement des bogues
Des années d’expérience sur l’écriture de bogues ont été condensées pour votre plaisir dans les Bug Writing Guidelines (directives d’écriture des bogues) (http://landfill.bugzilla.org/bugzilla-tip/bugwritinghelp.html). Si certains de
ces conseils sont spécifiques à Mozilla, les principes de base de signalement de bogues reproductibles spécifiques,
d’identification du produit que vous utilisez, sa version, le composant dont provient l’erreur, la plateforme matérielle,
et le système d’exploitation que vous utilisiez au moment du plantage, sont d’une aide précieuse pour vous assurer
des corrections responsables et précises du bug qui vous a gêné.
La procédure pour classer un bogue testé est la suivante :
1. Allez sur le site de Landfill (http://landfill.bugzilla.org/bugzilla-tip/) dans votre navigateur et cliquez sur Enter a
new bug report (http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi)(écrire un nouveau rapport de bogue).
2. Choisissez un produit - n’importe lequel fera l’affaire.
3. Complétez les champs. Bugzilla devrait avoir assez bien deviné en se basant sur votre navigateur, les bonnes listes
déroulantes "Platform" (plateforme) et "OS" (Système d’exploitation). Si elles sont erronées, changez-les.
4. Choisissez "Commit" (Valider) et envoyez votre rapport de bogue.
8
3.2. Trucs et astuces
Cette section détaille quelques-unes des astuces et pratiques d’usage de Bugzilla qui ont été développées.
3.2.1. Création automatique de liens (Autolinkification)
Les commentaires de Bugzilla sont sous forme de texte ordinaire - donc, le fait d’introduire du code HTML aura pour
conséquence l’affichage des balises HTML ; en effet, elles ne sont pas interprétées par un navigateur. Cependant,
Bugzilla fera automatiquement la transformation de certains types de textes en liens dans les commentaires. Par
exemple, le texte http://www.bugzilla.org sera transformé en http://www.bugzilla.org. Les autres chaînes de caractères
qui sont transformées en liens de façon évidente sont les suivants :
bogue 12345
bogue 23456, commentaire 53
pièce jointe 4321
mailto:[email protected]
[email protected]
ftp://ftp.mozilla.org
La plupart d’autres sortes d’URL
Un corollaire à ceci est que si vous tapez un numéro de bogue dans un commentaire, vous devez mettre le mot "bug"
devant, de façon à ce que le lien soit fait de façon automatique pour que ce soit pratique pour tous.
3.2.2. Quicksearch
Quicksearch est un outil de requête muni d’un champ de recherche unique qui emploie des métacaractères pour
indiquer ce qui doit être recherché. Par exemple, si vous tapez "foo|bar" dans Quicksearch, Quicksearch cherchera
le mot "foo" ou bien le mot "bar" dans le résumé et le Status WhiteBoard (tableau blanc de statut) d’un bogue ; ajouter
":BazProduct" effectuera la requête seulement dans ce produit.
Vous trouverez le cadre de recherche Quicksearch sur la page d’accueil de Bugzilla, avec un lien d’aide (../../quicksearch.html) qui détaille comment l’utiliser.
3.2.3. Commentaires
Si vous modifiez les champs d’un bogue, n’ajoutez un commentaire que si vous avez quelque chose de pertinent
à dire, ou si Bugzilla l’exige. Autrement, votre modification pourrait entraîner l’envoi de mails inutiles à certaines
personnes. Pour prendre un exemple : un utilisateur peut configurer son compte de façon à filtrer les messages par
lesquels quelqu’un s’ajoute simplement à la zone de cc d’un bogue (ce qui se produit souvent). Si vous vous ajoutez
dans la zone « cc », et ajoutez un commentaire disant Adding self to CC "je m’ajoute dans la rubrique CC", la personne
obtiendra un E-mail sans intérêt qu’elle aurait autrement évité.
N’utilisez pas les signatures dans les commentaires. Signer avec votre nom ("Bill") est acceptable, en particulier si
vous avez l’habitude de le faire, mais des créations artistiques surchargées en ASCII de plusieurs lignes ne le sont pas.
9
3.2.4. Pièces jointes
Utilisez les pièces jointes, plutôt que les commentaires, pour de grandes quantités de données ASCII, tels que les
fichiers de traçage, ou les fichiers de log de déboggage. C’est pour éviter d’infliger des bogues surchargés à ceux qui
veulent les lire, et pour qu’ils ne reçoivent pas des courriers inutiles et de taille importante.
Allégez les copies d’écrans. Il n’est pas nécessaire de montrer l’écran entier pour signaler un problème qui peut être
illustré avec seulement quelques pixels.
Ne joignez pas des cas qui constituent des précédents (par exemple un fichier HTML, un fichier CSS et une image)
comme fichier ZIP. Au lieu de cela, envoyez-les dans l’ordre inverse et éditez le fichier référent de sorte qu’ils pointe
vers les fichiers joints. De cette façon, le cas qui constitue un précédent fonctionne immédiatement hors du bogue.
3.2.5. Classement des bogues
Essayez de vous assurer que tout ce qui est dit dans le résumé est également dit dans le premier commentaire. Les
résumés sont souvent mis à jour et ceci ganrantira que votre information initiale soit facilement accessible.
Vous n’avez pas besoin de mettre "any" (n’importe lequel) ou des chaînes de caractères de ce type dans le domaine de
l’URL. S’il n’y a aucune URL spécifique au bogue, laissez cette zone vide.
Si vous avez l’impression qu’un bogue que vous avez classé a été marqué par erreur comme DUPLICATE (bogue
dupliqué), veuillez poser la question dans votre bogue, et non pas dans l’autre bogue dans lequel il a atterri. N’hésitez
pas à mettre la personne qui a dupliqué le bogue dans la liste des contacts CC si ce n’est pas déjà le cas.
3.3. Préferences Utilisateurs
Une fois que vous avez ouvert une session, vous pouvez personnaliser divers aspects de Bugzilla par l’intermédiaire
du lien "Edit prefs" (Editez vos préférences) en pied de page. Les préférences sont divisées en quatre onglets :
3.3.1. Account Settings (Configuration du compte)
Dans cette partie, vous pouvez changer les informations de base sur votre compte, y compris votre mot de passe,
adresse email et votre vrai nom. Pour des raisons de sécurité, avant de changer quoi que ce soit sur cette page, vous
devez taper votre mot de passe actuel dans la zone “Password” située en haut de la page. Si vous essayez de changer
votre adresse email, un email de confirmation sera envoyé aussi bien à votre ancienne qu’à votre nouvelle adresse, avec
un lien à utiliser pour confirmer le changement. Ceci a pour but d’essayer d’empêcher le détournement de compte.
3.3.2. Email Settings (Configuration des Emails)
Dans cette partie vous pouvez réduire ou augmenter la quantité d’emails qui vous est envoyée par Bugzilla, vous
pouvez choisir en fonction de chaque bogue et des changements qui lui ont été apportés. (Notez que vous pouvez
également utiliser le filtrage côté client en utilisant l’en-tête de X-Bugzilla-Reason que Bugzilla ajoute à tout mail
concernant un bogue.)
10
En écrivant les emails des utilisateurs, séparés par des virgules, dans la boîte de dialogue "Users to watch" (utilisateurs
à observer), vous pouvez recevoir une copie de tout mail concernant un bogue d’un autre utilisateur (si les configurations de sécurité le permettent). Cette fonctionnalité puissante permet des transitions en douceur lorsque que les
développeurs changent de projets ou lorsque les utilisateurs partent en vacances.
Note: La capacité d’observer d’autres utilisateurs peut ne pas être disponible dans toutes les installations de
Bugzilla. Si vous ne pouvez pas accéder à cette fonction, contactez votre administrateur.
3.3.3. Pied de page
Sur la page de recherche, vous pouvez stocker des requêtes dans Bugzilla, donc si vous exécutez régulièrement une
requête particulière vous pourrez y accéder rapidement depuis un menu déroulant. Une fois que vous avez stocké une
requête, c’est ici que vous pouvez demander qu’elle soit également affichée en pied de page.
3.3.4. Permissions
C’est une page purement informative qui décrit vos permissions en cours sur cette installation de Bugzilla - à quels
groupes de produit vous appartenez, et si vous pouvez éditer les bogues ou assurer diverses fonctions d’administration.
11
Chapter 4. Installation
4.1. Installation étape par étape
4.1.1. Introduction
Bugzilla a déjà été installé avec succès sous Solaris, Linux et Win32. Win32 n’est pas encore officiellement supporté,
mais beaucoup d’utilisateurs ont réussi à le faire fonctionner correctement sous cet environnement. Veuillez lire Notes
d’installation sur Win32 pour une aide plus poussée sur le fonctionnement de Bugzilla sous Microsoft Windows.
4.1.2. Liste des logiciels
Note: Si vous utilisez la version la plus récente de Perl et MySQL sur votre système (les exécutables ainsi que les
bibliothèques de développement), vous pouvez sauter ces étapes suivantes qui décrivent l’installation manuelle
des modules Perl en utilisant Bundle::Bugzilla. Pour celà, veuillez lire Utiliser Bundle::Bugzilla au lieu d’installer
manuellement les modules Perl.
Les logiciels nécessaires au bon fonctionnement de Bugzilla sont les suivants (avec l’URL pour les télécharger) :
1. Le serveur de base de données MySQL (http://www.mysql.com/) (3.22.5 ou plus)
2. Perl (http://www.perl.org) (5.005 ou plus; 5.6.1 est recommandé si vous souhaitez utiliser Bundle::Bugzilla)
3. Les modules Perl (version minimale) :
a. Template (http://www.template-toolkit.org) (v2.07)
b. AppConfig (http://www.cpan.org/modules/by-module/AppConfig/) (v1.52)
c. Text::Wrap
(v2001.0131)
(http://www.cpan.org/authors/id/MUIR/modules/Text-Tabs%2BWrap-2001.0131.tar.gz)
d. File::Spec (http://search.cpan.org/search?dist=File-Spec) (v0.8.2)
e. Data::Dumper (http://www.cpan.org/modules/by-module/Data/) (toutes les versions)
f. DBD::mysql (http://www.cpan.org/modules/by-module/Mysql/) (v1.2209)
g. DBI (http://www.cpan.org/modules/by-module/DBI/) (v1.13)
h. Date::Parse (http://www.cpan.org/modules/by-module/Date/) (toutes les versions)
i. CGI::Carp (toutes les versions)
Les logiciels suivants sont facultatifs :
a. GD (http://www.cpan.org/modules/by-module/GD/) (v1.19) pour les graphiques des bogues
b. Chart::Base (http://www.cpan.org/modules/by-module/Chart/) (v0.99c) pour les graphiques des bogues
12
c. XML::Parser (toutes les versions) pour l’interface XML
d. MIME::Parser (toutes les versions) pour l’interface par email
4. Le serveur Web de votre choix. Apache (http://www.apache.org/) est hautement recommandé.
Warning
Lors de l’installation de Bugzilla, il est conseillé de s’assurer qu’il existe un pare-feu entre vous et le reste
d’Internet, parce qu’à certains moments pendant l’installation votre machine peut se trouver avec une sécurité amoindrie. En effet, une bonne partie des étapes de l’installation nécessite une connexion active à
Internet, et vous devez prendre soin de vérifier qu’à aucun moment votre machine n’est vulnérable à aucune attaque
Note: Linux-Mandrake 8.0 comprend toutes les librairies obligatoires et facultatives pour Bugzilla. La manière la
plus simple de les installer consiste à utiliser l’utilitaire urpmi. Si vous suivez ces commandes, vous devriez avoir
tout ce qu’il vous faut pour Bugzilla, et checksetup.pl ne devrait pas se plaindre de bibliothèques manquantes.
Il se peut que vous ayez certaines de ces librairies déjà installées.
bash#
bash#
bash#
bash#
bash#
urpmi perl-mysql
urpmi perl-chart
urpmi perl-gd
urpmi perl-MailTools (pour les fonctionalités email de Bugzilla)
urpmi apache-modules
4.1.3. MySQL
Visitez le site de MySQL à www.mysql.com (http://www.mysql.com) pour récupérer et installer la dernière version
stable du serveur.
Note: De nombreuses versions binaires de MySQL stockent leurs fichiers de données dans le répertoire /var.
Sur certains systèmes UNIX, ce répertoire se trouve dans la partition principale (root). Si celle-ci est trop petite,
il peut ne pas y avoir assez de place pour contenir la base de données des bogues. Vous pouvez spécifier le
répertoire des données comme option à configure si vous compilez MySQL vous-même à partir des sources.
Si vous ne faites pas l’installation à partir d’un paquet RPM ou Debian, vous devrez ajouter mysqld à vos scripts de
démarrage pour que le démon du serveur se relance à chaque fois que votre machine redémarre. On ne traitera pas
plus des séquences de démarrage d’UNIX car elles dépassent le cadre de ce guide.
Modifiez vos scripts de démarrage pour que mysqld se lance avec l’option qui lui permet d’accepter les grands
paquets. En effet, par défaut, mysqld n’accepte pas les paquets supérieurs à 64K. Ceci limite la taille des pièces
jointes que vous pouvez ajouter aux bogues. Si vous précisez l’option -O max_allowed_packet=1M à la commande
qui démarre mysqld (ou safe_mysqld), alors vous pourrez disposer de pièces jointes d’à peu près 1 mégaoctet. La
configuration de Bugzilla comprend un paramètre pour la taille maximum des pièces jointes; il faut lui fixer la même
valeur que celle vous avez choisi pour mysqld.
13
Si vous prévoyez d’exécuter Bugzilla et MySQL sur la même machine, vous pouvez utiliser l’option
--skip-networking dans le script d’initialisation. Ceci améliore la sécurité en empêchant un accès au réseau à
MySQL.
4.1.4. Perl
Toute machine qui ne possède pas Perl est une machine bien malheureuse. Pour les rares systèmes *nix qui n’ont
pas Perl, celui-ci est disponible sous forme de sources depuis perl.com (http://www.perl.com). Bien que Bugzilla
fonctionne avec toutes les versions de Perl postérieures à 5.005, ils est conseillé, si vous pouvez, d’installer la toute
dernière version pour Bugzilla. Au moment où ces lignes sont écrites, Perl en est à la version 5.6.1.
Tip: Vous pouvez sauter les étapes suivantes d’installation des modules Perl en chargeant Bundle::Bugzilla depuis
CPAN, qui installe pour vous tous les modules requis.
bash# perl -MCPAN -e ’install "Bundle::Bugzilla"’
Bundle::Bugzilla ne comprend pas GD, Chart::Base et MIME::Parser, qui ne sont pas indispensables à une installation minimale de Bugzilla. Si l’installation du paquet Bundle::Bugzilla échoue, vous devrez installer alors chaque
module séparément pour identifier le problème.
4.1.5. Modules Perl
Tous les modules Perl sont disponibles sur le Réseau Complet des Archives Perl (http://www.cpan.org) (CPAN Comprehensive Perl Archive Network). Les serveurs de CPAN ayant tendance à être saturés, veuillez utiliser les
miroirs.
Le site Web du CPAN contient des documentations générales et de qualité sur l’installation de modules Perl, mais la
manière la plus facile de le faire est d’utiliser l’interpréteur de commande du CPAN qui fait tout le travail pour vous.
Pour utiliser l’interpréteur du CPAN pour installer un modules :
bash# perl -MCPAN -e ’install "<modulename>"’
Si vous choisissez la difficulté :
Décompressez l’archive du module - il devrait créer son propre répertoire.
Placez-vous dans le répertoire nouvellement créé et saisissez les commandes suivantes :
1. bash# perl Makefile.PL
2. bash# make
3. bash# make test
4. bash# make install
14
Warning
Beaucoup d’utilisateurs se plaignent que les modules Perl ne s’installent pas chez eux. La plupart du temps,
les messages d’erreur se plaignent de ne pas trouver un fichier dans “@INC”. Presque à chaque fois,
cette erreur se déclare soit parce que vous n’avez les permissions suffisantes pour compiler les modules
Perl, soit parce que les librairies de développement de Perl nécessaires ne sont pas installées sur votre
système. Demandez à votre administrateur UNIX de vous accorder les droits d’accès suffisants. Si c’est
vous l’administrateur UNIX, veuillez consulter le forum ou la liste de diffusion pour une aide plus poussée,
ou engager quelqu’un pour vous aider.
4.1.5.1. DBI
Le module DBI est un module Perl générique utilisé par les modules liés à MySQL. Si votre installation de Perl s’est
correctement effectuée, celle du module DBI devrait être facile. C’est un module hybride Perl/C, mais le système
Perl’s MakeMaker simplifie grandement la compilation en langage C.
4.1.5.2. Data::Dumper
Le module Data::Dumper fournit la persistance des structures de données (à la manière des sérialisation en Java). Ce
module fait partie de la dernière sous-version (sub-release) de Perl 5.004, mais une réinstallation pour être sûr qu’il
est disponible ne fera pas de mal.
4.1.5.3. Les modules liés à MySQL
L’interface Perl/MySQL demande quelques modules Perl mutuellement dépendants. Ces modules sont regroupés dans
le paquet "Msql-Mysql-modules".
Le processus MakeMaker vous posera quelques questions à propos de la cible que vous souhaitez pour la compilation
et votre installation MySQL. Pour la plupart des questions, la réponse par défaut sera suffisante, mais quand le processus vous demandera si la cible souhaitée est le paquet MySQL ou mSQL, vous devrez choisir celle liée à MySQL.
Plus tard, le programme vous demandera si vous voulez conserver une compatibilité inverse avec les paquets MySQL
plus anciens. Vous devez répondre OUI alors que la réponse par défaut est NON.
Une machine hôte ’localhost’ sera suffisante. De même, un utilisateur de tests ’test’ avec un mot de passe nul devrait
se trouver avec les droits d’accès suffisants pour faire des essais sur la base de données de tests ’test’ que MySQL
génère à l’installation.
4.1.5.4. Modules TimeDate
Une bonne partie des modules Perl en rapport avec la date/le temps/le calendrier ont été groupés dans un paquet
similaire au paquet de module MySQL. Ce paquet est enregistré sur CPAN sous le nom TimeDate. Le composant qui
nous intéresse le plus est le module Date::Format, mais installer tous les composants du module est probablement une
bonne idée de toutes façons.
15
4.1.5.5. GD (facultatif)
La bibliothèque GD a été écrite par Thomas Boutell il y a longtemps pour générer par programmation des images
en C. Depuis lors cette librairie est devenue le standard de facto pour la construction d’images par programmation.
Les fonctions Perl associées, que l’on trouve dans la librairie GD, sont utilisées par des millions de pages Web pour
générer des graphiques à la volée. C’est la raison pour laquelle Bugzilla va s’en servir, donc vous devez l’installer si
vous voulez que n’importe quelle fonctionnalité graphique fonctionne.
Note: La bibliothèque Perl GD nécessite d’autres bibliothèques qui peuvent ou non être installées sur votre système, telles que libpng et libgd. La liste complète des bibliothèques nécessaires se trouvent dans le fichier
README de la bibliothèque Perl GD. Si la compilation de GD échoue, c’est probablement parce qu’il manque une
des bibliothèques demandées.
4.1.5.6. Chart::Base (facultatif)
Le module Chart permet à Bugzilla de générer des diagrammes à la volée. On peut l’installer de la manière habituelle
après l’avoir récupéré sur CPAN. Notez que les versions plus anciennes que 0.99c utilisaient les GIF, mais ils ne sont
plus supportés par les dernières versions de GD.
4.1.5.7. Template Toolkit
Lors de l’installation de Template Toolkit, une série de questions vous seront posées à propos des fonctionnalités à
activer. Les options par défaut sont bien, à part celle qui vous recommande d’utiliser le stash très rapide "XS Stash" du
Template Toolkit, pour disposer de meilleures performances. Cependant, il existe des problèmes bien connus avec XS
Stash et Perl version 5.005_02 et antérieures. Si vous désirez utiliser ces anciennes versions de Perl, veuillez utiliser
le stash classique.
4.1.6. Serveur HTTP
Vous avez dans ce domaine une grande liberté de choix : Apache, Netscape ou n’importe quel serveur sous UNIX
devrait faire l’affaire. Vous pouvez exécuter le serveur Web sur une autre machine que MySQL, mais vous devrez
alors régler les permissions de l’utilisateur "bugs" en conséquence.
Note: Nous vous recommandons fortement d’utiliser Apache comme serveur Web. Les instructions d’installation
du Guide Bugzilla considèrent en général que vous utilisez Apache. Si vous avez réussi à faire tourner Bugzilla
sur un autre serveur, veuillez nous faire part de vos expériences.
Il faut vérifier que votre serveur Web exécute tous les fichiers avec l’extension .cgi en tant que CGI et ne se contente
pas de les afficher. Si vous utilisez Apache, cela signifie qu’il faut décommenter la ligne suivante dans le fichier
httpd.conf :
AddHandler cgi-script .cgi
16
Avec Apache, il faut aussi vérifier que dans le fichier httpd.conf se trouve les lignes suivantes :
Options ExecCGI
AllowOverride Limit
dans la section qui traite des répertoires dans lesquels vous comptez mettre les fichiers .html et .cgi de Bugzilla.
Note: AllowOverride Limit permet d’utiliser une instruction Deny (NdT : de refus) dans le fichier .htaccess généré
par checksetup.pl
Les utilisateurs des versions plus anciennes d’Apache peuvent trouver les lignes ci-dessus respectivement dans
les fichiers srm.conf et access.conf
Warning
Il y a des fichiers et des répertoires importants qui ne doivent pas être affichés par le serveur HTTP - la
plupart des fichiers dans les répertoires “data” et “shadow” et le fichier “localconfig”. Vous devez configurer
votre serveur HTTP pour qu’il ne les affiche pas. Si vous ne le faites pas des mots de passe et d’autres données importantes seront visibles. Vous trouverez les informations sur la manière de procéder pour Apache
dans la section Fichiers .htaccess et sécurité; le script checksetup.pl devrait vous sortir les fichiers .htaccess
appropriés.
4.1.7. Bugzilla
Décompressez les fichiers de Bugzilla dans un répertoire que vous voulez bien laisser avec les droits d’écriture pour
l’utilisateur sous lequel s’exécute par défaut le serveur Web (probablement “nobody”). Vous pouvez décider de mettre
ces fichiers dans l’espace principal des pages Web du serveur Web ou peut-être dans /usr/local avec un lien
symbolique dans l’espace des pages Web pointant sur le répertoire de Bugzilla.
Tip: Si vous faites un lien symbolique du répertoire de Bugzilla vers la hiérarchie de fichiers HTML de votre
Apache, vos pourriez rencontrer l’erreur Forbidden. Pour l’éviter, ajoutez la directive “FollowSymLinks” dans
httpd.conf, à la section <Directory> du répertoire racine des fichiers HTML.
Une fois que tous les fichiers se trouvent dans le répertoire accessible par le Web, donnez lui les droits d’écriture
pour l’utilisateur du serveur Web. Il s’agit d’une étape temporaire en attendant d’exécuter le script de post-installation
checksetup.pl, qui verrouillera votre installation.
Après, faites un lien symbolique vers /usr/bonsaitools/bin/perl de l’emplacement correct de votre exécutable
Perl (probablement /usr/bin/perl). Sinon, vous devez bidouiller tous les fichiers .cgi pour modifier le chemin par
lequel ils accèdent à Perl. On peut le faire en utilisant la commande Perl suivante en une ligne, mais je vous conseille
d’utiliser la méthode avec les liens symboliques pour éviter les mauvaises surprises pendant les mises à jour.
17
perl -pi -e
’s@#\!/usr/bonsaitools/bin/perl@#\!/usr/bin/perl@’ *cgi *pl Bug.pm
processmail syncshadowdb
Remplacer /usr/bin/perl pour qu’il corresponde à l’emplacement de Perl sur votre machine.
4.1.8. Configurer la Base de Données MySQL
Après que tous les logiciels requis soient installés et fonctionnent, vous pouvez alors commencer à configurer la base
de données qui va maintenat être l’épine dorsale d’un seveur de suivi de bogues de haute qualité.
Tout d’abord, il va falloir corriger les permissions de MySQL pour permettre l’accès depuis Bugzilla. Dans de cette
section Installation, nous conviendrons que l’utilisateur de Bugzilla sera “bugs”, et aura les permissions minimums.
Commencez par donner à l’utilisateur root de MySQL son mot de passe. Les mots de passe MySQL sont limités à 16
caractères.
bash# mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD(’<new_password>’) WHERE user=’root’;
mysql> FLUSH PRIVILEGES;
A partir de ce point, si vous avez besoin d’accéder à MySQL sous l’utilisateur root de MySQL, vous devrez utiliser
mysql -u root -p et saisir <new_password>. N’oubliez pas que les noms d’utilisateur MySQL n’ont rien à voir avec
les noms d’utilisateur UNIX (les noms de login).
Ensuite, nous utilisons la commande SQL GRANT pour créer un utilisateur “bugs”, et lui accorder les permissions
suffisantes pour que checksetup.pl, que nous utiliserons tout-à-l’heure, opère sa magie. Cela restreint également les
opérations de l’utilisateur “bugs” à celles agissant sur la base de données “bugs”, et n’autorise le compte à se connecter
que depuis “localhost”. Modifiez cela en fonction de votre configuration si vous devez vous connecter plus tard depuis
une autre machine ou sous un autre utilisateur.
N’oubliez pas de remplacer <bugs_password> par un mot de passe unique.
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,INDEX, ALTER,CREATE,DROP,REFERENCES ON bugs.* TO bugs@loca
Note: Si vous utilisez MySQL 4, l’utilisateur bugs doit aussi se voir accorder les permissions sur les tables suivantes : LOCK TABLES et CREATE TEMPORARY TABLES.
4.1.9. checksetup.pl
Ensuite, exécutez le script magique checksetup.pl (un grand merci à Holger Schurig
(mailto:[email protected]) pour avoir écrit ce script!). Ce script a été conçu pour s’assurer que votre base de
données MySQL, les options de configuration et les fichiers CGI de Bugzilla sont cohérents. Ce script vérifiera que
les fichiers et les répertoires de Bugzilla ont des permissions raisonnables, installera le répertoire data, et créera
toutes les tables MySQL.
bash# ./checksetup.pl
18
La première fois que vous le démarrerez, il créera un fichier appelé localconfig.
Ce fichier contient une grande variété de paramètres que vous pouvez avoir besoin de modifier, notamment comment
Bugzilla se connecte à la base de données MySQL.
Les paramètres de connexion comprennent :
1. Machine du serveur: utilisez simplement “localhost” si le serveur MySQL est local
2. Nom de la base de données: “bugs” si vous suivez nos indications
3. Nom de l’utilisateur MySQL: “bugs” si vous suivez nos indications
4. Mot de passe pour le compte MySQL “bugs”; (<bugs_password>) plus haut
Dès que vous êtes satisfait de ces paramètres, connectez-vous avec la commande su sous l’utilisateur sous lequel
votre serveur Web tourne et redémarrez checksetup.pl. (Note: sur certains systèmes orientés sécurité, vous pouvez
avoir besoin de changer le shell d’ouverture de session du compte du serveur Web avant de le faire.) Durant ce second
appel au script, il va créer la base de données et un compte administrateur pour lequel il vous sera demandé de fournir
quelques informations.
Note: Le script checksetup.pl est conçu pour que vous puissiez l’exécuter à n’importe quel moment sans causer
de problèmes. Vous devez l’exécuter après chaque mise à jour de Bugzilla.
4.1.10. Configurer Bugzilla
Vous devez parcourir les options sur la page “Edit Parameters” (le lien est en bas de page) et leur donner la valeur
appropriée. Les options importantes sont documentéesécrites dans Section 5.1.
4.2. Configuration supplémentaire facultative
4.2.1. Diagrammes de dépendance
Tout comme les diagrammes de dépendance en mode texte, Bugzilla supporte également les graphes de dépendance,
en utilisant un logiciel appelé ’dot’. L’option ’webdotbase’ en commande le fonctionnement exact. Elle peut prendre
trois valeurs. Son fonctionnement exact est contrôlé par l’option ’webdotbase’, qui peut prendre trois valeurs :
1. Le chemin d’accès complet à la commande ’dot’ (qui fait partie de GraphViz (http://www.graphviz.org/)) qui va
générer les graphiques localement.
2. Un préfixe URL pointant vers une installation du logiciel webdot qui va générer les graphiques à distance.
3. Une valeur nulle qui désactive les graphiques de dépendance.
19
Donc, pour le faire marcher, installez GraphViz (http://www.graphviz.org/). Dans ce cas, vous devez activer les cartes
d’image côté serveur (http://httpd.apache.org/docs/mod/mod_imap.html) dans Apache. Autrement, vous pouvez installer un serveur webdot, ou utiliser le serveur public webdot AT&T (le choix par défaut pour l’option webdotbase).
Notez que le serveur de AT&T ne marchera pas si Bugzilla n’est accessible que par HTTPS.
4.2.2. Les graphiques de Bogues
Puisque vous avez installé les modules Perl GD et Graph::Base, vous pouvez tant que vous y êtes activer les
formidables graphiques de rapport de bogues de Bugzilla.
Ajoutez une entrée cron telle que celle-ci pour exécuter collectstats.pl tous les jours à minuit 5 :
bash# crontab -e
5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl
Deux jours après vous pourrez visualiser les graphiques de bogues depuis la page de rapport de bogue.
4.2.3. Le cron plaintif
Maintenant vous avez un bugzilla complètement fonctionnel. Mais les meilleurs bogues ne sont-ils pas aussi les plus
énervants ? Pour vous aider à rendre ces bogues encore plus agaçants, vous pouvez activer le système automatique de
plainte de Bugzilla pour se plaindre auprès des ingénieurs qui laissent leur bogues dans un état NEW sans faire de
triage.
Pour ce faire, ajoutez la commande suivante en tant qu’entrée crontab quotidienne (lire la page du manuel de crontab
si vous voulez de l’aide sur le sujet) :
cd <your-bugzilla-directory> ; ./whineatnews.pl
Tip: Selon votre système, crontab peut avoir plusieurs pages de manuel. La commande suivante devrait vous
mener à la page de manuel la plus pertinente sur le sujet :
man 5 crontab
4.2.4. Authentification LDAP
Warning
Les informations suivantes qui décrivent l’utilisation de l’option d’authentification LDAP de Bugzilla sont
anciennes, et les auteurs ne connaissent personne qui les ait testées. A utiliser avec précaution.
20
Le système d’authentification traditionnel de Bugzilla utilise les adresses email comme ID utilisateur primaire, et
un mot de passe pour identifier l’utilisateur. Tous les endroits de Bugzilla qui traitent les ID utilisateurs (exemple :
assigner un bogue) utilisent l’adresse email. L’authentification LDAP se place au dessus de ce schéma au lieu de le
remplacer. L’utilisateur se connecte au début avec un nom d’utilisateur et un mot de passe pour l’annuaire LDAP.
L’adresse email est récupérée depuis LDAP et l’utilisateur est identifié par le système traditionnel d’une façon cohérente en utilisant son adresse email. Si un compte pour cette adresse email existe déjà dans votre système Bugzilla,
il s’y connectera. Si aucun compte pour cette adresse email n’existe, un compte est créé au cours de la connexion. (Dans ce cas, Bugzilla essaie d’utiliser le "displayName" ou l’attribut "cn" pour déterminer le nom complet de
l’utilisateur). Après l’authentification, toutes les tâches liées à cet utilisateur sont gérées par l’adresse email, et non
par le nom d’utilisateur LDAP. Vous continuez d’assigner des bugs par adresse email, de rechercher des utilisateurs
par adresse email, etc.
Utiliser LDAP pour l’authentification dans Bugzilla nécessite le module Perl Mozilla::LDAP (ou PerLDAP). Le module Mozilla::LDAP nécessite à son tour le Directory SDK de Netscape pour le C. Après que vous ayez installé le SDK,
installez le module PerLDAP. Mozilla::LDAP et le Directory SDK sont tous les deux disponibles en téléchargement
(http://www.mozilla.org/directory/) sur mozilla.org.
Fixez le paramètre ’useLDAP’ à "On" **seulement** si vous voulez utiliser un annuaire LDAP pour l’authentification.
Soyez très prudent en modifiant ce paramètre; si vous activez l’authentification LDAP sans avoir un annuaire LDAP
valide, vous ne pourrez plus vous reconnecter à Bugzilla quand vous vous serez déconnecté. (Si cela se produit, vous
pouvez y retourner en éditant manuellement les fichiers de données et de paramètres, et en fixant ’useLDAP’ à 0).
Si vous utilisez LDAP, vous devez fixer trois paramètres supplémentaires : spécifiez le nom de votre serveur LDAP (et
éventuellement son port) dans l’option LDAPServer. Si vous ne choisissez pas le port, le port par défaut est 389. (Ex :
"ldap.mycompany.com" ou "ldap.mycompany.com:1234"). Fixer LDAPBaseDN avec la base DN pour rechercher des
utilisateurs dans le répertoire LDAP. (Ex : "ou=People,o=MyCompany"). Les identifiants UID doivent être uniques
dans la DN choisie. Spécifiez dans LDAPmailattribute le nom de l’attribut dans l’annuaire LDAP qui contient l’adresse
email primaire. Dans beaucoup de serveurs d’annuaire disponibles, c’est "mail", mais vous pouvez avoir besoin de le
changer.
4.2.5. Empêcher les pages de Bugzilla d’exécuter du code Javascript
malveillant.
Il arrive que Bugzilla exécute du code Javascript malveillant. A cause de problèmes d’internationalisation,
il est impossible d’intégrer les modifications de code nécessaires pour remplir les conditions minimums
conseillées par le CERT et décrites à l’adresse http://www.cet.org/tech_tips/malicious_code_mitigation.html/#3
(http://www.cert.org/tech_tips/malicious_code_mitigation.html/#3). Si votre installation de Bugzilla est prévue pour
des utilisateurs anglophones, l’exécution de ce bout de code à partir d’un interpréteur de commande résoudra le
problème. Comme toujours, assurez-vous que votre installation de Bugzilla soit correctement sauvegardée avant
d’exécuter ces changements. De plus, je vous recommande de comprendre ce que le script fait avant de l’exécuter.
bash# perl -pi -e "s/Content-Type\: text\/html/Content-Type\: text\/html\; charset=ISO-8859-1/i" *.cg
Tout ce que fait cette commande d’un seul ligne est de rechercher toutes les occurrences de “Content-type: text/html”
et de les remplacer par “Content-Type: text/html; charset=ISO-8859-1”. Cette commande empêche une possible attaque Javascript sur le navigateur, et est conseillée pour tous les site anglophones. (NdT : cette option HTML permet
21
en fait de spécifier la table de caractère à utiliser pour la page). Pour les sites Bugzilla non-anglophones, je vous
conseille de changer l’option “ISO-8859-1” ci-dessus par “UTF-8”.
Note : il n’est pas conseillé d’utiliser les étiquettes <meta> pour spécifier les tables de caractères car, à cause d’un
bogue dans Netscape 4.x, les pages ainsi configurées sont chargées deux fois avec ce navigateur.
4.2.6. Fichiers .htaccess et sécurité
Pour améliorer la sécurité de votre installation de Bugzilla, le script checksetup.pl de Bugzilla va générer des
fichiers .htaccess que le serveur Web Apache peut utiliser pour restreindre l’accès sur les fichiers de données de
Bugzilla. Ces fichiers .htaccess ne marcheront pas avec Apache 1.2.x - mais puisqu’il possède des trous de sécurité,
vous de devriez pas l’utiliser de toutes manières.
Note: Si vous utilisez un fournisseur alternatif de service webdot pour les graphiques (comme cela est décrit
quand vous visualisez editparams.cgi dans votre serveur Web), il vous faut changer l’adresse IP dans
data/webdot/.htaccess et spécifier l’adresse IP du serveur webdot que vous utilisez.
Le fichier .htaccess par défaut peut ne pas fournir les restrictions d’accès suffisantes, selon la configuration de votre
serveur Web. Prenez soin d’activer les entrées <Directory> de votre répertoire de Bugzilla pour que les fichiers
.htaccess soient autorisés à surcharger les options par défaut du serveur Web. Par exemple, supposons que votre
Bugzilla soit installé dans le répertoire /usr/local/bugzilla. Vous devez donc avoir cette entrée <Directory>
dans votre fichier httpd.conf:
<Directory /usr/local/bugzilla/>
Options +FollowSymLinks +Indexes +Includes +ExecCGI
AllowOverride All
</Directory>
L’élément important ci-dessus est “AllowOverride All”. Sans lui, le fichier .htaccess généré par checksetup.pl
n’aura pas les permissions suffisantes pour protéger votre installation de Bugzilla.
Si vous utilisez Internet Information Server (IIS) ou un autre Serveur Web qui ne suit pas les conventions .htaccess,
vous pouvez désactiver leur création en éditant localconfig et en donnant à la variable $create_htaccess la
valeur 0.
4.2.7. mod_throttle et la sécurité
Il est possible pour un utilisateur, par erreur ou volontairement, d’accéder plusieures fois de suite à la base de données,
ce qui peut engendrer des vitesses d’accès très faibles pour les autres utilisateurs. Si votre installation de bugzilla
rencontre ce problème, vous pouvez installer le module Apache mod_throttle, qui est capable de limiter le nombre
de connexions par adresse IP. Vous pouvez télécharger ce module à http://www.snert.com/Software/mod_throttle/.
Suivez les instructions pour l’insérer dans votre installation d’Apache. Ce module ne fonctionne qu’avec le serveur
Web Apache ! Vous pouvez utiliser la commande ThrottleClientIP fournie avec le module pour réaliser cet objectif.
Veuillez lire la documentation du module (http://www.snert.com/Software/mod_throttle/) pour plus d’informations.
22
4.3. Notes d’installation sur Win32
Cette section traite de l’installation de Bugzilla sur Microsoft Windows. Bugzilla a été conçu pour fonctionner sur
les plate-formes Win32, mais l’équipe Bugzilla insiste sur le fait que la manière la plus simple de l’installer sur les
machines Intel est de le faire sur une variante de GNU/Linux, et de suivre les instructions d’installation pour UNIX
dans ce guide. Si vous avez une quelconque influence dans le choix de la plate-forme sur laquelle tourne Bugzilla,
alors choisissez GNU/Linux au lieu de Microsoft Windows.
Warning
Après cet avertissement, voici la situation pour la version 2.16 et Windows. Tout ne fonctionne pas du
premier coup. Vous avez plutôt intérêt à prendre la version 2.17 du CVS (après vous être assuré auprès
de l’équipe Bugzilla que vous vous trouvez dans un jour stable), parce que nous allons devoir effectuer une
charge de travail non négligeable pour rendre votre expérience sous Win32 plus agréable qu’elle ne l’est à
présent.
Si vous voulez toujours l’essayer, pour avoir une chance de le faire marcher, vous devez appliquer
la rustine mail patch () du bogue 124174 (http://bugzilla.mozilla.org/show_bug.cgi?id=124174).
Ceci fait, vous devrez lire les instructions d’installation (dépassées) ci-dessous, celles
plus récentes
(http://bugzilla.mozilla.org/attachment.cgi?id=84430&action=view) (et probablement meilleures) gentiment fournies
par Toms Baugis et Jean-Sébastien Guay, et aussi vérifier la page de mise-à-jour Win32 de Bugzilla 2.16 (Bugzilla
2.16 Win32 update page) (http://www.bugzilla.org/releases/2.16/docs/win32.html). Si nous avons le temps, nous
écrirons de meilleures instructions d’installation pour le 2.16, et nous les intégrerons dans ce document. Mais je ne
vous promets rien.
4.3.1. Installation sur Win32 : étape par étape
Note: Familiarisez-vous avec le reste de la section Bugzilla Installation avant d’effectuer l’installation sur Win32.
Faire tourner Bugzilla sur Microsoft Windows n’est pas une partie de plaisir. Le support de Win32 s’est amélioré
de façon spectaculaire dans les dernières versions, mais, si vous choisissez de continuer, vous devrez posséder
de sérieuses compétences d’administrateur des systèmes Windows ainsi que des fortes capacités à résoudre
les problèmes, une tolérance élevée à la douleur, et des connaissances en perl suffisantes. Bugzilla sous NT
demande de bidouiller des codes source et d’implémenter des utilitaires avancés. Ce qui suit est la procédure
d’installation recommandée pour Win32; des suggestions supplémentaires sont proposées dans la section Appendix A.
1.
Installez Le Serveur Web Apache (http://www.apache.org/) pour Windows, et copiez les fichiers de Bugzilla
là où Apache pourra les afficher. Veuillez suivre toutes les instructions mentionnées dans la section Bugzilla
Installation en fonction de votre configuration d’Apache, particulièrement les instructions à propos du paramètre
“AddHandler” et de l’option “ExecCGI”.
Note: Vous pouvez aussi utiliser les serveurs Web Internet Information Server et Personal Web Server dans
ce but. Cependant, la configuration est assez différente. Si ActivePerl ne semble pas gérer vos associations
de fichiers correctement (pour les fichiers .cgi et .pl), veuillez consulter la section Appendix A.
Si Vous vous utilisez IIS, et si c’est sous Windows NT, vous devez vous être mis à jour au moins au niveau
Service Pack 4. Windows 2000 est fourni avec une version suffisante d’IIS.
23
2.
Installez
ActivePerl
(http://www.activestate.com/)
pour
Windows.
Cherchez
sur
http://aspn.activestate.com/ASPN/Downloads/ActivePerl
(http://aspn.activestate.com/ASPN/Downloads/ActivePerl/)
un
binaire
compilé
de
la
version
en cours
Suivez également les liens suivants pour connaître le statut de ActivePerl sous Win32 :
Perl Porting (http://language.perl.com/newdocs/pod/perlport.html) et
Perl on Win32 FAQ
(http://ftp.univie.ac.at/packages/perl/ports/nt/FAQ/perlwin32faq5.html) (la FAQ de Perl sous Win32)
3.
Utilisez ppm depuis votre répertoire perl\bin pour installer les paquets suivants : DBI, DBD-Mysql, TimeDate,
Chart, Date-Calc, Date-Manip, GD, AppConfig et Template. Vous pouvez avoir besoin de les extraire d’une
archive .zip avant en utilisant Winzip ou un autre programme de décompression. On peut télécharger la plupart de
ces modules ppm supplémentaires depuis ActiveState, sauf AppConfig et Template, disponible sur OpenInteract
en utilisant les instructions sur le site Web du Toolkit Template (http://openinteract.sourceforge.net/).
Note:
Vous
pouvez
trouver
une
liste
des
modules
à
l’adresse
:
http://www.activestate.com/PPMPackages/zips/5xx-builds-only/
(http://www.activestate.com/PPMPackages/zips/5xx-builds-only)
ou
http://www.activestate.com/PPMPackages/5.6plus (http://www.activestate.com/PPMPackages/5.6plus)
La syntaxe de ppm est : C:> ppm <nom du module>
Example 4-1. Installer les modules ppd ActivePerl sur Microsoft Windows
C:> ppm DBD-Mysql
Surveillez la touche majuscule !
Le répertoire 5.6Plus de ActiveState contient aussi un ppm AppConfig, c’est pourquoi vous pourriez rencontrer
l’erreur suivante en essayant d’installer la version d’OpenInteract :
Error installing package ’AppConfig’: Read a PPD for ’AppConfig’, but it is not
intended for this build of Perl (MSWin32-x86-multi-thread)
Si c’est le cas, téléchargez à la fois l’archive tar (http://openinteract.sourceforge.net/ppmpackages/AppConfig.tar.gz)
et le ppd (http://openinteract.sourceforge.net/ppmpackages/AppConfig.ppd) directement depuis OpenInteract.
Exécutez ensuite le ppm depuis le même répertoire que celui dans lequel vous avez téléchargé ces fichiers et
installez le paquets en référençant le fichier ppd explicitement à l’aide de la commande install. Par exemple :
Example 4-2. Installer manuellement les modules ppd d’OpenInteract sur Microsoft Windows.
install C:\AppConfig.ppd
4.
Installez MySQL pour NT.
24
Note: Vous pouvez télécharger MySQL pour Windows NT à l’adresse MySQL.com (http://www.mysql.com/). Certains trouvent utile d’utiliser l’utilitaire WinMySqlAdmin, inclus dans l’archive téléchargée pour configurer la
base de données.
5.
Configurer MySQL
a.
C:> C:\mysql\bin\mysql -u root mysql
b.
mysql> DELETE FROM user WHERE Host=’localhost’ AND User=”;
c.
mysql> UPDATE user SET Password=PASSWORD (’nouveau_password’) WHERE
user=’root’;
“nouveau_password”, ci-dessus, est le mot de passe que vous voulez utiliser pour votre utilisateur
“root”.
d.
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, DROP,
REFERENCES ON bugs.* to bugs@localhost IDENTIFIED BY ’bugs_password’;
“bugs_password”, ci-dessus, est le mot de passe que vous voulez utiliser pour votre utilisateur “bugs”.
6.
e.
f.
mysql> create database bugs;
g.
mysql> exit;
h.
C:> C:\mysql\bin\mysqladmin -u root -p reload
Editez checksetup.pl dans votre répertoire de Bugzilla. Remplacer la ligne :
my $webservergid =
getgrnam($my_webservergroup);
par celle-ci :
my $webservergid =
$my_webservergroup;
Vous pouvez aussi donner explicitement le nom du groupe que vous voulez voir posséder les fichiers :
my $webservergid =
’Administrators’
7.
Exécutez checksetup.pl depuis le répertoire de Bugzilla.
8.
Editez localconfig pour satisfaire vos exigences. Donnez la valeur de votre “bugs_password” dans la partie
step 5.d à la variable $db_pass, et la valeur “8” à la variable $webservergroup.
Note: Nous ne sommes pas sûrs du “8” pour $webservergroup ci-dessus. Si c’est faux, veuillez nous envoyer
vos corrections.
25
9.
Editez defparams.pl pour satisfaire vos exigences. En particulier, fixez DefParam("maintainer") et
DefParam("urlbase") pour se conformer à votre installation.
Note: Il s’agit à nouveau d’une étape dont je ne suis pas sûr, car le mainteneur de cette documentation
n’assure pas le suivi de Bugzilla sur NT. Si vous pouvez confirmer ou infirmer cette étape, veuillez me le faire
savoir.
10.
Note: Il existe plusieures alternatives à Sendmail qui fonctionnent sous Win32. Celle qui est mentionnée ici est
une suggestion, pas une obligation. Parmi les quelques autres logiciels de mail qui peuvent fonctionner, on
trouve BLAT (http://www.blat.net/), Windmail (http://www.geocel.com/windmail/), Mercury Sendmail
(http://www.dynamicstate.com/), et le module Net::SMTP du CPAN (disponible en .ppm). Chaque solution
demande un peu de bidouillage des scripts Perl pour faire marcher Bugzilla. La solution proposée ici en
demande le moins.
1.
Téléchargez NTsendmail, disponible sur www.ntsendmail.com (http://www.ntsendmail.com/). Vous devez
avoir un "vrai" serveur mail capable de le relayer dans votre variable $ENV{"NTsendmail"} (que vous devrez
probablement mettre dans globals.pl).
2.
Copier ntsendmail.pm dans votre répertoire .\perl\lib.
3.
Ajoutez à globals.pl :
# ces paramètres configurent NTsendmail
process use NTsendmail;
$ENV{"NTsendmail"}="your.smtpserver.box";
$ENV{"NTsendmail_debug"}=1;
$ENV{"NTsendmail_max_tries"}=5;
Note: Certains prétendent qu’il faut aussi modifier $db_pass dans globals.pl pour que ce soit votre
“bugs_password”. Cela peut vous éviter quelques problèmes d’authentification pour accéder à votre base
de données, vu que globals.pl, normalement, n’est pas concerné par les restrictions de .htaccess. Mais
votre mot de passe de la base de données est ainsi exposé à la vue de quiconque utilise votre serveur
Web.
4.
Recherchez et décommentez toutes les occurences de “open(SENDMAIL” dans le répertoire de Bugzilla.
Remplacez-les par :
# Nouvelles fonctionalités de sendmail
my $mail=new NTsendmail;
my $from="bugzilla\@your.machine.name.tld";
my $to=$login;
my $subject=$urlbase;
$mail->send($from,$to,$subject,$msg);
26
Note: Certains utilisateurs ont rencontré du succès avec le logiciel commercial Windmail. Une solution
serait peut-être de remplacer vos appels à sendmail par :
open SENDMAIL,
"|\"C:/General/Web/tools/Windmail 4.0 Beta/windmail\" -t >
mail.log";
ou quelque chose qui aurait le même effet.
11. Modifiez toutes les références dans tous les fichiers en remplaçant processmail par processmail.pl, et
renommez processmail en processmail.pl.
Note: Beaucoup pensent que c’est un changement à faire pour l’arbre principal de Bugzilla. Cela ne fera
aucun mal aux gens d’UNIX, et peut rendra ceux de Win32 plus heureux.
Note: Certaines personnes ont suggéré d’utiliser le module Perl Net::SMTP à la place de NTsendmail ou des
autres propositions énoncées ici. Vous pouvez changer processmail.pl pour que ça marche.
my $smtp = Net::SMTP->new(’<Nom de votre serveur SMTP>’);
#connexion au serveur SMTP
$smtp->mail(’<votre nom>@<votre serveur SMTP>’);# utilisez l’adresse de l’expéditeur ici
$smtp->to($tolist); # adresse des destinataires
$smtp->data(); # Commencer le mail
$smtp->datasend($msg);
$smtp->dataend();
# Finir en envoyant le mail
$smtp->quit;
# Fermer la conexion SMTP
$logstr = "$logstr; mail sent to $tolist $cclist";
}
Voici un programme de test de mail pour Net::SMTP :
use Net::SMTP;
my $smtp = Net::SMTP->new(’<Name of your SMTP server’, Timeout => 30, Debug
=> 1, ); # connexion au serveur SMTP
$smtp->auth;
$smtp->mail(’[email protected]’);# utilisez l’adresse de l’expéditeur ici
$smtp->to(’[email protected]’); #adresse des destinataires
$smtp->data(); # Commencez le mail
$smtp->datasend(’test’);
$smtp->dataend();
# Finir d’envoyer le mail
$smtp->quit;
# Fermer la connexion SMTP
exit;
27
12.
Note: Cette étape est facultative si vous utilisez IIS ou un autre serveur Web qui choisit l’interpréteur seulement
d’après l’extension du fichier (.pl) au lieu de regarder la ligne de déclaration de l’interpréteur, dite ligne “shebang”
(#!/usr/bonsaitools/bin/perl)
Modifiez le chemin d’accès à Perl sur la première ligne (#!) de tous les fichiers pour pointer vers votre Perl,
et ajoutez “perl” au début de chaque appel système Perl qui utilise un script Perl en argument. Cela peut vous
prendre pas mal de temps. Il y a un utilitaire “setperl.csh” pour accélérer une partie de cette procédure, disponible
dans la section Useful Patches and Utilities for Bugzilla du Guide Bugzilla. Cependant, cela nécessite que
l’environnement Gygwin compatible GNU pour Win32 soit configuré pour que ça marche. Des informations
pour obtenir Cygwin sont disponibles à l’adresse : http://www.cygwin.com/.
13. Modifiez l’invocation des tous les appels system() dans tous les script perl dans le répertoire dans lequel vous
avez installé Bugzilla. Il faut préciser le chemin d’accès complet à perl pour chaque appel system(). Par exemple,
changez cette ligne dans processmail :
system ("./processmail",@ARGLIST);
to
system ("C:\\perl\\bin\\perl", "processmail", @ARGLIST);
14. Ajoutez les appels à binmode() pour que
(http://bugzilla.mozilla.org/show_bug.cgi?id=62000)).
les
pièces-jointes
fonctionnent
(bogue
62000
Parce que les systèmes basés sur Microsoft Windows gèrent les fichiers binaires d’une façon différente
des systèmes basés sur UNIX, you devez ajouter les lignes suivantes à createattachment.cgi et
showattachment.cgi avant la ligne require ’CGI.pl’;.
binmode(STDIN);
binmode(STDOUT);
Note: D’après le bogue 62000 (http://bugzilla.mozilla.org/show_bug.cgi?id=62000), la documentation de perl
dit qu’il faut toujours utiliser binmode() quand on a à faire à des fichiers binaires, mais jamais quand on a
à faire à des fichiers texte. Cela voudrait donc dire qu’il ne faut pas mettre à priori binmode() au début des
fichiers attachés. Il serait plus logique de vérifier si binmode() est nécessaire ou non.
28
Tip: Si vous utilisez IIS ou Personal Web Server, vous devez ajouter des relations sur les cgi dans Properties ->
Home directory (onglet) -> Application Settings (section) -> Configuration (bouton), telles que celles-ci :
.cgi to: <répertoire d’installation de perl>\perl.exe %s
%s .pl to: <répertoire d’installation de perl>\perl.exe %s %s
GET,HEAD,POST
Bien-sûr, choisissez le chemin d’accès à Perl correspondant à votre installation.
4.3.2. Astuces supplémentaires pour Windows
Tip: Par Andrew Pearson:
Vous
pouvez
faire
marcher
Bugzilla
avec
Personal
Web
Server
sous
Windows
98 et suivant, ainsi qu’avec IIS 4.0. Microsoft a mis des informations sur leur
site
web
:
http://support.microsoft.com/support/kb/articles/Q231/9/98.ASP
(
http://support.microsoft.com/support/kb/articles/Q231/9/98.ASP)
En fait, vous devez ajouter deux clés dans la base de registre, dans l’emplacement suivant :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
Ces clé doivent être appelées ".pl" et ".cgi", et toutes les deux doivent contenir une valeur du genre :
c:/perl/bin/perl.exe "%s" "%s"
L’article de KB ne parle que des .pl, mais il rentre plus dans les détails et fourni un script perl de test.
Tip: Si vous avez l’intention de faire tourner Bugzilla en version 2.12 ou antérieure, vous devrez supprimer les
appels encrypt() des sources Perl. Cela n’est pas nécessaire pour Bugzilla 2.13 et suivant, ce qui inclut la version
en cours, Bugzilla 2.16.4.
Example 4-3. Suppression de encrypt() dans la version 2.12 et antérieur de Bugzilla, pour Windows NT
Remplacez ceci :
SendSQL("SELECT encrypt(" . SqlQuote($enteredpwd) .
", " . SQLQuote(substr($realcryptpwd, 0, 2)) . ")"); my
$enteredcryptpwd = FetchOneColumn();
par :
my $enteredcryptpwd = $enteredpwd
dans cgi.pl.
29
4.4. Notes d’installation sous Mac OS X
Il existe beaucoup de bibliothèques courantes et d’utilitaires dans la nature qu’Apple n’a pas inclus dans Mac OS X,
mais qui fonctionnent très bien avec. La bibliothèque GD, dont Bugzilla a besoin pour faire des graphes de bogues,
est l’un d’entre eux.
Le programme appelé Fink est ce qui permet d’en obtenir le plus facilement. Fink est proche de l’installeur CPAN,
mais installe les utilitaires GNU courants. Fink est disponible à l’adresse <http://sourceforge.net/projects/fink/>.
Suivez les instructions pour configurer Fink. Une fois qu’il est installé, vous devez exécuter la commande suivante en
tant que root : fink install gd
Fink va alors vous demander s’il doit résoudre un certain nombre de dépendances. Saisissez ’y’ et tapez entrée pour
installer toutes les dépendances. Surveillez alors que tout ce passe bien.
Pour ne pas entrer en conflit avec les logiciels installés par défaut par Apple, Fink crée sa propre arborescence dans
/sw et y place la plupart des logiciels qu’il installe. Cela signifie que vos bibliothèques et vos entêtes pour libgd
seront dans /sw/lib et /sw/include au lieu de /usr/lib et /usr/local/include. Puisque l’emplacement de ces bibliothèques
a changé, le module Perl GD ne va pas s’installer directement à partir de CPAN. En effet, il recherche des chemins
d’accès fixés au lieu de les extraire de votre environement. Mais il y a un moyen de contourner le problème. :-)
Au lieu de taper “install GD” dans l’invite cpan>, tapez look GD. Cela devrait télécharger automatiquement la
dernière version du module GD, et vous ouvrir un shell dans le répertoire de construction. Appliquez cette rustine
(../xml/gd-makefile.patch) au fichier Makefile.PL (pour cela, enregistrez le patch dans un fichier et utilisez la commande patch < fichier_patch >.)
Pour terminer l’installation du module GD, exécutez ces commandes :
perl Makefile.PL
make
make test
make install
Et noubliez pas d’exécuter exit pour revenir au CPAN.
4.5. Résolution des problèmes
Cette section donne des solutions aux problèmes courants d’installation de Bugzilla.
4.5.1. Bundle::Bugzilla met à niveau Perl à la version 5.6.1
Exécutez la commande perl -MCPAN -e ’install CPAN’ pour voir et continuez.
Certaines versions plus anciennes des outils CPAN étaient un peu naïves quand elles mettaient à jour des modules
Perl. Quand des modules entraient dans la distribution Perl 5.6.1, CPAN pensait que le meilleur moyen de les garder à
jour était de récupérer la distribution Perl elle-même et de la reconstruire. Inutile de vous dire que cela a causé un mal
de tête à presque tout le monde. Une mise à niveau vers la nouvelle version de CPAN, grâce à la commande ci-dessus
devrait régler le problème.
30
4.5.2. "DBD::Sponge::db prepare failed" (la préparation de
DBD::Sponge::db a échoué)
Le message suivant peut apparaître à cause d’un bogue dans DBD::mysql (sur lequel l’équipe Bugzilla n’a aucun
contrôle) :
DBD::Sponge::db prepare failed: Cannot determine NUM_OF_FIELDS at D:/Perl/site/lib/DBD/mysql.pm line
SV = NULL(0x0) at 0x20fc444
REFCNT = 1
FLAGS = (PADBUSY,PADMY)
Pour régler le problème, éditez le fichier <chemin-vers-perl>/lib/DBD/sponge.pm dans votre répertoire
d’installation de Perl et remplacez
my $numFields;
if ($attribs->{’NUM_OF_FIELDS’}) {
$numFields = $attribs->{’NUM_OF_FIELDS’};
} elsif ($attribs->{’NAME’}) {
$numFields = @{$attribs->{NAME}};
par
my $numFields;
if ($attribs->{’NUM_OF_FIELDS’}) {
$numFields = $attribs->{’NUM_OF_FIELDS’};
} elsif ($attribs->{’NAMES’}) {
$numFields = @{$attribs->{NAMES}};
(notez le S ajouté à NAME).
4.5.3. "cannot chdir(/var/spool/mqueue)" (impossible de faire
chdir...)
Si vous installez Bugzilla sur SuSE Linux, ou sur une autre distribution avec des options de sécurité “paranoïdes”, le
script checksetup.pl peut se bloquer avec l’erreur suivante :
cannot chdir(/var/spool/mqueue): Permission denied
Cette erreur se produit parce que votre répertoire /var/spool/mqueue a des permissions insuffisantes : “drwx------”.
Exécutez la commande suivante sous root pour régler le problème : chmod 755 /var/spool/mqueue
4.5.4. "Your vendor has not defined Fcntl macro O_NOINHERIT"
(votre revendeur n’a pas défini ...)
Cette erreur est provoquée par un bogue dans la version de File::Temp distribuée avec Perl 5.6.0. De nombreuses
variantes de cette erreur légèrement différentes ont été signalées. On peut en trouver des exemples : Figure 4-1.
31
Figure 4-1. D’autres message d’erreur File::Temp
Your vendor has not defined Fcntl macro O_NOINHERIT, used
at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 208.
Your vendor has not defined Fcntl macro O_EXLOCK, used
Your vendor has not defined Fcntl macro O_TEMPORARY, used
Beaucoup d’utilisateurs ont signalé qu’une mise à niveau vers la version 5.6.1 et suivant a réglé leur problème. Une
solution moins définitive consiste à appliquer la rustine décrite dans Figure 4-2. Cette rustine est aussi disponible sous
la forme d’un fichier patch (../xml/filetemp.patch).
Figure 4-2. Rustine pour for File::Temp dans Perl 5.6.0
--- File/Temp.pm.orig
Thu Feb 6 16:26:00 2003
+++ File/Temp.pm
Thu Feb 6 16:26:23 2003
@@ -205,6 +205,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+
local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};
@@ -226,6 +227,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+
local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};
32
Chapter 5. Administrer Bugzilla
5.1. Configuration de Bugzilla
Pour configurer Bugzilla, il faut changer différents paramètres accessibles à partir du lien "Edit parameters" au bas
de la page. Voici quelques-uns des paramètres importants de cette page. Il faut parcourir cette liste et les remplir
correctement après l’installation de Bugzilla.
1.
maintainer: Le paramètre "maintainer" est l’adresse électronique de la personne chargée de maintenir cette
installation Bugzilla. Il n’est pas nécessaire que l’adresse soit celle d’un compte Bugzilla valide.
2.
urlbase: Ce paramètre indique à votre installation Bugzilla le nom de domaine entier et le chemin du serveur
web.
Par exemple, si votre page de requête Bugzilla est http://www.foo.com/bugzilla/query.cgi, fixez votre
paramètre “urlbase” à http://www.foo.com/bugz/.
3.
usebuggroups: C’est de ceci que dépend l’application ou non d’une sécurité de groupe pour Bugzilla. S’il a été
instauré, on peut associer un groupe à un bogue de Bugzilla, ce qui définit les utilisateurs qui sont autorisés à voir
et éditer un bogue.
Mettez le paramètre "usebuggroups" sur "on" seulement si vous souhaitez limiter l’accès à des bogues particuliers
à certains groupes d’utilisateurs. Je suggère de laisser le paramètre sur "off" pendant le test initial de Bugzilla.
4.
usebuggroupsentry: Les produits Bugzilla peuvent être associés à un groupe, de telle façon que certains utilisateurs ne puissent voir que les bogues de certains produits. Quand ce paramètre est mis sur “"on"”, les nouveaux
bogues d’un produit sont immédiatement placés dans le groupe associé.
5.
shadowdb: Un problème intéressant se pose quand Bugzilla atteint un niveau élevé d’activité en continu. MySQL
ne supporte que le verrouillage en écriture au niveau des tables. Cela signifie que, si quelqu’un doit apporter une
modification à un bogue, il devra verrouiller la table tout entière jusqu’à la fin de l’opération. Le verrouillage en
écriture bloque également la lecture jusqu’à ce que l’écriture soit terminée. Le paramètre “shadowdb” a été conçu
pour contourner cette restriction. Alors qu’un seul utilisateur à la fois est autorisé à écrire sur une table, on peut
continuer à lire sans problème sur une copie fantôme de la base de données ouverte uniquement en lecture. Bien
que la taille de la base de données soit doublée, une base de données fantôme peut provoquer une amélioration
importante des performances quand elle est implantée sur des bases de données de Bugzilla au trafic extrèmement
élevé.
A titre indicatif, mozilla.org a commencé à avoir besoin de “shadowdb” quand ils ont atteint environ 40000
utilisateurs de Bugzilla avec plusieurs centaines de modifications et de commentaires sur les bogues de Bugzilla
par jour.
La valeur du paramètre définit le nom de la base de données fantôme contenant les bogues. Fixez "shadowdb" à,
par exemple, "bug_shadowdb" si vous comptez lancer une très grosse installation de Bugzilla.
Note: Activer "shadowdb" peut avoir de sérieuses répercussions sur la stabilité de votre installation Bugzilla.
Il faut vérifier régulièrement que votre base de données est synchronisée. Il est souvent prudent de forcer
une synchronisation de la base de données fantôme toutes les nuits via “cron”.
33
Si vous utilisez l’option "shadowdb", il va de soi qu’il faut activer l’option "queryagainstshadowdb" également.
Sinon, vous dupliquez des données dans une base de données fantôme sans aucune raison!
6.
shutdownhtml: Si vous devez éteindre Bugzilla pour des tâches d’administration, tapez ici une description
en langage HTML et chaque personne qui essayera d’utiliser Bugzilla recevra cette page HTML. Evidemment,
editparams.cgi sera encore accessible de sorte que vous puissiez enlever le HTML et réactiver Bugzilla. :-)
7.
passwordmail: Chaque fois qu’un utilisateur crée un compte, le contenu de ce paramètre (avec des adaptations)
ainsi que son mot de passe lui est envoyé.
Ajouter le texte que vous souhaitez dans le champ du paramètre "passwordmail". Par exemple, beaucoup de
personnes utilisent ce champ pour donner de rapides indications sur la façon d’utiliser Bugzilla sur leur site.
8.
useqacontact: Ceci vous permet de définir une adresse électronique pour chaque composant, en plus de celle du
propriétaire par défaut, à qui seront envoyées des copies des nouveaux bogues.
9.
usestatuswhiteboard: Ceci indique si vous souhaitez un champ réinscriptible de forme libre associé à chaque
bogue. L’avantage du "Status Whiteboard" est qu’il peut être supprimé ou modifié aisément, et qu’il fournit un
champ interrogeable facilement pour l’indexation des bogues qui ont des traits en commun.
10. whinedays: Fixez ce paramètre au nombre de jours que vous souhaitez laisser les bogues à l’état "NEW" ou
"REOPENED" avant de signaler aux personnes concernées qu’elles n’ont pas traité de nouveaux bogues. Si vous
ne pensez pas utiliser cette fonctionnalité, il suffit tout simplement de ne pas installer la fonction cron de rappel
(“whining cron”) comme cela est décrit dans les instructions d’installation, ou de fixer la valeur à "0" (aucun
rappel).
11. commenton*: Tous ces champs vous permettent de signaler quelles modifications ne nécessitent pas de commentaires et celles qui doivent être commentées par leur auteur. Souvent, les administrateurs autorisent les utilisateurs
à s’ajouter eux-mêmes à la liste des copies, à accepter des bogues, ou à changer le "Status Whiteboard" sans
ajouter de commentaires sur les raisons du changement, et exigent cependant que la plupart des autres changements soient accompagnés d’une explication.
Remplissez les options "commenton" conformément à la politique de votre site. Au minimum, il est bon de
demander des commentaires quand les utilisateurs résolvent, réassignent ou rouvrent des bogues.
Note: Il est généralement préférable de demander le commentaire du développeur quand il résout un bogue.
Il n’y pas grand chose de plus agaçant pour les utilisateurs de base de données de bogues que de rencontrer
un bogue marqué comme "fixed" par un développeur sans aucun commentaire sur la nature de la réparation
(ou même pour indiquer qu’il a vraiment été réparé!).
12. supportwatchers: Activer cette option permet aux utilisateurs de demander à recevoir des copies de tous les
messages électroniques concernant un bogue particulier d’un autre utilisateur. Ceci est, bien-sûr, soumis aux
restrictions de groupe sur ce bogue ; si “l’observateur” n’est normalement pas autorisé à voir un bogue, il ne
peut pas contourner le système en se permettant d’étudier des bogues qui ne correspondent pas à ses droits. Les
utilisateurs ne recevront par message électronique que les mises-à-jour qui concernent les bogues qu’ils peuvent
normalement voir.
34
5.2. Administration des utilisateurs
5.2.1. Créer l’utilisateur par défaut
Quand vous lancez pour la première fois checksetup.pl après l’installation de Bugzilla, on vous demandera le nom
de l’administrateur (adresse électronique) et le mot de passe de ce "super utilisateur". Si pour une raison quelconque
vous supprimez ce compte , relancez checksetup.pl et on vous redemandera le nom d’utilisateur et le mot de passe de
l’administrateur.
Tip: Si vous souhaitez ajouter d’autres administrateurs, vous devez utiliser l’interface de MySQL. Lancez "mysql"
en ligne de commande et utiliser ces commandes:
mysql> use bugs;
mysql> update profiles set groupset=0x7fffffffffffffff where login_name = "(user’s login name)";
Oui, ce sont bien quinze “f” . Il faut taper une longue suite de f si vous voulez créer un nouvel administrateur.
5.2.2. Gérer les autres utilisateurs
5.2.2.1. Créer de nouveaux utilisateurs
Vos utilisateurs peuvent créer leurs propres comptes utilisateur en cliquant sur le lien "New account" situé en bas de
chaque page (en supposant qu’ils n’aient pas déjà ouvert une autre session sous un autre nom). Toutefois, si vous
souhaitez créer les comptes utilisateur à l’avance, voici comment faire.
1. Après avoir ouvert votre session, cliquez sur le lien "Users" situé en bas de page de requête, puis sur le lien "Add
a new user".
2. Remplissez le formulaire. Cette page est toute simple. Une fois que cela est fait, cliquez sur "Submit".
Note: En ajoutant un utilisateur de cette façon, aucun message électronique ne lui sera envoyé pour l’informer
de son nom d’utilisateur et de son mot de passe. Bien que cela soit utile pour créer des comptes factices (par
exemple, des observateurs qui transmettent et reçoivent des messages électroniques à un autre système,
ou des adresses électroniques qui font partie d’une liste de diffusion), il est, en général, préférable de fermer
sa session et d’utiliser le bouton “New account” pour créer des utilisateurs, car tous les champs obligatoires
seront pré-remplis et l’utilisateur sera également informé du nom de son compte et de son mot de passe.
5.2.2.2. Modifier les utilisateurs
Pour voir un utilisateur particulier, recherchez-le en tapant son nom d’utilisateur dans la case prévue sur la page "Edit
Users". Pour voir tous les utilisateurs, laissez la case vide.
35
Vous pouvez effectuer des recherches de différentes façons grâce à la liste déroulante située à droite de la zone de
texte. Vous pouvez rechercher à partir d’une sous-chaîne (par défaut sans tenir compte de la casse), d’une expression
régulière ou d’une expression régulière inverse, qui trouve tous les utilisateurs qui ne correspondent pas à l’expression
régulière (Veuillez vous reporter au manuel issu de la commande man regexp pour des informations sur la syntaxe
des expressions régulières).
Une fois que vous avez trouvé votre utilisateur, vous pouvez changer les champs suivants :
•
Login Name: En général, c’est l’adresse électronique entière de l’utilisateur. Toutefois, si vous utilisez le paramètre
"emailsuffix", ce champ peut contenir uniquement le nom d’utilisateur. On peut noter que les utilisateurs peuvent
désormais changer leur nom d’utilisateur eux-mêmes (en le remplaçant par une adresse électronique valide).
•
Real Name: C’est le nom réel de l’utilisateur. On peut noter que Bugzilla n’exige pas cette information pour créer
un compte.
•
Password: Vous pouvez changer le mot de passe utilisateur ici. Les utilisateurs peuvent demander un nouveau mot
de passe automatiquement, vous ne devriez donc pas avoir à le faire souvent. Si vous voulez désactiver un compte,
reportez-vous à la description de "Disable Text" ci-dessous.
•
Disable Text: Si vous entrez quelque chose dans cette case, y compris rien qu’un espace, vous empêchez l’utilisateur
d’ouvrir sa session, ou d’apporter des modifications à des bogues via l’interface internet. Le code HTML que vous
tapez dans cette case est affiché à l’utilisateur quand il essaye d’effectuer une de ces actions. Il est conseillé d’y
expliquer pourquoi le compte a été désactivé.
Warning
Ne désactivez pas le compte administrateur !
Note: L’utilisateur peut toujours soumettre des bogues via le portail de messages électroniques, si vous l’activez,
même si le champ Disable Text n’est pas vide. Il est conseillé de ne pas activer le portail de messages électroniques pour les installations sécurisées de Bugzilla.
•
<groupname>: Si vous avez créé des groupes, comme "securitysensitive", alors des cases apparaîtront ici pour vous
permettre d’ajouter ou de supprimer des utilisateurs à ces groupes.
•
canconfirm: Ce champ n’est utilisé que si vous avez autorisé l’état "unconfirmed". Si vous activé ce champ pour
un utilisateur, celui-ci pourra alors passer des bogues de l’état "Unconfirmed" à un état "Confirmed" (par exemple
: l’état "New").
•
creategroups: Cette option permet à un utilisateur de créer et détruire des groupes dans Bugzilla.
•
editbugs: Sauf si ce champ activé, les utilisateurs peuvent seulement éditer les bogues dont ils sont responsables
ou qu’ils ont signalés. Même si l’option n’est pas sélectionnée, les utilisateurs peuvent tout de même ajouter des
commentaires à des bogues.
•
editcomponents: Cette option permet à un utilisateur de créer de nouveaux produits et composants, ainsi que de
modifier et supprimer ceux auxquels aucun bogue n’est associé. Si un produit ou un composant a des bogues qui
lui sont associés, ces bogues doivent être affectés à un autre produit ou composant pour que Bugzilla permette sa
suppression.
36
•
editkeywords: Si vous utilisez la fonctionnalité de mot-clé de Bugzilla, activer cette option permet à un utilisateur
de créer et détruire des mots-clé. Comme toujours, les mots-clé pour des bogues existants contenant le mot-clé que
l’utilisateur veut détruire doivent être modifiés pour que Bugzilla autorise sa suppression.
•
editusers: Cette option permet à un utilisateur de faire ce que vous faîtes en ce moment : éditer d’autres utilisateurs.
Cela permettra à ceux qui ont le droit de le faire de supprimer les droits administrateur d’autres utilisateurs ou de
se les accorder. A activer avec précaution.
•
tweakparams: Cette option permet à un utilisateur de changer les paramètres de Bugzilla (en utilisant
editparams.cgi).
•
<productname>: Ceci permet à un administrateur de spécifier les produits au sein desquels un utilisateur pourra
voir des bogues. L’utilisateur devra quand même avoir le droit "editbugs" pour éditer les bogues dans ces produits.
5.3. Produit, composant, jalon ["Milestone"], et
administration de version
5.3.1. Les produits
Les produits sont la plus large catégorie dans Bugzilla, et représentent quasiment les produits réels embarqués.
Par exemple, si votre entreprise conçoit des jeux video, vous devriez avoir un produit par jeu, peut-être un produit
"commun" pour les technologies utilisés dans de nombreux jeux, et peut-être quelques produits spéciaux (Site Internet,
Administration,...)
Beaucoup des réglages de Bugzilla sont configurables pour un produit donné. Le nombre de "votes" disponibles par
utilisateur est fixé pour un produit donné, tout comme le nombre de votes nécessaire pour faire passer un bogue
automatiquement de l’état UNCONFIRMED à l’état NEW.
Pour créer un nouveau produit :
1. Sélectionnez "products" en bas de page
2. Sélectionnez le lien "Add" en bas à droite
3. Entrez le nom du produit et une description. Il est possible de remplir le champ Description en HTML.
Ne vous inquiétez pas des options "Closed for bug entry", "Maximum Votes per person", "Maximum votes a person
can put on a single bug", "Number of votes a bug in this Product needs to automatically get out of the UNCOMFIRMED state", et "Version" pour le moment. Nous allons les aborder dans quelques instants.
5.3.2. Les composants
Les composants sont des sous-sections des produits. Par exemple, le jeu video que vous développez peut avoir un
composant IHM ["UI"], un composant "API", un composant "Sound System" et un composant "Plugins", chacun
étant surveillé par un programmeur différent. Il est souvent pratique de séparer les composants dans Bugzilla en
suivant les séparations naturelles des responsabilités au sein du produit ou de votre entreprise.
37
Chaque composant a un propriétaire et un contact QA (si vous l’activez dans les paramètres). Il est préférable que le
propriétaire d’un composant soit la première personne qui répare des bogues dans ce composant. Il est conseillé que
le contact QA soit la personne qui s’assurera que ces bogues sont complètement réparés. Le propriétaire, le contact
QA et celui qui a signalé le bogue recevront un message électronique quand de nouveaux bogues seront créés dans
ce composant et quand ces bogues seront modifiés. Les champs Default Owner et QA contact indique seulement les
affectations par défaut; celles-ci peuvent être modifiées lors de la soumission d’un bogue, ou à n’importe quel moment
de la vie du bogue.
Pour créer un nouveau composant:
1. Sélectionnez le lien "Edit components" dans la page "Edit product".
2. Sélectionnez le lien "Add" en bas à droite.
3. Remplissez le champ "Component", une courte "Description", les champs "Initial Owner" et "Initial QA Contact"
(s’ils sont activés). Il est possible de remplir les champs Component et Description en HTML; Vous devez remplir
le champ "Initial Owner" avec un nom d’utilisateur déjà présent dans la base de données.
5.3.3. Les versions
Les versions sont les révisions d’un produit, comme "Flinders 3.1", "Flinders 95", et "Flinders 2000". La version n’est
pas un champ à plusieurs choix; en général, on choisit la plus récente version du bogue.
Pour créer et éditer des versions:
1. Sélectionnez le lien "Edit Versions" à partir de la page "Edit product"
2. Vous pourrez remarquer que le produit a déjà par défaut la version "undefined". Cliquez sur le lien "Add" en bas
à droite.
3. Entrez le nom de la version. Ce champ ne peut contenir que du texte. Ensuite, cliquez sur le bouton "Add".
5.3.4. Jalons
Les jalons sont des "cibles" pour lesquelles vous projetez qu’un bogue sera réparé. Par exemple, si vous avez un bogue
que vous projetez de réparer pour la version 3.0, vous lui affecterez le jalon 3.0.
Note: Les options des jalons apparaissent seulement pour un produit si vous activez le paramètre "usetargetmilestone" dans la page "Edit Parameters".
Pour créer de nouveaux jalons, définir les jalons par défaut et fixer l’URL des jalons:
1. Sélectionnez "Edit milestones" dans la page "Edit product".
2. Sélectionnez "Add" dans le coin inférieur droit.
3. Entrez le nom du jalon dans le champ "Milestone". En option, vous pouvez fixer le "sortkey", qui est un nombre
positif ou négatif (-255 à 255) qui définit où ce point clé apparaîtra dans la liste. En effet, les jalons ne se
38
présentent pas souvent dans l’ordre alphanumérique. Par exemple, on peut trouver "Future" après "Release 1.2".
Sélectionnez "Add".
4. Dans la page Edit product, vous pouvez entrer l’URL d’une page qui donne des informations à propos de vos
jalons et de ce qu’ils signifient.
Tip: Si vous souhaitez que l’accès à votre document de jalons soit restreint de façon à ce qu’il ne puisse être
vu que par des personnes d’un groupe Bugzilla particulier, la meilleure solution est de lier le document à un
bogue de ce groupe et mettre comme URL l’URL de ce lien.
5.4. Le vote
Le vote permet aux utilisateurs de disposer d’un certain nombre de votes qu’ils peuvent affecter à des bogues, pour
indiquer qu’ils souhaitent que ces bogues soient réparés. Cela permet aux développeurs d’évaluer les besoins utilisateurs pour une amélioration ou une réparation particulière. En permettant que les bogues avec un certain nombre
de votes puissent passer automatiquement de "UNCONFIRMED" à "NEW", les utilisateurs du système de bogues
peuvent aider les bogues de priorité élevée à capter l’attention de façon à ce qu’ils ne restent pas trop longtemps à
attendre le triage.
Pour modifier les paramètres de vote:
1. Naviguez jusqu’à la page "Edit product" du produit que vous voulez modifier.
2. Maximum Votes per person: Mettre ce champ à 0 désactive le vote.
3. Maximum Votes a person can put on a single bug: A l’évidence, cela doit être un nombre inférieur au nombre
inscrit dans le champ "Maximum votes per person". Ne mettez pas ce champ à 0 si "Maximum votes per person"
n’est pas à 0; cela n’a pas de sens.
4. Number of votes a bug in this product needs to automatically get out of the UNCONFIRMED state: Mettre ce
champ à "0" désactive le passage automatique des bogues de UNCONFIRMED à NEW.
5. Une fois que vous avez ajusté les valeurs selon vos préférences, cliquez sur "Update".
5.5. Groupes et sécurité de groupes
Les groupes permettent à l’administrateur d’isoler des bogues ou des produits qui ne doivent être vus que par certaines
personnes. Il y a deux types de groupes - les groupes génériques ["Generic Groups"] et les groupes basés sur les
produits ["Product-Based Groups"].
Les groupes basés sur les produits sont liés à des produits et vous permettent de limiter l’accès aux bogues de ces
produits. Ils sont activés en utilisant le paramètre usebuggroups. Activer le paramètre usebuggroupsentry implique
que les bogues sont automatiquement ajoutés au groupe de leur produit quand ils sont classés.
Les groupes génériques n’ont pas de lien particulier avec les produits; vous les créez, et leur ajoutez des bogues
comme vous le souhaitez. Un exemple de l’utilisation des groupes génériques est le groupe "Security" de Mozilla,
39
dans lequel sont placés les bogues sensibles en termes de sécurité jusqu’à ce qu’ils soient réparés. Seuls les membres
de la Mozilla Security Team font partie de ce groupe.
Pour créer des groupes génériques :
1. Sélectionnez le lien "groups" au bas de la page.
2. Consacrez quelques minutes à la lecture des instructions sur la page "Edit Groups", et sélectionnez ensuite le lien
"Add Group".
3. Remplissez les champs "New Name", "New Description", et "New User RegExp". "New User RegExp" vous
permet de placer automatiquement dans le nouveau groupe tous les utilisateurs qui correspondent à l’expression
régulière ["Regular Expression"]. Quand vous avez terminé, cliquez sur "Add".
Pour utiliser les groupes basés sur les produits :
1. Activez "usebuggroups" et "usebuggroupsentry" dans la page "Edit Parameters".
Warning
XXX est-il encore valable ? "usebuggroupsentry" permet d’empêcher l’administrateur de modifier directement des bogues à cause de conflits au niveau des permissions de groupes. Si vous
prévoyez d’utiliser "usebuggroupsentry", il faut prévoir de limiter l’usage du compte administrateur
uniquement aux les tâches administratives. En d’autres termes, gérez les bogues avec un compte
utilisateur sans droits particuliers et gérez les utilisateurs, groupes, produits, etc. avec le compte
administrateur.
2. Par la suite, quand vous créerez un produit, le groupe correspondant sera automatiquement créé. Si vous devez
créer un groupe de produit pour un produit qui a été créé avant l’activation de usebuggroups, alors créez simplement un nouveau groupe, comme cela est décrit plus haut, auquel vous donnerez le même nom que le produit.
Warning
Bugzilla est actuellement limité à 64 groupes par installation. Si vous avez plus de 50 produits environ, il
faut envisager de lancer plusieurs Bugzilla. Demandez dans le forum d’autres suggestions pour contourner
cette limite.
Notez que les permissions de groupe sont telles que vous devez être membre de tous les groupes dans lesquels se
trouve un bogue, quelque soit la raison, pour voir ce bogue.
40
5.6. Sécurité Bugzilla
Warning
Les installations de MySQL et Bugzilla dont la configuration était médiocre ont donné aux pirates informatiques l’accès complet à des systèmes par le passé. Veuillez prendre ces instructions au sérieux, même
pour les machines Bugzilla bien cachées derrière un coupe-feu. 80% des intrus proviennent de l’intérieur,
et ne sont pas des pirates informatiques anonymes.
Note: Ces intructions doivent forcément être plus ou moins vagues puisque Bugzilla fonctionne sur de nombreuses plateformes différentes. Si vous avez des améliorations à apporter à ces directives, veuillez soumettre
un bug à Bugzilla (http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation).
Warning
Ceci ne se veut pas une liste complète de tous les problèmes de sécurité possibles concernant les outils
mentionnés dans cette partie. Rien ne remplace la lecture des informations écrites par les auteurs des
logiciels qui fonctionnent sur votre système.
5.6.1. Ports TCP/IP
TCP/IP définit quelque chose comme 65000 ports pour le trafic. Parmi ceux-là, Bugzilla n’en a besoin que d’1... 2
si vous devez utiliser des éléments qui nécessitent les messages électroniques comme le déplacement de bogues ou
l’interface de messages électroniques. Vous devriez vérifier votre serveur et vous assurer qu’il n’est pas à l’écoute sur
des ports dont vous n’avez pas besoin. Vous pourriez aussi utiliser quelque chose du genre logiciel coupe-feu pour
être sûr que le trafic peut seulement être reçu sur les ports que vous avez choisis.
5.6.2. MySQL
MySQL est livré par défaut avec de nombreux paramètres qui doivent être changés. Par défaut, il permet à n’importe
qui de se connecter à partir de la machine hôte sans mot de passe et d’avoir tous les privilèges administratifs. Il ne fixe
pas non plus par défaut le mot de passe administrateur (ce n’est pas le même que l’administrateur système). De plus,
de nombreuses installations lancent par défaut mysqld en tant qu’administrateur système.
1. Assurez-vous que vous utilisez au moins la version 3.22.32 de MySQL parce que les versions plus anciennes
présentent d’importants trous de sécurité.
2. Reportez-vous à la documentation qui est fournie avec votre système pour trouver les informations permettant de
lancer mysqld en tant qu’utilisateur sans droits.
3. Il faut aussi être sûr d’avoir désactivé le compte utilisateur anonyme et d’avoir fixé un mot de passe pour
l’administrateur. Ca se fait en utilisant les commandes suivantes :
bash$ mysql mysql
mysql> DELETE FROM user WHERE user = ”;
mysql> UPDATE user SET password = password(’new_password’) WHERE user = ’root’;
41
Ensuite, quand vous utiliserez le client mysql, vous devrez utiliser mysql -u root -p et entrer
nouveau_mot_de_passe quand cela est demandé.
4. Si vous utilisez MySQL sur la même machine que votre serveur httpd, il faudrait penser à désactiver la communication en réseau à partir de MySQL en ajoutant ce qui suit à votre /etc/my.conf :
[myslqd]
# Prevent network access to MySQL.
skip-networking
5. Vous aurez peut-être aussi envie de lancer MySQL, ou même tous les éléments de Bugzilla dans un environnement
d’exécution restreint ["chroot jail"] ; toutefois, les instructions pour le faire n’entrent pas dans le cadre de ce
document.
5.6.3. Comptes démons
De nombreux démons, comme le httpd de Apache ou le mysqld de MySQL sont exécutés par défaut soit en tant que
“root” soit en tant que “nobody”. L’exécution en tant que “root” crée des prolèmes de sécurité évidents, mais les
problèmes créés en exécutant tout en tant que “nobody” ne semblent pas être aussi gênants. En gros, si vous exécutez
tous les démons en tant que “nobody” et que l’un d’entre eux est compromis, ils sont tous compromis. Pour cette
raison, il est recommandé de créer un compte utilisateur pour chaque démon.
Note: Vous devrez fixer le webservergroup sur le groupe que vous avez créé pour le serveur Web pour l’exécuter
comme cela est défini dans le localconfig. Cela permettra à ./checksetup.pl de mieux ajuster les permissions
des fichiers de votre installation Bugzilla afin de ne pas avoir besoin de mettre les droits en écriture à tout le
monde sur quoi que ce soit.
5.6.4. Contrôles d’accès au serveur Web
Il y a beaucoup de fichiers qui sont placés dans la zone de répertoires de Bugzilla qui ne devraient pas être accessibles à partir d’Internet. A cause de la façon dont Bugzilla est actuellement disposé, la liste de ce qui devrait et
de ce qui ne devrait pas être accessible est assez longue. Une nouvelle méthode d’installation est actuellement en
cours de réalisation et devrait résoudre cela en permettant que les fichiers qui ne devraient pas être accessibles à
partir d’Internet soient placés dans un répertoire à l’extérieur de la racine Internet. Reportez vous au bogue 44659
(http://bugzilla.mozilla.org/show_bug.cgi?id=44659) pour plus d’informations.
•
Dans le répertoire principal de Bugzilla, il faudrait :
• Bloquer : *.pl, *localconfig*, runtests.sh, processmail, syncshadowdb
• Mais rendre accessible : localconfig.js, localconfig.rdf
42
•
Dans data :
• Bloquer tout
• Mais rendre accessible : duplicates.rdf
•
Dans data/webdot :
• Si vous utilisez un serveur webdot distant :
• Bloquer tout
• Mais rendre accessible *.dot seulement pour le serveur webdot distant
•
Dans le cas contraire, si vous utilisez un GraphViz local :
• Bloquer tout
• Mais rendre accessible : *.png, *.gif, *.jpg, *.map
•
Et si vous n’utilisez aucun fichier dot :
• Bloquer tout
•
Dans Bugzilla :
• Bloquer tout
•
Dans template :
• Bloquer tout
Tip: A l’état brut, Bugzilla a la possibilité de générer des fichiers .htaccess précisant à Apache quels fichiers
doivent être accessibles ou non.
Vous devriez faire des tests pour vous assurer que les fichiers cités ci-dessus ne sont pas accessibles à partir d’Internet,
particulièrement le fichier localconfig qui contient votre mot de passe pour la base de données. Pour tester, faîtes
simplement pointer votre navigateur Web vers le fichier ; par exemple, pour tester l’installation de mozilla.org, il faut
essayer d’accéder à http://bugzilla.mozilla.org/localconfig. Vous devriez obtenir une erreur 403 Forbidden.
Caution
Ne pas suivre les instructions de cette partie, y compris ne pas faire le test, peut avoir pour conséquence
de rendre accessibles au niveau mondial des informations sensibles.
43
5.7. Personnalisation des modèles ["Template
Customisation"]
L’une des évolutions importantes de la 2.16 a été l’utilisation de modèles pour toute l’interface côté utilisateur, en se
servant de la Template Toolkit (http://www.template-toolkit.org). Les administrateurs peuvent maintenant configurer
l’aspect et la convivialité de Bugzilla sans avoir à éditer des fichiers Perl ou à être confrontés au cauchemar des conflits
massifs de fusion quand ils mettront à niveau avec une version plus récente à l’avenir.
L’utilisation de modèles rend également possible, pour la première fois, les versions de Bugzilla adaptées selon la
région. A l’avenir, une installation Bugzilla pourra avoir des modèles installés pour différentes régions, et sélectionner
lesquels utiliser en se basant sur la langue choisie dans le navigateur de l’utilisateur.
5.7.1. Ce qu’il faut éditer
Il y a deux façons différentes d’éditer des modèles de Bugzilla, et celle que vous utilisez dépend principalement de la
manière dont vous mettez à jour Bugzilla. L’arborescence de répertoires des modèles est composée d’un répertoire de
haut niveau template, qui contient un répertoire pour chaque région installée. Les modèles par défaut pour l’anglais
sont par conséquent dans en. En dessous de ça, il y a un répertoire default et en option un répertoire custom. Le
répertoire default contient tous les modèles fournis avec Bugzilla, alors que le répertoire custom n’existe pas a
priori et doit être créé si vous souhaitez l’utiliser.
La première méthode pour personnaliser les modèles est de les éditer directement dans template/en/default.
C’est probablement la meilleure méthode pour de petites modifications si vous comptez utiliser la méthode de mise à
niveau par CVS, parce qu’alors, si vous exécutez un cvs update, toute correction dans un modèle s’intègrera automatiquement dans les versions que vous aurez modifiées.
Avec cette méthode, votre installation sera perdue si des conflits CVS surviennent.
L’autre méthode consiste à copier les modèles dans une arborescence de répertoires mirroir sous
template/en/custom. Les modèles dans ce répertoire annule automatiquement ceux par défaut. C’est la technique
que vous devez utiliser si vous utilisez la méthode de mise à niveau par réécriture, parce qu’autrement vos
modifications seront perdues. Cette méthode est également meilleure si vous utilisez la méthode de mise à niveau par
CVS et que vous comptez faire des modifications majeures, car il est garanti que le contenu de ce répertoire ne sera
pas touché au cours d’une mise à niveau, et vous pouvez alors décider soit de continuer en utilisant votre propre
modèle, soit de faire l’effort d’intégrer à la main vos modifications dans les nouvelles versions.
Avec cette méthode, votre installation peut être perdue si des modifications incompatibles sont faites à l’interface des
modèles. Si de telles modifications sont faites, elles seront détaillées dans la notice de la version, à condition que vous
utilisiez une version stable de Bugzilla. Si vous utilisez du code instable, vous devrez vous occuper de ça vous-même,
bien que, si possible, les modifications seront citées, avant qu’elles ne se produisent, dans la partie "A éviter" de la
notice de la précédente version stable.
Note: N’éditez pas directement dans data/template/* les modèles compilés - vos modifications seront perdues
quand Template Toolkit les recompilera.
Note: Il est recommandé d’exécuter ./checksetup.pl après toute édition de modèle, en particulier si vous avez
créé un nouveau fichier dans le répertoire custom.
44
5.7.2. Comment éditer des modèles
La syntaxe du langage de la Template Toolkit dépasse le cadre de ce guide. Elle est assez facile à comprendre en
regardant les modèles actuels ; ou, vous pouvez lire le manuel, disponible sur la page d’accueil de la Template Toolkit
(http://www.template-toolkit.org). Toutefois, il faut surtout se rappeler (pour des raisons de sécurité) de toujours filtrer
par rapport au langage HTML les données qui viennent de la base de données ou qui sont entrées par l’utilisateur, afin
d’éviter les attaques par scripts à l’intérieur du site.
Cependant, une chose à laquelle vous devriez apporter un soin particulier est la nécessité de filtrer correctement par
rapport au langage HTML les données qui ont été transmises dans le modèle. Cela signifie que si les données sont
susceptibles de contenir des caractères HTML spéciaux comme <, et que les données ne sont pas sensées être du
HTML, elles doivent être converties sous la forme d’entité, c’est-à-dire &lt ; on utilise le filtre ’html’ de la Template
Toolkit pour faire cela. Si vous ne le faîtes pas, vous pouvez exposer votre installation à des attaques par scripts à
l’intérieur du site.
Notez également que Bugzilla inclut de lui-même quelques filtres, qui ne sont pas dans la Template Toolkit standard.
En particulier, le filtre ’url_quote’ peut convertir les caractères qui sont illégaux ou qui ont un sens particulier dans les
URLs, comme &, en une forme encodée, c’est-à-dire %26. En fait, celui-ci encode la plupart des caractères (mais pas
les plus fréquents comme les lettres et les nombres etc.), y compris les caractères HTML spéciaux, de cette manière,
par la suite, vous n’avez jamais besoin de filtrer par rapport au langage HTML.
Editer des modèles est une bonne façon de faire les "champs personnalisés du pauvre". Par exemple, si vous n’utilisez
pas le Status Whiteboard, mais que vous souhaitez disposer d’une boîte d’entrée de texte de forme libre pour le "Build
Identifier", alors vous pouvez contenter d’éditer les modèles pour changer le nom des champs. Ca s’appellera toujours
status_whiteboard en interne, mais vos utilisateurs n’ont pas besoin de le savoir.
Note: Si vous apportez des modifications aux modèles que vous souhaitez voir incluses dans
le Bugzilla standard, il faut lire les parties correspondantes dans le guide des développeurs
(http://www.bugzilla.org/developerguide.html).
5.7.3. Formats des modèles
Certains CGIs sont capables d’utiliser plus d’un modèle. Par exemple, buglist.cgi peut générer des listes de bogues en
RDF ou en 2 formes différentes de HTML (complexe et simple). (Faîtes un essai en ajoutant &format=simple à une
URL de buglist.cgi sur votre installation Bugzilla.) Ce mécanisme, appelé modèle ’formats’, est extensible.
Pour savoir si un CGI supporte plusieurs formats de sortie, effectuez un grep sur le CGI de "ValidateOutputFormat".
S’il n’y en a pas, ajouter le support de plusieurs formats n’est pas trop dur - regardez comment c’est fait dans d’autres
CGIs.
Pour faire un nouveau modèle de format pour un CGI qui supporte ça, ouvrez un modèle actuel pour ce CGI et prenez
note du commentaire INTERFACE (s’il est présent). Ce commentaire définit les variables qui sont passées dans ce
modèle. S’il n’y en a pas, j’ai bien peur que vous deviez lire le modèle et le code pour voir ce que vous avez comme
informations.
Vous pouvez écrire votre modèle dans n’importe quel style de balisage ou de texte.
Votre modèle sera affiché en tant que quel type de contenu? A vous de choisir. Ouvrez le fichier localconfig et
trouvez la variable $contenttypes. Si votre type de contenu ne s’y trouve pas, ajoutez le. Mémorisez l’étiquette de
trois ou quatre lettres affecté à votre type de contenu. Cette étiquette fera partie du nom de fichier du modèle.
45
Enregistrez le modèle sous <stubname>-<formatname>.<contenttypetag>.tmpl. Testez le modèle en appelant
le CGI par <cginame>.cgi?format=<formatname>.
5.7.4. Modèles particuliers
Il y a quelques modèles qui pourraient vous intéresser tout particulièrement pour personnaliser votre installation.
index.html.tmpl : C’est la page d’accueil de Bugzilla.
global/header.html.tmpl : Il définit l’en-tête qui apparaît sur toutes les pages de Bugzilla. L’en-tête inclut la bannière,
qui est ce qui apparaît aux utilisateurs et qui est probablement ce que vous voulez éditer plutôt que l’en-tête. Cependant, l’en-tête inclut également la section HTML HEAD, vous pourriez donc par exemple ajouter une feuille de style
ou une balise META en éditant l’en-tête.
global/banner.html.tmpl : Il contient la "bannière", la partie de l’en-tête qui apparaît en haut de toutes les pages de
Bugzilla. La bannière par défaut est assez basique, vous voudrez donc probablement la personnaliser pour donner à
votre installation son propre aspect et sa propre convivialité. Il est recommandé de conserver le numéro de version
Bugzilla sous une forme qui permette de déterminer la version que vous utilisez, et que les utilisateurs sachent quelle
documentation ils doivent lire.
global/footer.html.tmpl : Il définit le pied de page qui apparaît sur toutes les pages de Bugzilla. En l’éditant, vous
avez un autre moyen de donner rapidement son propre aspect et sa propre convivialité à votre installation Bugzilla.
bug/create/user-message.html.tmpl : C’est un message qui apparaît près du haut de la page de soumission de bogues.
En le modifiant, vous pouvez dire à vos utilisateurs comment soumettre des bogues.
bug/create/create.html.tmpl and bug/create/comment.txt.tmpl : Vous souhaitez peut être que ceux qui soumettent
des bogues donnent certains fragments d’information structurée, chacun dans un objet graphique d’entrée différent,
pour lequel il n’y a pas de champs dans la base de données. Le système d’entrée de bogues a été conçu sous une forme
extensible pour vous permettre de définir arbitrairement des champs et des objets graphiques, et que leurs valeurs apparaissent formatées dans la description initiale, plutôt que dans les champs de la base de données. Un exemple de cela est
le formulaire guidé de soumission de bogue de mozilla.org (http://bugzilla.mozilla.org/enter_bug.cgi?format=guided)
Pour que cela fonctionne, créez un modèle personnalisé pour enter_bug.cgi (le modèle par défaut, sur lequel
vous pouvez vous baser, est create.html.tmpl), et soit vous l’appelez create.html.tmpl soit vous utilisez un
format et l’appelez create-<formatname>.html.tmpl. Mettez-le dans le répertoire custom/bug/create. Dans
celui-ci, ajoutez un objet graphique pour chaque fragment d’information que vous voulez qu’on récupère - comme un
numéro de produit, ou un ensemble d’étapes à reproduire.
Ensuite, créer un modèle comme custom/bug/create/comment.txt.tmpl, également suffixé par votre format
si vous en utilisez un, qui référence les champs de formulaire que vous avez créés. Quand un rapport de bogue est
soumis, le commentaire initial lié au rapport de bogue sera formaté conformément à la disposition de ce modèle.
Par exemple, si votre modèle enter_bug possèdait un champ
<input type="text" name="buildid" size="30">
et que votre comment.txt.tmpl avait
BuildID: [% form.buildid %]
alors
BuildID: 20020303
46
apparaîtrait dans le commentaire initial d’enregistrement.
5.8. Mettre à jour avec les nouvelles versions
Mettre à niveau Bugzilla est quelque chose que nous voulons tous faire de temps en temps, pour avoir de nouvelles
fonctionnalités ou pour obtenir les dernières corrections pour la sécurité. La facilité de mise à jour dépend de quelques
facteurs.
•
Si la nouvelle version est une révision ou une nouvelle version intermédiaire
•
Combien de modifications locales ont été faites, s’il y en a
Il y a également 3 méthodes pour mettre à niveau votre installation.
1. En utilisant CVS (Example 5-1)
2. En téléchargeant une nouvelle archive "tar" (Example 5-2)
3. En appliquant les programmes de correction appropriés (Example 5-3)
Les options qui s’offrent à vous dépendent de la taille du saut que vous êtes en train de faire et/ou de votre configuration
réseau.
Les révisions sont normalement distribuées pour réparer des failles de sécurité et sont différenciées par le passage du
troisième chiffre au chiffre supérieur. Par exemple, quand la 2.16.2 a été distribuée, c’était une révision de la 2.16.1.
Les versions intermédiaires sont normalement distribuées quand l’équipe Bugzilla estime qu’un certain nombre
d’avancées ont été faites depuis la dernière version intermédiaire. Celles-ci sont souvent précédées par une période de
stabilisation et par des versions précommerciales, cependant l’utilisation des versions de développement ou des versions précommerciales dépasse le cadre de ce document. Les versions intermédiaires sont différenciées par le passage
du deuxième chiffre, ou version mineure, au chiffre supérieur. Par exemple, la 2.16.2 est une version intermédiaire
plus récente que la 2.14.5.
Les exemples de cette partie sont écrits comme si vous mettiez à jour à la version 2.16.2. Les procédures sont les
mêmes que vous mettiez à jour à une nouvelle version intermédiaire ou à une nouvelle révision. Toutefois, la probabilité d’avoir des problèmes augmente quand vous mettez à niveau avec une nouvelle version intermédiaire, surtout si
vous avez fait des modifications locales.
Ces exemples supposent également que votre installation Bugzilla est dans /var/www/html/bugzilla. Si ce n’est
pas le cas, remplacez les chemins appropriés là où cela est nécessaire.
Example 5-1. Mise à niveau avec CVS
Chaque version de Bugzilla, que ce soit une révision ou une version intermédiaire, est étiquettée dans CVS. De plus,
chaque archive "tar" que nous avons distribuée depuis la version 2.12 a été prévue pour utiliser CVS. Cependant, cela
implique que vous puissiez avoir accès à cvs-mirror.mozilla.org sur le port 2401.
Tip: Si vous pouvez le faire, mettre à jour avec CVS est probablement la méthode la plus simple, surtout si vous
avez beaucoup de modifications locales.
47
bash$ cd /var/www/html/bugzilla
bash$ cvs login
Logging in to :pserver:[email protected]:2401/cvsroot
CVS password: anonymous
bash$ cvs -q update -r BUGZILLA-2_16_2 -dP
P checksetup.pl
P collectstats.pl
P globals.pl
P docs/rel_notes.txt
P template/en/default/list/quips.html.tmpl
Caution
Si une ligne dans la sortie du cvs update commence par un C, cela représente un fichier avec des modifications locales que CVS n’a pas pu intégrer correctement. Vous devez résoudre ces conflits manuellement
pour que Bugzilla (au moins la partie de Bugzilla qui utilise ce fichier) soit utilisable.
Note: Vous devez également lancer ./checksetup.pl pour terminer votre mise à jour de Bugzilla
Example 5-2. Mise à niveau avec l’archive "tar"
Si vous ne pouvez ou ne voulez pas utiliser CVS, une alternative toujours disponible est de télécharger la dernière
archive "tar". C’est la solution la plus difficile à utiliser, surtout si vous avez des modifications locales.
bash$ cd /var/www/html
bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.2.tar.gz
Output omitted
bash$ tar xzvf bugzilla-2.16.2.tar.gz
bugzilla-2.16.2/
bugzilla-2.16.2/.cvsignore
bugzilla-2.16.2/1x1.gif
Output truncated
bash$ cd bugzilla-2.16.2
bash$ cp ../bugzilla/localconfig* .
bash$ cp -r ../bugzilla/data .
bash$ cd ..
bash$ mv bugzilla bugzilla.old
bash$ mv bugzilla-2.16.2 bugzilla
bash$ cd bugzilla
bash$ ./checksetup.pl
Output omitted
48
Warning
Les commandes cp se terminent toutes les deux par un point ce qui est un détail très important, cela
informe l’interpréteur de commandes système que le répertoire de destination est le répertoire de travail
actuel. En outre, le point au début du ./checksetup.pl est important et ne doit pas être oublié.
Note: Vous devrez maintenant refaire manuellement toutes les modifications que vous aviez faites à votre installation locale.
Example 5-3. Mise à niveau avec les programmes de correction
Normalement, l’équipe Bugzilla fera un fichier de correction pour les révisions pour passer de la révision la plus
récente à la nouvelle. Vous pouvez également lire la notice et récupérer les programmes de correction associés au
bogue mentionné, mais il est plus sûr d’utiliser les fichiers de correction distribués car les programmes de correction
sont parfois modifiés avant d’être enregistrés (pour les corrections orthographiques mineures et le reste du même
acabit). Il est également possible théoriquement de chercher dans la liste des bogues réparés et de choisir quels
programmes de correction d’une version intermédiaire appliquer, mais ce n’est pas recommandé non plus puisque
votre Bugzilla deviendra un espèce de salmigondis qui ne correspond véritablement à aucune version. Cela le rendrait
aussi plus difficile à mettre à jour à l’avenir.
bash$ cd /var/www/html/bugzilla
bash$ wget ftp://ftp.mozilla.org/pub/webtools/bugzilla-2.16.1-to-2.16.2.diff.gz
Output omitted
bash$ gunzip bugzilla-2.16.1-to-2.16.2.diff.gz
bash$ patch -p1 < bugzilla-2.16.1-to-2.16.2.diff
patching file checksetup.pl
patching file collectstats.pl
patching file globals.pl
Caution
Si vous faîtes ça, méfiez-vous car cela ne modifie pas la totalité de votre répertoire CVS, cela peut donc
rendre les mises à jour par CVS plus difficiles par la suite.
49
5.9. Intégrer Bugzilla avec des outils Third-Party
5.9.1. Bonsai
Bonsai est un outil orienté web pour contrôler CVS, le système de gestion de versions et de concurrence. En utilisant
Bonsai, les administrateurs peuvent contrôler les états ouverts/fermés des arbres, interroger une base de données
relationnelle rapide principale pour le changement, relier, et commenter des informations, et voir les changements
effectués depuis la dernière fois que l’arbre a été fermé. Bonsai intègre également avec Tinderbox, le système de
gestion automatisé de construction de Mozilla.
5.9.2. CVS
L’intégration de CVS est mieux réalisée, en ce moment, en utilisant l’entrée Email de Bugzilla.
Suivez les instructions de ce guide pour permettre l’intégration des E-mail dans Bugzilla. Assurez-vous que vos scripts
d’inscription envoie un email à l’entrée E-mail de Bugzilla avec le sujet "[Bug XXXX]", et vous pouvez faire ajouter
des commentaires d’inscriptions CVS à votre bogue Bugzilla. Si vous voulez que le bogue se ferme automatiquement,
vous devrez modifier le scriptcontrib/bugzilla_email_append.pl.
Il y a également un projet CVSZilla, basé sur un code de Bugzilla qui date, pour intégrer CVS et Bugzilla grâce
aux capacités de CVS à envoyer des emails. Contrôlez-le à l’adresse : http://homepages.kcbbs.gen.nz/~tonyg/
(http://homepages.kcbbs.gen.nz/~tonyg/).
5.9.3. Perforce SCM
Vous pouvez trouver la page de projet pour l’intégration de Bugzilla et de Teamtrack Perforce (p4dti)
à l’adresse :
http://www.ravenbrook.com/project/p4dti (http://www.ravenbrook.com/project/p4dti/) .
“p4dti” est maintenant un produit officiellement supporté de Perforce, et vous pouvez trouver la page
p4dti "Perforce Public Depot" à l’adresse
http://public.perforce.com/public/perforce/p4dti/index.html
(http://public.perforce.com/public/perforce/p4dti/index.html) .
L’intégration de Perforce avec Bugzilla, une fois que les patches sont installés, se fait sans difficulté. Les informations
de réplication de Perforce apparaîtront au-dessous des commentaires de chaque bogue. Soyez certain que vous avez
un ensemble assorti de patches pour la version de Bugzilla que vous êtes en train d’installer. p4dti est conçu pour être
compatible avec les traqueurs à multiples défauts, et pour mettre à jour sa propre documentation dans ce but. Veuillez
consulter les pages en lien ci-dessus pour de plus amples informations.
5.9.4. Tinderbox/Tinderbox2
Nous avons besoin des informations d’intégration de Tinderbox.
50
Appendix A. La foire aux questions de Bugzilla
Cette FAQ contient des questions qui ne sont pas traitées ailleurs dans ce guide.
1. Questions générales
1.1. Où trouver des informations sur Bugzilla ?
Vous pouvez rester à jour grâce aux dernières informations concernant Bugzilla sur http://www.bugzilla.org/
(http://www.bugzilla.org/)
1.2. Sous quelle licence Bugzilla est-il distribué ?
Bugzilla est couvert par la Mozilla Public License. Pour plus de détails, voir http://www.mozilla.org/MPL/
(http://www.mozilla.org/MPL/)
1.3. Comment obtenir une assistance commerciale pour Bugzilla ?
http://bugzilla.org/consulting.html contient une liste de personnes et d’entreprises qui nous ont demandé de les
faire apparaître en tant que consultant pour Bugzilla.
www.collab.net (http://www.collab.net/) propose Bugzilla dans son offre destinée aux grands projets. Ils demandent une contrepartie financière qui reste assez élevée et ne sont généralement pas intéressés par des projets de
faible envergure.
On trouve plusieurs inconditionnels de Bugzilla expérimentés sur la liste de diffusion ou le forum et qui sont
disposés à rendre service en échange d’une généreuse indemnité. Essayez en envoyant un message à la liste de
diffusion pour rechercher un volontaire.
1.4. Quelles sont les entreprises ou les projets de grande envergure qui utilisent actuellement Bugzilla pour le
suivi de bogues ?
Il existe des dizaines d’entreprises de première importance équipées de sites publiques Bugzilla afin de suivre
les bogues au sein de leurs produits. En voici quelques unes :
Netscape/AOL
Mozilla.org
NASA
Red Hat Software
SuSe Corp
The Horde Project
AbiSource
Real Time Enterprises, Inc
Eggheads.org
Strata Software
RockLinux
Creative Labs (créateurs de SoundBlaster)
The Apache Foundation
The Gnome Foundation
Ximian
Linux-Mandrake
Il suffit de dire qu’il y a assez de projets de grande envergure qui utilisent Bugzilla pour affirmer qu’il est
extrêmement populaire.
51
1.5. Qui assure la maintenance de Bugzilla ?
Une équipe de base
([email protected]).
(http://www.bugzilla.org/who_we_are.html),
dirigée
par
Dave
Miller
1.6. Que vaut Bugzilla par rapport aux autres bases de données pour le suivi des bogues ?
Nous n’avons pu trouver aucune étude comparative entre Bugzilla et d’autres logiciels de suivi de défauts.
Si vous en connaissez, merci de nous contacter. Néanmoins, d’après l’expérience personnelle de l’auteur au
sujet des autres systèmes de suivi de bogues, Bugzilla offre des performances supérieures sur le matériel grand
public, à un meilleur prix (gratuit !), plus de fonctionnalités facilitant la tâche des développeurs (comme la
sauvegarde des requêtes, l’intégration du courrier électronique et l’indépendance vis-à-vis de la plate-forme.),
une adaptabilité améliorée, un code source libre, une plus grande fléxibilité et une plus grande facilité d’emploi.
Si vous êtes vendeur d’un système de suivi de bogues commercial, merci de vous faire connaître et de nous
remettre une liste des avantages de votre produit par rapport à Bugzilla. Nous serions heureux de l’inclure dans
notre section ’concurrents’.
1.7. Pourquoi Bugzilla ne propose-t-il pas telle ou telle fonctionnnalité ou compatibilité avec cet autre logiciel
de suivi de bogues ?
Il se peut que le support n’ait pas encore été développé ou que vous ne l’ayez pas trouvé. Bugzilla fait de
grands progrès en terme de facilité d’emploi, de personnalisation, d’adaptabilité et d’interface utilisateur. Il est
largement considéré comme le plus complet et le plus populaire des logiciels libres existant pour le suivi de
bogues.
Ceci ne signifie pas que Bugzilla ne peut pas connaître d’améliorations ! Vous pouvez participer au projet, soit
en élaborant vous même une correction qui réalise la fonctionnalité que vous désirez, soit en soumettant une
RFE (Request For Enhancement) via l’interface de soumission des bogues disponible sur bugzilla.mozilla.org
(http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla).
1.8. Pourquoi MySQL ? J’aimerais voir Bugzilla fonctionner avec Oracle/Sybase/Msql/PostgreSQL/MSSQL.
Au départ, MySQL a été choisi car il était gratuit, facile à installer et compatible avec le matériel sur lequel
Netscape comptait le faire fonctionner.
Le travail est actuellement en cours pour faire fonctionner Bugzilla avec PostgreSQL et
Sybase dans la distribution par défaut. Vous pouvez suivre l’avancement de ces initiatives
repectivement dans les bogues 98304 (http://bugzilla.mozilla.org/show_bug.cgi?id=98304) et 173130
(http://bugzilla.mozilla.org/show_bug.cgi?id=173130).
Une fois ces deux tâches réalisées, ajouter la prise en compte de bases de données supplémentaires devrait être
une opération banale.
52
1.9. Pourquoi les scripts référencent-ils /usr/bonsaitools/bin/perl plutôt que /usr/bin/perl ou autre
?
Mozilla.org se servait de /usr/bonsaitools/bin/perl, car à l’origine Terry désirait bénéficier d’un emplacement qui soit entièrement sous son contrôle pour installer une version de Perl ainsi que d’autres outils.
Note: Cet usage a été abandonné lors du cycle de développement 2.17 donc ce ne sera plus un problème
lorsque la version 2.18 verra le jour.
1.10. Existe-il un moyen simple de changer le nom des cookies de Bugzilla ?
Pas pour le moment.
2. Questions relatives à la gestion d’entreprises
Note: Des questions susceptibles d’être posées par les cadres de direction.
2.1. Bugzilla est-il un logiciel Web ou bien nécessite-t-il des logiciels particuliers ou un système d’exploitation
spécial sur la machine ?
Il utilise le Web et la messagerie électronique. Vous pouvez éditer des bogues en envoyant un courrier électronique formatté d’une certaine manière à un Bugzilla correctement configuré, ou alors effectuer l’opération par
l’intermédiaire du Web.
2.2. Bugzilla peut-il se combiner avec Perforce (logiciel SCM) ?
Oui ! Vous trouverez de plus amples informations ailleurs dans "Le guide de Bugzilla" au sein de la partie
"Intégration de logiciels tiers".
2.3. Bugzilla permet-il à l’utilisateur de suivre les bogues au sein de plusieurs projets ?
Parfaitement ! Vous pouvez effectuer le suivi d’un nombre illimité de produits, pouvant chacun être composé
d’un nombre illimité de composants.
Note: Seuls 55 groupes sont disponibles dans la version 2.16 de Bugzilla. Si vous utilisez les groupes
de produits, le nombre de produits dont vous pouvez disposer sera par conséquent limité. Cette limitation
n’apparaît pas dans les versions de développement 2.17 actuelles et n’apparaîtra pas dans la version 2.18.
2.4. Si je participe à plusieurs projets et que je recherche l’ensemble des bogues dont je suis chargé, Bugzilla
m’en établira-t-il une liste et me permettra-t-il de les trier par projet, par gravité, etc ?
Oui.
53
2.5. Bugzilla admet-il les pièces jointes (texte, capture d’écran, adresses Web, etc)? Si oui, y en a-t-il qui ne
sont pas autorisées ?
Oui - tous les types de pièces jointes sont permis, bien que les administateurs puissent configurer une taille
maximale. Bugzilla donne à l’utilisateur la possibilité soit d’utiliser le type-MIME proposé par le naviguateur,
soit de choisir à partir d’une liste pré-définie, soit de taper manuellement n’importe quel type-MIME arbitraire.
2.6. Bugzilla nous permet-il de définir nos propres priorités et niveaux ? Avons nous l’entière liberté de modifier
les libellés des champs ainsi que leur format et le choix des valeurs admises ?
Oui. Cependant, modifier certains champs, notamment ceux liés aux états de progression des bogues, nécessite
aussi d’ajuster la logique du programme pour compenser le changement.
Pour le moment, il n’existe pas d’interface utilisateur graphique (GUI) pour ajouter des
champs dans Bugzilla. Vous pouvez suivre le développement de cette fonctionnalité sur
http://bugzilla.mozilla.org/show_bug.cgi?id=91037.
2.7. Bugzilla propose-t-il des fonctions de rapports d’état, des métriques, des graphes, etc ? Vous savez, le genre
de trucs que les chefs aiment bien voir. :)
Oui. Jettez un coup d’oeil à http://bugzilla.mozilla.org/reports.cgi, vous y trouverez des extraits de ce que
Bugzilla sait faire en terme de génération de rapports et de graphiques.
Si vous n’obtenez pas les rapports désirés à partir des scripts de rapports fournis, il est possible d’inclure un
paquetage professionnel pour les rapports comme par exemple Crystal Reports qui utilise ODBC. Si vous choisissez de procéder ainsi, faites attention au fait que donner un accès direct à la base de données peut avoir
des effets sur la sécurité. Même si vous donnez un accès en consultation seule à la base de données, il y aura
contournement des éléments de sécurité des bogues de Bugzilla.
Note: Les versions de développement actuelles peuvent faire bien plus en terme de rapports. Pour voir des
exemples, consultez http://bugzilla.mozilla.org/report.cgi.
2.8. Existe-t-il une notification par courrier électronique et si oui que voit-on lorsque l’on reçoit un courrier
électronique ?
La notification par courrier électronique est configurable par l’utilisateur. Par défaut, l’identifiant du bogue
et un résumé de son rapport accompagne chaque notification par courrier électronique, ainsi qu’une liste des
changements effectués.
2.9. La notification par courrier électronique peut-elle être configurée pour l’envoi à plusieurs personnes, certaines sur la liste To, la liste CC, la liste BCC, etc ?
Oui.
54
2.10. Les utilisateurs doivent-ils disposer d’un type particulier d’application pour les courriers électroniques ?
Les courriers électroniques de Bugzilla sont envoyés en texte simple, le format de courrier le plus compatible
sur la planète.
Note: Si vous décidez d’utiliser les caractéristiques d’intégration de bugzilla_email pour permettre à Bugzilla
d’enregistrer les réponses aux courriers électroniques avec les bogues associés, vous devrez peut-être
prévenir vos utilisateurs de configurer leur logiciel de courrier électronique pour répondre aux messages
dans le format où ils ont été reçus. Pour des raisons de sécurité, Bugzilla ignore les balises HTML en commentaire et si un utilisateur envoie un courrier électronique en HTML à Bugzilla, le commentaire résultant
sera carrément illisible.
2.11. Bugzilla permet-il d’importer et d’exporter des données ? Si des personnes extérieures rédigent un rapport
de bogue avec un ’template’ de bogue MS Word, ce ’template’ peut-il être importé dans les champs correspondant ? Si je veux obtenir le résultat d’une requête et exporter cette donnée vers MS Excel est-ce possible ?
Bugzilla peut seulement exporter des listes de bogues en HTML dans sa version 2.16. Il existe d’autres formats
disponibles (CSV et RDF) dans les versions de développement plus récentes.
Bugzilla peut exporter des bogues en utilisant xml.cgi avec soit un numéro de bogue soit une liste de numéros
de bogue.
Actuellement le seul script livré avec Bugzilla qui peut importer des données est importxml.pl qui est destiné
à l’importation de données générées par xml.cgi associées au déplacement de bogues. Toute autre utilisation
est laissée à la disposition de l’utilisateur s’il souhaite s’exercer.
Il y a aussi des scripts inclus dans le répertoire contrib/ pour l’utilisation des courriers électronique afin
d’importer des données dans Bugzilla, mais ces scripts ne sont pas pris en charge actuellement et sont inclus
dans un but pédagogique.
2.12. Quelqu’un a-t-il traduit Bugzilla dans une autre langue afin de l’utiliser dans d’autres pays ? Bugzilla
possède-t-il des paramètres régionaux ?
Oui. Pour plus d’informations ainsi que les traductions des ’templates’ disponibles, consultez
http://www.bugzilla.org/download.html#localizations. Les interfaces d’administration ne sont pas
encore incluses dans les ’templates’ traduits et sont par conséquent toujours en anglais. Il peut
également y avoir des problèmes si le jeu de caractères n’est pas défini. Voir le bogue 126226
(http://bugzilla.mozilla.org/show_bug.cgi?id=126266) pour plus d’informations.
2.13. Un utilisateur peut-il créer et sauvegarder des rapports ? Peut-il le faire au format Word ? Au format Excel
?
Oui. Non. Pas dans la version 2.16.
2.14. Bugzilla peut-il effectuer une recherche par mot, par groupe de mots, une recherche composée ?
Vous n’avez même pas idée. L’interface de requête de Bugzilla, en particulier avec les opérateurs booléens
avancés, est incroyablement polyvalente.
55
2.15. Bugzilla utilise-t-il le verrouillage des enregistrement lorsqu’il y a des accès simultanés au même bogue
? La deuxième personne est-elle informée que le bogue est en cours d’utilisation ou comment sont-ils avertis
tous les deux ?
Bugzilla ne verrouille pas les enregistrements. Il permet la détection des accès concurrentiels, et offre le choix
des options pour traiter le conflit à l’utilisateur fautif.
2.16. Existe-il des fonctions de sauvegarde ?
MySQL,la base de donnée principale de Bugzilla, permet la reprise à chaud pour les données. Vous pouvez
trouver des stratégies pour traiter des problèmes de sauvegarde sur http://www.mysql.com/doc/B/a/Backup.html
(http://www.mysql.com/doc/B/a/Backup.html)
2.17. Les utilisateurs peuvent-ils utiliser le système alors qu’une sauvegarde est en cours ?
Oui. Cependant, les validations de transaction dans la base de données doivent attendre que les tables soient
débloquées. Les bases de données Bugzilla sont généralement très petites et les sauvegardes prennent systématiquement moins d’une minute.
2.18. Comment puis-je mettre à jour le code et la base de données avec CVS ?
1. Faites une sauvegarde de votre répertoire Bugzilla et de votre base de données. Pour le répertoire de
Bugzilla, il suffit de faire un cp -rp bugzilla bugzilla.bak. Pour la base de données, il existe un certain
nombre d’options - consultez la documentation MySQL et choisissez celle qui vous convient le mieux (le
moyen le plus simple est de faire une copie physique de la base de données sur le disque dur, mais pour cela
vous devez faire éteindre le serveur de la base de données afin d’éviter tout risque de perte de données).
2. Placez vous dans le répertoire de Bugzilla.
3. Tapez cvs -q update -AdP si vous voulez tout mettre à jour ou cvs -q update -dP -rTAGNAME si vous
voulez une version spécifique (dans ce cas remplacez TAGNAME par un nom de fichier CVS similaire à
BUGZILLA-2_16_5).
Si vous n’avez fait aucun changement localement, ça devrait être parfait. Si vous avez effectué des changements en local, vérifiez la présence de résultats notés C en sortie de CVS. Si vous obtenez des lignes
commencant par C, cela signifie qu’il existe des conflits entre vos changements locaux et ce qui se trouve
sur le CVS. Vous devrez régler cela à la main avant de pouvoir continuer.
4. Après avoir résolu tout conflit généré par l’opération de mise à jour du CVS, l’exécution ./checksetup.pl
se chargera de mettre à jour la base de données pour vous ainsi que tout autre changement nécessaire pour
que la nouvelle version puisse fonctionner.
Warning
Une fois que vous avez exécuté checksetup.pl, le seul moyen de revenir en arrière est
de restaurer les sauvegardes de la base de données. Vous ne pourrez pas ramener le
système à sa version initiale de manière propre dans la plupart des cas.
56
2.19. Quel type de ressources humaines faut-il dans l’équipe pour installer et assurer la maintenance de Bugzilla
? Pour être plus précis, quelles compétences sont nécessaires à la personne ? J’ai besoin de savoir, si nous devions
utiliser Bugzilla, quel type de personnes devrons-nous embaucher et combien cela nous coûtera-t-il comparé à
l’achat d’une solution prête à l’emploi ?
Si Bugzilla est configuré correctement dès le début, les besoins pour la maintenance continue sont minimes et
peuvent être réalisés facilement via l’interface Web.
Les logiciels de suivi de bogues commerciaux coûtent généralement au delà de $20,000 ou plus pour entre 5
et 10 licences partagées. Des conseils pour Bugzilla sont donnés par les spécialistes, membres de la liste de
diffusion.On y trouve aussitôt les réponses aux questions simples.
2.20. En terme de durée, que doit-on prévoir si nous décidons d’embaucher du personnel pour installer et
assurer la maintenance de Bugzilla ? Est-ce quelque chose qui prend des heures ou des semaines pour installer
et deux ou trois heures par semaine pour assurer la maintenance et l’adaptation à nos besoins ou bien est-ce un
processus d’installation de plusieurs semaines, plus un travail à plein temps pour une personne ou deux, etc ?
Cela dépend complètement de ce que vous voulez y mettre. Quelqu’un avec beaucoup d’expérience sur Bugzilla
peut tout mettre sur pied et en état de marche en moins d’une journée, et votre installation Bugzilla peut fonctionner sans soin particulier pendant des années. Si votre stratégie Bugzilla est cruciale par rapport à votre
plan de travail d’entreprise, embauchez quelqu’un avec des compétences raisonnables en UNIX et en Perl pour
conduire votre gestion de processus ainsi que la maintenance et la personnalisation de votre suivi de bogues.
2.21. Y a-t-il des droits de licence ou d’autres frais pour l’utilisation de Bugzilla ? D’autres coût marginaux que
les personnes nécessaires comme exposé ci-dessus ?
Non. MySQL vous propose, si vous appréciez la valeur de leur produit, de souscrire à un contrat d’assistance,
qui convient à vos besoins.
3. La sécurité de Bugzilla
3.1. Comment désactiver complètement la sécurité dans MySQL si elle me cause des problèmes (j’ai suivi les
instructions de la partie installation de ce guide) ?
Exécutez MySQL comme suit :"mysqld --skip-grant-tables". Souvenez vous que cela rend MySQL aussi sûr que
de de scotcher un billet de 100 $ par terre dans les toilettes d’un stade de foot pour ne pas se le faire piquer.
3.2. Y a-t-il des problèmes de sécurité avec Bugzilla ?
Le code de Bugzilla a subit un audit de sécurité relativement complet, et les scripts CGI de présentation pour
les utilisateurs sont exécutés avec l’option taint de Perl. Cependant il est recommandé d’examiner attentivement
les permissions de votre installation de Bugzilla et de suivre les recommandations en matière de sécurité dans
le guide Bugzilla.
3.3. J’ai mis en oeuvre les modifications mentionnées dans le rapport de sécurité de Chris Yeh du 10/05/2000
conseillant de ne pas exécuter MySQL en tant que root et je rencontre des problèmes avec MySQL qui ne
fonctionne plus correctement.
Il s’agit d’un problème fréquent, lié au fait de ne plus avoir de descripteur de fichier. Ajoutez simplement "ulimit
-n unlimited" dans le script qui démarre mysqld.
4. Les courriers électroniques de Bugzilla
57
4.1. J’ai un utilisateur qui ne veut plus recevoir de courriers électroniques de Bugzilla. Comment les arrêter
complètement pour cet utilisateur ?
L’utilisateur doit pouvoir régler cela dans les préférences de courrier électronique de l’utilisateur (décocher
toutes les boîtes) ou vous pouvez ajouter son adresse électronique dans le fichier data/nomail.
4.2. Je suis en train d’évaluer/tester Bugzilla et je ne veux pas qu’il envoie des mails à toute autre personne que
moi. Comment faire ?
Editez le paramètre "newchangedmail". Remplacez "To:" par "X-Real-To:", "Cc:" par "X-Real-CC:", et ajoutez
"To: <votreadresseemail>".
4.3. Je souhaite que whineatnews.pl génère une réclamation pour un fait supplémentaire, ou autre chose que
pour signaler de nouveaux bogues. Comment faire ?
Essayez l’excellent correctif de Klaas Freitag pour la fonctionnalité "whineatassigned". Vous pourrez la trouver
sur http://bugzilla.mozilla.org/show_bug.cgi?id=6679. Ce correctif est pour une ancienne version de Bugzilla,
vous devrez donc effectuer les modifications manuellement.
4.4. Je n’aime pas/ne veux pas utiliser Procmail pour transférer les courriels à bug_email.pl. Quelles sont les
solutions ?
Vous pouvez appeler bug_email.pl directement à partir de votre fichier d’alias, avec une commande comme
celle-ci :
bugzilla-daemon: "|/usr/local/bin/bugzilla/contrib/bug_email.pl"
Cependant, c’est assez délicat et sujet à problèmes; vous devez aussi configurer votre smrsh (sendmail restricted
shell) pour permettre cela. A la rigueur cela peut tout de même marcher.
4.5. Comment régler l’interface de courrier électronique pour soumettre/changer des bogues par courrier électronique ?
Vous trouverez un fichier README.mailif mis à jour dans le répertoire contrib/ de votre distribution Bugzilla
qui vous guidera dans la configuration.
4.6. Les courriers électroniques venat de Bugzilla mettent un temps fou pour me parvenir -- C’est extrêmement
lent. Qu’est-ce qui se passe ?
Si vous utilisez un Mail Transfer Agent (Serveur de Courriers Electroniques) différent (un MTA autre que
sendmail), assurez vous que les options fixées dans le "processmail" ainsi que dans les autres scripts pour toutes
les instances de sendmail conviennent à votre MTA.
Si vous utilisez sendmail, essayez en activant "sendmailnow" dans editparams.cgi. Si vous utilisez Postfix, vous
devrez aussi activer “sendmailnow”.
4.7. Comment se fait-il que les courriers électroniques concernant les modifications sur Bugzilla ne me parviennent pas ?
Assurez vous que vous n’avez pas désactivé les courriers électroniques dans vos préférences d’utilisateur. Vérifiez que Bugzilla est capable d’envoyer des courriers électroniques en cliquant sur le lien "Connexion" ["Log
In"] de votre installation Bugzilla puis en cliquant sur le bouton "Envoyez moi un mot de passe par courrier
électronique" ["E-mail me a password"] après avoir entré votre adresse électronique.
58
Si vous ne recevez pas de courrier électronique de Bugzilla, il ya des chances que vous n’ayez pas sendmail
dans "/usr/lib/sendmail". Assurez-vous que sendmail se trouve à l’intérieur ou qu’il existe un lien symbolique
pointant vers lui dans "/usr/lib/sendmail".
5. La base de données de Bugzilla
5.1. J’ai entendu dire que Bugzilla pouvait être utilisé avec Oracle ?
L’ancienne version de Bugzilla pour Red Hat (Basé sur la version 2.8) fonctionnait sur Oracle. La nouvelle
version pour Red Hat (basée sur la version 2.17.1 et sur le point d’être intégrée dans la distribution principale)
fonctionne avec PostgreSQL. Pour le moment, nous n’avons pas connaissance d’un portage de Bugzilla sur
Oracle mais nous prévoyons bien de le prendre en charge dans le futur (probablement pour la version 2.20).
5.2. Je pense que ma base de données doit être altérée, ou bien qu’elle contient des entrées non-valides. Que
faire ?
Exécutez l’utilitaire de “bilan de santé” (./sanitycheck.cgi dans le répertoire Bugzilla_home) via votre
naviguateur internet pour voir ! Si il se termine sans erreur, vous n’avez à priori aucun problème. S’il ne se
termine pas bien (c’est à dire avec des messages en rouge), certaines choses peuvent être réparées par Bugzilla
et d’autres non. Si la réparation est impossible, j’éspère pour vous que vous avez l’habitude des commandes
d’administration d’une base de données mysql ou bien que vous avez installé un autre moyen d’administrer
votre base de données. Le bilan de santé, bien qu’étant un bon test de base pour vérifier l’intégrité de votre
base de données, ne remplace en aucun cas une administration compétente de la base de données ni n’évite
la suppression de données. Il n’est pas exhaustif et a été crée pour effectuer une vérification de base sur les
problèmes les plus communs dans des bases de données Bugzilla.
5.3. Je veux éditer à la main des entrées dans ma base de données. Comment faire ?
Il n’existe pas de moyen de faire cela dans Bugzilla lui-même. De plus ce n’est généralement pas une tâche
que l’on peut rapidement réaliser si l’on ne sait pas exactement ce qu’on veut faire. Cependant si vous
connaissez le SQL, vous pouvez utiliser mysql en ligne de commande pour insérer, supprimer et modifier
les informations d’une table à la main. Des client graphiques plus intuitifs sont également disponibles. Les
favoris de l’équipe Bugzilla sont phpMyAdmin (http://www.phpmyadmin.net/) et MySQL Control Center
(http://www.mysql.com/downloads/gui-mycc.html).
5.4. Je pense que j’ai correctement réglé les permissions de MySQL mais Bugzilla ne parvient toujours pas à
se connecter.
Essayez d’exécuter MySQL à partir de son fichier binaire : "mysqld --skip-grant-tables". Cela vous permettra
de complètement contourner les permissions sur les tables qui sont la cause de votre frustration. Si dans ce cas
Bugzilla est capable de se connecter, vous devez vérifier que vous avez donné les bonnes permissions au couple
utilisateur - mot de passe défini dans localconfig.
Warning
Exécuter MySQL avec cette option dans la ligne de commande n’est pas sûr du tout et doit
être uniquement effectué dans le cadre d’une démarche de dépannage lorsque l’on est pas
connecté au réseau extérieur.
59
5.5. Comment est-ce que je fais pour synchroniser les informations sur les bogues entre plusieurs bases de
données ?
En fait, vous pouvez synchroniser ou déplacer les bogues. La synchronisation s’opèrera uniquement dans un
sens -- vous avez la possibilité de créer une copie de la base en lecture seule sur un site et la faire mettre à jour
à partir de la base de données principale à intervalles réguliers.
MySQL intègre des fonctionnalités de synchronisation dans les dernières versions. Ce serait une bonne idée si
quelqu’un se penchait sur les possibilités dans ce domaine et proposait un compte rendu sur le forum expliquant
comment synchroniser efficacement deux installations de Bugzilla.
Si vous avez simplement besoin de transférer des bogues d’un Bugzilla à un autre jetez un coup d’oeil au script
"move.pl" dans la distribution de Bugzilla.
6. Bugzilla et Win32
6.1. Quel est le moyen le plus facile d’utiliser Bugzilla sur Win32 (Win98+/NT/2K) ?
Enlevez Windows. Installez Linux. Installez Bugzilla. La chef ne verra jamais la différence.
6.2. Existe-t-il un équivalent de "Bundle::Bugzilla" pour Win32?
Pas pour le moment. Bundle::Bugzilla simplifie énormément l’installation de Bugzilla sur les systèmes UNIX.
Si quelqu’un se porte volontaire pour réaliser un bundle PPM (module pour le gestionnaire de packetages de
Perl) qui convient à Win32, une telle initiative sera appréciée.
6.3. Des fichiers CGI plantent avec une erreur "quelquechose.cgi is not a valid Windows NT application"
(quelquechose.cgi n’est pas une application Windows NT valide). Pourquoi ?
En fonction du serveur Web que vous utilisez, vous devez configurer celui-ci pour traiter les fichier *.cgi comme
des scripts CGI. Pour IIS, vous pouvez faire cela en ajoutant *.cgi dans la mise en correspondance des applications (App Mapppings) avec <path>\perl.exe %s %s comme exécutable.
Microsoft donne quelques indications à ca sujet, comme suit :
"Configurer la mise en correspondance des applications. Dans l’ISM, liez l’extension du ou des fichier(s) script à
l’exécutable de l’interpréteur du script. Par exemple, vous devez faire correspondre l’extension .py à Python.exe,
l’exécutable de l’interpréteur de scripts Python. Notez que pour l’interpréteur de scripts Perl ActiveState, l’extension
.pl est associée à PerIIS.dll par défaut. Si vous voulez changer l’association pour .pl par perl.exe, vous devez changer
la correspondance d’applications. Dans la correspondance, vous devez ajouter deux caractères pourcent (%) à la fin du
chemin jusqu’à perl.exe, comme montré dans cet exemple : c:\perl\bin\perl.exe %s %s"
6.4. J’ai des problèmes avec les modules de perl pour NT qui n’arrivent pas à communiquer avec la base de
données.
Vos modules sont peut-être obsolètes ou inappropriés. Essayez ce qui suit :
1. Tapez http://www.activestate.com/ActivePerl
2. Téléchargez ActivePerl
60
3. Lancez votre invite de commande.
4. Tapez ’ppm’
5. PPM> install DBI DBD-mysql GD
Je pense que TimeDate et Date::Dumper sont inclus dans activeperl. Vous pouvez aller vous renseigner sur le
site d’ActiveState à propos des packages pour l’installation via PPM. http://www.activestate.com/Packages/ (
http://www.activestate.com/Packages/)
7. Utilisation de Bugzilla
7.1. Comment est-ce que je fais pour changer mon nom d’utilisateur (adresse de courrier électronique) dans
Bugzilla ?
Nouveau dans la version 2.16 - allez dans la section compte dans les préférences. Vous recevrez un courrier
électronique aux deux adresses pour confirmation.
7.2. La page pour les requêtes est très troublante. N’y a-t-il pas un moyen plus simple d’effectuer une requête ?
L’interface a été simplifiée par un designer d’interfaces dans la version 2.16. Les suggestions d’amélioration
sont les bienvenues, mais nous ne sacrifierons pas la puissance à la simplicité.
7.3. Je suis troublé par le comportement du bouton "accept" dans le formulaire Show Bug. Pourquoi est-ce que
le bogue ne m’est pas affecté après que j’aie accepté ?
Le comportement actuel convient à bugzilla.mozilla.org ainsi qu’à la plupart des utilisateurs. Malgré tout, vous
disposez d’un choix de programmes de correction pour changer son comportement.
Ajoutez une case d’option "and accept bug". (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8029)
Le bouton "Accept" vous affecte automatiquement le bogue. (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8153)
Notez que ces corrections commencent un peu à dater. Vous devrez les appliquer à la main.
7.4. Je ne peux rien inscrire dans la base de données via le lien "Create Attachment". Qu’est ce que je fais mal
?
La cause la plus probable vient de l’utilisation d’un très vieux navigateur ou d’un navigateur incompatible avec
le téléchargement de fichiers vers le serveur via POST. Téléchargez le dernier navigateur Netscape, Microsoft
ou Mozilla pour effectuer les téléchargements vers le serveur correctement.
7.5. Comment est-ce que je change un mot-clé dans Bugzilla, une fois que plusieurs bogues l’utilisent ?
Dans l’interface administrateur de Bugzilla, éditez le mot-clé et ça remplacera pour vous l’ancien mot-clé par
le nouveau. Cela causera un problème avec la mémoire cache des mots-clés. Exécutez sanitycheck.cgi pour le
résoudre.
7.6. Pourquoi est-ce que je ne peux pas clore des bogues à partir de la page "Change Several Bugs at Once"
(Changer plusieurs bogues d’un coup) ?
Le cheminement logique actuellement adopté est RESOLVED (résolu), puis VERIFIED (vérifié) et enfin
CLOSED (fermé). Vous avez la possibilité de clore plusieurs bogues à partir de la page changer plusieurs
bogues à la fois. Mais tous les bogues listés sur la page doivent être dans l’état VERIFIED afin que la
commande pour le faire apparaisse sur le formulaire. Vous pouvez aussi donner le statut VERIFIED d’un
coup à plusieurs bogues, mais tous les bogues listés doivent alors être dans l’état RESOLVED pour que la
61
commande apparaisse dans le formulaire. La logique derrière tout cela est que si vous sélectionnez un bogue
qui n’est pas dans l’état VERIFIED et que vous essayez de le passer en CLOSED, la modification du bogue
échouera lamentablement (ce qui annulera tous les changement situés après dans la liste lors du changement
massif) donc ça ne vous laisse pas le choix.
8. Bidouiller Bugzilla
8.1. Quels sont les bogues de Bugzilla actuellement ?
Consultez ce lien (http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&
pour voir les bogues actuels ou les demandes d’amélioration de Bugzilla.
Vous
pouvez
voir
des
bogues
marqués
pour
la
version
2.18
ici
(http://bugzilla.mozilla.org/buglist.cgi?product=Bugzilla&target_milestone=Bugzilla+2.18).
Cette liste contient les bogues de la version 2.18 qui ont déjà été corrigés et consignés dans le CVS. Veuillez
consulter la page du projet Bugzilla [Bugzilla Project Page] (http://www.bugzilla.org/) pour les détails sur la
manière de récupérer les sources actuelles sur le CVS afin que les bogues soient déjà corrigés pour vous.
8.2. Comment changer la valeur par défaut en une valeur nulle ? Par exemple, avoir "---" comme valeur par
défaut au lieu de "P2" ?
Ce
point
est
bien
documenté
ici
:
http://bugzilla.mozilla.org/show_bug.cgi?id=49862
(http://bugzilla.mozilla.org/show_bug.cgi?id=49862). En fin de compte, ce n’est pas plus compliqué que
d’ajouter le champ de priorité "---" à l’endroit approprié de votre fichier localconfig, de relancer checksetup.pl
et enfin de changer la priorité par défaut dans votre navigateur au moyen d’ "editparams.cgi".
8.3. Quel est la meilleure façon de soumettre des programmes de correction ? Quelles sont les directives à
suivre ?
1. Ajoutez
un
bogue
sur
bugzilla.mozilla.org
concernant
(http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla). ”
le
logiciel
“
Bugzilla
2. Téléchargez votre programme de correction vers le serveur en tant que unified diff (en utilisant "diff -u"
sur les sources actuelles récupérés sur CVS), ou en tant que nouveau fichier source en cliquant sur le
lien "Create a new attachment" dans la page de bogue que vous venez juste de créer, et ajoutez dans la
description du bogue que vous avez soumis à l’étape 1 toute description que vous pouvez faire concernant
des changements dans la base de données. Soyez sûr de valider la boîte de choix "Patch" pour indiquer que
le texte que vous envoyez est un programme de correction !
3. Faites part de l’arrivée de votre programme de correction et de l’URL associée
(http://bugzilla.mozilla.org/show_bug.cgi?id=XXXXXX) afin d’en discuter dans le forum
(netscape.public.mozilla.webtools). Vous aurez une réaction vraiment bonne et relativement immédiate sur
les implications de votre programme de correction, ce qui nous donnera aussi une idée de la manière dont
seraient reçus les changements.
4. S’il passe les contrôles avec un minimum de modifications, la personne à qui le bogue est assigné chez
Bugzilla sera chargée d’assurer que le programme de correction soit consigné sur CVS.
5. Repaissez-vous de la gloire d’avoir participé à la réalisation du logiciel de suivi de bogues le plus réputé de
la planète :)
62
Appendix B. La base de données de Bugzilla
Note: Ce document a vraiment besoin d’être mis à jour avec des informations étoffées sur les clés primaires, les
liens entre relations et peut être quelques tables pratiques pour documenter les dépendances. Des volontaires ?
63
B.1. Schema de la base de données
64
Schema des relations de la base de données de Bugzilla
B.2. Introduction à la base de données MySQL de
Bugzilla
Ces informations sont tirées de mon expérience personnelle. J’ai dû apprendre comment Bugzilla organise la base de
données à cause des pinaillages d’utilisateurs demandant de minuscules changements dans le choix des termes plutôt
que d’attendre que les gens se rééduquent par eux-même ou comprennent comment utiliser nos procédures. Ca craint
mais vous y passerez peut être aussi, donc apprenez comment fonctionne le schéma pour pouvoir vous débrouiller
quand ça arrivera.
Donc, vous en êtes arrivé là avec votre installation toute neuve de Bugzilla. Vous avez installé MySQL, Apache tourne
bien, Perl DBI et DBD communiquent parfaitement avec la base. Peut-être avez-vous même rentré quelques bogues
de test et quelques modifications pour vérifier que le courrier électronique fonctionne bien; les gens semblent être
avertis des nouveaux bogues ou modifications, et vous pouvez créer ou éditer des bogues comme bon vous semble.
Vous avez peut-être rencontré des problèmes lors de la configuration d’une passerelle de connexion afin que les gens
puissent soumettre des bogues à votre base de données par courrier électronique, vous avez demandé à des personnes
de tester votre installation et reçu des retours enthousiastes de la part de vos bêta-testeurs.
Quelle est la suite au programme ? Esquisser un stratégie de formation de votre équipe de développement et leur
demander de se ruer sur le nouvel outil sur lequel vous avez travaillé pendant des heures.
Votre première session de formation débute très bien ! Votre audience captivée semble émerveillée par l’efficacité
intrinsèque de cette chose appelée "Bugzilla". Vous êtes complètement absorbé dans la description des caractéristiques
pratiques, comment les gens peuvent sauvegarder leurs requêtes favorites dans la base de données, les mettre en tête
ou en pied de leur page, personnaliser leur mise en page, générer des rapports, suivre le statut avec une efficacité
plus grande que jamais, atteindre la cime de grands immeubles d’un seul bond, sauver Jane des griffes de la Mort en
Personne !
Mais la Mort en Personne prend la parole -- une petite voie, venue d’un coin sombre de la salle de conférence. "J’ai
une remarque," la voie sort de l’ombre,"à propos de l’utilisation du mot ’verified’.".
La salle, alors remplie d’un heureux babil, plonge dans un silence religieux tandis que la Mort en Personne (plus
connue sous le nom de Vice Président du département génie logiciel) continue. "Vous voyez, pendant deux ans nous
avons utilisé le mot ’verified’ pour indiquer le fait qu’un développeur ou un ingénieur qualité avait confirmé qu’un
bogue était valide. Je ne veux pas perdre deux ans de formation à un nouveau logiciel. Vous devez remplacer le statut
’verified’ d’un bogue par ’approved’ dès que possible. Pour éviter toute confusion, bien sûr."
Oh non ! La peur vous frappe de plein fouet alors que vous balbultiez "oui, oui, je pense que ça ne sera pas un
problème," vous examinez les changements à apporter dus à la Mort en Personne et continuez à baragouiner, "non, ça
ne représente pas une grosse modification. Je veux dire, nous avons le code source, n’est-ce pas ? Vous savez bien,
’Utiliser le code source tu dois, Luke’ et tout ça... aucun problème," pendant tout ce temps vous frémissez à l’intérieur
comme une méduse échouée, bouillonnant, murmurant des sons inarticulés, cuisant sur le sable brûlant d’une dune
jamaïquaine...
Ainsi commence votre aventure au coeur de Bugzilla. Vous avez été condamné à faire connaissance avec les champs
enum() fixes, les colonnes de varchar et les définitions des tinyint. L’aventure vous attend !
65
B.2.1. Les rudiments de la base de données de Bugzilla
Si vous êtes comme moi, vous êtes totallement ignorant des mécanismes internes de MySQL à ce stade, et si vous
n’étiez pas sous les ordres du Vice-Président vou vous moqueriez de la différence qui existe entre un champ “bigint”
et un “tinyint” dans MySQL. Je vous recommande de consulter la documentation MySQL en ligne sur MySQL.com
(http://www.mysql.com/doc.html). Vous trouverez ci-dessous les rudiments nécessaires pour comprendre la base de
données de Bugzilla. Consultez le schéma ci-dessus pour plus de détails.
1. Pour vous connecter à votre base de données :
bash# mysql -u root
Si cela fonctionnne sans demander de mot de passe, honte sur vous ! Vous auriez dû mettre en place un verrouillage de sécurité comme cela était expliqué dans les instructions d’installation. Vous pouvez trouver plus de
détails concernant le verrouillage de votre base de données dans la FAQ de Bugzilla dans ce répertoire (dans la
partie "Securité"), ou des généralités plus solides sur la sécurité dans la documentation consultable de MySQL
(http://www.mysql.com/php/manual.php3?section=Privilege_system).
2. Vous devez maintenant voir une invite de commande qui ressemble à celle-ci:
mysql>
A l’invite, si “bugs” est le nom que vous avez choisi dans le fichier localconfig pour votre base de données
Bugzilla, tapez :
mysql use bugs;
B.2.1.1. Les tables de la base de données de Bugzilla
Imaginez votre base de données MySQL comme une série de feuilles de calcul d’un tableur, et vous ne serez pas loin
de la vérité. Si vous tapez cette commande :
mysql> show tables from bugs;
vous pourrez voir le nom de toutes les “feuilles de calcul” (tables) dans votre base de données.
A partir de la commande tapée ci-dessus, vous devriez obtenir une réponse qui ressemble à celle-ci :
+-------------------+
| Tables in bugs
|
+-------------------+
| attachments
|
| bugs
|
| bugs_activity
|
| cc
|
| components
|
| dependencies
|
| fielddefs
|
| groups
|
| keyworddefs
|
66
| keywords
|
| logincookies
|
| longdescs
|
| milestones
|
| namedqueries
|
| products
|
| profiles
|
| profiles_activity |
| shadowlog
|
| tokens
|
| versions
|
| votes
|
| watch
|
+-------------------+
Voici un aperçu de ce que fait chaque table. La plupart des colonnes de chaque table possède un nom descriptif qui permet de comprendre relativement rapidement leur rôle.
attachments:
Cette table contient tous les fichiers joints aux bogues. Cette table tend à être la plus grande mais généralement aussi celle qui comporte le moins d’entrées car les fichiers joints sont (relativement) gros.
bugs:
C’est le coeur de votre système. La table bugs contient la plupart des informations concernant les bogues à l’exception des informations stockées dans les autres tables.
bugs_activity:
Celle ci conserve les informations concernant les changements apportés aux bogues -- un fichier d’historique.
cc:
Cette petite table conserve simplement toutes les informations de copie carbone (CC) des bogues dont le champ CC est renseigné. Notez que, comme la plupart des autres tables dans Bugzilla, il n’est pas fait référence aux utilisateurs par le biais de leur nom d’uti
tifiant d’utilisateur [userid], stocké dans la table profiles comme clé primaire.
components:
Cette tabe stocke les programmes [programs] et les composants (ou les produits [products] et les composants [components] dans le nouveau langage de Bugzilla) de Bugzilla. Curieusement, le champ "program" (product) est le nom complet du produit et non un autre identifiant unique, comme bug_id et user_id le sont ailleurs dans la base de données.
dependencies:
Contient les données sur ces supers arbres de dépendance.
fielddefs:
Une table pratique qui définit les autres tables. Par exemple lorsque vous validez un formulaire qui change la valeur de "AssignedTo", cette table permet le transfert de l’information vers le champ actuel dont le nom est "assigned_to" pour une entrée de MySQL.
67
groups:
Définit les masques binaires pour les groupes. Un masque binaire est un nombre qui peut identifier de manière unique les
appartenances à un groupe. Par exemple, disons que le groupe qui a le droit d’apporter quelques petites modifications aux
paramètres est affecté d’une valeur "1", le groupe qui a la droit d’éditer les utilisateurs est affecté d’une valeur "2"
et le groupe qui peut créer de nouveaux groupes est affecté d’un masque binaire de "4". Simplement en combinant les masques
binaires des groupes (tout comme la commande chmod d’UNIX,) vous pouvez identifier un utilisateur qui a le droit de
modifier légèrement les paramètres et de créer des groupes mais pas d’éditer les utilisateurs, en lui affectant un masque
binaire de "5", ou un utilisateur ayant le droit d’éditer des utilisateurs et de créer des groupes, mais pas de modifier
les paramètres en lui donnant un masque binaire de "6", non ? Si vous n’avez pas compris, essayer de tazper ceci à
l’invite de commande de mysql :
mysql> select * from groups;
Vous verrez la liste, c’est plus compréhensible de cette manière.
keyworddefs:
Définition des mots-clés utilisés.
keywords:
A l’inverse de ce que vous pensez, cette table dit quels mots-clés sont associés avec quels identifiants de bogues.
logincookies:
Cette table stocke tous les cookies de connexion qui vous sont assignés pour chaque machine à partir de laquelle vous vous êtes connecté à Bugzilla. Curieusement, elle ne gère pas le nettoyage -- je vois des cookies que je n’ai pas utilisé depuis des mois.
Cependant, comme Bugzilla ne donne pas de date d’expiration aux cookies, cela se comprend.
longdescs:
La substance de Bugzilla -- voici où sont stockés tous les commentaires des utilisateurs ! Vous disposez uniquement de 2^24
octets par commentaire (il s’agit d’un champ de type mediumtext), donc soyez concis -- l’ancien testament de la Bible prendrait
seulement cet espace (16 megaoctets, non compréssé). Tout commentaire reçoit comme clé le bug_id du bogue auquel il est lié
de tel manière que l’ordre soit nécessairement chronologique, pour les commentaires qui sont retourné dans l’ordre où ils
ont été reçus.
milestones:
C’est intéressant que les jalons soient associés à un produit particulier dans cette table, mais Bugzilla ne
permet pas encore de différer les jalons en fonction des projets via l’interface de configuration standard.
namedqueries:
C’est ici que chacun stocke ses "requêtes personnelles". Caractéristique très sympa; ça éradique le fait d’avoir à mettre un signet sur chaqu
quête sympa que vous construisez.
products:
Indique les produits dont vous disposez dans la base, si les nouveaux ajouts de bogues sont permis pour ce produit, sur quel
jalon vous travaillez avec ce produit, les votes, etc. Ce sera une bonne chose lorsque la table components contiendra les mêmes
attributs, de telle façon que l’on puisse bloquer l’ajout de nouveaux bogues pour un composant particulier sans bloquer un
produit entier...
profiles:
Ahh, alors vous vous demandiez où vos précieuses informations d’utilisateur étaient gardées ? C’est ici ! Avec les mots de passe
en clair pour tout le monde ! (mais chuut... n’en parlez pas à vos utilisateurs !)
68
profiles_activity:
Vous avez besoin de savoir qui a fait quoi à quel profil utilisateur ? C’est ici que vous le saurez, il s’agit d’un historique assez complet.
shadowlog:
Je peux me tromper ici mais je crois que cette table vous indique quand votre image de la base de données [shadow database]
pour les accès en lecture a été mise à jour et quelles commandes ont été utilisées pour le faire. Nous n’utilisons pas
encore une base de données de ce type sur notre site, c’est pourquoi cette table est relativement vide pour nous.
versions:
Informations sur la version de chaque produit
votes:
Qui a voté pour quoi et quand
watch:
Qui (relativement au userid) consulte les bogues de qui (relativement à leur userid).
===
LES DETAILS
===
Ahh, alors vous vous demandez que faire des informations ci-dessus ? A l’invite de commande vous pouvez visualiser les informations sur n’importe quelle colonne d’une table grâce à cette commande (où table est le nom de la tables que vous
souhaitez voir) :
mysql> show columns from table;
Vous pouvez aussi voir toutes les données contenues dans une table avec cette commande :
mysql> select * from table;
-- note : ce n’est pas une bonne idée de faire cela si, par exemple, la table "bugs" contient 50 000 bogues. Vous pourriez rester assis là un moment jusqu’à ce que vous faisiez un ctrl-c ou que les 50 000 bogues se soient affichés à l’écran.
Vous pouvez limiter un peu l’affichage de la commande ci-dessus avec cette commande ou "colonne" est le nom de la
colonne à laquelle vous voulez restreindre l’affichage d’information :
mysql> select * from table where (colonne = "some info");
-- ou l’inverse de cela
mysql> select * from table where (colonne != "some info");
Reprenons l’exemple de l’introduction et supposons que vous ayez besoin de changer le mot "verified" par "approved" dans le
champ de résolution. Nous savons depuis la partie précédente que la résolution doit se trouver dans la table "bugs".
69
Notez que nous devrons changer un peu le code perl en supplément de la modification de la base de donnée, mais je ne vais pas
rentrer là dedans dans ce document. Vérifions que l’information est bien stockée dans la table "bugs" :
mysql> show columns from bugs
(le long résultat est tronqué ici)
| bug_status| enum(’UNCONFIRMED’,’NEW’,’ASSIGNED’,’REOPENED’,’RESOLVED’,’VERIFIED’,
’CLOSED’)||MUL | UNCONFIRMED||
Désolé de cette longue ligne. Nous voyons à partir du résultat que la colonne "bug status" est de type "enum field", ce qui est une
particularité de MySQL où un champ de type chaîne de caractères ne peut prendre que certaines valeur en entrée. Bien que je trouve
cela vraiment sympa, il ne s’agit pas de SQL standard. Néanmoins, nous avons besoin d’ajouter ’APPROVED’ dans les valeurs
possibles du champ enuméré en modifiant la table "bugs".
mysql> ALTER table bugs CHANGE bug_status bug_status
-> enum("UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED", "RESOLVED",
-> "VERIFIED", "APPROVED", "CLOSED") not null;
(notez que vous pouvez entrer trois lignes ou plus -- quelque soit ce que vous placez avant le point virgule, c’est compris comme une seul
Maintenant si vous faites cela :
mysql> show columns from bugs;
vous verrez que le champ bug_status dispose d’un ’APPROVED’ supplémentaire dans l’énumération ! Une autre chose sympa
serait que ce changement soir propagé jusqu’à votre page de requête aussi -- vous pouvez effectuer une requête au
moyen du nouveau statut. Mai comment cela se propage-t-il dans la réalité des choses ?
Il semble que vous deviez retourner chercher les instances du mot "verified" dans le code perl de Bugzilla -- partout
où vous trouvez "verified", remplacez le par "approved" et vous serez rendu (assurez-vous que la recherche n’est pas
sensible à la casse). Bien que vous puissiez effectuer des requêtes grâce au champ énuméré, vous ne pouvez donner le
statut "APPROVED" à quelque chose avant d’avoir réalisé les changements dans le code perl. Notez que ce changement que
j’ai mentionné peut aussi être réalisé en éditant checksetup.pl, ce qui automatise un bon nombre de choses. Mais vous
avez besoin de connaître ce truc aussi, n’est-ce pas ?
70
Appendix C. Programmes de correction et
utilitaires utiles pour Bugzilla
Vous cherchez un moyen de faire passer votre Bugzilla à la vitesse supérieure ? Récupérez certains des trucs les plus
pratiques présentés ici dans cette section.
C.1. L’excellent mod_rewrite d’Apache
Le module mod_rewrite d’Apache vous permet de faire des choses véritablement étonnantes en reformulation
d’URL. Voici quelques exemples de ce que vous pouvez faire.
1. Agir de telle manière que si quelqu’un tape http://www.foo.com/12345 , Bugzilla retourne
http://www.foo.com/show_bug.cgi?id=12345. Essayez de modifier votre section VirtualHost pour Bugzilla avec
une règle comme celle-ci :
<VirtualHost 12.34.56.78>
RewriteEngine On
RewriteRule ^/([0-9]+)$ http://foo.bar.com/show_bug.cgi?id=$1 [L,R]
</VirtualHost>
2. On peut faire encore bien plus avec mod_rewrite. Veuillez vous reporter à la documentation de mod_rewrite à
l’adresse http://www.apache.org.
C.2. Requêtes Bugzilla en ligne de commande
Il existe une suite d’utilitaires Unix permettant d’adresser une requête à Bugzilla à partir de la ligne de commandes.
Ils se trouvent dans le répertoire contrib/cmdline. Cependant ils n’ont pas encore été mis à jour pour pouvoir
fonctionnner avec la version 2.16 (post-templatisation.). Il y a trois fichiers - query.conf, buglist et bugs.
query.conf contient la correspondance entre les options de ligne de commande et les noms de champs ainsi que les
types de comparaison. Les noms d’option entre guillemets sont rassemblés de telle manière qu’il soit facile d’éditer
ce fichier. Les commentaires (#) n’ont aucun effet; assurez vous que ces lignes ne contiennent pas d’option entre
guillements.
buglist est un script shell dont le rôle est d’adresser une requête à Bugzilla et d’écrire le résultat sous forme d’une
page HTML sur la sortie standard. Il prend en compte à la fois les options abbrégées (comme "-Afoo" ou "-Rbar") et
les options en format long (comme "--assignedto=foo" ou "--reporter=bar"). Si le premier caractère d’une option n’est
pas "-", elle est considérée comme si elle était préfixée de "--default=".
La variable columnlist est extraite du contenu de la variable d’environnement COLUMNLIST. C’est équivalent à
l’option "Change columns" lorque vous listez les bogues dans buglist.cgi. Si vous avez déjà utilisé Bugzilla, faites un
"grep" de COLUMNLIST dans vos fichiers de cookies pour voir le contenu actuel de COLUMNLIST.
bugs est un simple script qui appelle buglist et extrait les numéros de bogues à partir du résultat en sortie. Le
fait d’ajouter le préfixe "http://bugzilla.mozilla.org/buglist.cgi?bug_id=" transforme la liste de bogues en liens qui
71
Appendix C. Programmes de correction et utilitaires utiles pour Bugzilla
fonctionnent si des bogues sont trouvés. Compter les bogues est une chose aisée. Faites un "pipe" du résultat vers sed
-e ’s/,/ /g’ | wc | awk ’{printf $2 "\n"}’
Akkana Peck affirme avoir de bons résultats en effectuant un "pipe" du résultat de buglist vers w3m -T text/html
-dump
72
Appendix D. Variantes et Concurrents de
Bugzilla
J’ai créé cette section afin de pouvoir répondre aux questions concernant les concurrents et les variantes de Bugzilla
puis j’ai trouvé un très bon site qui traite d’une bonne partie de ce dont je voulais discuter. Plutôt que de le recopier
entièrement ici, je vous redirige simplement ici : http://linas.org/linux/pm.html (http://linas.org/linux/pm.html)
D.1. Le Bugzilla de Red Hat
L’ancienne branche red hat de Bugzilla qui était basée sur la version 2.8 est maintenant obsolète. La nouvelle version
en service est basée sur la version 2.17.1 et est sur le point d’être intégrée au tronc principal source de Bugzilla. Le
système dorsal est modifié pour fonctionner avec PostgreSQL au lieu de MySQL et ils ont des templates spécifiques
pour avoir l’aspect et la convivialité désiré, mais à part cela c’est Bugzilla 2.17.1. Dave Lawrence de Red Hat a mis en
avant le grand effort réalisé afin d’assurer que les modifications opérées puissent être intégrée dans le tronc principal.
Le bogue 98304 (http://bugzilla.mozilla.org/show_bug.cgi?id=98304) a été créé pour suivre cette intégration.
URL: http://bugzilla.redhat.com/bugzilla/ (http://bugzilla.redhat.com/bugzilla/)
Dernière modification datée du 24 Décembre 2002
D.2. Loki Bugzilla (Fenris)
Fenris était une branche de Bugzilla réalisée par Loki Games; lorsque Loki a fait faillite, le projet est tombé à l’eau.
Tandis que le code de Loki continue de vivre, ses dépositaires recommendent Bugzilla pour le déploiement de futurs
systèmes de suivi de bogues.
Dernière modification datée du 27 Juillet 2002
D.3. Issuezilla
Issuezilla était une autre branche de Bugzilla, réalisée par collab.net et hébergée chez tigris.org. Il a aussi été abandonné; tigris.org concentre principalement son activité de suivi de bogues sur son système de suivi de bogues basé sur
Java, Section D.4.
D.4. Scarab
Scarab est le nouveau système libre de suivi de bogues construit sur la technologie Servlet Java. Il en est actuellement
à la version 1.0 beta 13.
URL: http://scarab.tigris.org (http://scarab.tigris.org/)
Dernière modification datée du 18 Janvier 2003
73
Appendix D. Variantes et Concurrents de Bugzilla
D.5. Perforce SCM
Bien que Perforce ne soit pas un système de suivi de bogues à proprement parler, il peut être utilisé en tant que tel
grâce à la fonctionnalité “jobs”.
URL: http://www.perforce.com/perforce/technotes/note052.html (http://www.perforce.com/perforce/technotes/note052.html)
D.6. SourceForge
SourceForge est un moyen de coordonner de manière géographique des logiciels librement distribués ainsi que des
projets libres au travers d’Internet. Il dispose d’un système de suivi de bogues inclus à l’intérieur, mais il n’est pas très
bien pensé.
URL: http://www.sourceforge.net (http://www.sourceforge.net)
74
Appendix E. GNU Free Documentation License
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is
permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom:
to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially
or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their
work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free
in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals for free software, because free software needs free
documentation: a free program should come with manuals providing the same freedoms that the software does. But
this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter
or whether it is published as a printed book. We recommend this License principally for works whose purpose is
instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as "you".
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied
verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the
relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters)
and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter
of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or
political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the
notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification
is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic
text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available draw-
75
ing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable
for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to
thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called
"Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed
for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited
only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally
available, and the machine-generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold,
legibly, the material this License requires to appear in the title page. For works in formats which do not have any
title page as such, "Title Page" means the text near the most prominent appearance of the work’s title, preceding the
beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that
this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced
in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may
accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow
the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and the Document’s license notice requires
Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover
Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present the full title with all words of the title equally
prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the
covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim
copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as
fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a
machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publiclyaccessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard
network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution
of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers)
of that edition to the public.
76
It is requested, but not required, that you contact the authors of the Document well before redistributing any large
number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above,
provided that you release the Modified Version under precisely this License, with the Modified Version filling the role
of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of
it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of
previous versions (which should, if there were any, be listed in the History section of the Document). You may
use the same title as a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications
in the Modified Version, together with at least five of the principal authors of the Document (all of its principal
authors, if it has less than five).
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s
license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors,
and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the
Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the
Document, and likewise the network locations given in the Document for previous versions it was based on.
These may be placed in the "History" section. You may omit a network location for a work that was published at
least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications", preserve the section’s title, and preserve in the
section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or
the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and
contain no material copied from the Document, you may at your option designate some or all of these sections as
77
invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These
titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization
as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover
Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one
of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you
are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the
previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity
for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section
4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the
original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be
replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make
the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list
of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the various original documents, forming
one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled
"Dedications". You must delete all sections entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace
the individual copies of this License in the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided
you insert a copy of this License into the extracted document, and follow this License in all other respects regarding
verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on
a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document,
78
provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and
this License does not apply to the other self-contained works thus compiled with the Document, on account of their
being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less
than one quarter of the entire aggregate, the Document’s Cover Texts may be placed on covers that surround only the
Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms
of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders,
but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant
Sections. You may include a translation of this License provided that you also include the original English version of
this License. In case of a disagreement between the translation and the original English version of this License, the
original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License.
Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate
your rights under this License. However, parties who have received copies, or rights, from you under this License will
not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time
to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new
problems or concerns. See http://www.gnu.org/copyleft/ (http://www.gnu.org/copyleft/) .
Each version of the License is given a distinguishing version number. If the Document specifies that a particular
numbered version of this License "or any later version" applies to it, you have the option of following the terms and
conditions either of that specified version or of any later version that has been published (not as a draft) by the Free
Software Foundation. If the Document does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.
How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the
following copyright and license notices just after the title page:
Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with
79
the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts
being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If
you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for
Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel
under your choice of free software license, such as the GNU General Public License, to permit their use in free
software.
80
Glossary
0-9, caractères spéciaux
.htaccess
Le serveur Web Apache ainsi que d’autres serveurs web compatibles avec le NCSA adoptent la convention visant
à utiliser des fichiers appelés .htaccess à l’intérieur des répertoires pour restreindre l’accès à certains fichiers.
Dans Bugzilla, ils sont utilisés pour cacher des fichiers secrets qui pourraient, s’ils étaient découverts, mettre
en péril votre installation - par exemple le fichier localconfig contient le mot de passe pour votre base de
données. Curieux.
A
Apache
Dans ce contexte, Apache représente le serveur web le plus couramment utilisé pour mettre en ligne les pages de
Bugzilla. Contrairement à une vieille croyance populaire, le serveur web apache n’a rien à voir avec l’ancienne
et noble tribu d’indiens d’Amérique mais tient son nom du fait qu’il s’agissait d’une version “patchée["a patchy
version"]” du serveur web original du NCSA.
N.d.T : en anglais, Apache se prononce [A patchy].
Instructions utiles pour configurer Bugzilla
AddHandler (http://httpd.apache.org/docs-2.0/mod/core.html#addhandler)
Indique à Apache qu’il a le droit d’exécuter les scripts CGI.
AllowOverride (http://httpd.apache.org/docs-2.0/mod/core.html#allowoverride)
Options (http://httpd.apache.org/docs-2.0/mod/core.html#options)
Ces instructions sont utilisées pour indiquer à Apache un certain nombre de choses relatives au répertoire
auquel elles s’appliquent. Pour Bugzilla par exemple, nous en avons besoin pour autoriser l’exécution de
scripts et l’utilisation de fichiers .htaccess pour les droits.
DirectoryIndex (http://httpd.apache.org/docs-2.0/mod/mod_dir.html#directoryindex)
Utilisé pour indiquer à Apache quels fichiers sont utilisés en tant qu’index. Si vous ne pouvez pas
ajouter index.cgi à la liste des fichiers valides, vous devez fixer la valeur de $index_html à 1 dans
localconfig de telle manière que ./checksetup.pl crée un index.html qui redirige vers index.cgi.
81
ScriptInterpreterSource (http://httpd.apache.org/docs-2.0/mod/core.html#scriptinterpretersource)
Utilisé lorque l’on fait fonctionner Apache sous windows afin de ne pas avoir à changer la ligne et tout le
toutim dans chaque script de Bugzilla.
B
Bug
Dans Bugzilla, un “bogue” correspond à un problème ajouté dans la base de données, associé à un numéro, des
affectations, des commentaires, etc. Certains se rapportent à un“tickets” ou à un “issues”; dans Bugzilla, ils sont
synonymes.
Numéro de bogue
Chaque bogue de Bugzilla est affecté à un numéro qui identifie ce dernier de manière unique. On peut récupérer
le bogue associé à un numéro de bogue via une requête, ou simplement à partir de la toute première page en
tapant le numéro dans le champ "Trouver" [Find].
Bugzilla
Bugzilla est le leader mondial du logiciel libre de suivi de bogues.
C
Common Gateway Interface
CGI est l’acronyme de Common Gateway Interface. Il s’agit d’un standard pour interfacer une application externe
grâce à un serveur web. Bugzilla est un exemple d’application CGI.
Composant
Un composant est une sous-partie d’un Produit. Il faut que ce soit une catégorie limitée, à la mesure de votre
organisation. Tout Produit doit obligatoirement contenir au moins un Composant (et d’ailleurs, créer un Produit
sans Composant génèrera une erreur dans Bugzilla).
82
CPAN
CPAN signifie “Comprehensive Perl Archive Network”. Le CPAN conserve un grand nombre de modules Perl
extrêmement utiles - de gros morceaux de code encapsulés pour réaliser une tâche particulière.
D
daemon
Un démon [daemon] est un programme informatique qui s’exécute en tâche de fond. En général, la plupart des
démons sont exécutés au démarrage du système via des scripts d’initialisation System V ou à l’aide de scripts
RC sur les systèmes BSD. mysqld, le serveur MySQL et apache, un serveur web, sont généralement des démons.
G
Groupes
Le mot “Groups” possède un sens très spécial dans Bugzilla. Le principal système de sécurité de Bugzilla intervient en placant les utilisateurs dans des groupes et en donnant à ces groupes certaines permissions pour voir les
bogues de Produits [Products] particuliers dans la base de données de Bugzilla.
M
Message Transport Agent
Un serveur de courriers électroniques [Message Transport Agent] est utilisé pour gérer le flot de courriers électroniques d’un système. Plusieurs systèmes UNIX utilisent sendmail (http://www.sendmail.org) qui est ce que
Bugzilla s’attend à trouver par défaut dans /usr/sbin/sendmail. Plusieurs autres MTA fonctionneront, mais
ils nécessitent tous que le paramètre sendmailnow soit fixé à on.
MySQL
MySQL est actuellement le SGBD [RDBMS] utilisé par Bugzilla. MySQL peut être téléchargé à partir de
http://www.mysql.com. Bien qu’il soit nécessaire de prendre connaissance de l’ensemble de la documentation,
les principaux points sont :
83
•
Le
système
de
droits
de
MySQL
[MySQL
Privilege
System]
(http://www.mysql.com/doc/P/r/Privilege_system.html)
De
nombreuses
informations
bien plus détaillées concernant les suggestions dans le Section 5.6.2.
P
Product
Un Produit [Product] rassemble une large catégorie de types de bogues, représentant normalement un seul logiciel
ou une seule entité. En général, il existe plusieurs Composants [Components] dans un Produit. Un Produit peut
définir un groupe (à des fins de sécurité) pour tous les bogues de ses Composants.
Perl
Ecrit à l’origine par Larry Wall, Perl est un langage de programmation remarquable. Il possède les avantages
d’un langage de scripts interprété (comme les scripts shell), associés à la rapidité et à la puissance de langages
compilés comme le C. Bugzilla est programmé en Perl.
Q
QA
“QA”, “Q/A”, et “Q.A.” sont des abréviations d’ “Assurance Qualité [Quality Assurance]”. Dans la plupart des
grands organismes de développement logiciel, il y a une équipe chargée d’assurer que le produit respecte un
minimum de standards avant sa livraison. Souvent cette équipe voudra aussi suivre la progression des bogues
tout au long de leur cycle de vie, d’où la présence d’un champ “Responsable Qualité [QA Contact]” dans un
bogue.
R
Relational DataBase Managment System
Un système de gestion de base de données (SGBDR) relationnelle est un système de base de données qui stocke
les informations dans des tables liées entre elles.
84
S
SGML
SGML signifie “Standard Generalized Markup Language”. Créé dans les années 80 pour fournir un moyen
évolutif de conserver les documents, basé sur le contenu et non sur la présentation, SGML a résisté à l’épreuve
du temps et s’est affirmé comme un langage puissant et robuste. XML est le “petit frère” de SGML; tout
document XML valide est, par définition un document SGML valide. Le document que vous êtes en train de lire
est écrit et maintenu en SGML, mais c’est égalment du XML valide si vous modifiez la DTD [Document Type
Definition].
T
Target Milestone
Les jalons cibles [Target Milestones] sont les objectifs du produit. Ils sont configurables produit par produit. La
plupart des boîtes de développement logiciel utilisent le concept de “jalons” lorsque ceux qui financent un projet
attendent certaines fonctionnalités pour certaines dates. Bugzilla facilite l’utilisation de ce concept de jalons en
vous donnant la possibilité de déclarer à quel jalon un bogue sera réparé ou une amélioration sera apportée.
Tool Command Language
TCL est un langage de scripts libre et disponible sur les plateformes Windows, Macintosh et Unix. Bugzilla 1.0
a été écrit en TCL mais n’a jamais vu le jour. La première version de Bugzilla fut la 2.0 lorsqu’il a été porté en
perl.
Z
Zarro Boogs Found
C’est juste une façon rigolote de dire qu’aucun bogue correspondant à votre requête n’a été trouvé. Lorsqu’on
lui a demandé d’expliquer ce message, Terry a dit la chose suivante :
On m’a demandé d’expliquer ce truc... il y a bien longtemps, lorsque Netscape a fait paraître la version 4.0 de son
navigateur, nous avons fait une fête pour la sortie. Naturellement, ça avait été la grosse panique pour essayer de réparer
tous les bogues identifiés avant la sortie. Naturellement, nous n’y sommes pas parvenus. (Ce n’est pas quelque chose de
spécifique à Netscape ou à la version 4.0; la même chose s’est produite dans chaque projet logiciel auquel j’ai participé.)
Enfin bref, revenons à nos moutons, à la fête de sortie, des T-shirts où il était marqué quelque chose comme "Netscape
4.0: Zarro Boogs" furent distribués. Tout comme le logiciel, le T-shirt n’avait aucun bogue identifié. Hé hé.
85
Donc lorsque vous effectuez une requête pour obtenir une liste de bogues et que vous n’obtenez aucun résultat en retour,
vous penserez à cela avec un petit sourire. Bien sûr qu’il y a des bogues correspondant à votre requête, c’est simplement
qu’ils ne sont pas encore listés dans le système de bogues...
—Terry Weissman
86

fichier

Transcription

Documents pareils

Tester et valider des patchs Koha en 5 étapes

Module Perl DBI MySQL Plan de cours

PERL 5.x Système et DBI

CV Florent

Formation PHP MYSQL - Formation Industries Loire

Formation programmation Perl DBI avec MySQL Plan de cours

Programmation de sites Web dynamiqes avec PHP et MySQL

epm expert php/mysql

Assistant CV

formation php / mysql expert