Fini le développement web approximatif ! Aujourd’hui, les applications web deviennent de véritables usines à gaz qu’il faut savoir maîtriser. Certains regrettent l’époque du développement procédural avec ses projets de moins de 2000 lignes de code, mais il faut se rendre à l’évidence : le web est la plate-forme, il a besoin d’applications riches, complexes et stables. Un exemple, Magento : 300.000 lignes de code…

Sans outils d’aide au développement, il n’est plus possible de garantir la qualité de son code. Heureusement, ils ne manquent pas, encore faut-il les installer et les configurer correctement.

Parmi les outils indispensables, le debugger et le profiler arrivent en tête. Ils permettent de tracer tout ce que le code source est censé faire : inclusions, chargement de données, valeurs de variables, temps d’exécution, contenu des objets, etc. Avec eux, on gagne déjà la moitié du temps de test ! Je devrais plutôt dire : sans eux, on ne fait pas de vrais tests !

Je vais prendre l’exemple d’une application web PHP développée avec Eclipse et son extension PDT (PHP Development Tools), en utilisant Xdebug comme debugger. Cela n’a rien d’original, des milliers de développeurs PHP utilisent cette configuration, mais je vais sortir des sentiers battus pour traiter un cas plus délicat, mais plus courant en entreprise : comment utiliser xdebug sous Eclipse quand mon serveur web de test n’est pas mon poste de travail, mais un serveur distant ?

L’environnement de travail

Imaginons donc cette configuration : un serveur web de test sous Linux Debian Etch et un poste de développement sous Windows. Rien de plus classique. J’aurais pu prendre un poste sous Linux, cela ne change rien à la suite. J’aurais aussi pu prendre un serveur web sous Windows (XAMP), mais je trouve tellement dangereux de faire des tests sous Windows pour une application qui sera hébergée par un serveur Linux que je préfère ne pas en parler…

On part du principe que PHP et Apache sont installés et actifs sur le serveur web. De même, Eclipse et PDT sont prêts sur le poste client.

Configuration du serveur web

Pour installer Xdebug, le plus simple est d’utiliser PECL. Mais pour utiliser PECL, il faut PEAR ! Et pour utiliser PEAR, il faut la version client de PHP ! Pas de panique, c’est tout simple : on prend sa console shell (en root) et on y va.

Installation de la version client de PHP :

apt-get install php5-cli

Installation de PEAR :

apt-get install php-pear

Pour éviter de se retrouver coincé par phpize, il faut aussi installer les paquets de développement PHP :

apt-get install php5-dev

On peut enfin installer Xdebug :

pecl install xdebug

Ensuite, on modifie le fichier de configuration de PHP pour activer Xdebug sur les applications web installées sur le serveur :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la ligne suivante :

zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

On enregistre, on ferme et on redémarre Apache :

/etc/init.d/apache2 restart

Si on fait un phpinfo() sur le serveur web, on obtient déjà un résultat encourageant :

Oui, mais… Par défaut, Xdebug n’est pas en mode remote :

Or nous avons besoin du mode remote pour utiliser Xdebug depuis le poste client. Qu’à cela ne tienne ! Un autre petit tour dans la configuration PHP :

vi /etc/php5/apache2/php.ini

Dans le bloc Dynamic extensions, on ajoute la gestion du mode remote :

xdebug.remote_enable=1
xdebug.remote_host=192.168.1.2
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so

Attention, le paramètre xdebug.remote_host correspond à l’hôte distant… vu du serveur ! Il s’agit donc du poste de développement. Piège classique.

Après redémarrage d’Apache, le phpinfo() est déjà plus sympathique :

C’est fini pour le serveur !

Configuration d’Eclipse

Il reste à configurer Eclipse pour envoyer les requêtes vers le serveur web. On ouvre les préférences (menu Windows > Preferences) et on choisit PHP > PHP Servers pour définir le serveur de test :

