Il peut arriver, dans certains de vos projets Symfony, que vous deviez appeler une fonction spécifique dans toutes vos actions d’un controller en particulier. Mais voila, vous êtes également dépendant de vos services, qui ne sont disponibles qu’à l’intérieur de vos actions.

L’astuce consiste ici à surcharger chacune des actions de vos controllers automatiquement, pour leur demander d’exécuter le même code avant même de s’exécuter elle-même. Vous bénéficiez ainsi des mêmes dépendances que vos actions ainsi que du même environnement.

Lire la suite

css3

Il y a quelques années, je vous expliquais comment, grâce à du PHP, nous pouvions créer des vignettes à partir d’une grande image. C’était lourd pour le serveur, pas très optimal, mais léger pour le client. Mais avec l’arrivée du HTML5, du CSS3 et l’amélioration du réseau (merci la 4G), nous pouvons maintenant changer de technique en allégeant un peu notre serveur.

Lire la suite

debian

Après avoir monté votre premier serveur web, vous pouvez être amené à devoir le maintenir et à travailler un peu dessus pour l’améliorer, l’optimiser, le changer, le migrer, bref, faire des trucs assez sympathiques avec votre serveur. Etant en plein travail sur ce sujet, voici un petite liste des commandes indispensables (ou pas) pour bien débuter dans l’administration de votre serveur Debian.Lire la suite

mail

L’e-mail, apparu en 1966 (rien que ça), est omniprésent dans notre vie et est indispensable. On l’utilise pour communiquer avec ses collègues, avec ses amis, avec ses clients et même maintenant avec l’administration française … Mais voila, entre le spam, les comptes multiples, les erreurs de configuration et les logiciels obsolètes, les mails sont-ils toujours aussi efficaces ? Petite réflexion personnelle.

Lire la suite

logo_carre

Un an après mes déboires avec mon hébergeur et après la négociation acharnée avec une société de domain-parking, j’ai enfin retrouvé mon nom de domaine préféré : tiloweb.com.

Ainsi, ce blog revient ! Avec un nouveau design et les mises à jours qui vont avec …

Certes, le SEO est tout cassé, il faudra tout recommencer, mais je suis motivé à redonner vie à ce blog avec de nouveaux articles.

Longue vie à Tiloweb !

Le comble pour un développeur web / administrateur réseau ? Et bien, se voir déconnecté du jour au lendemain.

En effet, mon ex-hébergeur, ex-registrar et accessoirement ex-ami, a déposé le bilan de son entreprise debut de la semaine dernière et en a profité pour déconnecter tous les noms de domaine dont il avait la gestion (dont tiloweb.com, avec qui je me battais pour pouvoir le transférer chez un autre registrar plus sérieux), toutes ses lignes téléphones (mêmes personnelles, impossible de le joindre) ainsi que tous ses serveurs (dont les miens) et ce, sans sommation.

Ainsi, le mardi 18 juin 2013 au matin, plus de blog, plus de serveur, plus de mails, plus de nom de domaine, plus rien. Le temps que je comprenne ce qu’il se passe, le blog, pourtant très bien référencé, s’est vu totalement désindexé de Google. Là c’est le drame.

Mais c’est une bonne leçon à prendre. Ne jamais faire confiance aux petits pour des choses aussi importantes qu’un nom de domaine. Ainsi, je resterais toujours fidèle à mon Gandi (même si c’est 2 fois le prix d’OVH, mais allez savoir …).

J’ai mit en place une URL temporaire, http://www.tiloblog.com, en espérant pouvoir racheter mon http://www.tiloweb.com rapidement et tout en pouvant garder la possibilité de poster des articles et d’interagir avec vous.

Désolé pour cette absence, il faut maintenant recommencer tout depuis le départ.

La vie est dure, CMB.

UPDATE :

– Le nom de domaine a été racheté par une société pour le mettre en parking, profitant ainsi de mon bon référencement pour se faire un peu d’argent …

– Négociation en cours pour récupérer mon nom de domaine contre un gros chèque

– Quelques mensonges larmoyant ont fait leur effet. Je récupère mon nom de domaine ! Victoire !

apache-php

Il peut arriver certains cas où vous avez tout intérêt à définir des variables spécifiques à votre environnement de développement ou de production tout en gardant exactement le même code pour votre application (dans le cas de l’utilisation de git par exemple, ou simplement si vous travaillez en local avant la mise en production). Plus concrètement, vous pouvez vouloir changer les informations de connexion à votre base de donnée en fonction de votre environnement sans que ça impact votre code.

La solution la plus commune reste alors à déterminer dans votre code dans quel environnement vous vous trouvez :

if($_SERVER['HTTP_HOST'] == 'localhost') {
    // Environnement de développement
} else {
    // Environnement de production
}

Mais très honnêtement, cela peut apporter son lot de complications. A savoir, devoir modifier et redéployer son application à chaque changement pour le moindre environnement par exemple, ou ça devient vite ingérable si vous en utilisez plusieurs.

