Serveur web Apache sous Mac OS X : Partie 3
Note du Rédacteur : Dans la première partie de cette série, Kevin vous a montré comment démarrer facilement un serveur de pages Web sur votre ordinateur Mac OS X. Puis, dans le deuxième article, il a exploré le monde des accés CGI. Aujourd’hui, il aborde le trés célébre module PHP.
Mise en route de PHP4
Nous arrivons presque aux derniéres étapes de notre ballade “Ruelle des Fonctionnalités, Impressiville”. Ce sera la section la plus facile de notre voyage, principalement parce que nous allons passer en revue des aspects que nous connaissons déjà. Tout comme CGI, PHP est très populaire, trés bien supporté et très souvent installé par défaut sur les serveurs web.
Tout comme SSI, le code est inclus et interprété dans le code HTML réel de vos pages Web.
De la même façon que nous l’avons fait dans les sections relatives au CGI et à SSI, la mise en route de PHP implique
la recherche du mot particuliers (”php”) dans notre fichier de configuration Apache. Ouvrez le fichier de configuration avec pico :
sudo pico /etc/httpd/httpd.conf
Les premières occurences auxquelles nous nous heurtons sont :
# LoadModule php4_module libexec/httpd/libphp4.so # AddModule mod_php4.c
Ces lignes ressemblent à celles que nous avons rencontrées quand nous nous amusions avec les CGI - ils permettent d’activer ou de désactiver le chargement de PHP au démarrage de notre serveur Apache. Puisqu’ils sont mis en commentaires avec le caractére “#“, nous devons enlever ce caractére pour rendre les lignes actives. Si vous vous sentez prêts, faites-le maintenant. Si ces lignes n’apparaissent pas dans le fichier de configuration (et c’est le cas chez moi depuis le passage en 10.1.4 de Mac OS X), ajoutez ces lignes aux endroits appropriés (la première ligne dans le paragraphe des “LoadModule” et la deuxième dans le paragraphe des “AddModule“).
En se déplaçant vers l’occurence suivante de notre recherche, nous voyons :
# For example, the PHP 3.x module will typically use: # # AddType application/x-httpd-php3 .php3 # AddType application/x-httpd-php3-source .phps # # And for PHP 4.x, use: # # AddType application/x-httpd-php .php # AddType application/x-httpd-php-source .phps
Nous avons déjà rencontrés ce genre de lignes quand nous activions SSI. En synthése, elles disent que tout fichier ayant l’extension .php doit être traité par le module PHP dont nous venons d’autoriser l’activation. Comme nous le verrons bientôt, Mac OS X (versions 10.1 et ultérieures) sont livrées avec PHP 4 pré-installé, donc enlever le caractére de commentaire des lignes relatives à PHP 4. Sauvegardez le fichier de configuration Apache et relancez le serveur du Web en employant le tableau de bord “Partage“.
Nous allons retourner à notre fichier log Apache pendant une seconde pour illustrer une information simple mais utile. Chaque fois que vous démarrez Apache, il inscrira une ligne simple dans la log vous indiquant que tout est démarré avec succès. En général, cette ligne ressemblera à ceci :
[notice] Apache/1.3.20 (Darwin) configured -- resuming normal operations
Quand vous ajoutez un module tiers ou particulier (comme PHP, mod_perl, mod_ssl, etc…), Apache le mentionnera gentiment dans sa ligne de démarrage. Si vous venez
juste de redémarrer le serveur Apache Web maintenant, jeter un coup d’oeil au fichier log en tapant :
tail /var/log/httpd/error_log
Vous devriez voir la poésie d’Apache suivante :
[notice] Apache/1.3.20 (Darwin) PHP/4.0.6
configured -- resuming normal operations
Apache nous dit que l’on a autorisé l’activation de PHP, mais comment en être sûr ? Plutôt facilement en réalité. Prenez-le le fichier index.shtml avec lequel nous avons joué dans l’article relatif aux SSI et rebaptisez le en index.php.
Maintenant, remplacez son contenu avec les instructions suivantes :
<html><body> <h1>Gleefully Served By Mac OS X</h1> <? phpinfo()?> </body></html>
Enfin, avec votre navigateur, allez à l’adresse http://127.0.0.1/index.php et vous devriez voir une longue page pleine d’informations de diagnostique PHP. S’il en est ainsi frottez vous les mains avec une lueur de satisfaction dans l’oeil, parce que PHP a maintenant été ajouté à votre arsenal.
Vous voulez ajouter un programme de webmail pour vos collègues itinérants ? Allez voir PHPost. Note : La plupart des applications PHP exigent une base de données sophistiquée en arrière plan, comme MySQL ou Postgres - PHPost est un de ceux qui n’en utilisent pas. L’installation et la configuration des systèmes de base de données relationnelles est relativement facile sur Mac OS X, mais cela sortirait du périmètre de ce tutoriel. Un futur article sera donc entièrement consacré à ce sujet.
Choisir qui peut voir quoi !
Il est cinq heures du matin. Vous avez vidé trois pack de six boites de soda, deux boîtes Penguin Reds et un nombre incroyable de délicieux snacky. Vous avez un script CGI de sondage prêt à interroger vos employés sur le menu du prochain pique-nique de la société, une galerie d’image SSI qui sème la panique dans le département marketing et une application PHP avec laquel vos développeurs peuvent suivre à la trace et contrôler leur code.
Et maintenant ?
Après tout vous avez fait quelque chose d’assez secondaire. Nous venons juste de mettre en place un petit contrôle d’accès sur notre nouvel intranet - nous ne voudrions pas que le monde extérieur contemple le grand travail que nous avons fait (nous préférerions attendre et leur montrer toute la substance de nos efforts pris sur notre temps personnel, ok ?).
Bien qu’Apache puisse certainement contrôler les accès authentifiés, nous allons seulement abordé l’aspect “localisation”
de ce contrôle. Pour faire ainsi, nous allons retourner dans l’extrait du fichier de configuration avec lequel nous nous sommes amusés au moment où nous avons abordé les SSI dans l’article précédent :
<Directory "/Library/WebServer/Documents">
Options Includes Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
J’avais mentionné dans l’article sur les SSI que nous serions finalement amenés à modifier ces lignes et bien le moemnt est venu. (bien que nous allons toujours ignorer AllowOverride). Très simplement, le “Order allow, deny” et le “Allow from all” sont les ordres magiques qui éviteront que des visiteurs extérieurs accèdent à notre intranet. En ce moment, avec ces lignes en leur état originel, notre intranet est grand ouvert au public.
Nous allons donc mettre un terme à ceci :
<Directory "/Library/WebServer/Documents">
Options Includes Indexes FollowSymLinks MultiViews
AllowOverride None
Order deny,allow
Deny from all
Allow from gatesmcfaddenco.org
</Directory>
Vous voyez ce que nous avons fait là ? Premièrement, nous avons donné un petit coup à notre directive “Order“. Ceci indique à Apache de traiter d’abord tous les règles de type “Deny“, puis les règles de type “Allow“. De plus, notre premier “Deny” est “from all“, signifiant que personne ne peut venir frapper à la porte. Si nous avions refuser tout le monde, bien sûr, personne ne pourrait contempler notre site, donc nous avons ajouté une règle “Allow” pour les personnes de notre domaine GatesMcFaddenCo. Nous pourrions aussi accepter et refuser des adresses IP, comme “Allow 209.204.146“. Cela permettra l’accès à tous les membres du réseau GatesMcFaddenCo, mais à personne de l’extérieur.
Conclusion
Bien, il est sept heures du matin et il est temps de mettre en oeuvre ce que vous avez appris. Vous êtes confiants, feignant un baillement d’ennui, mais pas de somnolence. Comme le soleil du matin brille sur l’argent de votre glorieuse tour G4, vous souriez en privé - comme toujours, vous avez fait quelque chose d’étonnant sur votre Mac avec une incroyable simplicité. Votre patron est impressionné, vos collègues n’en croient pas leurs yeux et vous pouvez signer le bon de commande du prochain mystérieux produit du monde Mac. Oh, comme la vie est belle !
Ne pensez pas que nous avons épuisé tout ce qu’Apache et Mac OS X puissent offrir, cependant. Vous n’avez pas toujours goûté au mod_ssl, qui permet des modes serveur sécurié, vous n’avez pas joué non plus avec mod_perl, qui peut grandement accélérer vos scripts CGI. Vous n’avez pas vu les fonctons d’identification du contrôle d’accès d’Apache, ni même altérer la configuration d’Apache avec des fichiers .htaccess. Et puis, si quelqu’un tape une mauvais URL sur votre intranet, une vilaine page d’erreur 404 générique sera affichée.
Seulement 7:30 ? Encore pas mal de temps pour m’attaquer à tous ces sujets avant le déjeuner. Bonne chance !
Textes originaux en anglais sur O’Reilly : Apache Web Server par Kevin Hemenway
Chargement
Commentaires récents