2.2. Configuration

Avertissement

Des installations mal configurées de MySQL et Bugzilla ont permis de donner l'accès complet au système aux pirates dans le passé. Veuillez prendre au sérieux les recommandations sur la sécurité de ce guide, même pour des machines Bugzilla protégées derrière votre pare-feu. Assurez-vous de lire Chapitre 4 pour ces conseils sur la sécurité importants.

2.2.1. localconfig

Vous devez maintenant exécuter checksetup.pl à nouveau, cette fois sans l'argument --check-modules.

bash# ./checksetup.pl

Cette fois, checksetup.pl devrait vous dire que tous les modules appropriés sont installés et affichera un message à ce sujet, et générera un fichier de sortie appelé localconfig. Ce fichier contient les paramètres par défaut pour un grand nombre de paramètres de Bugzilla.

Ouvrez ce fichier dans votre éditeur. Les deux seules valeurs que vous avez besoin de changer sont « $db_driver » et « $db_pass », respectivement le type de base de données et le mot de passe pour l'utilisateur qui créera pour vous la base de données. Choisissez un mot de passe compliqué (pour la simplicité, il ne dervait pas contenir d'apostrophe) et saisissez-le dans le fichier. « $db_driver » peut être 'mysql', 'Pg', 'oracle' ou 'SQLite'.

Note

Sous Oracle, $db_name devrait en fait être le nom du SID de votre base de données (par ex. « XE » si vous utilisez Oracle XE).

Vous devrez peut-être changer la valeur de webservergroup si votre serveur Web ne s'exécute pas dans le groupe « apache ». Sur Debian, par exemple, Apache s'exécute dans le groupe « www-data ». Si vous allez exécuter Bugzilla sur une machine où vous n'avez pas l'accès « root » (comme sur un serveur Web partagé hébergé), vous aurez besoin de laisser webservergroup vide, en ignorant les avertissements que checksetup.pl affichera à chacune de ses exécutions.

Attention

Si vous utilisez « suexec », vous devez utiliser votre propre groupe principal pour webservergroup plutôt que de le laisser vide, et consultez les autres directives dans la section suexec Section 2.6.6.1.

Les autres options du fichier localconfig sont documentés par les commentaires les accompagnant. Si vous avez une configuration légèrement non-standard, vous voudrez sans doute modifier un ou plusieurs autres paramètres « $db_* ».

2.2.2. Serveur de base de données

Cette section traite de la configuration de votre serveur de base de données utilisé avec Bugzilla. Actuellement, MySQL (Section 2.2.2.2), PostgreSQL (Section 2.2.2.3), Oracle (Section 2.2.2.4) et SQLite (Section 2.2.2.5) sont disponibles.

2.2.2.1. Schéma de la base de données de Bugzilla

Le schéma de la base de données de Bugzilla est disponible est disponible sur Ravenbrook. Cet outil très utile peut générer une description écrite du schéma de la base de données de Bugzilla pour toute version de Bugzilla. Il peut aussi générer un diff entre deux versions pour aider quelqu'un à voir ce qui a changé.

2.2.2.2. MySQL

Attention

La configuration par défaut de MySQL est peu sécurisée. Nous vous recommandons vivement d'exécuter mysql_secure_installation sous Linux ou l'installeur de MySQL sous Windows, et de suivre les instructions. Les points importants à noter sont :

  1. Assurez-vous que le compte root a son mot de passe défini.

  2. Ne créez pas de compte anonyme, et s'il en existe un, dites « oui » pour le supprimer.

  3. Si votre serveur Web et le serveur MySQL sont sur la même machine, vous devriez désactiver l'accès par le réseau.

2.2.2.2.1. Autoriser les gros fichiers et plusieurs commentaires

