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 paquets 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
		

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.

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, « localconfig ».

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;
          

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.

	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.

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, « localconfig ».

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).

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

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.

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.

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;
          

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.

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

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

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.

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.