SVN: Gestion des dépendances externes

Le versionning de vos projets de développement est une chose essentielle pour garantir la sécurité et la tenu à jour de vos sources entre développeurs.

Si l’intégralité des sources de votre projet peut être place sur un seul et unique dépôt, il arrive souvent que votre application soit dépendante d’un framework ou de quelques librairies importé d’un autre projet et souvent d’un autre dépôt SVN.

Il est donc relativement lourd est contraignant de devoir stocker et versionner les fichiers de ces sources externes qui ne seront de toute façon pas à jour par rapport au dépôt sur lequel vous l’aurez récupéré. Prenons l’exemple d’un projet PHP utilisant Zend Framework. Nous avons déjà mis en place la structure MVC du projet et nous l’avons importé vers notre dépôt SVN.

Nous souhaitons ajouter le Framework à jour dans le dossier /library à partir du dépôt officiel: http://framework.zend.com/svn/framework/standard/branches/release-1.9/library/

Commencez donc par vous placer dans le dossier /library en ligne de commande.

Pour déclarer notre dépôt externe nous allons utiliser la propriété “externals”  à l’aide de la fonction “propset” de SVN.

svn propset svn:externals “http://framework.zend.com/svn/framework/standard/branches/release-1.9/library/Zend Zend” .

Le point passé en dernier argument précise que nous déclarons cette propriété dans le dossier courant, ne l’oubliez surtout pas!

SVN nous répond alors: property ‘svn:externals’ set on ‘.’ Il ne nous reste plus qu’a faire un “svn up” pour mettre à jour la copie locale et récupérer ainsi une copie à jour du Framework sans que celui si soit stocké sur votre dépôt.

Votre projet sera maintenant à jour à chaque mise à jour et vous voilà affranchis de toute maintenance sur vos sources externes.

Wordpress et PHP 5.3

Après plusieurs tentatives d’installation (ou de migration) de Wordpress sous un serveur PHP 5.3, je viens enfin de trouver la solution à ce qui semble être une incompatibilité due à une configuration non explicite de php.

L’erreur est simple, vous affichez votre site/blog sous wordpress et celui ci vous hurle dessus que les fonction strtotime() et date() ne peut répondre à au système car le timezone n’a pas été défini dans php.

Reste donc a aller faire un tour dans votre php.ini, a rechercher “date.timezone = ” et à plus préciser “Europe/Paris” (oui ici on est en France monsieur!) en prenant soin de décommenter la ligne (retirez le “;”)

Bon maintenant que j’ai downgrader mes serveurs en 5.2.10 je vais pouvoir remonter sur une 5.3!

Partager une librairie PHP entre plusieurs sites

Sur un serveur en production, il peut nous arriver d’avoir plusieurs sites qui utilisent le même framework, ou le même fichier de configuration. De la même manière, les framework, comme dans mon cas Zend Framework, évoluent très rapidement et il peux être utile de gérer plusieurs versions sur le même serveur. Dans tous les cas, cette manipulation vous fera économiser de la place et facilitera vos mises à jours.

Commençons alors par placer dans un répertoire le ou les framework ainsi que les versions qui nous intéressent et incluons ce répertoire dans la configuration de php (votre fichier php.ini). Recherchez la ligne contenant la directive “include_path”. Celle si est commentée par défaut à l’aide d’un point-virgule (;). Elle décrit les différents répertoires contenant des fichiers sur lesquels nous voulons faire des include(). Décommentez alors la ligne en supprimant le point-virgule et adapter la description du chemin en fonction de l’endroit où vous avez placer vos librairies. Dans mon cas, cela donne:

include_path = “.:/var/www/library”

Pensez à conserver le “.” dans la liste des chemins à inclure afin de pouvoir inclure un fichier localement dans vos différentes applications php et redémarrez votre serveur http.

Dans le cas où nous avons plusieurs versions, il peut aussi être intéressant de simplifier le chemin d’accès à la dernière version stable. On peux alors utilise de manière toute simple utiliser les liens virtuels unix:

