Installer php4 et php5 en même temps
Par Laurentj le samedi, mai 7 2005, 12:34 - Geek-log - Lien permanent
Sur mon serveur fraîchement ré-installé, j'ai installé apache et php4. Cependant, il n'est pas possible d'avoir PHP4 et PHP5 en même temps pour une même instance d'apache (pour d'obscures raisons au niveau d'apache). Si on veut pouvoir avoir les deux en mêmes temps, une astuce consiste à lancer deux instances d'apaches, avec une configuration différente.
Je n'ai pas installé apache et php à partir des packages debian. De toute façon, il n'y a pas de packages officiels debian pour PHP5. J'ai ainsi décidé de recupérer les sources du serveur web, de php4 et de php5, et de me compiler tout ça avec toutes les options que je veux.
compilation
Pour la compilation d'apache, rien de spécifique. J'ai juste indiqué les repertoires d'installation (avec les directives --prefix &co de configure ou mieux en indiquant tout ça dans un fichier layout). Les mêmes binaires me serviront pour mes deux instances d'apache.
Pour la compilation de php, il faut faire attention de spécifier un répertoire d'installation différent pour les deux versions differentes de php (avec la directive --prefix), sinon les binaires de l'un écraseront ceux de l'autre lors de l'installation. Ainsi, j'ai indiqué le répertoire /usr/local/php4 pour PHP4 et /usr/local/php5 pour PHP5. Je préfère avoir le fichier php.ini dans le repertoire d'apache, pour plus de commodité. On ne peut pas choisir le nom du fichier php.ini, donc là encore, il faut spécifier un repertoire différent avec la directive --with-config-file-path. Dans mon cas, ça sera donc /etc/apache/php4/ et /etc/apache/php5/. Pour le reste,j'ai suivi les instructions comme indiqué dans la documentation de PHP.
configuration d'apache
Une fois tout compilé et installé, il faut passer à la phase de configuration d'apache. Je veux donc lancer deux instances d'apaches. J'ai donc crée deux fichiers, /etc/apache/httpd-4.conf et /etc/apache/httpd-5.conf, avec donc une configuration différente :
- écoute sur un port différent (80 pour la version PHP4, 81 pour la version PHP5)
- fichier de lock, de pid, de scoreboard, de log et d'erreur différent (ex, pour la version PHP4 : /var/run/httpd-4.lock, /var/run/httpd-4.pid, /var/run/httpd-4.scoreboard /var/log/apache/access-4.log /var/log/apache/error-4.log
- chargement de module différent :
LoadModule php4_module lib/apache/libphp4.sopour php4 etLoadModule php5_module lib/apache/libphp5.sopour php5 - un NameVirtualHost différent : 192.168.1.1:80 et 192.168.1.1:81
Pour le reste de la configuration, c'est totalement identique. D'ailleurs, pour plus de simplicité, j'ai déclaré mes hôtes virtuels dans un fichier séparé, que j'inclus dans mes deux fichiers de configuration d'apache.
configuration du lancement
Pour lancer apache, il existe un script, /usr/local/sbin/apachectl, dans lequel est indiqué notament le fichier de configuration à lancer, le fichier pid à utiliser etc.. Donc là encore, il faut dupliquer ce script (apachectl-4 et apachectl-5 par exemple) et modifier chaque copie pour que l'une lance apache avec http-4.conf, et l'autre lance apache avec http-5.conf.
J'ai ensuite crée les scripts de démarrage automatique dans /etc/init.d/. Il en faut un pour les deux instances d'apache. Je me suis basé sur le script /etc/init.d/apache livré avec le package d'apache pour debian. Je l'ai modifié pour que ça lance apachectl plutôt que de passer par le programme start-stop-daemon. Ça donne ça pour /etc/init-d/apache-4 (extrait):
NAME=apache-4
DAEMON=/usr/local/sbin/httpd
PIDFILE=/var/run/httpd-4.pid
CONF=/etc/apache/httpd-4.conf
APACHECTL="/usr/local/sbin/apachectl-4"
(...)
case "$1" in
start)
$ENV $APACHECTL start
;;
stop)
$ENV $APACHECTL stop
rm -rf /var/lib/apache/mod-bandwidth/link/*
;;
reload | force-reload)
$ENV $APACHECTL graceful
;;
restart)
$ENV $APACHECTL restart
;;
*)
echo "Usage: /etc/init.d/apache {start|stop|reload|force-reload|restart}"
exit 1
;;
esac
Ensuite, il restait plus qu'à faire un update-rc.d apache-4 stop 91 0 1 6 . start 91 2 3 4 5 . et update-rc.d apache-5 stop 91 0 1 6 . start 91 2 3 4 5 . pour que ça se lance automatiquement au démarrage de la machine.
lancement
Aprés avoir démarré mes deux instances d'apache (/etc/init.d/apache-4 start et /etc/init.d/apache-5 start), j'ai pu afficher une page montrant le phpinfo. En tapant http://monserveur/phpinfo.php, j'obtenais bien l'information sur la config de PHP4 et en faisant http://monserveur:81/phpinfo.php, celle de PHP5. Magique ! :-) Ceci va me permettre de tester mes applis avec les deux versions de PHP, en changeant simplement le numéro de port.
Commentaires
Bien compliqué ta méthode :-)
Perso j'aime bien mettre PHP4 en module et PHP5 en CGI le tout sur la même instance d'Apache (voir les deux en CGI). Pour passer de l'un à l'autre, soit on joue avec le numero de version dans l'extension des fichiers, soit on met un AddHandler dans un .htaccess.
Bien lourde ta méthode à l'usage :-p
Car si tu veux tester une même appli en php4 et php5, tu dois alors avoir une copie différente avec des extensions différentes. Donc pour tester, tu es obligé de travailler sur deux versions différentes de ton appli en même temps. Ou alors il te faut modifier à chaque fois ton .htaccess pour passer de l'un à l'autre. Lors du developpement intensif, je trouve que ma méthode est plus simple : on a juste à rajouter un numéro de port dans l'url.
Je préfère m'embeter un peu à l'installation, que d'être tout le temps embeter lors de mes développements ;-)
Et puis CGI, c'est plus lent. Surtout quand il s'agit d'une appli avec des dizaines d'include.
Je ne vois pas trop de différences entre le temps de commenter ou non une ligne dans le .htaccess ou ajouter un port dans l'url mais bon.
Pour ce qui est des includes multiple en CGI, je n'ai vu aucune différence (bon certes, je ne fais pas non plus 10Mo d'include), si tu as des bench je suis preneur.
Le problème de ta méthode c'est qu'elle ne fonctionne uniquement sur un serveur de dév (ce qui était ton but) mais complètement inexploitable sur un serveur de prod. La miènne si :-)
Tu n'as pas à éditer un fichier, tout simplement. Regarde. Pour tester en php5 une page que je viens d'afficher pour php4, je fais :
(ou encore mieux, juste un simple clic sur un bookmark)
Et voilà. Je te laisse compter toutes les manips à faire dans ton cas :-p Moins je fais de manip, mieux je me porte, et plus je suis productif. Si je peux économiser des manips, je le fais. Mes petits doigts fatigués s'en porteront beaucoup mieux.( éviter les TMS, tout ça ...)
Pour les CGI, de par mon expérience professionnelle, j'ai vu une grosse différence entre des serveurs mutualisés qui étaient en CGI, et des serveurs mutualisés qui étaient en module apache. Pour de simple script, on ne la voit pas, mais pour des applis basées sur Copix où il y a beaucoup d'include, on le remarque tout de suite. Tu vas me dire qu'il y a d'autres parametres qui entrent en jeux (charge serveur, quota etc..) mais d'un point de vue général, c'est ce que j'ai remarqué. Et il est communément admis que passer par un CGI, ça coûte plus que passer par un module apache (pour une simple histoire d'architecture interne).
Désolé, je ne développe que sur des serveurs de dev moi :-p Rien à faire que configurer comme j'ai fait sur un serveur de prod est impossible. Je l'ai configurer comme ça pour des raisons *pratiques* de développement. Mon billet n'a pas pour cible les hébergeurs.
Laurent, tu opposes "mise en module et séparation par le port TCP" à "mise en CGI et séparation par extension". Ca fausse.
Quand bien même, il existe un intermédiaire qui bénéficie de beaucoup des avantages du module (ne pas relancer un processus à chaque fois, pouvoir gérer des connexions permanentes) et les avantages du CGI (processus indépendant du serveur Web, pouvoir séparer les droits d'accès) : c'est FastCGI. FastCGI tient à jour un pool de process PHP qu'il va réutiliser au besoin, un peu comme Apache fait avec lui même. Les performances sont quasi identiques au module.
Essayez FastCGI, ça n'a quasi que des avantages.
L'histoire du second apache en parallèle, je ne suis pas convaincu : quand tu lances un apache, tu lances en fait n processus. Et ce nombre est configurable dans le httpd.conf. Il suffit de faire les bons reglages pour éviter d'avoir une machine surchargée quand tu lances deux fois apache. Ce que j'ai fait. (resultat : j'ai pas plus de processus que la conf par défaut d'apache, et pour un serveur de dev, c'est suffisant). Et encore, vu que je suis loin d'entamer mon swap, j'aurais pu laisser comme tel.
Pour l'histoire du fastcgi, tu as surement raison. Pour l'histoire du CGI sur un serveur de dev, peut etre que je ne verrais pas la différence effectivement, mais j'ai préféré optimisé directement plutôt que de tester cette solution qui ne m'a pas laisser de joli souvenir :-)
Concernant ta solution intermediaire : j'ai actuellement sur mon serveur local une vingtaine de virtual host (tout mes sites en dev, divers applis etc..). Ça devient lourd à gerer si il faut 2 virtual host pour chaque site. (ce qui ne l'est pas actuellement puisque les 2 conf partagent le fichier déclarant les virtualhost). (ça m'arrive souvent de modifier mes virtualhosts)
Comme je disais, je prefère m'embeter un peu plus à l'installation (chose que je ne vais faire qu'une fois) et me faciliter la vie pour le reste du temps que le contraire.
Enfin du moins, pour l'instant, la solution allant dans ce sens que j'ai choisie est la mieux pour moi, je pense. Si je dois reinstaller un jour mon apache, je regarderais du coté de fastcgi, que je ne connais pas vraiment.
Cette méthode me semble bien compliquée quand même. Ça va pour 2 version de PHP mais quand tu en as 5 ou 6, la méthode du CGI appelé par un AddHandler dans un .htaccess me semble bien plus simple. C'est ce que je fais pour tester dotclear de PHP 4.1.2 à PHP 5. En plus, les CGI permettent parfois de soulever des problèmes courants chez les hébergeurs (la gestion des en-tête HTTP par exemple). Ce que j'utilise c'est la définition de plusieurs handler par version de php et juste une directive Action à changer pour switcher d'une version à l'autre (ou à commenter pour repasser sur la version en module d'Apache).
A noter que les packages WAMP (www.wampserver.com/) en français et XAMPP (http://www.apachefriends.org/en/xampp.html) en anglais), propose un switch PHP4/PHP5 ultra-simple sous la forme d'un add-on.