Une solution bien plus simple existe alors. Pour cela, il suffit de déclarer vos variables directement à l’intérieur même de votre environnement et simplement de les récupérer de manière transparente dans votre application. Pour cela, il suffit d’utiliser en PHP la fonction getenv($var) pour récupérer la variable $var que vous aurez déclaré dans votre votre vhost apache ou votre htaccess à l’aide de la commande SetEnv $var value

Exemple

Pour illustrer cette méthode, nous allons imaginer une application déployée sur 2 environnements différents. La première plateforme est celle de développement répondant à l’URL http://dev.application.com et devra se connecter sur le serveur de base de donnée de développement 123.456.789.0. La seconde plateforme est celle de production répondant à l’URL http://www.application.com et devra se connecter sur le serveur de base de donnée de production 123.456.789.1.

Vhost Apache :

# Développement
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName dev.application.com
    DocumentRoot /var/www/application/dev/

    SetEnv DBHOST 123.456.789.0
    SetEnv DBUSER application_dev
    SetEnv DBPASS application123
    SetEnv DBNAME application_dev

    <Directory /var/www/application/dev/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

# Production
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName www.application.com
    DocumentRoot /var/www/application/www/

    SetEnv DBHOST 123.456.789.1
    SetEnv DBUSER application_www
    SetEnv DBPASS application123
    SetEnv DBNAME application_www

    <Directory /var/www/application/www/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

Application PHP

$db = new PDO('mysql:host='. getenv('DBHOST').';dbname='.getenv('DBNAME'),
               getenv('DBUSER'),
               getenv('DBPASS'));

Et voila votre application communique maintenant avec votre environnement et est prête à être déployée où vous le voulez.

images

Récemment (très récemment en fait … hier), j’ai subi quelques soucis avec un serveur mit hors-ligne par mon hébergeur sans me prévenir (ouh le méchant OVH). Le soucis le plus important, c’est que je m’en suis rendu compte un peu tard, à savoir, le lendemain (dur dur l’arrivée au bureau ce matin. Je n’ai même pas eu le temps de mettre en place mon intraveineuse de café). Il existe bien entendu beaucoup de systèmes automatique de monitoring sur le web mais quoi de mieux que de réinventer la roue et surtout, de savoir comment celle-ci fonctionne.

Le principe de notre système va donc être de regarder régulièrement, à l’aide d’une tâche CRON, si le serveur de votre site répond correctement et si celui-ci est bien le bon serveur (une guerre existe au sujet de la prononciation du mot « CRON », un camps prône la tâche « crone » et l’autre, la tâche « cron » . Je préfère pour ma part « cron », ça me permet d’insulter tout le monde de « tâche » automatique sans passer pour un … bref).

I/ Créer la base de donnée

La base de donnée n’a rien de compliqué en soit, il suffit de hiérarchiser toutes les données dont nous avons besoins, à savoir :

  • Le titre du site
  • Le nom de domaine du site
  • L’IP du serveur hébergent le site
  • L’indicateur d’état DNS
  • L’indicateur d’état HTTP
  • La date du dernier changement d’état

Soit en SQL :

CREATE TABLE IF NOT EXISTS `monitoring` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(64) NOT NULL,
`domain` varchar(64) NOT NULL,
`ip` varchar(64) NOT NULL,
`dns` tinyint(1) NOT NULL,
`http` tinyint(1) NOT NULL,
`update` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=58 ;

II/ Créer le script

Pour la création de ce script, je vais assumer le fait que vous soyez correctement connecté à votre base de donnée et que vous utilisez la bibliothèque PDO.

Récupéreration des données

Commençons ainsi par créer notre requête de récupération des données :

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP

    // Traitement du monitoring DNS
endforeach;

Tester l’accès HTTP

Ensuite, on va tester si l’accès au site est bien possible. Pour cela, il vous suffit de tenter d’ouvrir une connexion PHP entre votre script et votre serveur avec la fonction fopen pointant sur l’IP. Si la connexion s’effectue, la fonction va vous retourner le code brut de votre script, si votre serveur est indisponible, alors votre fonction retournera false.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $ping = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
endforeach;

En ajoutant un (bool) avant la fonction, on s’assure que celle-ci ne nous renvoit pas le code source du site, mais simplement la valeur true. de la même manière, en ajoutant un @ avant le nom de la fonction, je demande à PHP de ne pas renvoyer d’erreur mais simplement un false si quelque chose ne se passe pas bien (comme le fait que votre serveur ne réponde pas).

Tester le paramétrage DNS

Nous allons maintenant tester le paramétrage des DNS. Cette étape est assez important en fonction de votre configuration. En effet, nous allons vérifier que le serveur correspondant au nom de domaine est bien le bon. En effet, il existe de nombreux cas ou votre nom de domaine pourrait pointer vers un serveur, certe, fonctionnel, mais ne vous appartenant pas pour autant. (Cela m’arrive malheureusement régulièrement avec des clients qui pensent bien faire en modifiant eux-même leur nom de domaine et qui en fait, plombe totalement leur site internet sans même vous prévenir … Pour après vous en blâmer).

