Chapitre 68. Installation

PHP est un mortier. C'est un mortier utilisé pour construire de belles applications web en utilisant beaucoup de bibliothèques ensemble, apparaissant comme une seule entité à travers un langage intuitif et facile à apprendre. La flexibilité et la puissance de PHP se fondent sur la stabilité et la robustesse de la plate-forme fondamentale. Il a besoin d'un OS qui fonctionne, d'un serveur web qui fonctionne et de bibliothèques externes pour coller le tout. Lorsqu'un seul de ces éléments arrêtent subitement de fonctionner, PHP doit identifier le problème et le réparer au plus vite. En rendant le cadre fondamental plus complexe en ne séparant pas les exécutions des threads, ni les segments mémoires, ni un endroit clos pour traiter chaque requête entrante, des pieds d'argile sont introduits dans le système PHP.

Et finalement, cette mise en garde contre les environnements MPM threadés n'est pas aussi forte pour les environnements Windows, où les bibliothèques sont mieux threadées.

Par défaut sous Unix, il doit être placé dans /usr/local/lib qui est en fait <install-path>/lib. La plupart des personnes voudront changer ceci lors de la compilation avec l'option --with-config-file-path. Vous pouvez par exemple le régler de cette façon :

--with-config-file-path=/etc

Et alors vous copierez le fichier php.ini-dist livré avec les sources vers /etc/php.ini et l'éditer pour l'adapter à vos besoins.

--with-config-file-scan-dir=PATH

Sous Windows, le chemin par défaut de php.ini est le répertoire de Windows. Si vous utilisez le serveur web Apache, php.ini est tout d'abord cherché dans le répertoire d'installation de Apache, c'est à dire c:\program files\apache group\apache. De cette façon, vous pouvez avoir un php.ini différent pour chaque version de Apache installée.

Consultez aussi le chapitre sur le fichier de configuration.

Cela signifie probablement que PHP rencontre un problème et génère un fichier core. Consultez vos fichiers de logs de votre serveur pour voir si c'est le cas, et tentez de reproduire le problème avec un test simple. Si vous savez utiliser 'gdb', il serait très utile de fournir un backtrace avec votre rapport de bogue, afin d'aider les développeurs à cerner le problème. Si vous utilisez PHP en module Apache, essayez ceci :

• Stoppez vos processus httpd

• gdb httpd

• Stoppez vos processus httpd

• > run -X -f /path/to/httpd.conf

• Pointez alors avec votre navigateur vers l'URL posant problème.

• > run -X -f /path/to/httpd.conf

• Si vous obtenez un fichier core, gdb doit alors vous en informer.

• tapez : bt

• Vous devriez inclure votre backtrace dans votre rapport de bogue. Celui-ci doit être posté sur http://bugs.php.net/.

Si votre script utilise les expressions rationnelles (ereg() et consorts), assurez-vous que PHP et Apache ont été compilés avec les même outils d'expression rationnelles. Cela doit être automatiquement le cas avec PHP et Apache 1.3.x.

En supposant que vous avez installé à la fois Apache et PHP à partir de fichiers RPM, vous devrez commenter ou ajouter au moins quelques unes des lignes suivantes dans votre fichier httpd.conf :

# Extra Modules AddModule mod_php.c AddModule mod_php3.c AddModule mod_perl.c # Extra Modules LoadModule php_module modules/mod_php.so LoadModule php3_module modules/libphp3.so # for PHP 3 LoadModule php4_module modules/libphp4.so # for PHP 4 LoadModule perl_module modules/libperl.so

Et ajouter :

AddType application/x-httpd-php3 .php3 # for PHP 3 AddType application/x-httpd-php .php # for PHP 4

... aux propriétés globales ou aux propriétés du VirtualDomain ou vous voulez que PHP officie.

La façon dont PHP 3 est compilé rend la contruction flexible de paquets RPM très peu aisée. Ceci est résolu avec PHP 4. Pour PHP 3, nous vous conseillons de suivre le mécanisme décrit dans le fichier INSTALL.REDHAT inclus avec les sources. Si vous persistez à vouloir construire des fichiers RPM de PHP 3, lisez ceci...

Les mainteneurs des paquets RPM ont configuré les paquets RPM à s'installer sans le support des bases de données pour simplifier l'installation et parce que les paquets RPM utilisent le répertoire /usr au lieu du répertoire standard /usr/local/ pour les fichiers. Vous devez spécifier au fichier de spécification du paquet RPM quelle base de données vous voulez utiliser et quel est chemin complet du serveur de votre base de données.

L'exemple ci-dessous explique la procédure pour ajouter le support de la base de données populaire, MySQL, en utilisant une installation en module d'Apache.

Bien sûr, toutes ces informations peuvent être ajustées pour n'importe quel serveur de bases de données que PHP supporte. Nous supposerons que vous avez installé MySQL et Apache complètement avec des paquets RPM pour cet exemple.