Par défaut, MySQL ne vous autorisera à insérer dans la base de données, que des objets plus petits que 1 Mo. Les fichiers joints peuvent être plus gros que cela. De même, Bugzilla concatÚne tous les commentaires d'un bogue dans un seul champ pour la recherche plein texte, et la somme de tous les commentaires d'un bogue sera vraisemblablement supérieure à 1 Mo.

Pour changer ce paramÚtre par défaut de MySQL, vous devez modifier votre fichier de configuration MySQL, qui est habituellement /etc/my.cnf sous Linux. Nous vous recommandons d'autoriser au moins des packets de 4 Mo en ajoutant le paramÚtre max_allowed_packet dans votre fichier de configuration MySQL dans la section [mysqld], comme ceci :

[mysqld]
			# Allow packets up to 4MB
			max_allowed_packet=4M
		

2.2.2.2.2. Autoriser les mots courts dans les index texte intégral

Par défaut, les mots doivent avoir au moins quatre caractères afin d'être indéxés par les index texte intégral de MySQL. Ceci fait que beaucoup de mots clés spécifique peuvent être manqués, y compris « cc », « ftp » et « uri ».

MySQL peut être configuré pour indexer ces mots en définissant le paramètre « ft_min_word_len » pour la taille minimale des mots à indexer. Ceci peut être fait en modifiant le fichier /etc/my.cnf comme l'indique 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 suivant les indications de la documentation sur http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html.

2.2.2.2.3. Ajouter un utilisateur à MySQL

Vous avez besoin d'ajouter un nouvel utilisateur à MySQL pour Bugzilla. (Il n'est pas sûr de faire utiliser par Bugzilla le compte « root » de MySQL). Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig ; si vous changez celles-ci, vous devez modifier la commande SQL en conséquence. Vous aurez besoin du mot de passe $db_pass que vous avez défini dans le fichier localconfig : Section 2.2.1.

Nous utilisons une commande SQL GRANT pour créer un utilisateur « bugs ». Ceci limite aussi l'utilisateur « bugs » aux opérations dans la base de données appelées « bugs » et ne permet à ce compte de se connecter qu'à partir de « localhost ». Modifiez-le pour refléter votre configuration si vous voulez vous connecter à partir d'une autre machine ou avec un utilisateur différent.

Exécutez le client en ligne de commande mysql et saisissez :


           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;
          

2.2.2.2.4. Autoriser la table des fichiers joints à dépasser les 4 Go

Par défaut, MySQL limitera la table à 4 Go. Cette limite est présente même si le système d'exploitation sur lequel est exécuté MySQL n'a pas cette limite. Pour définir une limite plus haute, suivez ces instructions.

Après avoir terminé le reste de l'installation (ou au moins les parties concernant la configuration de la base de données), vous devez exécuter le client en ligne de commande MySQL et saisir les commandes suivantes, en remplaçant $bugs_db avec votre nom de base de données (bugs par défaut) :


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

La commande ci-dessus changera la limite à 20 Go. Mysql devra faire une copie temporaire de toute votre table pour faire ceci. Idéalement, vous devriez faire ceci quand la table des fichiers joint est encore petite.

Note

Ceci n'affecte pas le champ « Gros fichiers », les fichiers qui sont stockés directement sur disque au lieu de la base de données.

2.2.2.3. PostgreSQL

2.2.2.3.1. Ajouter un utilisateur à PostgreSQL

Vous devez ajouter un nouvel utilisateur pour PostgreSQL pour que Bugzilla accède à la base de données. Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig ; si vous changez celles-ci, vous devrez modifier les commandes en conséquence. Vous devrez utiliser le mot de passe $db_pass que vous vaez défini dans localconfig : Section 2.2.1.

Sur la plupart des systèmes, pour créer l'utilisateur dans PostgreSQL, vous devrez vous connecter en tant qu'utilisateur « root » et saisir la commande

 bash# su - postgres

en tant qu'utilisateur « postgres », vous devez créer un nouvel utilisateur :

 bash$ createuser -U postgres -dRSP bugs

