Par défaut, MySQL acceptera seulement les paquets ayants une taille maximum de 64 ko. 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 ko) 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. (N.D.T. : la version française se trouve à 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.

Par défaut, MySQL limitera la taille de la table à 4 Go. 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 à 20 Go. 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 Section 2.1, « 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;

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 à 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™) (N.D.T. : « 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™) (N.D.T. : « 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 Section 3.1, « 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"
  }
        

	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.