3.15. Une installation, plusieurs instances¶
Ceci est destiné aux spécialistes. Si vous ne savez pas si vous en avez besoin, c'est que vous n'en avez pas besoin. Ceci est utile pour les administrateurs qui voudraient exécuter plusieurs instances distinctes de Bugzilla en utilisant une seule installation du code.
Ceci est possible en utilisant la variable d'environnement PROJECT
. Quand il est accédé,
Bugzilla vérifie l'existence de cette variable, et si elle est présente, utilise sa
valeur pour vérifier la présence d'un fichier de configuration alternatif appelé
localconfig.<PROJECT>
au même emplacement que celui par
défaut (localconfig
). Il vérifie aussi la présence de modèles
personnalisés dans le répertoire nommé <PROJECT>
au même emplacement que celui
par défaut (template/<langcode>
). Par défaut, c'est le
répertoire template/en/default
donc les modèles de PROJECT
se trouveraient
dans template/en/PROJECT
.
Pour définir une installation alternative, exporter la variable PROJECT=toto
avant de
lancer checksetup.pl pour la première fois. Les noms des projets ne peuvent contenir
que des lettres, des chiffres, des traits de soulignement ou des tirets. Il en résultera un fichier
nommé localconfig.toto
au lieu
de localconfig
. Modifiez ce fichier comme décrit plus haut, avec la référence
à une nouvelle base de données, et relancez checksetup.pl
pour la populer. C'est tout.
Maintenant, vous devez paramétrer le serveur Web pour lui passer cette variable d'environnement quand il est accédé via une URL alternative, comme un hôte virtuel par exemple. Ce qui suit est un exemple de ce que vous pouvez faire avec Apache, cela peut différer pour les autres serveurs Web.
<VirtualHost 12.34.56.78:80>
ServerName bugzilla.example.com
SetEnv PROJECT toto
</VirtualHost>
N'oubliez pas aussi d'exporter cette variable avant d'accéder à Bugzilla
par d'autres voies, comme les tâches programmées de cron
par exemple.