Quand un mot de passe vous sera demandé, fournissez le mot de passe qui sera défini pour $db_pass dans localconfig. L'utilisateur créé ne sera pas un super utilisateur (-S) et ne pourra pas créer de nouveaux utilisateurs (-R). Il aura seulement la possibilité de créer des bases de données (-d).

Note

Si vous utilisez PostgreSQL 8.0, vous devez remplacer -dRSP par -dAP.

2.2.2.3.2. Configurer PostgreSQL

Maintenant, vous devez modifier le fichier pg_hba.conf qui se trouve habituellement dans le répertoire /var/lib/pgsql/data/. Dans ce fichier, vous devez ajouter une nouvelle ligne, comme indiqué ci-dessous :

host all bugs 127.0.0.1 255.255.255.255 md5

Ceci signifie pour les connexions TCP/IP (hôte), de les autoriser pour « 127.0.0.1 » pour « all » (toutes) les bases de données de ce serveur pour l'utilisateur « bugs », et d'utiliser l'authentification de mot de passe (md5) pour cet utilisateur.

Maintenant, vous devez redémarrer PostgreSQL, mais vous devrez arrêter complètement le serveur et le démarrer au lieu de seulement le redémarrer à cause de la possibilité d'un changement dans le fichier postgresql.conf. Après le redémarrage du serveur, vous devrez modifier le fichier localconfig, en cherchant la variable $db_driver et en la définissant à Pg et en changeant le mot de passe dans $db_pass pour celui que vous avez choisi précédemment, lors de la création du compte.

2.2.2.4. Oracle

2.2.2.4.1. Créer un nouveau tablespace

Vous pouvez utiliser un tablespace existant ou en créer un nouveau pour Bugzilla. Pour créer un nouveau tablespace, exécutez la commande suivante :


    CREATE TABLESPACE bugs
    DATAFILE '$path_to_datafile' SIZE 500M
    AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED
          

Ici, le nom du tablespace est 'bugs', mais vous pouvez choisir un autre nom. $path_to_datafile est le chemin d'accès au fichier contenant votre base de données, par exemple /u01/oradata/bugzilla.dbf. La taille initiale du fichier de base de données est défini dans cet exemple à 500 Mo, avec un incrément de 30 Mo chaque fois que la taille limite du fichier est atteinte.

2.2.2.4.2. Ajouter un utilisateur à Oracle

Le nom d'utilisateur et le mot de passe doivent correspondre à ce que vous avez défini dans localconfig ($db_user et $db_pass, respectivement). Ici, nous supposons que l'utilisateur est 'bugs' et que le nom du tablespace est identique.


    CREATE USER bugs
    IDENTIFIED BY "$db_pass"
    DEFAULT TABLESPACE bugs
    TEMPORARY TABLESPACE TEMP
    PROFILE DEFAULT;
    -- GRANT/REVOKE ROLE PRIVILEGES
    GRANT CONNECT TO bugs;
    GRANT RESOURCE TO bugs;
    -- GRANT/REVOKE SYSTEM PRIVILEGES
    GRANT UNLIMITED TABLESPACE TO bugs;
    GRANT EXECUTE ON CTXSYS.CTX_DDL TO bugs;
          

2.2.2.4.3. Configurer le serveur Web

Si vous utilisez Apache, ajoutez ces lignes au fichier httpd.conf pour définir les variables ORACLE_HOME et LD_LIBRARY_PATH. Par exemple :


    SetEnv ORACLE_HOME /u01/app/oracle/product/10.2.0/
    SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/10.2.0/lib/
          

Quand ceci est fait, redémarrez votre serveur Web.

2.2.2.5. SQLite

Attention

En raison des limitations de concurrence de SQLite, nous ne le recommandons que pour des petites installations de Bugzilla ou des installations de développement.

