Configuration

Avertissement

Les installations de MySQL et Bugzilla dont la configuration était médiocre ont permis à des pirates informatiques de s’introduire dans des systèmes par le passé. Veuillez prendre au sérieux les parties de ces instructions qui portent sur la sécurité, même pour les machines Bugzilla bien cachées derrière un coupe-feu. N’oubliez surtout pas de lire les conseils de sécurité importants donnés dans le Chapitre 4, Sécurité de Bugzilla.

localconfig

Dès que vous exécutez checksetup.pl avec tous les bons modules installés, il affiche un message concernant un fichier nommé localconfig qu’il crée. Ce fichier contient les réglages par défaut pour un certain nombre de paramètres de Bugzilla.

Chargez ce fichier dans votre éditeur. La seule valeur que vous devez changer est $db_pass, mot de passe utilisateur que vous allez créer pour votre base de données. Tapez à cet endroit le mot de passe adéquate (pour simplifier, il ne devrait pas contenir le caractère « guillemet unique ») que vous avez choisi.

Les commentaires fournis dans le fichier localconfig donnent des informations sur les autres options. Si vous avez une installation de MySQL légèrement non standard, vous aurez la possibilité de changer un ou plusieurs des autres paramètres « $db_* ».

Si vous le souhaitez, vous pouvez changer le nom des priorités, les niveaux de gravité, les systèmes d’exploitation et les plate-formes pour votre installation. Cependant, vous pouvez toujours changer tout ça après que l’installation soit finie ; si vous re-exécutez checksetup.pl, les changements seront mis à jour.

MySQL

Attention

La configuration par défaut de MySQL est très insécurisée. la section intitulée « MySQL » donne des informations utiles pour améliorer la sécurité de votre installation.

Autoriser les fichiers joints volumineux

Par défaut, MySQL acceptera seulement les paquets ayants une taille maximum de 64Kb. Si vous voulez avoir des fichiers joints plus gros que ça, vous devez modifier votre /etc/my.cnf comme indiqué ci-dessous.

Si vous utilisez MySQL 4.0 ou plus récente, entrez :

  [mysqld]
  # Allow packets up to 1M
  max_allowed_packet=1M

Si vous utilisez une version plus vieille de MySQL, entrez :

  [mysqld]
  # Allow packets up to 1M
  set-variable = max_allowed_packet=1M

Il y a aussi un paramètre dans Bugzilla appelé ‘maxattachmentsize’ (par défaut = 1000 Kb) qui contrôle la taille maximum autorisable des pièces jointes. Les pièces jointes plus volumineuses que l’une des deux valeurs ’max_allowed_packet’ ou ’maxattachmentsize’ ne seront pas acceptées par Bugzilla.

Autoriser les mots courts dans les index en texte intégral

Par défaut, les mots doivent avoir une longueur d’au moins quatre caractères pour être indexés dans les index en texte intégral de Bugzilla. En conséquence beaucoup de mots spécifiques à Bugzilla ne sont pas pris en compte, parmi lesquels "cc", "ftp" et "uri".

MySQL peut être configuré pour indexer ces mots en réglant le paramètre ft_min_word_len à la taille minimum des mots à indexer. Ceci peut être fait en modifiant le /etc/my.cnf selon l’exemple ci-dessous :

  [mysqld]
  # Allow small words in full-text indexes
  ft_min_word_len=2

La reconstruction des index peut être faite en s’appuyant sur la documentation trouvée à http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html. (NDT : la version française se trouve a http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html).

Note

Le paramètre Ft_min_word_len est supporté seulement dans MySQL v4 ou supérieure.

Permettre à la table des fichiers joints de passer à une taille supérieure à 4Go

Par défaut, MySQL limitera la taille de la table à 4Go. Cette limite existe même si le système de fichiers sous-jacent n’a pas une telle limite. Pour fixer une limite plus haute, suivez les instructions suivantes.

Exécutez le client en ligne de commande MySQL et entrez :

  mysql> ALTER TABLE attachments 
          AVG_ROW_LENGTH=1000000, MAX_ROWS=20000;
        

La commande ci-dessus fera passer à 20Go. Mysql devra faire une copie temporaire de l’intégralité de votre table pour cela. Idéalement, vous devriez faire ça quand la table est encore petite.

Ajouter un utilisateur à MySQL

Vous devez ajouter un nouvel utilisateur que Bugzilla puisse utiliser. (Il n’est pas prudent que Bugzilla utilise le compte root de MySQL.) Les instructions suivantes supposent que les paramètres par défaut sont dans localconfig; si vous changez ces derniers, vous devez changer la commande MySQL de façon appropriée. Vous aurez besoin du mot de passe $db_pass vous avez mis dans localconfig dans la section intitulée « localconfig ».