Il ne faut pas oublier les chemins (Path Mapping) pour faire le lien entre les deux machines. Si vous avez déjà créé un projet, vous pouvez directement le sélectionner comme chemin local (celui du poste client puisque, cette fois-ci, on est sous Eclipse !). Attention à un détail qui tue, le nom de votre projet ne doit pas contenir d’espace, sinon Xdebug ne fonctionnera pas !

Le serveur est maintenant configuré :

Il reste à définir les paramètres par défaut du debugger PHP :

• PHP Debugger : XDebug
• Server : celui qui vient d’être configuré
• PHP Executable : on le laisse non défini puisque nous sommes en mode distant

Cerise sur le gâteau, on oblige Eclipse à utiliser un navigateur web externe. Je choisis Firefox qui me permettra de tester l’interface avec d’autres outils (Firebug, Web Developper Tools, etc.).

Voilà, c’est tout ! C’est un peu long, mais pas sorcier ! Maintenant on peut s’amuser et tester son code :

Pourtant, mettre à l’heure un serveur est simple. Et quand le serveur accueille des serveurs virtuels ? Comme nous allons le voir, cela reste toujours simple !

Lire l’heure

L’heure d’un serveur sous Debian (comme sur d’autres distributions Linux) est gérée par la commande date. Sans paramètre, elle retourne la date et l’heure du système :

# date
mar avr 18 12:47:53 CEST 2006

On remarque au passage que le résultat est formaté selon les paramètres de localisation du système (ici en français pour l’heure locale de Paris).

Pour obtenir l’heure UTC, c’est-à-dire l’heure universelle ou heure de Greenwich, on ajoute le paramètre -u :

# date -u
mar avr 18 10:47:53 UTC 2006

On obtient bien un décalage de 2 heures par rapport à l’heure de Paris.

Modifier l’heure

Pour modifier l’heure, on utilise le paramètre --set :

# date --set 12:53:20

Et si la date n’est pas bonne, même remède :

# date --set 2006-05-18

Configuration du fuseau horaire

Si le fuseau horaire ne convient pas, inutile de réinstaller le système ! On utilise simplement la commande tzconfig et on répond aux questions :

# tzconfig
Your current time zone is set to Europe/Paris
Do you want to change that? [n]: y

Please enter the number of the geographic area in which you live:
[...]
Number: 8

[...]

Please enter the name of one of these cities or zones
[...]
Name: Paris
Your default time zone is set to 'Europe/Paris'.
Local time is now: mar avr 18 13:07:02 CEST 2006.
Universal Time is now: mar avr 18 11:07:02 UTC 2006.

Facile ! Pour information, la configuration du fuseau horaire est stockée dans le fichier /etc/timezone.

Temps système et temps BIOS

Tout semble parfait mais il y a un détail sournois : votre serveur gère deux références de temps, celle du système et celle de la carte-mère (horloge BIOS) ! Et elles peuvent très bien ne pas indiquer la même heure ! Dans certains cas, cette subtile différence peut avoir des conséquences agaçantes lors du redémarrage du serveur (par exemple, perte de l’heure système). Comme dit le proverbe, « l’homme qui a une montre sait l’heure qu’il est, celui qui en a deux n’est jamais sûr. »

Donc, autant régler une bonne fois pour toute l’heure matérielle avec la commande hwclock. Comme nous avons déjà réglé l’heure système, on utilise l’option --systohc pour la récupérer et --utc pour la définir en heure UTC :

# hwclock --systohc --utc

Synchronisation avec un serveur de temps

« Bon, tout est à l’heure, je passe à autre chose. »

Pas encore ! Car le quartz qui pilote l’oscillation de l’horloge de la carte-mère n’est jamais parfait. L’heure va donc se décaler petit à petit (parfois de plusieurs secondes par jour !). Heureusement, le protocole NTP (Network Time Protocol) vient à notre secours et offre la possibilité de synchroniser l’horloge du serveur avec un serveur de temps qui fait référence. Là encore, rien de bien méchant.