Aucune configuration spéciale n'est requise pour exécuter Bugzilla avec SQLite. La base de données sera stockée dans data/db/$db_name, où $db_name est le nom de la base de données définie dans localconfig.

2.2.3. checksetup.pl

Ensuite, ré-exécutez checksetup.pl. Il confirmera à nouveau que tous les modules sont présents et remarquera la modification du fichier localconfig, en supposant que vous l'avez modifié à votre convenance. Il compile ensuite les modèles de l'interface utilisateur, 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 crée enfin la base de données « bugs » et les tables à l'intérieur.

Après cela, il demande des détails sur le compte administrateur. Bugzilla peut avoir plusieurs administrateurs - vous pouvez en créer plus plus tard - mais il en a besoin d'un pour démarrer. Saisissez l'adresse électronique d'un administrateur, son nom complet, et un mot de passe approprié pour Bugzilla.

checksetup.pl se terminera alors. Vous pouvez relancer checksetup.pl à tous moments si vous le souhaitez.

2.2.4. Le serveur Web

Configurer votre serveur Web selon les instructions de la section appropriée. (Si cela peut faire une différence dans votre choix, l'équipe de Bugzilla recommande Apache). Pour vérifier si votre serveur Web est correctement configuré, essayez d'accéder à la page testagent.cgi à partir de votre serveur Web. Si « OK » est affiché, alors votre configuration est correcte. Peu importe le serveur Web que vous utilisez, assurez-vous que les informations sensibles ne sont pas accessibles à distance en appliquant des contrôles d'accès corrects dans Section 4.2.1. Vous pouvez exécuter testserver.pl pour vérifier si votre serveur Web sert les pages de Bugzilla comme prévu.

2.2.4.1. Bugzilla utilisant Apache

vous avez deux options pour exécuter Bugzilla sur Apache : mod_cgi (par défaut) et mod_perl (nouveau à partir de Bugzilla 2.23)

2.2.4.1.1. Apache httpd avec mod_cgi

Pour configurer votre serveur Web Apache pour fonctionner avec Bugzilla en utilisant mod_cgi, suivez les instructions suivantes :

  1. Ouvrez le fichier httpd.conf dans votre éditeur. Sous Fedora et Red Hat Linux, ce fichier se trouve dans /etc/httpd/conf.

  2. Apache utilise des directives <Directory> pour permettre des paramètrages de permissions granulaires. Ajoutez les lignes suivantes à une directive s'appliquant à l'emplacement de votre installation Bugzilla. (Si une telle section n'existait pas, vous devrez en ajouter une). Dans cet exemple, Bugzilla a été installé dans /var/www/html/bugzilla.

    
    <Directory /var/www/html/bugzilla>
        AddHandler cgi-script .cgi
        Options +Indexes +ExecCGI
        DirectoryIndex index.cgi
        AllowOverride Limit FileInfo Indexes
        </Directory>
                    

    Ces instructions : autorisent Apache à exécuter les fichiers « .cgi » se trouvant dans le répertoire bugzilla ; indiquent au serveur de chercher un fichier appelé index.cgi si quelqu'un saisit seulement le nom du répertoire dans le navigateur ; et autorisent les fichiers .htaccess de Bugzilla à outrepasser les permissions globales.

    Note

    Il est possible de faire ces changements globalement ou sur la directive contrôlant le répertoire parent de Bugzilla (par ex. <Directory /var/www/html/>). De tels changements s'appliquent aussi au répertoire de Bugzilla directory… mais ils s'appliqueraient aussi à plein d'autres endroits où cela pourrait ne pas être approprié. Dans la plupart des cas, y compris celui-ci, il est mieux d'être aussi restrictif que possible lors de l'affectation de droits d'accès supplémentaires.

    Note

    Sous Windows, vous pourriez aussi avoir à ajouter la ligne ScriptInterpreterSource Registry-Strict, voir les notes spécifiques pour Windows.

  3. checksetup.pl peut définir des permissions plus réduites sur les fichiers et répertoires de Bugzilla s'il connaît le groupe dans lequel est exécuté le serveur Web. Cherchez la ligne Group dans le fichier httpd.conf, placez la valeur trouvée ici dans la variable $webservergroup du fichier localconfig, puis, ré-exécutez checksetup.pl.

  4. Optionnel : Si Bugzilla ne se trouve pas dans le répertoire de l'espace Web, mais a été lié symboliquement ici, vous devrez ajouter ce qui suit à la ligne Options de la directive <Directory> de Bugzilla (la même que dans l'étape précedente) :

    
    +FollowSymLinks
                    

    Sans cette directive, Apache ne suivra pas les liens symboliques aux emplacements extérieurs à sa propre structure de répertoires et vous ne pourrez pas exécuter Bugzilla.

2.2.4.1.2. Apache httpd avec mod_perl

Une certaine configuration est requise pour faire fonctionner Bugzilla avec Apache et mod_perl

  1. Ouvrez httpd.conf dans votre éditeur. sous Fedora et Red Hat Linux, ce fichier se trouve dans /etc/httpd/conf.

  2. Ajoutez les informations suivantes à votre fichier httpd.conf, en substituant où cela est approprié vos propres chemins d'accès locaux.

    Note

    Ceci doit être utilisé au lieu du bloc <Directory> indiqué plus haut. Ceci doit aussi être placé au-dessus de toute autre directive mod_perl dans le fichier httpd.conf et doit être spécifié dans l'ordre indiqué ci-dessous.

    Avertissement

    Vous devez aussi vous assurer que vous avez désactivé la gestion de KeepAlive dans votre installation Apache en utilisant Bugzilla avec mod_perl

    
    PerlSwitches -w -T
        PerlConfigRequire /var/www/html/bugzilla/mod_perl.pl
                    
  3. checksetup.pl peut définir des permissions plus réduites sur les fichiers et répertoires de Bugzilla s'il connaît le groupe dans lequel est exécuté le serveur Web. Cherchez la ligne Group dans le fichier httpd.conf, placez la valeur trouvée ici dans la variable $webservergroup du fichier localconfig, puis, ré-exécutez checksetup.pl.

Au redémarrage d'Apache, Bugzilla devrait alors fonctionner en environnement mod_perl. Veuillez vous assurer d'avoir exécuté checksetup.pl pour définir les permissions avant de redémarrer Apache.

Note

Veuillez garder à l'esprit les points suivants quand vous cherchez à utiliser Bugzilla avec mod_perl :

  • La gestion mod_perl dans Bugzilla peut consommer ÉNORMÉMENT de RAM. Vous pouvez compter facilement 30 Mo par processus httpd enfant. En gros, vous avez seulement besoin de beaucoup de RAM. Plus vous en aurez, mieux ce sera. mod_perl utilise basiquement la mémoire pour augmenter la vitesse de traitement. Il est recommandé d'avoir au moins 2 Go de RAM pour exécuter Bugzilla sous mod_perl.

  • Sous mod_perl, vous devez redémarrer Apache si vous faites un chagement manuel sur tout fichier de Bugzilla. vous ne pouvez pas seulement recharger -- vous devez en fait redémarrer le serveur (être sûr qu'il soit arrêté puis démarré à nouveau) Vous pouvez modifier le fichier localconfig et le fichier des paramètres, si vous le voulez, car ceux-ci sont lus chaque fois que vous chargez une page.

  • Vous devez exécuter « Prefork MPM » de Apache (c'est l'option par défaut). Le « Worker MPM » peut ne pas fonctionner -- nous n'avons pas testé Bugzilla sous mod_perl avec la gestion des threads. (Et en fait, nous sommes pratiquement sûrs que cela ne fonctionnera pas.)

  • Bugzilla s'attend généralement à être la seule application fonctionnant sous mod_perl sur tout le serveur. Il peut ne pas fonctionner s'il y a d'autres applications fonctionnant aussi sous mod_perl. Il s'efforcera de cohabiter avec d'autres applications sous mod_perl, mais il pourra y avoir des conflits.

  • Il est recommandé de n'avoir qu'une seule instance de Bugzilla fonctionnant sous mod_perl sur votre serveur. Bugzilla n'a pas été testé avec plus d'une instance.

2.2.4.2. Microsoft Internet Information Services

Si vous voulez exécuter Bugzilla sur Windows et choisir d'utiliser Microsoft Internet Information Services ou Personal Web Server vous aurez besoin de réaliser d'autres étapes de configuration comme expliqué ci-dessous. Vous pouvez aussi vous référez aux articles 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) et 231998 « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server).