Nous utilisons la commande SQL GRANT pour créer un utilisateur « bugs ». 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.

Exécutez le client en ligne de commande mysql.

Si vous utilisez MySQL 4.0 ou plus récent, entrez :

  mysql> GRANT SELECT, INSERT,
         UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,
         CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.*
         TO bugs@localhost IDENTIFIED BY '$db_pass';
  mysql> FLUSH PRIVILEGES;

Si vous utilisez une version plus ancienne de MySQL, les permissions de LOCK TABLES et CREATE TEMPORARY TABLES seront indisponibles et doivent être supprimées de la liste des permissions. Dans ce cas, on peut utiliser la ligne de commande suivante :

  mysql> GRANT SELECT, INSERT,
         UPDATE, DELETE, INDEX, ALTER, CREATE, DROP,
         REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY
         '$db_pass';
  mysql> FLUSH PRIVILEGES;

checksetup.pl

Ensuite, réexécutez checksetup.pl. Il reconfirme que tous les modules sont présents et fait remarquer que le fichier localconfig a changé, qu’il considère comme ayant été édité à votre satisfaction. Il compile les modèles UI [User Interface templates], se connecte à la base de données en utilisant l’utilisateur « bugs » que vous avez créé et le mot de passe que vous avez défini et il crée la base de données de « bugs » et les tables incluses.

Après cela, il demande des informations sur un compte administrateur. Bugzilla peut avoir plusieurs administrateurs – vous pouvez encore en créer d’autres plus tard – mais il en a besoin d’un pour commencer. Entrez l’adresse de courrier électronique d’un administrateur, son nom complet et un mot de passe Bugzilla approprié.

checksetup.pl a maintenant fini. Vous pouvez réexécuter checksetup.pl quand vous le souhaitez.

Web server

Configurez votre serveur web selon les instructions données dans la section appropriée. (Si cela peut influencer votre choix, l’équipe de Bugzilla recommande Apache.) Quel que soit le serveur web que vous utilisez, cependant, faites en sorte que les informations sensibles ne soient pas disponibles à distance en appliquant correctement les contrôles d'accès indiqués dans la section intitulée « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

httpd™ d'Apache

Chargez httpd.conf dans votre editeur.

Décommentez (ou ajouter) la ligne suivante. Ceci autorise Apache à exécuter les fichiers .cgi files en dehors du répertoire cgi-bin.

  AddHandler cgi-script .cgi

Apache utilise les directives <Directory> pour peaufiner les droits. Ajoutez les deux lignes suivantes à une directive <Directory> qui s'applique soît au répertoire Bugzilla ou l'un de ses parents (i.e. la directive <Directory /var/www/html>). Ceci autorisent les fichiers .htaccess de Bugzilla à outrepasser les permissions globales. et permet aux fichiers .cgi de tourner dans le répertoire Bugzilla.

  Options +ExecCGI +FollowSymLinks
  AllowOverride Limit

Ajoutez index.cgi a la fin de la ligne DirectoryIndex.

checksetup.pl peut mettre des permissions plus restreintes sur les fichiers et les répertoires de Bugzilla si il sait en tant que quel groupe le serveur web est exécuté. Trouvez la ligne Group dans httpd.conf et placez la valeur que vous y trouvez dans la variable $webservergroup dans localconfig. Puis réexécutez checksetup.pl.

Internet Information Services™ de Microsoft

Si vous êtes en train d’exécuter Bugzilla sous Windows et que vous choisissez d’utiliser Internet Information Services™ ou Personal Web Server™ de Microsoft, vous devrez exécuter un certain nombre d'autres étapes de configuration comme expliqué ci-dessous. Vous aurez peut-être également besoin de consulter les articles suivants de la base de connaissance de Microsoft : 245225 « HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1 » (pour Internet Information Services™) (NDT: « HOW TO : configurez et testez un script PERL avec IIS 4.0, 5.0 et 5.1 ») et 231998 « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server™) (NDT: « HOW TO : FP2000 : Perl utilisation avec serveur Web personnel Microsoft sous Windows 95/98 »).

Vous aurez besoin de créer un répertoire virtuel pour l’installation de Bugzilla. Mettez les fichiers de Bugzilla dans un répertoire dont le nom est différent du répertoire que vous voulez rendre accessible à l’utilisateur final. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à l’installation de  Bugzilla par « http://<lenomdevotredomaine>/Bugzilla », ne mettez pas les fichiers de Bugzilla dans un répertoire appelé « Bugzilla ». Mettez les plutôt dans un endroit différent, puis utilisez l’outil d’administration de IIS pour créer un répertoire virtuel appelé « Bugzilla » qui joue le rôle d’alias pour l’emplacement réel des fichiers. En créant ce fichier virtuel, assurez vous que vous avez ajouté les droits d’accès « Execute (comme les applications ISAPI ou CGI) ».