$ ln -s Zend_1.9.2 Zend

Pensez également à régler vos droits sur vos librairies:

# chown -R www-data:www-data /var/www/library

Enfin, voyons comment nous allons pouvoir utiliser cette librairie partagée coté applications. Je reprend alors mon exemple de Zend et le fichier bootstrap dans lequel nous avions l’habitude de re-écrire le path d’include de php (ici Zend se trouvais dans le ./library et ./application/models/ contient les modèles de notre application MVC):

set_include_path(‘.’ . PATH_SEPARATOR . ‘./library’ . PATH_SEPARATOR . ‘./application/models/’ . PATH_SEPARATOR . get_include_path());

Le path contenant le Zend Framework étant maintenant inclue par le “get_include_path()” nous pouvons supprimer le ./library des répertoires inclus.

Ensuite nous appelions notre framework avec la ligne:

require_once ‘Zend/Loader/Autoloader.php’;

Si vous avez suivit toutes les indications précédente et que vous laissez la ligne telle quelle, le site chargera ici la version courante de Zend Framework que j’ai décrit tout à l’heure par le lien logique unix. C’est ici que ça deviens intéressant et que nous pouvons préciser la version de Zend à utiliser.

Selon la manière donc vous avez nommé vos répertoires (dans mon cas Zend_x.y.z ou x.y.z correspond à la version du framework), vous pouvez alors appeler par exemple une version 1.6.2 de Zend dans une ancienne application.

require_once ‘Zend_1.6.2/Loader/Autoloader.php’;

Libre à vous d’adapter tout cela à vos propres conventions de nommage et de rangement.

Configuration d’Exim pour l’envoi externe

La plupart des applications web que nous pouvons être amené à déployer sur un serveur web utilise des fonctions d’envoi de mails.

Afin de gérer soit même les files d’attentes, il peut alors être utile d’héberger soit même un serveur SMTP directement sur la machine qui héberge l’application. Nous allons donc voir comment configurer simplement Exim pour l’envoi de mails vers les domaines externes. Nous utiliserons une distribution Debian stable.

Commençons par installer Exim:

aptitude install exim4

Exim va alors s’installer avec une configuration de base que nous allons modifier avec l’assistant fourni par exim4-config:

dpkg-reconfigure exim4-config

Le premier écran vous expliquera le rôle de cet utilitaire, validez avec “Ok” pour passer à l’écran suivant.

Sur celui si, choisissez “Distribution direct par SMTP (site internet)”.

Ensuite sur l’écran suivant entrez le nom tel que vous l’avez défini dans votre configuration ou tel qu’il a été défini par votre hébergeur.

Deux écran plus loin, l’assistant va vous demander sur quelle adresse il va devoir accepter le courrier. Puisque nous sommes parti sur une configuration simple où le serveur d’applications (php par exemple) se trouve sur la même machine, nous utiliseront donc l’adresse 127.0.0.1 pour limiter les connections au serveur avec lui-même.

L’écran suivant nous demande alors de préciser sur quel autre nom le serveur doit accepter les mails. Nous pouvons ici lui repriser le nom DNS de notre machine.

Vient ensuite, la question des domaines à relayer. Nous l’avons déjà vu, nous n’acceptons les mails entrant que sur l’adresse de localhost: 127.0.0.1. Nous pouvons donc autoriser le transfert vers tous les domaines afin que les mails puissent sortir. Remplissez donc ce champ avec une étoile “*”.

Laissez la liste des machines à relayer vide car nous souhaitons que le serveur transmette lui même les mails sortants.

Deux écran plus loin, répondez “Non” à la proposition de minimiser les requêtes DNS, laissez la distribution du courrier au “format mbox dans /var/mail” et ne séparez pas la configuration dans plusieurs fichiers.

L’assistant va se fermer et va redémarrer Exim et vous pourrez tester sans problème le bon fonctionnement de votre MTA par exemple avec la fonction mail() de PHP.