Vous devrez créer un répertoire virtuel pour l'installation de Bugzilla. Mettez les fichiers Bugzilla dans un répertoire appelé autrement que le nom que vous voulez que vos utilisateurs voient. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à votre installation Bugzilla par « http://<votre_nom_de_domaine>/Bugzilla », alors ne mettez pas vos fichiers Bugzilla dans un répertoire nommé « Bugzilla ». Au lieu de cela, placez les dans un emplacement différent et utilisez l'outil d'administration de IIS pour créer un répertoire virtuel nommé « Bugzilla » qui se comporte comme un alias pour l'emplacement réel des fichiers. Lors de la création du répertoire virtuel, assurez-vous d'ajouter les permissions « Exécuter les scripts ».

Vous devrez aussi indiquer à IIS comment Bugzilla doit manipuler les fichiers « .cgi ». Utilisez à nouveau l'outil d'administration de IIS, ouvrez les propriétés du nouveau répertoire virtuel et sélectionnez l'option « Configuration » pour accéder à l'association de fichiers. Créez une entrée « .cgi » ainsi :


<chemin d'accès complet à perl.exe >\perl.exe -x<chemin d'accès complet à Bugzilla> -wT "%s" %s
        

Par exemple :


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

Note

L'installation de ActiveState a peut-être déjà créé une entrée pour les fichiers « .pl » qui est limitée à « GET,HEAD,POST ». Si c'est le cas, cette association doit être retirée car les fichiers « .pl » de Bugzilla ne sont pas conçus pour être exécutés par un serveur Web.