• Premièrement, supprimer mod_php3 :

  rpm -e mod_php3

• Ensuite, récupérer le paquet RPM et installez-le, SANS --rebuild

  rpm -Uvh mod_php3-3.0.5-2.src.rpm

• Ensuite, éditez le fichier /usr/src/redhat/SPECS/mod_php3.spec

  Dans la section %build, ajoutez le support de la base de données désiré ainsi que son chemin.

  Pour MySQL, vous devez ajouter --with-mysql=/usr La section %build devrait ressembler à quelque chose comme ceci :

  ./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --with-config-file-path=/usr/lib \ --enable-debug=no \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --with-mysql=/usr \ --with-system-regex

• Une fois cette modification effectuée, compiler le binaire RPM comme ceci :

  rpm -bb /usr/src/redhat/SPECS/mod_php3.spec

• Ensuite, installez le RPM

  rpm -ivh /usr/src/redhat/RPMS/i386/mod_php3-3.0.5-2.i386.rpm

Non, PHP fonctionne très bien avec l'extension FrontPage. Le souci vient du fait que le patch pour l'installation de FrontPage modifie la structure d'Apache, qui est relié à PHP. Recompiler PHP (en utilisant 'make clean ; make') après avoir patché Apache avec l'extension FrontPage devrait résoudre ce problème.

Affichez le code source du document dans votre navigateur et vous devriez probablement trouver le code source de votre script PHP. Cela signifie que le serveur web n'a pas envoyé le script à PHP pour interprétation. Quelque chose est donc incorrecte dans le fichier de configuration de votre serveur web - re-vérifier la configuration du serveur web en vous référant aux instructions d'installations de PHP.

Quelque chose se passe mal lorsque le serveur tente d'utiliser PHP. Pour tenter de récupérer un message d'erreur, depuis la ligne de commande, placez-vous dans le répertoire contenant l'exécutable PHP (php.exe sous Windows) et exécutez la commande php -i. Si PHP a un problème quelconque l'empéchant de fonctionner, un message d'erreur devrait s'afficher qui devrait expliquer comment résoudre ce souci. Si un écran de code HTML apparaît (la sortie de la fonction phpinfo()), cela signifie que PHP fonctionne correctement et que le problème doit certainement venir de la configuration de votre serveur web que vous devriez re-vérifier.

Cela n'a actuellement rien à voir avec PHP mais avec la bibliothèque cliente MySQL. Suivant les versions, elle a besoin que PHP soit compilé avec l'option --with-zlib, d'autre non. Ce problème est égaement traité dans la FAQ de MySQL.

Ce message d'erreur signifie que PHP a échoué lors de l'affichage. Pour tenter de récupérer un message d'erreur, depuis la ligne de commande, placez-vous dans le répertoire contenant l'exécutable PHP (php.exe sous Windows) et exécutez la commande php -i. Si PHP a un quelconque souci de fonctionnement, alors un message d'erreur le décrivant s'affichera. Si vous obtenez un écran de code HTML (le contenu du résultat de la fonction phpinfo()), alors PHP fonctionne correctement.

Si PHP fonctionne depuis la ligne de commande, tentez d'accéder à votre script encore une fois via votre navigateur. S'il échoue toujours, alors, il se peut que ce soit l'un des soucis suivants :

• Les permissions de votre script PHP des fichiers php.exe, php4ts.dll, php.ini ou de toute extension nécessaire à PHP que vous tentez de charger, sont telles que l'utilisateur internet anonyme de votre système ISUR_<machinename> ne peut pas y accéder.

• le script PHP n'existe pas (ou n'est pas à l'endroit que vous pensez, relativement au répertoire racine de votre serveur web). Notez que pour le serveur web IIS, vous pouvez vérifier cela en cochant la case 'vérifier si le fichier existe' lors de la configuration de l'exécution des scripts dans le gestionnaire de services Internet. Si un fichier de script n'existe pas, le serveur web retournera une erreur 404. IIS a également l'avantage d'effectuer tous les identifications requises à votre place, basés sur les permissions NTLanMan, sur votre fichier de script.

Assurez-vous que chaque utilisateur qui a besoin d'exécuter un script PHP possède les droits requis pour exécuter le fichier php.exe ! IIS utilise un utilisateur anonyme qui est ajouté lors de l'installation de IIS. Cet utilisateur doit avoir les droits suffisant sur le fichier php.exe. De même, tous les utilisateurs enregistrés doivent posséder les droits requis pour exécuter le fichier php.exe. Pour IIS4, vous devez lui dire que PHP est un moteur de script. De plus, vous devriez lire cette FAQ.

Vous devez définir la directive cgi.force_redirect à 0. Par défaut, elle vaut 1, donc, soyez sûr que cette directive n'est pas commentée (précédé d'un point virgule). Comme toutes les directives, elles sont définies dans le php.ini.