Pour cela, il existe une fonction toute faite ! gethostbyname qui prend comme paramètre le nom de domaine recherché et vous renvoi l’IP vers lequel celui-ci redirige. Il suffit alors de vérifier si l’IP répondu correspond bien à notre IP.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $http = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
    $dns = gethostbyname($site['domain']) == $site['ip'];
endforeach;

Vérification du monitoring

Il reste tout de même une dernière étape avant d’alerter quiconque en cas de problème. Car effectivement, si dès que vous détectez un soucis dans votre monitoring vous envoyez en e-mail, alors dites-vous que tant que votre problème n’est pas réglé, vous allez harcelé par votre propre serveur. Pour cela, il ne faut donc pas oublier de vérifier que l’état actuel des DNS ou du HTTP est différent du précédant état de votre site.

$sites = $pdo->query('SELECT * FROM monitoring');
foreach($sites->fetchAll() as $site):
    // Traitement du monitoring HTTP
    $http = (bool) @fopen('http://'.$site['ip'].'/', "r");

    // Traitement du monitoring DNS
    $dns = gethostbyname($site['domain']) == $site['ip'];

    if($dns != $site['dns'] || $http != $site['http']):
        // On met à jour le site dans la base de donnée
        $pdo->query('UPDATE monitoring SET http = '.$site['http'].', dns = '.$site['dns'].', time = '.time().' WHERE id = '.$site['id']);

        // On n'alerte qu'à cette condition
    endif;
endforeach;

Alerte

Pour les alertes, je vous laissez gérer comme vous le souhaitez. Vous pouvez vous envoyer un mail, un SMS, une notification push … Tout ce qui compte, c’est que vous ayez toutes les informations nécessaire pour traiter le problème le plus rapidement possible. Ainsi, avec ce script, vous saurez :

  • Depuis combien de temps l’alerte est en place (ou depuis combien de temps le site est en ligne)
  • Qu’est-ce qui empêche vos utilisateurs d’accéder à votre site :
    • Votre serveur ne répond plus ?
    • Vos DNS sont mal configurés ?

III/ Paramétrer la tâche CRON

Il vous manque maintenant le plus important, la mise en production de votre script. Ici, nous allons demander à votre serveur (ce sera un debian 6.0 pour ma part) de lancer votre tâche CRON toutes les 3 minutes. Vous pouvez faire varier cette intervale mais plus elle augmente, moins vous serez réactif, plus elle diminue, plus vos serveurs vont travailler.

Nous supposerons que le chemin d’accès à mon script de monitoring soit à l’adresse suivante : /var/www/monitoring/cron.php et que vous avez les droits d’administration de votre serveur (un petit sudo et hop !)

Nous allons éditer le cron général de votre serveur. Pour se faire, connectez vous à votre terminal puis tapez la commande suivante :

$ crontab -e

Votre fichier CRON va s’ouvrir avec votre éditeur de texte préféré. Il vous suffira alors d’ajouter la ligne suivante :

*/3 * * * * php -f /var/www/monitoring/cron.php

Et voila, votre service de monitoring est en place. C’est plutôt cool, et surtout indispensable de savoir, avant votre client, quand ça va chauffer pour vos oreilles.

jquery_logo

Google a lancé, il y a quelques semaines maintenant, les communautés sur son réseau social. Soit l’équivalent des « groupes » sur Facebook, mais en beaucoup plus soigné, soyons honnête. Personnellement, c’est LA fonctionnalité qui m’a fait revenir sur Google+ et qui semble le faire revivre. A vrai dire, ça m’apporte un vrai plus. Effectivement, pour le moment, j’utilisais Twitter pour suivre les différentes communautés et nouveautés autour des différents langages, framework que j’utilisais. Mais Twitter a rapidement ses limites dans ce domaine puisque les informations étaient noyées parmi les postes perso du millier (ou presque) de twittos que je follow. Google+ a donc apporté une véritable solution à ce besoin ! Les posts sont classés en fonction des communautés (donc de la technologie ciblée) et même classés par groupes pour arriver directement là où l’on souhaite chercher la bonne information.

Je fais déjà parti de plusieurs communautés française comme Titanium appcelerator, PHP, etc … Mais il y en a une qui manquait beaucoup à son sens, une communauté française sur jQuery. Voila qui est donc réglé, la communauté jQuery France vient d’être créée sur Google+ et permettra le partage d’infos, de ressources, de plugins et d’entraide en français.

N’hésitez pas à y participer ! J’essayerais, pour ma part, d’y être actif, d’y poster un peu tout ce que je trouve en français et de répondre aux questions que certains peuvent se poser.

jquery_logo