Steve Frécinaux

PHP 4 et 5, avec Gentoo cette fois.

Aujourd’hui, j’ai mis en place un serveur de test sur mon ordinateur sous gentoo linux. Rien de bien difficile a priori, pas question de compiler tout par soi-même, laissons faire portage il est là pour ça. Le début, très classique : installation d’Apache 2 et de MySQL.

# emerge apache mysql

On a donc les trois premières composantes de notre serveur « LAMP » : Linux, Apache et MySQL. Il serait possible de faire se charger apache automatiquement, mais comme je ne l’utilise pas tout le temps, ça ne m’intéresse pas pour le moment. Je passerai outre la configuration, car à part mettre DocumentRoot /home/apache je n’ai pas fait grand chose.

Reste à installer PHP. Comme nous sommes dans une période charnière entre l’ancienne et la nouvelle version du langage, il est de bon ton d’installer les deux interpréteurs, tout comme je l’avais fait sous Windows, pour pouvoir développer avec la nouvelle version tout en continuant à utiliser sans problème des scripts plus anciens. J’ai choisi la même configuration que précédemment, c’est-à-dire PHP 5 en tant que module, et PHP 4 en tant que CGI.

Commençons donc par le module. Le paquet dev-php/mod_php-5.0.0 n’existant pas encore en version stable, il faut indiquer à Portage que nous voulons vraiment l’installer. Il faut donc le « démasquer » :

# echo "=dev-php/mod_php-5.0.0" >> /etc/portage/package.unmask
# echo "=dev-php/mod_php-5.0.0 -x86" >> /etc/portage/package.keywords

après cela, il reste à fignoler les USE selon les extensions que l’on veut utiliser, éventuellement indiquer à Portage que l’on désire utiliser certaines dépendances en version testing et puis il ne reste plus qu’à installer le module, via la commande # emerge mod_php (sans oublier auparavant de vérifier ce qui va être installé, via l’option –pretend). Bref, installation très classique, rien à redire.

À la fin de la compilation, Portage me dit d’ajouter -D PHP5 à la variable APACHE2_OPTS, dans le fichier /etc/conf.d/apache2, de sorte que Apache interprètera le contenu de /etc/apache2/conf/modules.d/70_mod_php5.conf. Personnellement, je n’aime pas trop le contenu de ce fichier (les RequestHeader unset If- Modified-Since notamment, qui empêchent la mise en place d’un cache HTTP, j’édite donc ce fichier de configuration de sorte qu’il n’en reste plus que ça :

<IfDefine PHP5>
   LoadModule php5_module modules/libphp5.so
   AddType application/x-httpd-php .php .php5
   AddType application/x-httpd-php-source .phps
</IfDefine>

Reste à créer un fichier dans le serveur contenant et portant l’extension .php5 pour tester. Tant qu’à faire, autant en créer directement une copie, avec l’extension .php4 cette fois…

Au tour du CGI. La version qui nous intéresse ici est la version stable, numérotée 4.3.8. Rien à faire donc du côté des paquets, il n’y a donc qu’à installer. Portage m’indique que le paquet php-cgi requiert le paquet php. Cette version (CLI) ne m’intéresse pas, mais si ça peut lui faire plaisir… Personnalisation de la variable USE, et puis installation :

# emerge php-cgi

Seulement il y a un hic. Les deux paquets ont été compilés, mais un seul binaire est présent, et bien entendu il s’agit de la version CLI, bref, pas celle qui m’intéresse. Du coup Apache ne veut rien savoir. Coup d’œil dans l’ebuild, il est censé renommer le binaire php issu de la compilation en php-cgi pour ne pas entrer en conflit avec le binaire CLI. Seulement, après plusieurs essais, une compilation sans dépendance (au cas où le binaire ne serait pas renommé et serait donc écrasé) et quelques petites modifications du fichier ebuild, il semble tout simplement qu’aucun binaire n’est généré par le paquet php-cgi !

Google est mon ami, je tombe, dans les forums gentoo, sur une explication sur comment faire un CGI à partir CGI à partir du paquet php, explication qui date d’avant la création du paquet php-cli. Solution : remplacer, dans /usr/portage/dev-php/php/php-4.3.8.ebuild, la ligne –disable- cgi par –enable-cgi –enable-fast-cgi. Une fois le remplacement effectué et les deux paquets désinstallés, je relance la compilation : # emerge –oneshot php (l’option –oneshot pour que le paquet ne soit pas pris en compte lors des mises à jour). Cette fois, comme me l’indique la commande $ php –version, le binaire généré est bien la version CGI. (Si d’aventure je mettais à jour l’interpréteur, il faudrait juste que je pense à copier les extensions dans un autre répertoire et à modifier le php.ini en conséquence.)

Maintenant, il est temps de configurer apache pour les fichiers .php4. Pour commencer, je copie le CGI dans un répertoire distinct (/home/apache/cgi-bin), je définit « apache » comme propriétaire et groupe du binaire, et je modifie en conséquence la ligne correspondante dans /etc/apache2/commonapache2.conf :

ScriptAlias "/cgi-bin/" /home/apache/cgi-bin/

Ensuite, ajoutons l’appel du CGI à la fin du fichier de configuration /etc/apache2/conf/apache2.conf :

<Directory /home/apache/cgi-bin/>
   Allow from all
   Options +FollowSymLinks +ExecCGI
</directory>
AddType application/x-httpd-php-4    .php4
Action application/x-httpd-php-4 /cgi-bin/php

Reste les Virtual Hosts, l’installation de phpMyAdmin et d’un équivalent pour Sqlite et la configuration est terminée, j’ai maintenant un serveur tout beau tout propre qui fonctionne, au moins jusqu’à la prochaine update de PHP.

Enfin, tout ça pour dire que même quand les ebuild sont pourries, y’a moyen de s’en sortir ;) Reste à espérer que ce bug ennuyant sur lequel j’ai dépensé mon après-midi disparaîtra…