Il faut d’abord installer les paquets qui permettront d’utiliser NTP :

# apt-get install ntp-simple ntpdate

Puis, on configure NTP :

# vi /etc/ntp.conf

Concernant les serveurs NTP, choisissez sans hésiter ceux du projet pool.ntp.org qui optimisent les requêtes NTP par l’utilisation de clusters répartis dans le monde entier. Une rapide visite de ce site vous indiquera les serveurs NTP à utiliser dans votre zone géographique. Si votre serveur est en France, on ajoute donc les lignes suivantes dans ntp.conf :

server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org

Avant de mettre en place le démon qui synchronisera l’heure automatiquement, il faut le faire manuellement (ici, avec le serveur principal de pool.ntp.org) :

# ntpdate pool.ntp.org

Maintenant que l’heure système est bonne, reste à mettre à jour celle de l’horloge BIOS :

# hwclock --systohc --utc

Pourquoi choisir l’heure UTC ? Pour éviter de perdre l’heure si les serveurs NTP ne sont pas accessibles au redémarrage de votre serveur.

Il reste à charger nos modifications et la synchronisation automatique est en place :

# /etc/init.d/ntp-server restart

On termine par le redémarrage du serveur qui est obligatoire pour éviter quelques mauvaises surprises (par exemple, les tâches cron qui se déclenchent à l’heure UTC ou les fonctions de temps de PHP qui perdent deux heures…). Si le redémarrage n’est pas possible, il faut relancer tous les services actifs.

Si vous souhaitez mettre à jour l’heure manuellement, le paquet ntp-server n’est pas utile. Gardez simplement le paquet ntpdate et utilisez directement la commande ntpdate. Vous pouvez aussi désactiver le chargement du démon NTP au démarrage :

# update-rc.d ntp remove

Et pour le remettre en place :

# update-rc.d ntp defaults

Régler l’heure d’un serveur virtuel (vserver)

« Et les serveurs virtuels dans tout ça ? Faut-il faire toutes ces opérations pour chacun des 100 vservers installés sur ma machine ? »

Non, heureusement ! Pour que le système de fichiers fonctionne correctement, tous les vservers utilisent la même référence de temps, celle du serveur principal. On ne peut donc pas modifier l’heure d’un vserver. Par contre, un vserver peut avoir sa propre configuration de fuseau horaire, très utile pour proposer des services à des utilisateurs de zones géographiques différentes.

Comme nous l’avons vu plus haut, la commande tzconfig permet de définir le fuseau horaire pour calculer le décalage horaire entre l’heure UTC du serveur principal et celle du vserver. On remarque au passage la nécessité d’utiliser l’heure UTC comme référence de temps sur un serveur.

Les puristes (ou plutôt les administrateurs qui ont la responsabilité d’exploiter des serveurs de production en toute sécurité) se pencheront sur les nombreuses options de configuration de NTP : installation d’un serveur NTP local, filtrage des adresses IP, portée des requêtes, périodicité de la synchronisation, etc. A chacun sa cuisine !

Voici brièvement comment monter un disque ATA :

1. Installer le disque (alimentation, connexion IDE sur le bon port, en maître ou en esclave, avec une nappe de 80 fils)
2. Partionner le disque (bien vérifier le nom du nouveau disque pour ne pas partitionner le premier !) :

   cfdisk /dev/hdb

3. Formater chaque partition :

   mke2fs -j /dev/hdb1

4. Tester chaque partition :

   cd /mnt
   mkdir disque2
   chmod 777 disque2
   mount -t ext3 /dev/hdb1 /mnt/disque2
   cd /mnt/disque2

5. Monter le disque au démarrage du système :

   cd /etc
   vi fstab

   Ajouter la ligne :

   /dev/hdb1 /mnt/disque2 ext3 defaults 1 1

   (options selon l’utilisation que vous en ferez)

Finalement, c’est plus simple qu’on ne l’imagine !