IIS devra aussi savoir que le fichier index.cgi doit être traité comme le document par défaut. Dans l'onglet « Documents » dans la page de propriétés du répertoire virtuel, vous devez ajouter « index.cgi » comme type de document par défaut. si vous le souhaitez, vous pouvez retirer les autres types de document pour ce répertoire virtuel particulier, puisque Bugzilla ne les utilise pas.

Et aussi, nous ne le dirons jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme indiqué dans Section 4.2.1.

2.2.5. Bugzilla

Votre installation de Bugzilla devrait à présent fonctionner. Accédez à la page http://<votre-serveur-bugzilla>/ - vous devriez voir la page d'accueil de Bugzilla. Si ce n'est pas le cas, consultez la section « Dépannage », Annexe A.

Note

L'URL ci-dessus peut être incorrecte si vous avez installé Bugzilla dans un sous-répertoire ou utilisé un lien symbolique depuis la racine de votre site Web vers le répertoire de Bugzilla.

Connectez-vous avec le compte administrateur que vous avez défini lors du dernier lancement de checksetup.pl. Rendez-vous sur la page des paramètres et regardez s'il y a des paramètres que vous souhaitez changer. Les paramètres clés sont documentés dans Section 3.1 ; vous devriez certainement modifier les paramètres maintainer et urlbase ; vous pourriez aussi vouloir modifier les paramètres cookiepath ou requirelogin.

Bugzilla comporte plusieurs fonctionnalités optionnelles qui nécessitent une configuration supplémentaire. Vous pouvez lire cela dans Section 2.3.