NSlookup et Dig: surveillez vous mises à jours DNS

Lors de l’achat d’un nom de domaine chez un registar, celui ci fourni généralement des services d’hébergement, de mails, mais aussi les services DNS liés à la gestion de ce domaine. On peux alors modifier directement sa configuration DNS dans l’interface mis à disposition par l’hébergeur et cette configuration sera alors répliquée sur les différents serveurs DNS desservant votre nom de domaine.

Nous allons voir ici comment contrôler la mise en applications de vos modifications via 2 outils en lignes de commande: NSLookup (présent sur tous systèmes) et Dig (présent de base sous Linux et Mac OS X, une version cygwin existe pour Windows).

Prenons un exemple concret, je viens de migrer mon blog sur un nouveau serveur et je souhaite que l’adresse “blog.lelevier.fr” pointe bien sur ce nouveau serveur. J’ai fait les modifications nécessaire dans l’interface de mon registar et je connaît l’adresse ip ou le nom de mon nouveau serveur.

Commençons par NSLookup avec une requête simple:

23:03: tibo@Boudallu ~ % nslookup blog.lelevier.fr Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: blog.lelevier.fr canonical name = rps.lelevier.fr. Name: rps.lelevier.fr Address: 87.98.170.232

Ici c’est mon serveur DNS local qui me répond (192.168.1.1) et bien qu’il n’ai pas autorité sur le domaine (il ne le gère pas directement) il me répond que “blog.lelevier.fr” est un Alias de “rps.lelevier.fr” défini par l’adresse “87.98.170.232” qui est justement mon serveur.

Même si le résultat est ici concluant nous allons partir sur le cas où la modification n’a pas encore été répliquée sur notre serveur local. Regardons alors directement sur les serveur DNS de notre registar pour voir si les modifications ont était prise en compte sur ces derniers. Commençons par trouver l’adresse ou le nom des serveurs DNS faisant autorité sur notre domaine avec Dig:

23:04: tibo@Boudallu ~ % dig NS lelevier.fr ; «» DiG 9.4.3-P3 «» NS lelevier.fr ;; global options: printcmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 64451 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;lelevier.fr. IN NS ;; ANSWER SECTION: lelevier.fr. 86400 IN NS dns11.ovh.net. lelevier.fr. 86400 IN NS ns11.ovh.net. ;; ADDITIONAL SECTION: dns11.ovh.net. 86371 IN A 213.251.188.130 ns11.ovh.net. 86371 IN A 213.251.128.130 ;; Query time: 54 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Wed Aug 19 00:06:38 2009 ;; MSG SIZE rcvd: 107

Nous pouvons lire ici dans la zone “ANSWER SECTION” que notre domaine est gérer par les serveur “dns11.ovh.net” et “ns11.ovh.net”. Retournons alors maintenant sur NSLookup pour vérifier l’état de la résolution sur un serveur précis. Lançez NSLookup sans argument avec la commande “NSLookup”, spécifiez le serveur DNS avec l’option “server” suivit du nom ou de l’ip d’un des serveur trouvé au dessus, et enfin entrez le nom DNS que vous souhaitez résoudre:

23:06: tibo@Boudallu ~ % nslookup > server dns11.ovh.net Default server: dns11.ovh.net Address: 213.251.188.130#53 > blog.lelevier.fr Server: dns11.ovh.net Address: 213.251.188.130#53 blog.lelevier.fr canonical name = rps.lelevier.fr. Name: rps.lelevier.fr Address: 87.98.170.232 >

On peut alors lire ici que le serveur en question redirige encore une fois “blog.lelevier.fr” vers l’hôte “rps.lelevier.fr” dont l’adresse est “87.98.170.232”. On pourra alors vérifier sur le second serveur DNS que les informations concordent et en conclure l’état de notre modification et sa prise en compte par notre registar.

A noté cependant qu’il faut généralement entre 4h et 48h pour que la modification soit répliquée.