Comme la valeur par défaut vaut 1, il est impératif que vous soyez sûrs à 100% que le bon fichier php.ini a été lu. Lisez cette FAQ pour plus de détails.

Pour être sûr que votre php.ini a été lu par PHP, effectuez un appel à la fonction phpinfo() et vers le haut du document résultant, il devrait figurer une liste appelée Configuration File (php.ini). Cela vous indiquera où PHP a cherché le php.ini et si oui ou non il l'a lu. S'il n'apparaît qu'un chemin vers un répertoire existant, cela signifie que vous devez copier votre php.ini dans ce répertoire. Si le php.ini est présent dans le chemin, cela signifie qu'il a bien été lu.

Si le php.ini a bien été lu et que vous exécutez PHP comme module, alors assurez-vous de redémarrer le serveur web après avoir effectué les modifications à votre php.ini.

Sous Windows NT, 2000, XP et 2003 :

• Allez dans le centre de contrôle et ouvrez l'icône système (Démarrer -> Paramètres -> Panneau de configuration -> Système ou juste Démarrer -> centre de contrôle -> Système pour Windows XP/2003)

• Allez à l'onglet "Avancé"

• Cliquez sur le bouton "Variables d'environnements"

• Regardez dans le panneau "Variables systèmes"

• Trouvez l'entrée Path (vous devriez avoir à faire descendre l'ascenseur pour le trouver)

• Double cliquez sur l'entrée Path

• Entrez votre répertoire PHP à la fin, sans oublier le point virgule (;) avant (e.g. ;C:\php)

• Confirmez en cliquant sur OK et redémarrer votre ordinateur

Sous Windows 98/Me, vous devez éditer le fichier autoexec.bat :

• Ouvrez Notepad (Démarrer ->Exécuter et entrez notepad)

• Ouvrez le fichier C:\autoexec.bat

• Ajoutez une nouvelle ligne à la fin du fichier : set PHPRC=C:\php (remplacez C:\php par le dossier où se trouve le php.ini). Notez que le chemin ne doit pas contenir d'espaces. Par exemple, si vous avez installé PHP dans le dossier C:\Program Files\PHP, vous devez indiquer le chemin sous la forme C:\PROGRA~1\PHP.

• Sauvegardez le fichier et redémarrer l'ordinateur

Le manuel PHP vous encourage à copier les fichiers dans le dossier système de Windows car ce dossier (C:\Windows, C:\WINNT, etc.) se trouve par défaut dans le PATH système. Copier les fichiers dans le dossier système de Windows est depuis déprécié et peut causer des problèmes.

Il y a plusieurs façons de faire cela. Si vous utilisez Apache, lisez leurs instructions spécifiques d'installation (Apache 1, Apache 2) sinon, vous devez définir la variable d'environnement PHPRC :

Sous Windows NT, 2000, XP et 2003:

• Allez dans le centre de contrôle et ouvrez l'icône système (Démarrer -> Paramètres -> Panneau de configuration -> Système ou juste Démarrer -> centre de contrôle -> Système pour Windows XP/2003)

• Allez à l'onglet "Avancé"

• Cliquez sur le bouton "Variables d'environnements"

• Regardez dans le panneau "Variables systèmes"

• Cliquez sur "Nouveau" et entrez "PHPRC" comme nom de variable et le dossier où se trouve votre fichier php.ini comme valeur (e.g. C:\php)

• Confirmez en cliquant sur OK et redémarrer votre ordinateur

Sous Windows 98/Me, vous devez éditer le fichier autoexec.bat :

• Ouvrez Notepad (Démarrer ->Exécuter et entrez notepad)

• Ouvrez le fichier C:\autoexec.bat

• Ajouter une nouvelle ligne à la fin du fichier : set PHPRC C:\php (remplacez C:\php avec le dossier où se trouve le fichier php.ini)

• Sauvegardez le fichier et redémarrer l'ordinateur

Si les liens vers les fichiers PHP incluent l'extension, tout fonctionne parfaitement. Cette entrée de la FAQ traite uniquement du cas où les liens vers les fichiers PHP n'incluent pas l'extension et que vous voulez utiliser la négociation sur le contenu fourni par Apache pour choisir les fichiers PHP depuis une URL qui ne contient pas d'extension. Dans ce cas, remplacez la ligne AddType application/x-httpd-php .php par :

# PHP 4 AddHandler php-script php AddType text/html php # PHP 5 AddHandler php5-script php AddType text/html php

Cette solution ne fonctionne pas pour Apache 1 car le module PHP ne captura pas le php-script.

Non, il est possible de gérer tout type de méthode, comme CONNECT. Les bons entêtes de réponse peuvent être envoyés avec la fonction header(). Si seules les méthodes POST et GET doivent être gérées, cela se fait avec la configuration Apache suivante :

<LimitExcept GET POST> Deny from all </LimitExcept>