Manuel PHP
Précédent |  | Suivant

# Chapitre 64. Installation

Cette section traite de questions courantes sur la façon d'installer PHP. PHP est disponible sur la plupart des systèmmes d'exploitation (sauf les versions de MacOS antérieures à Mac OSX) et pour quasiment n'importe quel serveur web.

Pour installer PHP, suivez les instructions présentes dans le fichier INSTALL livré avec les sources. Les utilisateurs de Windows doivent aussi lire le fichier install.txt. Des astuces intéressantes pour les utilisateurs de Windows sont aussi présentes ici.

1. Pourquoi ne doit-on pas utiliser Apache 2 dans un environnement de production ?
2. Unix/Windows: Où doit être placé mon fichier `php.ini`?
3. Unix : J'ai installé PHP, mais à chaque fois que je charge un document, j'obtiens l'erreur 'Document Contains No Data'! Que se passe-t-il?
4. Unix: J'ai installé PHP en utilisant des fichiers sources RPMS, mais apache ne traite pas les pages PHP. Que se passe-t-il?
5. Unix : J'ai installé PHP 3 en utilisant des paquets source RPMS, mais ils ne compilent pas avec le support de la base de données dont j'ai besoin! Que se passe-t-il?
6. Unix : J'ai patché Apache avec l'extension FrontPage et subitement, PHP ne fonctionne plus. Est-ce que PHP est incompatible avec l'extension FrontPage pour Apache ?
7. Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens un écran vide.
8. Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens une erreur de type 'server 500 error'.
9. Quelques systèmes d'exploitations : J'ai installé PHP sans erreur, mais lorsque je tente de démarrer Apache, j'otiens une erreur du type 'Undefined symbols' :

    [mybox:user /src/php4] root# apachectl configtest
     apachectl: /usr/local/apache/bin/httpd Undefined symbols:
      _compress
      _uncompress

10. Windows : J'ai installé PHP, mais lorsque j'accède à un fichier contenant un script PHP via mon navigateur, j'obtiens l'erreur :

    cgi error:
     The specified CGI application misbehaved by not
     returning a complete set of HTTP headers.
     The headers it did return are:

11. Windows : J'ai suivi toutes les instructions, mais je n'arrive toujours pas à faire fonctionner PHP et IIS ensemble !
12. Lorsque vous exécutez PHP comme CGI avec IIS, PWS, OmniHTTPD ou Xitami, j'obtiens l'erreur suivante : Security Alert! PHP CGI cannot be accessed directly..
13. Comment puis-je savoir si mon `php.ini` a bien été trouvé et lu ? Celà semble être le cas mais aucun de mes changements n'ont eu d'effets.
14. Où dois-je ajouter mon répertoire PHP à la variable PATH sous Windows ?
15. Comment rendre le fichier `php.ini` disponible à PHP sous Windows ?

1. Pourquoi ne doit-on pas utiliser Apache 2 dans un environnement de production ?

La réponse suivante est basée sur une réponse faite par mail par Rasmus Lerdorf.

Apache 2 est basé sur une réécriture complète ainsi qu'une toute nouvelle architecture de Apache 1. Ce n'est pas la même chose que d'aller de PHP 3 à 4 ou d'aller de PHP 4 à 5. La grande majorité du code est identique à toutes ces versions et très certainement, l'architecture de base de PHP n'a pas changé depuis des années. De ce fait, comparer Apache 1 et Apache 2 avec PHP 4 et PHP 5 n'a aucun sens. L'architecture a été prouvée depuis des années et le code, bien que difficilement maniable à certains endroits est une entité connue. PHP, depuis ces débuts, a été conçu pour l'architecture d'Apache 1 et fonctionne extrèmement bien dessus.

Le plus gros apport d'Apache 2 est la gestion des threads. Sous Windows, où la majorité des bibliothèques basiques gèrent et doivent gérer les threads, Apache 2 a actuellement un sens et il serait bon de l'utiliser sur cette plate-forme. Par contre, sous Unix, il y a beaucoup de bibliothèques basiques qui ne gèrent pas les threads. Celà n'est pas dû aux extensions de PHP mais plutôt la 3ème partie de ces centaines d'extensions de PHP. Il est vraiment difficile de déterminer si telle ou telle 3ème partie d'une extension est capable de gérer les threads. Il y a beaucoup de variables entrant en jeu, beaucoup d'OS, beaucoup de versions d'OS, quelle libc, quelle version de cette libc et sur certaines plate-formes, les flags utilisés lors de la compilation. Et pour rendre tout celà encore plus drôle, la gestion des problèmes lorsqu'un thread se termine inopinémant est très difficile, voir impossible. Des centaines de personnes rapportent que Apache+PHP+extenstion/foo fonctionnent parfaitement pour eux, mais peut être n'ont-ils qu'environs un million de visites par jour. Mais d'autres utilisateurs arrivent, ils ont environs 100 millions de visites par jour et utilisent une machine rapide avec deux processeurs et tout va mal car soudainement, la fenêtre pour quelques petites conditions spéciales a été trop large à cause de la rapidité des processeurs, le second processeur et haute fréquence des requêtes. Et les rapports de bogues que nous reçevons de la part de ces utilisateurs ressemblent à ceci :

> Celà ne fonctionne pas quelques fois. La pluspart du temps, tout fonctionne à merveille, et puis plus rien, ça ne fonctionne tout simplement plus du tout. L'erreur est différente à chaque fois et je n'ai aucune idée sur la procédure à effectuer pour la reproduire, mais allez donc trouver le problème maintenant !!