Vous devrez aussi dire à IIS comment s’y prendre avec les fichiers .cgi de Bugzilla. Utilisez de nouveau l’outil d’administration de IIS, ouvrez les propriétés pour le nouveau répertoire virtuel et choisissez l'option de configuration pour accéder aux scripts d’applications [Script Mapping]. Créez une entrée d’application .cgi à l’adresse :

<chemin complet vers perl.exe >\perl.exe -x<chemin complet vers Bugzilla> -wT "%s" %s
        

Par exemple :

c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
        

Note

L’installation d’ActiveState peut avoir déjà créé une entrée pour les fichiers .pl qui est limitée à « GET,HEAD,POST ». Si c’est le cas, cette application doit être supprimée car les fichiers .pl de Bugzilla ne sont pas conçus pour être exécutés via un serveur web.

IIS devra également savoir que l’index.cgi doit être traité comme un document par défaut. Sur la page onglets de Documents des propriétés du répertoire virtuel, vous devez ajouter index.cgi comme type de document par défaut. Si vous le voulez, vous pouvez effacer les autres types de document par défaut de ce répertoire virtuel particulier, puisque Bugzilla n’utilise aucun d’eux.

De plus, et on ne le soulignera jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme décrit dans la section intitulée « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

Serveur AOL

Ben FrantzDale que l’utilisation du serveur AOL avec Bugzilla a donné d’excellents résultats. Il a fait part de son expérience et celle-ci nous permet de proposer ce qui suit.

Le serveur AOL devra être configuré pour pouvoir exécuter les scripts CGI, veuillez consulter la documentation qui va avec votre serveur pour plus d’information sur la façon de procéder.

Parce que les serveurs AOL ne supportent pas les fichiers .htaccess, vous devrez créer un script TCL. Vous devrez créer un aolserver/modules/tcl/filter.tcl (le nom du fichier sera sans importance) avec le contenu suivant (remplacez /bugzilla/ par le chemin web de votre instance Bugzilla) :

  ns_register_filter preauth GET /bugzilla/localconfig filter_deny
  ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
  ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
  ns_register_filter preauth GET /bugzilla/*.pl filter_deny
  ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
  ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
  ns_register_filter preauth GET /bugzilla/data/* filter_deny
  ns_register_filter preauth GET /bugzilla/template/* filter_deny

  proc filter_deny { why } {
      ns_log Notice "filter_deny"
      return "filter_return"
  }
        

Avertissement

Ceci ne fonctionne probablement pas pour tous les fichiers de sauvegarde d’éditeur possibles alors vous aurez peut-être envie d’ajouter quelques variations supplémentaires de localconfig. Pour plus d'informations, voyez le bogue 186383 ou Bugtraq ID 6501.

Note

Si vous utilisez le logiciel webdot depuis research.att.com (la configuration par défaut pour le paramètre webdotbase), vous devrez autoriser l’accès à data/webdot/*.dot pour la machine reasearch.att.com.

Si vous utilisez une installation locale de GraphViz, vous devrez autoriser tout le monde à accéder aux *.png, *.gif, *.jpg et *.map dans le répertoire data/webdot.

Bugzilla

Votre Bugzilla devrait maintenant fonctionner. Allez sur http://<your-bugzilla-server>/ - vous devriez voir la page d’accueil de Bugzilla. Si ce n’est pas le cas, consultez la section Dépannage, Annexe B, Résolution des problèmes.

Identifiez vous avec le compte administrateur que vous avez défini lors de la dernière exécution de checksetup.pl. Vous devriez parcourir les options sur la page « Edit Parameters » (le lien est en bas de page) et voir s’il n’y en pas certaines que vous aimeriez changer. Les options importantes sont documentées dans la section intitulée « Configuration de Bugzilla »; vous devrez certainement modifier maintainer et urlbase; vous pouvez aussi modifier cookiepath ou requirelogin.

Cela pourrait être l’occasion de refaire un tour sur le fichier localconfig et de vous assurer que les noms des priorités, degrés de gravité [severities], plate-formes et systèmes d’exploitation sont ceux que vous souhaitez utiliser quand vous commencez à créer un bug. N’oubliez pas de réexécuter checksetup.pl si vous changez ce dernier.

Bugzilla a plusieurs options facultatives qui nécessitent des configurations supplémentaires. Vous pouvez vous documenter à ce sujet dans la section intitulée « Configuration supplémentaire facultative ».