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.
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.
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.
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.
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).
Le paramètre Ft_min_word_len est supporté seulement dans MySQL v4 ou supérieure.
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.
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;
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.
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 ».
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
.
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
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 ».
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" }
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.
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
.
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 ».