Que pouvons-nous faire face à celà ?

Il y a beaucoup de raisons techniques qui font dire à Rasmus que Apache2+PHP n'est pas une bonne idée dans un environnement de production que nous pourrions résumer ici en un seul concepte :

PHP est un colle. C'est la colle utilisée pour construire de belles applications web en utilisant beaucoup de bibliothèques ensemble, apparaissant comme une seule entité à travers un langage intuitif et facile à apparendre. La flexibilité et la puissance de PHP se fondent sur la stabilité et la robustesse de la plateforme 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 fondammental plus complexe en ne séparant pas les exécutions des threads, ni les segments mémoires, ni un endroit clôs pour traiter chaque requête entrante, des pieds d'argile sont introduits dans le système PHP.

Utiliser mpm avec Apache 2 pour permettre la gestion des threads est possible, et oui, en utilisant un méchanisme fastcgi indépendamment pour avoir la gestion des threads également, mais définir alors les caractéristiques des choix du serveur web sont évités. A ce point du développement, Rasmus continue de maintenir qu'il est plus juste de continuer avec Apache 1 pour servir des pages PHP avec l'inconvénient qu'Apache 1 ne fonctionne vraiment pas correctement sous Windows.

2. Unix/Windows: Où doit être placé mon fichier `php.ini`?

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 copirez le fichier `php.ini-dist` livré avec les sources vers `/etc/php.ini` et l'éditer pour l'adpater à 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.

3. Unix : J'ai installé PHP, mais à chaque fois que je charge un document, j'obtiens l'erreur 'Document Contains No Data'! Que se passe-t-il?

Celà 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 rationelles (ereg() et consorts), assurez vous que PHP et Apache ont été compilés avec les même outils d'expression rationelles. Celà doit être automatiquement le cas avec PHP et Apache 1.3.x.

4. Unix: J'ai installé PHP en utilisant des fichiers sources RPMS, mais apache ne traite pas les pages PHP. Que se passe-t-il?

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.

5. Unix : J'ai installé PHP 3 en utilisant des paquets source RPMS, mais ils ne compilent pas avec le support de la base de données dont j'ai besoin! Que se passe-t-il?

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 parceque les paquets RPMs utilise le répertoire /usr au lieu du répertoire standart /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-dessou explique la procédure pour ajouter le support de la base de données populaires, 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 installer MySQL et Apache complètement avec des paquets RPMs pour cette 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

Assurez-vous de redémarrer Apache et que vous avez PHP 3 avec le support MySQL en utilisant le paquet RPMs. Notez qu'il est probablement plus facile de compiler directement depuis l'archive tarball PHP 3 et de suivre les instructions du fichier `INSTALL.REDHAT` dans les sources de la distribution.

6. Unix : J'ai patché Apache avec l'extension FrontPage et subitement, PHP ne fonctionne plus. Est-ce que PHP est incompatible avec l'extension FrontPage pour Apache ?

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.

7. Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens un écran vide.

Affichez le code source du document dans votre navigateur et vous devriez probablement trouver le code source de votre script PHP. Celà signifie que le serveur web n'a pas envoyé le script à PHP pour interprétation. Quelque chose est donc incorrect 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.

8. Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP via mon navigateur, j'obtiens une erreur de type 'server 500 error'.

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 apparait (la sortie de la fonction phpinfo()), celà 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.

9. Quelques systèmes d'exploitations : J'ai installé PHP sans erreur, mais lorsque je tente de démarrer Apache, j'otiens une erreur du type 'Undefined symbols' :

    [mybox:user /src/php4] root# apachectl configtest
     apachectl: /usr/local/apache/bin/httpd Undefined symbols:
      _compress
      _uncompress

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

10. Windows : J'ai installé PHP, mais lorsque j'accède à un fichier contenant un script PHP via mon navigateur, j'obtiens l'erreur :

    cgi error:
     The specified CGI application misbehaved by not
     returning a complete set of HTTP headers.
     The headers it did return are:

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 commane, tentez d'accéder à votre script encore une fois via votre navigateur. Si 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 celà 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.

11. Windows : J'ai suivi toutes les instructions, mais je n'arrive toujours pas à faire fonctionner PHP et IIS ensemble !

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. Cette 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.

12. Lorsque vous exécutez PHP comme CGI avec IIS, PWS, OmniHTTPD ou Xitami, j'obtiens l'erreur suivante : Security Alert! PHP CGI cannot be accessed directly..

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`.

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

13. Comment puis-je savoir si mon `php.ini` a bien été trouvé et lu ? Celà semble être le cas mais aucun de mes changements n'ont eu d'effets.

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). Celà vous indiquera où PHP a cherché le `php.ini` et si oui ou non il l'a lu. Si il n'apparait qu'un chemin vers un répertoire existant, celà signifie que vous devez copier votre `php.ini` dans ce répertoire. Si le `php.ini` est présent dans le chemin, celà 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`.

14. Où dois-je ajouter mon répertoire PHP à la variable PATH sous Windows ?

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 boutton "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`

- Localisez la ligne avec PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;..... et ajoutez : ;C:\php à la fin de la ligne

- Sauvegardez le fichier et redémarrer l'ordinateur

15. Comment rendre le fichier `php.ini` disponible à PHP sous Windows ?

Il y a plusieurs façons de faire celà. 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 boutton "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 fchier : 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

Précédent | Sommaire | Suivant
Considérations sur les bases de données | Niveau supérieur | Problèmes de compilation