Préparation d un serveur Apache pour Zend Framework Jacques THOORENS 30 novembre 2010 Résumé Cette petite introduction explique comment paramétrer son serveur Apache personnel pour en faire une machine de développement permettant d écrire un code qui fonctionnera sans la moindre modification sur le serveur d un hébergeur. Plusieurs techniques sont mises en oeuvre : l URL rewritring, les serveurs virtuels et les variables de serveur. 1 Introduction Le framework Zend, comme d autres frameworks PHP, utilise un procédé d identification des pages basés sur l URL rewriting. Cela suppose que le nom du fichier PHP réellement exécuté est en fait calculé par le programme en examinant la ligne d URL envoyée par le navigateur. Outre le fait que cela permet des adresses moins cryptiques que le script habituel, le procédé permet également d utiliser des pages qui ne sont pas directement accessibles pour l internaute, ce qui contribue à faciliter la sécurisation du site. Par exemple, au lieu on aura : http://www.monsite.com/viewtopic.php?f=7&t=18114 http://www.monsite.com/topic/number/7/page/18114 Malheureusement, cette technique supporte mal le changement de contexte et notamment, risque d obliger le concepteur du site à de nombreux remaniements de code lors de l installation du code sur le site définitif. Dans cette petite introduction, nous allons voir comment une astucieuse configuration du serveur Web de développement simplifie la conception et le déploiement d un site en assurant les points suivants : la création d un site virtuel qui permet à la machine de développement de fonctionner comme si elle était un site réel une définition unique de l URL rewriting sans devoir tenir compte de la machine hôte qui offre effectivement l hébergement une identification sans équivoque du contexte d exécution (développement ou production) afin d assurer des comportements différenciés en cas d erreur. 2 Un serveur Apache «normal» Normalement, un serveur Apache installé sur une machine de développement permet de voir les pages qu il publie par le biais de l adresse localhost. Cette URL correspond en fait à l adresse 127.0.0.1 qui est une interface interne, parfois appelée loopback. Si la machine 1
fonctionne dans un réseau, des navigateurs situés sur d autres machines du réseau peuvent accéder à ces pages en donnant l adresse IP de la machine, le plus souvent une adresse non routable du style 192.168.1.3 ou 10.0.0.5. Si le réseau dispose d un DNS privé, les pages sont également acessibles par le biais d un nom comme naxos ou perlimpinpin. Les pages accessibles sont situées sur le disque dur de la machine, dans un répertoire accessible en lecture à l utilisateur qui fait tourner le serveur. Par défaut, ce répertoire se nomme htdocs et peut être contenu à différents endroits : par exemple /srv/www/htdocs ou encore /opt/lampp/htdocs ou encore /var/lib/http/htdocs. En fait, la localisation précise du répertoire est prévue dans le fichier de paramètrage du serveur, souvent nommé httpd.conf. Voici un extrait de ce fichier : # DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. # DocumentRoot "/srv/www/htdocs" Pour des raisons de sécurité, le serveur est en principe seulement capable d afficher des pages contenues dans ce répertoire ou l un de ses sous-répertoires. Sur les machines de type UNIX, on peut également accéder aux pages personnelles des différents utilisateurs au moyen d URL spécifiques. Par exemple, l URL localhost/~jacques ou naxos/~jacques permettra de visionner les pages personnelles d un utilisateur nommé jacques. A condition toutefois que certaines conditions soient rénies : l utilisateur doit avoir défini un répertoir public_html dans son répertoire personnel l utilisateur système qui fait tourner le serveur doit pouvoir accéder au moins en lecture aux fichiers concernés le serveur doit avoir été configuré pour permettre ce comportement (par défaut, il ne l est pas) L expérience montre que de nombreux problèmes surviennent si on tente de mettre au point un site utilisant l URL-rewriting dans un répertoire utilisateur. Si on veut pouvoir créer plusieurs sites sur une même machine, il faut avoir recours à une autre technique parfaitement intégrée au serveur Apache : la technique des hôtes virtuels. 3 Configuration d hôtes virtuels Créer un hôte virtuel consiste à faire croire au système qu il existe un serveur Apache lié à un nom de domaine spécifique alors qu en réalité le serveur physique porte un autre nom et assure en fait le service pour plusieurs hôtes différents. Cette usurpation ne peut se réaliser que par deux astuces : 1. faire correspondre au nom du serveur virtuel l adresse IP du serveur physique. Cela peut se faire en programmant le DNS du réseau, mais plus simplement en modifiant le fichier hosts des machines censées appeler le serveur virtuel. 2. avertir le serveur Apache que toute requête adressée au serveur virtuel doit choisir une racine différente pour les documents à renvoyer. Les fichiers de configuration du serveur le prévoient facilement. Pour créer un hôte virtuel, il faut donc paramétrer deux serveurs : le serveur Apache et le serveur de noms. Nous allons voir que pour un site en développement cette deuxième étape peut se simplifier. 2
3.1 Configuration des noms d hôtes Les machines actuelles recourent à deux techniques pour trouver l adresse IP correspondant à un nom de domaine. Chaque machine possède un fichier spécifique réalisant les équivalences entre les noms de domaine et les adresses IP. C est une méthode héritée du passé, à une époque où les réseaux étaient petites et souvent locaux. L autre technique consiste à recourir à un domain name server ou DNS qui réalise la même tâche, mais d une manière plus efficace. Le DNS n agit généralement pas seul et requiert les services d autres serveurs disponibles sur le réseau mondial. En pratique, il n est pas fréquent de pouvoir modifier facilement le DNS utilisé par la machine. Il est souvent situé dans un modem-routeur pour un réseau domestique ou accessible au seul administrateur du réseau dans le cas d un réseau d entreprise. Il est donc plus simple d opérer la modification du fichier hosts. Sous Linux, le fichier en question s appelle /etc/hosts. Pour marquer le caractère fictif du domaine virtuel, et éviter tout conflit avec un domaine potentiellement existant, je choisirai de spécifier un top level domain imaginaire : local. Il suffit d ajouter la ligne suivante au fichier en le faisant éditer par l utilisateur root. 127.0.0.1 exemple.local Sous Windows, le fichier est dans %SystemRoot%\system32\drivers\etc\, dans lequel %SystemRoot% correspond à Windows dans une installation standard. Si on veut qu une autre machine accède à l hôte virtuel, on peut modifier son fichier hosts pour qu il identifie le serveur par son adresse. Par exemple, sur mon système, j ai modifié les paramètres de ma machine Windows 7 virtuelle pour qu elle accède à mon serveur Linux en plaçant le ligne suivante : 192.168.1.3 exemple.local 3.2 Création du serveur virtuel sous Apache Ici deux phases sont nécessaires : 1. autoriser les noms de domaines virtuels sur le serveur Apache, en décommentant la ligne appropriée dans etc/httpd.conf : # Virtual hosts Include etc/extra/httpd-vhosts.conf 2. dans le fichier etc/extra/httpd-vhost.conf, donner le chemin vers la racine du serveur virtuel et une série d autres paramètres. <VirtualHost *:80> DocumentRoot "/srv/exemple/public" ServerName exemple.local # This should be omitted in the production environment SetEnv APPLICATION_ENV development <Directory "/srv/exemple/public"> Options Indexes MultiViews FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost> 3
Le répertoire choisi peut être placé n importe où, pour autant que l utilisateur qui fait tourner le serveur Apache (nobody sous Linux) puisse y avoir accès. J ai choisi /srv/exemple/public. L utilité du répertoire public apparaîtra lors de la création d un projet Zend. La variable d environnement APPLICATION_ENV sera détaillée dans la section 4. 3. redémarrer le serveur Apache pour qu il relise ses nouveaux paramètres. 4. on peut tester le fonctionnement du serveur en créant le fichier suivant /srv/exemple/public/index.php : <?php phpinfo();?> En proposant l URL http://exemple.local dans un navigateur, on devrait voir s afficher les caractéristiques du serveur. Sur une machine Unix, on donnera des droits d écriture, ou mieux de propriété, sur le répertoire /srv/exemple et ses sous-répertoires à l auteur du site. 3.3 Utilisation de NetBeans L IDE NetBeans permet de créer facilement un projet Zend utilisant un serveur virtuel. 1. créer un nouveau projet PHP à l endroit voulu (dans notre exemple /srv/exemple) 2. Donner le nom choisi pour l URL 4
3. Demander l utilisation du framework Zend (on suppose ici que NetBeans a été configuré en ce sens voir section 6). 4. Dans l arborescence créée, repérer le fichier README.txt. Il contient en fait les lignes à ajouter au fichier de configuration d Apache. Après redémarrage du serveur, une application minimale de Zend est opérationnelle. Voici l écran affiché : 4 Développement ou production? Pour rendre l application totalement indépendante du contexte, il reste à trouver un moyen de «marquer» le serveur de développement pour que l application sache où elle est. On peut parfaitement définir des variables sur le serveur Apache et les récupérer dans un script PHP. N importe quelle variable ferait l affaire, mais autant utiliser celle que Zend attend par défaut : 5
APPLICATION_ENV. Il suffit donc d ajouter les lignes suivantes au fichier de configuration du serveur Apache. Il est également possible de définir cette variable dans le bloc de définition réservé au serveur virtuel (voir section 2). # Permet de qualifier les applications Zend sur ce serveur comme # en développement SetEnv APPLICATION_ENV development On peut voir que le fichier index.php qui sert de point d entrée à l application utilise cette variable pour définir une constante fondamentale : // Define application environment defined( APPLICATION_ENV ) define( APPLICATION_ENV, (getenv( APPLICATION_ENV )? getenv( APPLICATION_ENV ) : production )); L instruction est cryptique, mais efficace : si aucune constante PHP APPLICATION_ENV n est définie, alors, en définir une qui prendra la valeur de la variable homonyme du serveur Apache ou à défaut la valeur production. Comme l accès aux variables Apache du serveur de production n est pas souvent autorisé dans le cas d un hébergement mutualisé, ce comportement par défaut identifie sans équivoque ce serveur de production. Nous voici arrivé au terme de la configuration de notre serveur de développement. Il nous reste à construire une application Zend réelle. Mais ça, c est une autre histoire. 5 Bibliographie Les éléments présents dans cet article figure dans un grand nombre de livres et sites, consacrés à Zend, à Apache et à NetBeans. J ai un certain mal à les créditer tous. Une recherche sur Google en donnera une infinité. On peut trouver un tutorial reprenant certains éléments de cet article sur le site suivant : http://www.13creation.com. 6 Note finale Pour activer les scripts de Zend dans NetBeans, on modifiera en conséquence l onglet Zend des options PHP. Sur ma machine, j ai mis un lien symbolique vers le script en ligne de commande en /usr/local/bin/zf.sh. 6