Toshy.net Derniers billets 2016-10-05CEST04:15:18+02:00 Configurer OpCache dans Docker 2015-05-31CEST19:50:00+02:00

Image utilisateur

Comme annoncé dans un précédant article, j'ai récemment migré mon site web vers une infrastructure Docker.

J'ai donc utilisé un conteneur PHP tout simple, mais plutôt que de partir d'un conteneur standard Ubuntu ou Debian et d'y installer PHP via les dépôts, j'ai préféré utiliser le conteneur officiel PHP proposé par Docker. Je l'ai préféré à une solution standard, car il propose plusieurs versions de PHP (5.4, 5.5 et 5.6) et qu'il est très facile d'y installer diverses extensions. 

Après une semaine, les résultats étaient plutôt positif, mais lors d'une vérification avec un simple phpinfo, je me suis rendu compte que par défaut, le cache opcode pourtant activé par défaut depuis php5.5 ne l'était pas. Bref, les performances étaient quand même pas génial, avec une moyenne de 15 requêtes traités par seconde.

 

J'ai donc fait des recherches pour voir comment remédier à ça et obtenir une configuration optimale pour un conteneur Docker où le code PHP exécuté n'est pas censé être changé sauf si le conteneur est relancé, j'ai donc opté pour la configuration suivante :

; Configuration opCache
; La librairie est présente par défaut mais pas chargée zend_extension=opcache.so
; Activation de l'opCache opcache.enable="1"
; Augmentation de la taille de la mémoire du cache de 64 à 256Mo opcache.memory_consumption="256"
; Désactive l'ajout du nom du dossier pour le cache, augmente les performances, mais risque de rendre l'application inutilisable, dans mon cas ça n'a pas eu d'effet négatif. opcache.use_cwd="0"
; Le cache a une durée de vie infini, seul un vidage manuel du cache (par le redémarrage du conteneur) permet de prendre en compte des modifications de code PHP (augmente énormément les performances) opcache.validate_timestamps="0"
; Accélére l'extinction d'opcache en vidant la mémoire par bloc opcache.fast_shutdown="1"
; Désactive la limite de taille pour les fichiers mis en cache opcache.max_file_size="0"

Cette configuration a eu des effets très importants sur le nombre de réponses traitées ainsi que sur le temps de chargement des pages. En ayant refait le même test de monté en charge qu'avant l'activation d'OpCache, je passe de 15 à 70 requêtes par seconde, vu que c'est simple à mettre en place ça serait dommage de s'en priver clin.png.

Il est bien entendu possible d'utiliser cette configuration pour OpCache en dehors d'un conteneur Docker, mais il faudra alors veiller à redémarrer PHP-FPM/Apache en cas de modification du code PHP de votre site/application.

Passage sous Docker 2015-05-23CEST16:40:00+02:00

Image utilisateur

Enfin...

Après plusieurs mois à me demander si c'était ou non une bonne idée, c'est fait, je suis passé à Docker pour héberger mon blog.

Il a fallu changer de serveur puisque j'étais pour le moment sur un VPS OpenVZ sur lequel il n'était pas possible de changer de noyau Linux, chose obligatoire pour pouvoir installer Docker. Je suis donc passé sur un VPS VMWare sur lequel j'ai pu modifier le noyau et me lancer dans la virtualisation par conteneur.

 

J'en ai profité pour régler quelques bugs sur le site (notamment une petite faille de sécurité) et mettre en place un serveur MemCached pour essayer d'améliorer les performances du blog qui me semble moins bonne que sur l'ancien système.

Il me reste encore du travail sur l'optimisation, mais la facilité de déploiement des conteneurs Docker va me permettre d'accélérer la fréquence des mises à jour du code du site.

Les prochaines fonctionnalités que je compte mettre en place sont le flux RSS et le retour du système de commentaire (sans spam si possible smile.png).

Mettre en place un packagist local 2015-04-18CEST17:20:00+02:00

Image utilisateur

Dans certains cas, notamment dans les entreprises ou pour des projets personnels, il arrive souvent que des librairies ou des Bundles Symfony2 doivent rester en interne ou n'ont tout simplement pas d'intérêt à être distribués. On se prive alors d'outils très pratique comme Composer et Packagist. Pourtant, il existe des solutions pas si complexe à mettre en place pour permettre une utilisation de Composer avec des librairies internes.

 

La solution la plus simple serait de simplement cloner les sources Git des librairies directement dans le projet mais, on continue de se priver de la facilité et des possibilités de Composer.

Une autre solution serait d'ajouter un dépôt Git à Composer de la façon suivante :

"repositories": [
    {
        "type": "vcs",
        "url":  "git@git.monsite.fr:mon-depot-prive.git"
    }
]

Le problème, c'est que chaque adresse Git doit être ajouté séparément. J'ai aussi remarqué au cours de mes tests que la génération de l'autoloader posait problème (celui du composer.json des dépôts Git n'étaient pas pris en compte).

Installer une version de Packagist sur son serveur

La solution la plus simple selon moi est d'installer une réplique de packagist.org sur son serveur. Les sources du site étant disponible sur GitHub, rien ne vous empêche de les cloner sur votre serveur et de les installer.

Pour l'installation, vous aurez besoin d'une base de données MySQL (mon essai avec postgresql n'a pas été fructueux) et d'un serveur PHP avec Git et Composer installé. Vous pouvez aussi installer Solr et Redis pour des fonctionnalités supplémentaires (recherche et statistique notamment).

L'installation se fait comme tout projet Symfony2 :

# Se déplacer dans le dossier parent d'installation de packagist
cd /var/www/;

# Clonage du dépôt Git
git clone https://github.com/composer/packagist.git;
cd packagist;

# Copie du fichier de parametrage par défaut
cp app/config/parameters.yml.dist app/config/parameters.yml

# Edition du fichier de parametrage utilisé (il est un moment question de clé github, il faut absolument en mettre une même si elle ne sert pas)
vi app/config/parameters.yml

# Installation des dépendances
composer install

# Création de la base de données
php app/console doctrine:schema:create

# Installation des ressources web
php app/console assets:install web

 Il faut ensuite créer un virtualhost qui pointe sur le dossier web et votre installation de packagist est quasiment fini.

Il ne reste plus qu'à mettre en place un cron toutes les minutes par exemple pour exécuter les commandes suivantes (la dernière n'a de sens que si vous avez installé Solr pour la recherche) :

php app/console packagist:update --no-debug --env=prod
php app/console packagist:dump --no-debug --env=prod
php app/console packagist:index --no-debug --env=prod

Je vous conseille quand même de les lancer une première fois manuellement pour éviter tous bugs (et certaines commandes recommandes de les lancer la première fois avec une option particulière).

Utilisation de son serveur Packagist

L'utilisation du serveur Packagist local se fait de la même façon qu'avec le service Packagist.org, vous vous inscrivez et vous ajoutez des dépôts Git. Pour l'utilisation c'est aussi très simple, il suffit juste d'ajouter ce bloc à votre fichier composer.json :

"repositories": [{
    "type": "composer",
    "url": "https://packagist.mon-site.fr/"
}]

Une fois ceci fait, vous pouvez ajouter vos dépendances vers des librairies de votre Packagist ou de Packagist.org, si composer ne trouve pas une librairie dans le premier, il ira la chercher dans le second, le tout avec la gestion de l'Autoload et des dépendances clin.png...

Créer votre système d'accroche pour Gitlab 2015-02-23CET18:00:00+01:00

Image utilisateur

Dans le cadre d'un développement, un logiciel de versionning de code est souvent utilisé car il permet de garder les différentes versions du logiciel et de faciliter son déploiement sur des serveurs quand il s'agit de projet web.

Dans le cadre de mon travail, j'ai eu à mettre en place un système d'accroche ou hooks lié au logiciel Gitlab (logiciel open source proposant les mêmes fonctionnalités que github). Jusqu'à récemment, le logiciel de gestion de code utilisé était Subversion, mais les nouveaux projets étaient gérés avec Gitlab (et donc git). Jusqu'à présent, les commits se faisaient depuis l'ordinateur du développeur puis celui-ci allait faire les commandes de pull manuellement sur les différents serveurs (test, production, parfois plusieurs serveurs pour les systèmes en cluster).

Pour un projet, j'utilisais donc Gitlab, mais étant encore au stade de développement et ayant donc des modifications fréquentes, je ne me voyais pas me connecter plusieurs fois par jours sur le serveur afin de déployer les modifications manuellement. En partant d'un simple script PHP, qui s'occupait de faire les pull automatiquement, j'ai amélioré le système afin d'avoir une configuration beaucoup plus complexe des dépôts avec possibilité de lancer des scripts avant et après chaque mise à jour, une gestion très fine des branches à "accrocher", des rapports d'exécution par mail...

 

Deploy Keys et WebHooks, le passage obligé...

 Une partie de la configuration des accroches se fait obligatoirement via l'interface de Gitlab, heureusement ces configurations ne seront à faire qu'une seule fois ... par projet. Et oui, ce n'est pas forcément la méthode la plus simple, mais je n'ai malheureusement rien trouvé d'autre...

Deploy Keys

Pour que le script d'accroche puisse faire des mises à jour depuis notre dépôt Gitlab, il faut que l'utilisateur qui executera le script (l'utilisateur www-data dans la plupart des cas mais pas forcément) puisse faire appel au serveur en ssh sans avoir à taper de mot de passe. Pour cela, Gitlab propose des Deploy Keys. On renseigne la clé publique d'un utilisateur du serveur dans l'interface de gitlab et quand un utilisateur essayera de faire un pull avec la clé privée correspondante, celui-ci n'aura pas à fournir son mot de passe et pourra faire les mises à jour. Le script pourra donc lancer la mise à jour du dépôt sans crainte de se retrouver bloquer par un problème d'identification.

 

Image utilisateur

Menu de gestion des Deploy Keys

WebHooks

Les WebHooks sont une autre fonctionnalité de Gitlab, elles permettent d'appeler une url au choix lors :

  • D'un push
  • D'un push taggé (ainsi sur le serveur de production on pourra ne mettra à jour que les commits taggés...)
  • D'une issue
  • D'une Merge Request

A mon sens, les deux dernières propositions ont beaucoup moins d'utilité que les deux premières surtout dans notre cas mais sachez que Gitlab offre cette possibilité.

Image utilisateur
Menu de gestion des WebHooks

Ainsi en alliant les concepts de Deploy Keys et de WebHooks, on peut lancer une page web qui se chargera de mettre à jour les différents dépôts lors d'un commit.

Script de gestion de l'accroche...

Lors de l'appel d'un WebHooks, Gitlab met à disposition un objet json dans sa requête HTTP, celui-ci est récupérable en PHP par exemple via un appel à une fonction de lecture de fichier comme file_get_contents et le flux php://input. On obtient alors un objet JSON de cette forme :

{
	"before":"095dab0794dcea6b81584f7a472dfc41693c011b",
	"after":"e8f1e3a2b71a70ecd2f58941ffc084de3eadb0d3",
	"ref":"refs/heads/master",
	"checkout_sha":"e8f1e3a2b71a70ecd2f58997ffc0879e3eadb0d3",
	"user_id":2,
	"user_name":"Toshy",
	"project_id":5,
	"repository":{
		"name":"projet-de-test",
		"url":"git@gitlab.toshy.net:toshy/projet-de-test.git",
		"description":"Projet de test Gitlab",
		"homepage":"https://gitlab.toshy.net/toshy/projet-de-test"
	},
	"commits":
		[
			{
				"id":"e8f1e3a2bcda70ecd2f58997ffc084de3eadb0d3",
				"message":"Test de commit 3\n",
				"timestamp":"2015-02-18T19:40:41+01:00",
				"url":"https://gitlab.toshy.net/toshy/projet-de-test/commit/ee8f1e3a2bcda70ecd2f58997ffc084de3eadb0d3",
				"author": {
					"user_name":"Toshy",
					"email":"no-reply@toshy.net"
				}
			},
			// Pour alléger, je n'ai pas mis les deux autres commits...
		],
	"total_commits_count":3
}

Mise à jour simple du dépôt

Il est alors possible grâce à un script PHP de transformer ce json en array (grâce à la fonction json_encode) afin de récupérer des données comme le nom du dépôt, l'url à utiliser pour le cloner ou encore le nom de la branche en faisant un petit travail sur le champs ref du tableau.

Avec ces informations on a déjà de quoi faire un petit système alléchant. Si on ajoute un petit fichier de configuration très simple en json comme celui ci-dessous, on peut alors faire un système un peu plus complexe :

{
	"projet-de-test": {
		"master":{
			"directory": "/var/www/projet-de-test"
		}
	}
}

Il suffit à chaque appel à la page web, de regarder que notre fichier de configuration a bien une entrée pour le projet et pour la branche et dans ce cas, de vérifier si le chemin defini existe ou non. On pourra alors executer une des deux commandes shell suivante avec shell_exec par exemple :

# Dans le cas ou $directory n'existe pas
git clone -b $branch $url $directory
# Sinon c'est juste une mise à jour
git pull origin $branch

On a donc déjà un script assez simple qui fait que mettre à jour notre dépôt mais il est bien sur possible d'aller plus loin...

Image utilisateur

Schéma de la mise à jour simple d'un dépôt

Attention : Dans le cas ou vous auriez fait le premier clone du projet dans l'arborescence du serveur manuellement, vérifier que c'est bien l'utilisateur web (www-data) qui a été utilisé lors du premier clonage. Si ce n'est pas le cas, je vous conseille de supprimer le dossier et de refaire un clone manuellement mais en utilisant cet utilisateur.

Pas mal d'autre choses intéressantes

On a vu jusqu'ici comment faire des mises à jour "simple" sur un dépôt mais comment gérer le fait que certains projets doivent obligatoirement executer certains scripts après une mise à jour, je pense notamment aux projets Symfony2 qui nécessitent de vider le cache pour fonctionner correctement (et il pourrait aussi être intéressant de demander à doctrine de mettre à jour le schéma sur un serveur de test par exemple...).

Le problème de ces traitements c'est qu'ils sont généralement long et que le temps d'exécution d'un script PHP est généralement limité par le serveur. Après quelques réflexions, j'ai décide de faire tourner le script PHP de mise à jour en PHP-Cli sans attendre que le script soit fini pour que le serveur retourne la réponse à Gitlab. Pour ce faire, dans ma page web, je me contente de récupérer les informations de dépôt, de branche et d'url puis j'exécute un autre script PHP en cli en arrière plan (option & dans bash et donc utilisable avec shell_exec). Le traitement PHP peut donc prendre plusieurs minutes sans être coupé au milieu ou que Gitlab attende une réponse pendant de longue minutes...

J'ai personnelement ajouter trois champs dans mon fichier de configuration :

  • preupdate: un ensemble de commandes shell à exécuter avant la mise à jour
  • postupdate: un ensemble de commandes shell à exécuter après la mise à jour
  • mail: un ensemble d'adresses mail où envoyer les logs de mise à jours

Preupdate me sert notamment pour les dépôts de production afin de pouvoir activer une page de maintenance, le script de postupdate vérifiera que la mise à jour s'est bien passée avant de désactiver cette page. Ainsi les utilisateurs du service ne se retrouvent pas face à des pages d'erreurs durant la mise à jour...

La gestion des accroches Gitlab via Gitlab...

Dans le cas, de mon travail, le nombre de serveur sur lequel devait être géré les accroches gitlab était assez important (une petite dizaine) et devait pouvoir facilement augmenter. Le système d'accroche devait être suffisamment simple pour que la totalité des membres de l'équipe puissent facilement créer leurs accroches et que je n'ai qu'à les valider. De plus, le code du script d'accroche devait pouvoir facilement être modifié. J'ai donc décidé de gérer les accroches comme un dépot Gitlab avec une partie code source et une autre partie contenant les fichiers de configuration par serveurs. Un script de postupdate s'occupait de lier le fichier de configuration du serveur actuel vers le fichier de configuration utilisé par le système d'accroche. Ainsi le dépôt Git peut contenir plusieurs dizaines de fichiers de configuration et celui utilisé varie en fonction du serveur.

Arborescence déployée sur un serveur (ici le "serveur 1"):

.
├── conf
│   ├── hooks.serveur1.json
│   ├── hooks.serveur2.json
│   ├── hooks.serveur3.json
│   ├── hooks.serveur4.json
│   ├── hooks.serveur5.json
│   └── hooks.json -> hooks.serveur1.json
├── web.php
└── cli.php

Et voici un exemple de ce que peut contenir le fichier hooks.serveur1.json :

{
	"toshy/accroche-git": {
		"master": {
			"comment": "Partie utiliser pour la mise à jour des accroches Gitlab",
			"location": "/var/www/accroche-git",
			"mail": "toshy@mon-email.fr",
			"preupdate": "rm -f conf/hooks.json",
			"postupdate": "cd conf/; ln -s hooks.serveur1.json hooks.json"
		}
	}
}

De cette manière, le script de mise à jour utilisera toujours le fichier hooks.json quelque soit le serveur. Il sera aussi possible de mettre à jour les fichiers de configuration et le code du système d'accroche directement via le dépôt gitlab. Seul le premier déploiement sur le serveur devra s'effectuer à la main (et aussi si quelqu'un commit un code non fonctionnelle dans le dépôt qui "casse" le script de mise à jour...).

 

J'espère dans cet article vous avoir fourni un apercu assez complet de comment mettre en place un système d'accroche simple avec Gitlab. La solution présentée est sans doute nettement améliorable et posera sans doute problème avec certains projets à cause de certaines faiblesses (script PHP obligatoire mais il est possible de le remplacer par un autre langage, une limitation au niveau de l'utilisateur pouvant faire des mises à jour : uniquement www-data dans la plupart des cas...). Mais le petit bonus, c'est que Github propose aussi un système de webhooks même si la syntaxe du json fourni est un peu différente, mais avec quelques modifications, il sera bien sûr possible d'avoir un resultat assez similaire avec Github.

 

Edition du 26/03/2015 : Merci beaucoup @bobmaerten pour avoir été la source d'inspiration du système ainsi que pour ses précieux conseils pendant la mise en place de la solution (et pour ses précieux conseils pour tout ce qui touche au développement/administration système d'ailleurs clin.png).

Installer Composer sous Debian/Ubuntu 2015-02-12CET19:00:00+01:00

Image utilisateur

Voici la marche à suivre pour installer Composer sous les distributions basées sous debian (ubuntu, linux mint...), Composer n'étant pas disponible sous forme de paquet deb.

 

Via PHP-cli et curl

Il est très facile d'installer composer via php-cli et curl.

Télécharger le fichier php permettant de générer le paquet phar puis l'exécuter avec php :

curl -sS https://getcomposer.org/installer | php

Déplacer le fichier ainsi généré dans le dossier /usr/local/bin (nécessite d'être root) :

mv composer.phar /usr/local/bin/composer

Avec wget

Télécharger directement le dernier paquet phar construit depuis le site du projet composer :

wget https://getcomposer.org/composer.phar

Le déplacer dans le répertoire /usr/local/bin (nécessite d'être root) :

mv composer.phar /usr/local/bin/composer

Vérifier l'installation de composer

Pour vérifier que composer est bien installé et connaître sa version :

composer -V

Mettre à jour composer

Pour mettre à jour composer, il suffit d'utiliser la commande :

composer self-update

 

Cette marche à suivre fonctionne sur les distributions basées sur debian, pour les distributions basées sous RedHat la marche à suivre est probablement assez similaire...

Ouverture du nouveau blog 2015-02-11CET21:30:00+01:00

Malgré le peu de changement ces derniers mois sur le blog, je vous propose aujourd'hui une nouvelle version ou plutôt un nouveau blog. Il y a en effet plusieurs raisons à cela, je vais vous les détailler dans cet article...

Mon premier blog a ouvert en octobre 2013, c'est assez récent, mais en même temps, cela fait presque un an et demi et énormément de choses ont changé durant ce laps de temps. Lorsque je me suis mis à coder la première version de toshy.net en juillet 2013, j'étais encore étudiant en fin de première année de DUT Informatique. Aujourd'hui et depuis quelques mois, je suis développeur et je travaille en tant qu'informaticien au sein d'une université Lilloise. Entre temps mon utilisation de l'informatique, mais aussi mes compétences en développement ont beaucoup changé.

Changement au niveau des contenus

Les contenus de l'ancien blog ne sont plus tous présents sur cette nouvelle version. J'ai en effet décidé de faire du tri dans les articles pour en enlever un certain nombre qui me semblaient obsolètes, inintéressants ou n'ayant que peu d'intérêt aujourd'hui. Je compte essayer de garder sur ce nouveau blog des articles majoritairement techniques autour de l'administration système ou du développement web.

Je parlerai aussi sans doute des nouvelles technologies en général, mais je compte éviter les articles coups de gueule ou du 3615mylife.

Par contre, je n'ai pas honte du passé et l'ancien site ainsi que l'intégralité des articles restent présents à l'adresse suivante: http://archive.toshy.net.

Changement au niveau du développement du site

Le constat

Quand j'ai écrit les premières lignes du "CMS" de toshy.net, j'étais encore un développeur voulant maîtriser ses développements de bout en bout sans utiliser d'outils tiers comme des frameworks. J'avais de grandes lacunes dans l'utilisation avancée de système de gestion de base de données notamment...

Je ne dis pas que deux ans plus tard, je n'ai plus aucune lacune puisque dans l'informatique, on ne maîtrise jamais entièrement une technologie. Mais lorsque j'avais posé les bases du code, je n'avais pas pris en compte énormément de bonnes pratiques même si au fur et à mesure du temps, j'ai développé un certain nombre d'outils qui m'ont permis de combler énormément de point faible du code source original :

  • Un outil permettant de générer automatiquement des liens réécrits et de remplir dynamiquement le fichier .htaccess
  • Un mini ORM qui me facilitait la gestion de la base de données, notamment du fait de l'absence d'intégrité relationnelle
  • Un outils de minification de css qui permettait de diminuer les temps de chargement du site

Malheuresement, les outils développés ont rapidement montré leurs limites et chaque opération de maintenance était de plus en plus couteuse en temps de développement et de tests. En plus des problèmes de spam m'ont forcé à fermer les commentaires sur l'ancien site, l'outils d'administration étant en plus ingérable, j'ai décidé de partir sur une nouvelle solution.

La réfléxion

Encore fallait-il avoir une idée de technologie pour la nouvelle base. Un recodage complet du site me trottait dans la tête depuis cet été. À l'époque, j'avais été tenté de réécrire le site avec la technologie nodejs mais l'envie m'en était assez vite passée, par manque de temps notamment. À l'époque, une refonte complète du site ne me semblait pas encore indispensable et un passage vers nodejs était plus un défi "technologique" qu'un véritable besoin.

Puis après avoir essayé de modifier l'interface d'administration de l'ancien site pour y intégrer TinyMCE, je me suis rendu compte du travail de maintenance énorme qu'aurait coûté la réécriture quasi totale de l'espace d'administration. Je me suis donc lancé dans l'idée de recoder le site en entier, mais en restant sur des technologies PHP. Voulant me lancer dans l'apprentissage d'un framework, j'ai décidé de mettre ce projet à profit pour me lancer dans le développement d'application Symfony2. Voulant faire simple au niveau du design, j'ai décidé d'utiliser le framework CSS bootstrap et la librairie jQuery comme surcouche javascript (venant par défaut avec le framework bootstrap, il aurait été dommage de s'en priver).

Après quelques jours de développement, je me suis rendu compte que malgré la courbe d'apprentissage de Symfony2 que j'ai trouvé assez rapide, le travail de mise en place du blog avec toutes les contraintes que je désirais (panel d'administration complet, outils d'importation d'articles) prendrait du temps et j'ai voulu regarder du côté des CMS puisque mes contraintes étaient assez "standard". Après quelques jours de recherche, je n'ai pas trouvé de CMS me donnant le rendu graphique et fonctionnel que je souhaitais ou alors en utilisant trop de plugins rendant chaque mise à jour complexe.

La décision

Après un certain temps de réflexion, j'ai pris la décision de finir la version que j'avais commencé en utilisant Symfony2. Cette première version n'aurait que peu de fonctionnalités, mais devait être mise en production assez rapidement afin de pouvoir ranger l'ancien site devenu complètement inutilisable. Aujourd'hui à la sortie, il manque donc un certain nombre de fonctionnalités :

  • Aucun système de commentaire
  • Pas de flux RSS

Mais en parallèle de nombreuses fonctionnalités du panel d'administration n'existait pas sur l'ancienne version :

  • Gestion de la réponse des messages de contacts
  • Création via le panel de compte et gestion des droits
  • Outils de création de page simple (les pages de l'ancien site étaient du code html en dure)

Bien sûr, les fonctionnalités manquantes seront ajoutées dans les prochaines semaines, cette version est la première mais ne sera normalement pas la dernière.

Conclusion

Le site prend un nouveau départ aujourd'hui...

De nouveaux articles devraient arriver prochainement, maintenant que j'ai une belle interface pour écrire des articles, il n'y a plus de raisons (me manque juste un correcteur orthographique intégré peut-être).

Tester votre serveur web avec Apache Benchmark 2014-11-07CET17:00:17+01:00

Il est souvent intéressant de savoir comment un serveur web se comporte face à un nombre important de connexion afin d'être sûr que votre serveur ne rendra pas l'âme si vous faites soudain face à un afflux de visiteurs.

Pour ce faire, il existe énormément d'outils différents pour faire des benchmarks de serveurs web. Certains sont très complexes et permettent de gérer différents scénarios avec une liste de requêtes à faire avec des paramètres. Ces outils tels JMeter, bien que très puissant ont l'inconvénient d'être long à configuré ce qui n'est pas toujours utile quand on veux juste tester la puissance brut d'une page (notamment si la page est censée faire un traitement lourd, il y aura alors moyen de rechercher des pistes d'améliorations).

Présentation de Apache Benchmark

C'est ici qu'Apache Benchmark entre en scène. Un programme simple, qui fait des choses simples et qui le fait bien. Il permet tout simplement de bombardé une URL de requête HTTP avec différents paramètres choisient par l'utilisateur et d'avoir un retour avec notamment des stats sur :

  • Le nombre de requêtes exécutés à la seconde
  • Le temps médian de réponse à une requête
  • Le temps maximum de réponse à la requête

Les informations concernant le nombre de requêtes exécuté à la seconde ainsi que le temps médian de réponse est important puisqu'on considère généralement une application comme "performante" tant qu'elle réponds à 10 requêtes par seconde, mais cela dépends bien entendu du nombre de requêtes exécutés en parallèle (qui est aussi définissable dans Apache Benchmark clin.png ).

Comme son nom l'indique, Apache Benchmark est développé par la fondation Apache et fait partie des apaches-utils, il était à la base développé pour tester les performances du serveur HTTP Apache, mais il est compatible avec la totalité des serveurs web HTTP et peut donc fonctionner sans problème avec nginx ou lighttpd smile.png.

Installation d'Apache Benchmark

L'installation d'Apache Benchmark se fait via les dépôts sur la plupart des distributions linux. Voilà la commande pour quelques systèmes différents :

Debian/Ubuntu
apt-get install apache2-utils 

 

Fedora/Redhat
yum install httpd-tools

 Sous Mac OS X, Apache Benchmark est installé par défaut et est accessible de base via le terminal.

Utilisation d'Apache Benchmark

L'utilisation d'Apache Benchmark se fait entièrement via la ligne de commande avec l'utilitaire ab. Le seul paramètre obligatoire est l'URL de la page à tester. Par exemple pour tester http://www.monsite.com, on utilisera la commande suivante :

ab http://www.monsite.com/

Avec cette commande, Apache Benchmark simulera une seule requête sur l'adresse passée en paramètre et retournera un certain nombre d'information :

Server Software:        nginx/1.2.1
Server Hostname:        www.monsite.com
Server Port:            80

Document Path:          /
Document Length:        13781 bytes

Concurrency Level:      1
Time taken for tests:   0.153 seconds
Complete requests:      1
Failed requests:        0
Total transferred:      14171 bytes
HTML transferred:       13781 bytes
Requests per second:    6.54 [#/sec] (mean)
Time per request:       152.984 [ms] (mean)
Time per request:       152.984 [ms] (mean, across all concurrent requests)
Transfer rate:          90.46 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       21   21   0.0     21      21
Processing:   132  132   0.0    132     132
Waiting:      131  131   0.0    131     131
Total:        153  153   0.0    153     153

On voit ici qu'on a fait une requête sur un serveur nginx qui a mis 152ms pour répondre, ce qui fait environ 6,5 requêtes par seconde.

Plusieurs requêtes

Le problème de ces résultats c'est que l'échantillon de test est trop petit (comme pour les statistiques). Pour avoir une moyenne acceptable, il va falloir augmenter le nombre de requête. On peut commencer par en faire 100 par exemple. Pour cela, on ajoute un argument -n à la commande suivi du nombre de requête désiré :

ab -n 100 http://www.monsite.com/

On obtient alors des indicateurs beaucoup plus fiable puisqu'en général une moyenne ou une médiane de la totalité des tests. Les résultats sont donc plus fiables à mesure que le nombre de connexion total augmente et donc la taille de l'échantillon de test.

Connexion simultanée

Mais la mesure la plus intéressante est celle du nombre de connexion simultannée: A partir de combien de connexion parallèle, le site internet devient tellement lent que le plaisir de surf est fortement réduit. Il est possible de simuler les connexions parallèles avec Apache Benchmark et son option -c. Par exemple, pour simuler 25 connexions simultannées, il faudra utiliser la commande suivante :

ab -n 1000 -c 25 http://www.monsite.com/

Vous remarquerez que j'ai augmenté le nombre de requête total afin de garder des chiffres fiables malgré l'augmentation des connexions simultanées. En général il faut garder une certaine proportionnalité entre le nombre de requêtes simultanées et le nombre total.

Simuler une authentification ou un Cookie

Certaines pages ne sont parfois accessibles que via une authentification que ce soit via une session (en php ou Java par exemple) ou via une authentification HTTP. Il est bien sûr possible de simuler ces deux cas avec Apache Benchmark puisqu'il est possible d'ajouter des en-têtes HTTP et des cookies à la requête qui sera exécutée.

Si vous utilisez votre propre système d'authentification généralement via une session, il faut transmettre votre cookie PHPSESSID à la page. Pour récupérer votre PHPSESSID, vous pouvez passer via les outils développeur de votre navigateur. Par exemple sous Firefox, vous pouvez passer par l'outil réseau dans Outils > Développement Web > Réseau. Vous pouvez alors récupérer la valeur de votre PHPSESSID via l'onglet cookies d'une requête.

Pour envoyer votre cookie avec la requête, il faut utiliser la commande -C :

ab -n 100 -C "PHPSESSID=g54h93sg35ejlnfzeam2874kn2" http://www.monsite.com/

Dans le cadre d'une authentification HTTP, il faut utiliser l'en tête Authorization qui est généralement sous la forme suivante :

Authorization: Basic BASE_64_DE_CONNEXION

La chaine BASE_64_DE_CONNEXION est l'encode base 64 de la chaine du type: username:password. Pour s'authentifier avec le nom d'utilisateur et le mot de passe moi, on utilisera donc la commande suivante :

ab -n 10000 -c 200 -H "Authorization: Basic bW9pOm1vaQ==" http://www.monsite.com/

L'instruction -H permet d'ajouter des en-têtes HTTP, il est bien sûr possible de définir d'autre en tête que Authorization clin.png.

Intégrer l'éditeur tinyMCE dans son site 2014-10-23CEST15:30:15+02:00

Dans cet article, je vais vous présenter comment intégrer l'éditeur de texte riche tinyMCE dans votre site internet. Le but d'un éditeur de texte riche est de proposer une solution WYSIWYG, afin que vos utilisateurs puissent rédiger sur votre site sans utiliser des langages de description de contenu comme le markdown ou le bbcode.

L'intégration de tinyMCE peut paraitre extrêmement simple au premier abord, mais elle n'en reste pas moins complexe dès qu'on souhaite pousser l'intégration.

Téléchargement et installation de tinyMCE

Pour pouvoir télécharger tinyMCE, je ne peux que vous conseiller de vous rendre sur le site officiel : http://www.tinymce.com.

L'utilitaire est proposé en trois versions :

  • Une version standard pour une utilisation en production.
  • Une version sous forme de module pour jquery.
  • Une version pour faire du développement de module (contrairement aux deux autres versions, le code javascript est disponible en version non minifiée).

 Personnellement, utilisant jquery sur mon site, j'ai récupéré la deuxième version, mais rien ne vous empêche de choisir la première si vous n'utilisez pas cette librairie.

L'installation basique de la librairie est d'une extrême simplicité, dezipper le répertoire tinymce/js/tinymce dans votre arborescence web (dans un dossier nommé tinymce par exemple) puis il est possible de remplacer un élément html (via un sélecteur css) par l'éditeur riche. Par exemple, pour transformer un textarea ayant l'id mon_editeur, il faudra utiliser le code suivant :



 

On se rend bien compte, qu'il n'y a rien de compliqué ici. Si vous utilisez la version jquery, voici le code ayant le même résultat :



 

 

Encore une fois, rien de bien compliqué ici, on sélectionne l'élement via son id et on appelle dessus la fonction tinymce en lui précisant le chemin du script tinyMCE.

On obtient alors un éditeur simple ressemblant à ceci :

image utilisateur

Il est maintenant temps de faire quelques modifications afin d'adapter celui-ci à nos besoins clin.png.

Personnalisation de tinyMCE

TinyMCE propose un certain nombre d'options de configuration afin d'adapter l'éditeur à vos besoins notamment via des plugins. Par défaut TinyMCE en propose une quarantaine, mais vous pouvez bien évidemment développer les vôtres pour intégrer certaines fonctionnalités spécifiques de vos sites à l'éditeur.

Je vous propose de commencer par changer la langue de l'éditeur, par défaut, les menus sont en anglais, mais il est bien évidemment possible de traduire l'éditeur dans d'autres langues (liste disponible ici clin.png). Pour cela téléchargez le fichier de langue puis placez-le dans le répertoire langs. Dans la configuration de votre module, vous devrez alors ajouter une ligne pour sélectionner la langue :

tinymce.init({
	selector:'#mon_editeur',
	language: 'fr_FR'
});

Vous obtenez alors un formulaire complètement traduit en français.

Vous pouvez bien entendu ajouter d'autres modules que ce présent par défaut via le paramètre plugins. Par exemple pour ajouter l'utilitaire des gestion des liens et des images à votre éditeur, adaptez la configuration comme ceci :

tinymce.init({
	selector:'#mon_editeur',
	plugins: 'link image',
	language: 'fr_FR'
});

Pour obtenir une liste des plugins disponibles, rendez-vous dans le dossier plugins de votre installation tinyMCE.

Maintenant que nous avons vu les deux plus importants paramètres de configuration, je vous propose ci-dessous ma configuration avec commentaire à l'appui afin de vous permettre de configurer finement votre installation :

tinymce.init({
	selector:'#mon_editeur',
	plugins: 'link image code',
	language: 'fr_FR',
	content_css: "style/tinymce.css", /* Change le style du contenu de l'éditeur */
	toolbar: "styleselect | bold italic | alignleft aligncenter alignright alignjustify | bullist numlist outdent indent | link | image | code", /* Liste les éléments à faire apparaitre dans la toolbar dans l'ordre voulu */
	menubar : false, /* Retire la barre de menu */
	theme_advanced_blockformats:"h1,h2,h3,h4,h5,h6" /* Désactive les boutons d'ajout de titre */
});

Et voici le résultat :

image utilisateur

 

Voilà, j'espère que cette petite introduction à tinyMCE vous sera utile et j'espère revenir très vite pour écrire un autre article hihi.png.

Dart : Premières impressions 2013-11-21CET18:00:18+01:00

La semaine dernière, le langage Dart sortait en version stable. Après avoir été présenté avec fracas il y a plus d'un an, il est maintenant temps de s'intéresser de plus près à ce langage. Présenter comme un javascript-killer, qui doit plonger ce dernier dans les abîmes de l'histoire, le langage tient-il ses promesses? Va t-il décoller ou rester un langage parmi d'autre comme Go?

Bref autant de questions qui me trottaient dans la tête quand je me suis dit qu'il valait mieux que je me forge ma propre opinion en me lançant dans l'étude de ce langage.

 

Détour par les outils de développements


Passage obligé pour tout débutant en dart, le site dartlang édité par Google où se trouvent le SDK et la doc de Dart. Il faut d'abord récupérer le SDK et déjà on voit qu'on dispose de plusieurs outils assez intéressants :

  • Un IDE : DartEditor qui finalement n'est qu'un dérivé d'Eclipse avec le plugin pour Dart
  • Un navigateur : Dartium, une versions de Chromium embarquant une machine virtuelle pour Dart
  • Un compilateur : dart2js qui permet comme son nom l'indique de compiler nos sources Dart en javascript (et ainsi pouvoir les lancer sur d'autre navigateur que Dartium).
  • Une VM Dart : dart qui permet d'exécuter du code Dart dans la console.

 

On dispose donc d'outils plutôt agréable sà utiliser surtout que DartEditor et Dartium travaillent ensemble, ce qui permet de voir les erreurs et exceptions dans DartEditor dès que Dartium les rencontres, ce qui a l'avantage de faciliter le développement par rapport au classique couple firebug/éditeur de texte

Il est possible aussi de récupérer la documentation de Dart mais celle-ci est aussi accessible en ligne. La documentation est complète, mais manque peut-être de quelques exemples. Après mon avis est sûrement biaisé par la documentation de PHP qui est rempli d'exemples. Il est aussi intéressant de récupérer le guide « A tour of Dart Language » qui présente la plupart des fonctionnalités du langage en question.

 

Dart en lui-même


Quand on se lance dans Dart, on voit clairement d'où vient l'inspiration des concepteurs. On retrouve des éléments de Javascript, pas mal de choses venant de Java et aussi sûrement quelques emprunts à Ruby.

La première chose incontournable à savoir est qu'en Dart tout est objet, y compris les types primitifs comme int ou bool, mais aussi les fonctions. L'autre chose à savoir c'est qu'en Dart, il y a possibilité de typer ses variables (mais ce n'est pas obligatoire), ça permet de trouver beaucoup plus vite des erreurs et aussi d'avoir un code plus propre (ceci reste un avis personnel).

Dart propose un modèle objet beaucoup plus « classique » où les prototypes sont absents. Dart permet de créer des classes et d'en faire des instances avec une syntaxe proche de Java (ou du C#). Toute classe en Dart, hérite de la classe Object ce qui lui permet d'avoir un certain nombre de méthode de base (comme la méthode toString par hasard).

 

void main() {
  Voiture v = new Voiture("Espace", "Bleu");
  print(v.toString());
}

class Voiture {
  String _modele, _couleur;
  Voiture(this._modele, this._couleur);
}

 

Ce code renverra la chaine : Instance of 'Voiture'. Si maintenant, on s'amuse à modifier la méthode toString, on peut tout à fait modifier le renvoi. Le morceau de code ci-dessus, vous montre déjà pas mal de choses sur Dart :

  • Tout le code doit se trouver dans une fonction, c'est la fonction main() qui est exécuté.
  • Il n'y a pas de mot clé pour la visibilité dans la classe, celle-ci fonctionne avec une convention de nommage. Tout attribut qui commence par un underscore n'est pas accessible en dehors de la Library (un fichier ou un ensemble de fichier) où il est défini.
  • Dart propose un sucre syntaxique assez intéressant. Ainsi la ligne Voiture(this._modele, this._couleur); qui est le constructeur de la classe Voiture (il a le même nom) attendra deux arguments donc il stockera le premier dans _modele et le deuxième dans _couleur. Attention : Ce sucre syntaxique ne fonctionne que dans le constructeur ;) .

 

Ces quelques lignes, permettes déjà de se donner une idée du but de Dart qui est de permettre la création d'un code rigoureux mais rapide à écrire avec pas mal de sucre syntaxique.

On retrouve aussi en Dart, un modèle objet entier comme on en trouve dans la plupart des langages actuelles. Ce qui permet de faire des choses jusqu'alors impossible en Javascript (ou alors beaucoup plus complexe) :

  • De l'héritage
  • Des interfaces
  • Des exceptions
  • Des getters/setters
  • Du polymorphisme

 

Petite déception cependant pour les interfaces puisqu'on parle d'interface mais qu'il n'existe pas comme tel, ce ne sont que des classes abstraites donc aucune méthode n'est défini. C'est malheureux puisque Dart ne gère pas l'héritage multiple. Les interfaces permettaient en général de régler ce problème. Ici, il faudra faire autrement.

 

La librairie standard


La librairie standard de Dart est sans aucun doute un gros avantage, avec un nombre de paquet permettant de toucher tous les aspects du développement web (et aussi un paquet pour le côté serveur). On retrouve notamment :

  • dart:html : librairie de gestion du HTML avec notamment DOM et la gestion du canvas
  • dart:collection : librairie qui propose plusieurs classes de gestion de structure de données (liste chaînés, itérateur, HashMap...)
  • dart:isolate : permet de faire de la programmation parallèle (thread) en dart
  • dart:web_audio : librairie de gestion du son
  • dart:web_gl : librairie de gestion du webGl (permettant de faire de la 3d dans le navigateur)

 

En plus de ces librairies, on trouve aussi des fonctions pour gérer le JSON, la serialization, les tests unitaires.

On trouve aussi une librairie plus surprenante dans un langage qui vise plutôt le web, je parle de dart:io. C'est une librairie qui regroupe un nombre conséquent de fonctions utile côté serveur : gestion des fichiers, des sockets, des websockets... En bref, de quoi remplacer des outils comme node.js pour le côté serveur.

 

Mise en production


Il n'y a pas de secret, pour l'instant aucun navigateur web ne propose une machine virtuelle Dart en dehors de Dartium. Il est donc obligatoire de passer par un compilateur afin d'obtenir du code JavaScript. C'est le but de dart2js qui permet de générer le code JavaScript d'un fichier Dart. Il suffit alors dans le code HTML de remplacer la ligne d'inclusion du fichier Dart par celle du fichier JavaScript et le code fonctionne sous la plupart des navigateurs (tout du moins les versions récentes).

Pendant le début de ma prise en main de Dart, je me suis amusé à transposer une ancienne animation que j'avais en JavaScript en Dart. Je vous propose donc ci-dessous deux liens. Le premier propose la version avec le code Dart (il est donc nécessaire de l'ouvrir avec Dartium pour qu'elle fonctionne) et l'autre contient la version JavaScript (afin que vous puissiez comparer les deux).

 


Pour finir, je vais vous livrer mon avis sur le Dart. C'est selon moi un langage plein de promesses malgré quelques petites imperfections mais qui est une parfaite alternative au JavaScript. Bien sûr, JavaScript reste préférable sur des codes de petites tailles où il est inutile de sortir l'artillerie lourde (un peu comme JQuery qui n'est pas vraiment utile sur des codes d'une dizaine de ligne). Mais je pense vraiment que sur le prochain développements costaux que je prévoyais de faire en JavaScript, je tenterai l'option Dart afin de me faire un avis plus précis.

Créer un serveur de développement avec Virtualbox 2013-10-10CEST14:00:14+02:00

Après avoir vu plusieurs messages sur différents forums où des personnes avaient les plus grandes peines du monde à faire fonctionner des logiciels comme EasyPHP ou Wamp, je me suis rendu compte à quel point la solution que j'utilise depuis près d'un an est simple et paramétrable. Wamp est un bon logiciel qui fait ce qu'on lui demande (c'est le plus important), mais il se trouve vite impuissant quand on souhaite ajouter des extensions PHP qu'il ne supporte pas, ou que l'on modifie trop profondément la configuration de celui-ci. De plus, Wamp fonctionne sur un environnement Windows alors que la plupart (voir la totalité) des hébergeurs proposant PHP ne proposent que des serveurs sous Linux. C'est un gros problème surtout quand l'on connait les nombreuses différences entre les versions Windows et Linux de PHP. C'est pour cette raison que depuis quelques temps, j'ai fait le choix d'installer une machine virtuelle sous Ubuntu Server qui me sert de serveur de développement en remplacement de Wamp (ou Mamp sous Mac). On pourrait croire que cela rend plus compliquer le développement, mais la gestion réseaux de Virtualbox permet d'accéder à une machine virtuelle depuis l'ordinateur hôte. Ainsi la machine virtuelle s'efface complètement à tel point qu'on a tendance à oublier de la démarrer au début de la journée :) .

Je vais donc vous proposer aujourd'hui, un article qui vous guidera pas à pas pour créer un serveur de développement pour PHP/MySQL sous Ubuntu Server à l'aide de Virtualbox.

 

Récupération des outils nécessaire


Nous allons commencer par récupérer le logiciel Virtualbox. Vous trouverez les archives pour Windows et Mac OS X ici. Si vous êtes sous Linux, Virtualbox est disponible dans les dépôts des principales distributions (bien que l'utilité d'un tel tutoriel sous Linux soit discutable). Une fois Virtualbox récupéré, installez-le.

Il nous faut aussi récupérer Ubuntu Server (ou n'importe quel autre distribution, mais cet article prendra l'exemple de Ubuntu Server). Pour cela, vous devez vous rendre sur cette page. J'ai personnellement choisi la version LTS, mais vous pouvez aussi prendre la dernière version en date ;) . Si vous désirez récupérer Ubuntu par torrent, vous pouvez le faire ici.

 

Installation de Ubuntu Server


Commencer par créer une nouvelle machine Virtuelle que vous nommerez par exemple "Ubuntu". Pour la taille de mémoire, je vous recommande entre 256 et 512Mo de RAM selon la quantité que possède votre machine (pour un simple serveur Web, les deux devraient être largement suffisant).


Vous devez ensuite créer un disque dur, la valeur par défaut de 8Go est normalement suffisante pour l'utilisation que nous voulons en faire. Adapter cette taille en fonction de vos besoins et de la taille de votre disque dur :) .


Ensuite, lancer la machine virtuelle et sélectionner l'iso de Ubuntu Server précédemment télécharger comme disque par défaut. Votre machine virtuelle devrait démarrer et vous devriez arriver sur l'écran suivant :


Sélectionnais le français, l'installation de Ubuntu démarre. Un écran vous demande de sélectionner votre pays. Ubuntu vous propose ensuite de détecter l'agencement de votre clavier. Une fois cette étape passée, Ubuntu configure le réseau et vous demande de donner un nom à votre machine (personnellement ma machine virtuelle se nomme serveur), vous devez ensuite renseigner le classique couple nom d'utilisateur/mot de passe puis votre zone géographique :p .

Nous arrivons enfin à l'étape du partitionnement. Ici, nous sommes dans une machine virtuelle, notre disque dur réel ne craint rien, nous pouvons donc choisir sans hésiter le partitionnement manuel. Une fois ce choix fait, nous devons créer une table de partition sur notre disque dur. Pour cela, sélectionnez votre disque dur puis à la question "Voulez-vous créer une nouvelle table de partition ?" répondez "oui".

Maintenant nous allons créer deux partitions :

  • Une partition de SWAP de 512Mo.
  • Une partition en ext4 qui prend tout le reste de l'espace disque avec indicateur d'amorçage et un point de montage à la racine (/).


Je vous laisse créer ces deux partitions puis valider les modifications :) . Ubuntu installe alors le système de base puis vous demande si vous désirez configurer un proxy, si vous n'en utilisez pas ou si vous ne savez pas ce que c'est, laisser le champ vide. Ubuntu télécharge alors les paquets manquants ainsi que les mises à jour puis installe le tout. Vous pouvez ensuite configurer les mises à jour automatique (je ne l'ai personnellement pas fait, car le système n'est pas critique ici puisqu'il s'agit d'un serveur de développement). Ubuntu vous propose ensuite une liste de logiciel à installer allant du serveur OpenSSH au serveur Samba. N'installer aucun de ces logiciels, nous ferons tout ça plus tard ;) . Appuyer sur continuer pour installer les derniers paquets. Il ne nous reste plus qu'à installer GRUB sur le secteur d'amorçage. L'installation est finie, nous allons maintenant configurer le réseau, pour cela quittez la machine virtuelle.

 

Configuration du réseau


Nous allons maintenant passer à la configuration du réseau, nous allons créer un réseau local avec deux machines :

 

  • 10.0.0.1 : Représente la machine hôte (votre machine physique).
  • 10.0.0.2 : Représente la machine serveur (la machine virtuelle).


Pour cela, nous utilisons le réseau 10.0.0.0 qui est un réseaux privé (non routable sur internet comme 192.168.0.0 qui est souvent l'adresse de votre réseau local). En utilisant 10.0.0.0, nous sommes sûrs de ne pas utiliser une adresse déjà existante ;) .

Pour configurer le réseaux tout en gardant un accès facile à internet, nous allons devoir configurer deux cartes réseaux virtuelle pour notre machine. La première déjà configurée lui permettant de naviguer sur internet, la deuxième lui permettra de communiquer avec la machine hôte.

Pour commencer, rendez-vous dans les préférences de Virtualbox (et non celle de votre machine virtuelle) puis dans l'onglet "Réseau". Puis sur le bouton en forme de plus : "Ajouter réseau privé hôte". Une fois celui-ci créé cliquez sur le bouton en forme de tournevis : "Modifier réseau privé hôte". Modifiez l'onglet Interface pour qu'il corresponde à ceci :


Puis l'onglet Serveur DHCP afin qu'il corresponde à celui-ci :


Validez ensuite les modifications puis allez dans l'onglet configuration de votre machine virtuelle (et non celle de Virtualbox), dans l'onglet réseau et dans l'onglet "Carte 2" cochez "Activer la carte réseau", dans le mode d'accès réseau, sélectionnez "Réseau privé hôte" et dans nom sélectionnez le réseau que vous venez de créer (vboxnet0 par défaut). Puis cliquer sur "Ok" pour valider les modifications.

Pour finir nous devons ajouter notre interface réseau à la liste des interfaces d'Ubuntu pour cela redémarrer votre machine virtuelle puis loguer vous. Ouvrer le fichier /etc/network/interfaces en tant qu'administrateur avec nano :

 

sudo nano /etc/network/interfaces

 

Puis ajouter ceci à la fin du fichier :

 

auto eth1
iface eth1 inet static
    address 10.0.0.2
    netmask 255.255.255.0

 

Nous avons ici configuré notre interface avec le nom eth1, pour que les modifications soient prise en compte, nous devons redémarrer les interfaces réseaux avec la commande suivante :

 

sudo /etc/init.d/networking restart

 

Installation des différents logiciel


Maintenant que le réseau est configuré, nous allons pouvoir installer tous les logiciels dont nous aurons besoin sur notre machine de développement. Pour ceci, nous allons commencer par installer un serveur SSH afin de pouvoir contrôler notre serveur de développement depuis notre système d'exploitation principale.

L'installation d'OpenSSH se fait tout simplement en tapant la commande suivante :

 

sudo apt-get install openssh-server

 

Maintenant que OpenSSH est installé, nous allons pouvoir travailler directement depuis le système hôte en nous connectant à notre machine via SSH. Pour vous connecter à votre serveur par SSH, vous pouvez utiliser la console sous Linux/Mac OS, mais sous Windows, vous aurez besoin de Putty. Pour la suite de ce cours, je suppose que vous savez utiliser Putty (si ce n'est pas le cas, il existe de nombreux cours très simple par exemple ici).

Nous allons nous connecter à notre serveur soit avec putty ou sous le terminal avec la commande :

 

ssh serveur@10.0.0.2

 

Maintenant que nous sommes connecté sur notre serveur depuis la machine hôte, nous allons pouvoir installer un serveur LAMP qui servira pour le développement web, mais avant afin de pouvoir facilement modifier le dossier /var/www depuis l'extérieur, nous devons changer son propriétaire avec la commande chown (en remplacent serveur par votre nom d'utilisateur):

 

sudo chown -R serveur /var/www

 

Nous pouvons maintenant installer le paquet lamp-server^ qui contient les différents paquets pour obtenir un serveur de développement fonctionnel (Apache2, mod_php, PHP5 et MySQL) :

 

sudo apt-get install lamp-server^

 

Durant l'installation, il vous sera demandé un mot de passe pour MySQL (il ne peut pas rester vide). Maintenant que notre serveur web est installé, nous pouvons nous rendre à l'adresse http://10.0.0.2/ et tester le rendu.

Il nous faut maintenant configurer PHP pour qu'il affiche les erreurs, car par défaut la configuration de PHP cache les erreurs, c'est important sur un serveur de production mais inutile et déconseillé sur un serveur de développement. Pour cela, nous devons modifier le fichier /etc/php5/apache2/php.ini :

sudo nano /etc/php5/apache2/php.ini


Vous devez trouver les deux lignes display_errors et display_startup_errors et passer leur valeur à On. Sauvegarder le fichier puis redémarrer apache :

 

sudo service apache2 restart

 

Il ne nous reste plus qu'à créer un fichier afin de vérifier que PHP fonctionne, pour cela nous allons supprimer le fichier index.html dans /var/www et le remplacer par un fichier index.php.

 

rm /var/www/index.html
echo"" > /var/www/index.php

 

Si tout se passe bien, vous devez tomber sur une page vous détaillant la configuration de PHP.

 

Accéder au fichier depuis la machine hôte


Nous avons maintenant un serveur fonctionnel, il ne nous manque plus qu'un outil pour pouvoir modifier notre dossier /var/www comme si celui-ci était sur la machine hôte. Il y a beaucoup de solutions différentes pour faire ça (scp, ftp) mais j'ai décidé d'utiliser SSHFS, car il ne demande aucune configuration supplémentaire du côté du serveur puisqu'il est compris dans openssh.

Mais pour cela, nous avons besoin de la commande sshfs sur notre machine hôte. Sous Linux, aucun problème elle s'installe en une ligne via les dépôts, mais sous Windows et Mac OS X c'est un poil plus complexe.

Commençons par Mac OS X, il faut télécharger et installer OSXFuse et SSHFS depuis le site du projet OSX FUSE. Une fois les deux paquets installés, vous avez accès à la commande SSHFS depuis le terminal. Pour monter le répertoire /var/www/ dans le dossier ubuntu qui se trouve sur le bureau, nous ferons :

 

sshfs serveur@10.0.0.2:/var/www ~/Desktop/ubuntu

 

Sous Windows, le logiciel Dokan vous permet de monter un lecteur SSHFS, vous pouvez le télécharger ici. Le logiciel propose une interface graphique assez simple, je vous laisse donc vous débrouillez seul ;) .


Voilà, je pense que vous avez maintenant la base d'un petit serveur de développement. Bien sûr, il n'est pas complet pour cela il faudrait ajouter PHPMyAdmin, des extensions pour PHP, un serveur SMTP pour utiliser la fonction mail... Mais le plus dur est fait, la plupart des choses manquantes existent dans les dépôts d'Ubuntu et dispose d'explication dans la documentation. Je n'exclue bien évidemment pas de faire un article sur l'installation de tel ou tel outils dans un futur plus ou moins proche ;) .

Wayland débarque et souhaiterait mettre X11 à la retraite 2012-10-29CET17:40:00+01:00

Aujourd'hui, l'interface graphique est quasiment une obligation dans un système d'exploitation. Malgré tout ce que peuvent dire les utilisateurs de Gentoo ou d'Arch Linux, peu de monde utiliserait un ordinateur si la seule interface disponible était la console avec du texte en noir et blanc. Il y a quelques jours est sortie la version 1.0 de Wayland, un projet ambitieux qui rêve de mettre le serveur X à la retraite. Celui-ci gère l'interface graphique depuis les années 1980 dans (quasiment) tous les systèmes d'explotation de type Unix. C'est une bonne occasion pour s'y intéresser, découvrir les raisons de sa création mais aussi pourquoi un remplaçant est aujourd'hui nécessaire et comment celui-ci va fonctionner.

 

X11, un ancêtre de l'informatique

 

L'invention de l'interface graphique

 

Pour comprendre ce qu'est X11, il est nécessaire de faire un retour dans le passé. L'histoire des débuts de l'interface graphique sur ordinateur est assez connue. Tout commence dans le début des années 1970 quand l'entreprise Xerox conçoit l'Alto : le tout premier ordinateur à disposer d'une interface graphique. Cette révolution ne se présente pas seule, car contrairement aux autres machines de l'époque, l'Alto n'est pas conçu pour les informaticiens, mais pour des utilisateurs plus occasionnels comme des employés de bureau. L'idée vient alors à l'équipe de création de réutiliser les éléments du bureau (les dossiers, les pots à crayon...) ainsi que des fenêtres pour séparer les différentes applications dans son ordinateur. De là est née la métaphore du bureau que l'on retrouve encore aujourd'hui dans la majorité des interfaces utilisateurs. La suite est plus connue. L'équipe d'Apple visite les laboratoires de Xerox et Steve Jobs comprend alors que ce concept pourrait révolutionner l'informatique grand public. Il essaye de convaincre la direction de Xerox de mettre en place l'interface graphique dans les ordinateurs Apple ; celle-ci accepte, car elle considère son invention comme un gadget. Après avoir connu un revers avec l'Apple Lisa (1983), le premier ordinateur qui propose une interface graphique, Apple va démocratiser l'invention de Xerox avec un ordinateur de légende : le Macintosh (1984).

 

La création de X11

 

L'interface graphique va très vite se vulgariser et tous les constructeurs de l'époque vont petit à petit en mettre en place dans les systèmes d'exploitation de l'époque. Le problème, c'est qu'il n'existe pas à l'époque de standards, ce qui a eu pour conséquence une grande variété d'implémentations de l'interface graphique autant du point de vue fonctionnel pour l'utilisateur que technique pour les développeurs. Ainsi, on trouva dans les années 1980 une foule de constructeurs qui créèrent des systèmes complètement différents, par exemple :
FM Towns avec Windows 3.0 et une surcouche graphique (Towns OS) ;
Atari ST avec TOS ;
Amiga 1000 avec Amiga OS.
L'idée vient alors à un groupe de chercheurs du MIT de standardiser les interfaces graphiques en proposant une façon de faire que chaque constructeur pourra implémenter dans son système d'exploitation. Ce standard s'appelle X Window System et sa première version sort en 1984. Pourtant, la version la plus connue est la version 11 qui sortit en 1987, c'est pour cela qu'on appelle couramment ce standard X11. Ce système va se démocratiser notamment dans les dérivés d'Unix, mais aussi plus récemment dans les systèmes GNU/Linux, tandis que Windows continue d'utiliser une solution maison et que Mac OS X utilise Quartz.

 

Fonctionnement de X11

 

Cela peut surprendre aujourd'hui, mais X11 fonctionne sur un mode client-serveur. La communication entre les clients (les applications) et le serveur (qui gère l'affichage) se fait donc avec des sockets. Ce choix, qui peut paraître étrange au premier abord, s'explique par des raisons historiques. Dans les années 80, les ordinateurs coûtaient cher et il était courant d'avoir dans une université ou une entreprise seulement un ordinateur qui contenait les données et les programmes, tandis que tous les autres n'étaient que des terminaux graphiques. X11 pouvait donc faire la communication entre le serveur sur une machine et les terminaux graphiques.

Le fonctionnement de X11 étant assez complexe, le schéma ci-dessous le résume assez bien :

 Image utilisateur

Quelques explications s'imposent :

  • les clients X, comme expliqué ci-dessus, sont les applications de l'utilisateur telles que gEdit, Firefox, etc... ;
  • le serveur X récupère toutes les informations graphiques des différentes applications et les envoie au compositeur ;
  • le compositeur va dessiner ce qu'il y aura à l'écran en prenant en compte certaines informations comme les fenêtres en plein écran ou encore la fenêtre en premier plan qui ne doit pas être cachée par les autres ;
  • KMS et evdev sont des éléments du noyau Linux qui permettent de gérer respectivement la partie graphique pour KMS, et les périphériques (souris, clavier...) pour evdev.

 

Chaque constructeur commença à implémenter X11 dans son système d'exploitation. Le nombre de serveurs X explose jusqu'en 1991 où quatre programmeurs se rassemblent pour corriger les bugs d'une implémentation libre nommée X386. Quand X386 devint payant quelques mois plus tard, les quatre programmeurs décidèrent de créer un fork de celui-ci afin de fournir une implémentation libre de X11. Ce fork prit le nom de XFree86 et fut le premier serveur X à fonctionner sur la quasi totalité des systèmes d'exploitation de l'époque. Il équipa la plupart des distributions Linux et des systèmes d'exploitation BSD jusqu'en février 2004. À cette date, une partie de l'équipe de développement décida de créer un nouvel embranchement avant un changement de licence de XFree86. Ce fork pris le nom de X.Org et est aujourd'hui le serveur X le plus connu et le plus utilisé.

Aujourd'hui, il existe quelques autres serveurs X parmi lesquels :

  • X11.app développé par Apple permet de faire tourner les applications X11 sur Mac OS. Cette application n'est plus maintenue depuis la sortie de Mac OS Leopard ;
  • XQuartz est développé à partir du code source de X11.app qui est distribué par Apple sous licence libre. Celui-ci continue d'être mis à jour et souhaite à terme remplacer X11.app ;
  • X-Ming est un serveur X qui tourne sous Windows et permet de rediriger l'interface graphique d'un système Unix vers une machine Windows.

 

Wayland, un possible successeur

 

Pourquoi un successeur à X11 ?

 

Comme expliqué dans la première partie, X11 est vieux. La dernière version de la norme date de plus de 25 ans et l'informatique d'aujourd'hui n'a plus grand chose à voir avec celle des années 1980. X11 utilise beaucoup de fonctionnalités qui ne sont plus utilisées aujourd'hui et qui ont pour la plupart été remplacées par d'autres librairies. Par exemple, X possède un système de gestion des sous-fenêtres pour éviter d'avoir à mettre à jour toute la fenêtre à chaque modification ainsi que pour gérer les événements du curseur. Pourtant, cette partie de code n'est plus maintenue dans la majorité des implémentations, car le code qui le gère est complexe et que plus aucun programmeur n'a les connaissances pour s'en charger. Une librairie nommée XDamage permettant de gérer les événements du curseur de la souris a donc été créée pour pallier ce problème.
D'autre part, le fonctionnement des drivers sous X11 est dépassé, car le serveur X gère un pilote par périphérique alors que le seul pilote utilisé la majorité du temps est evdev, la partie du kernel qui gère les périphériques.
Enfin, le serveur X délègue énormément au compositeur qui a pour rôle de dessiner les fenêtres, et aujourd'hui le serveur X n'a plus qu'un rôle, celui de distribuer les événements. Or, ce rôle nécessite de connaître la fenêtre qui doit recevoir l'information pour être fait correctement ; malheureusement le serveur X ne peut pas faire correctement cette tâche, car seul le compositeur connaît la fenêtre active.
En résumé, le serveur X demande énormément de maintenance de la part de la communauté alors qu'il n'apporte quasi rien aujourd'hui.

 

Fonctionnement de Wayland

 

Ce sont tous ces problèmes qui ont poussé Kristian Høgsberg à lancer le projet Wayland. Il s'est rendu compte que le serveur X ne servait quasiment plus qu'à communiquer les informations au compositeur qui devait dessiner les fenêtres. Kristian Høgsberg a donc eu l'idée de fusionner le serveur X et le compositeur dans Wayland. Les clients envoient les informations de leur fenêtre via un protocole réseau directement vers le compositeur qui va fusionner les informations qu'il reçoit afin de décider ce qui doit être affiché à l'écran (d'abord la fenêtre en premier plan puis les suivantes).

On remarque sur ce schéma de Wayland que la seule différence avec celui vu dans la première partie est la disparition du serveur X.

Image utilisateur

 

Malheureusement, ce fonctionnement a quelques inconvénients :

  • par défaut, la décoration des fenêtres est à la charge du client (de l'application donc) et non du serveur. Le risque est de voir fleurir des styles de fenêtres très différents selon les applications. Cela peut être changé en utilisant un autre compositeur que celui par défaut et de le programmer pour qu'il gère le style des fenêtres.
  • Une application ne peut plus se réserver l'utilisation d'une touche. Wayland permet quand même de gérer les menus déroulants mais à la place de réserver une touche pour le fermer, l'application devra notifier le serveur qu'elle utilise un menu déroulant et celui-ci s'occupera du reste.
  • Wayland nécessite les technologies d'udev et KMS, ce qui est actuellement disponible uniquement pour les systèmes à base du noyau Linux. D'autres systèmes sont actuellement sur le point de porter ce type de fonctions dans leurs noyaux afin de pouvoir supporter Wayland (et certains pilotes pour cartes graphiques actuellement).
  • La nécessité de porter les applications vers Wayland, cependant ce dernier dispose d'un moyen d'utiliser X.org au besoin des applications ce qui permet de l'adopter malgré ce manque, le temps que le portage de la plupart des applications soit terminé.


Chaque personne peut créer son compositeur Wayland : le projet KDE a par exemple annoncé qu'il allait créer son propre compositeur Wayland afin d'adapter les fenêtres à son gestionnaire de bureau.

 

Situation de Wayland aujourd'hui

 

Aujourd'hui, Wayland commence à se populariser. L'implémentation de Wayland va pouvoir commencer dans les différentes distributions Linux, car la version 1.0 est sortie il y a quelques jours et les prochaines versions ne devraient pas casser la compatibilité ascendante (les programmes fonctionnant avec cette version fonctionneront avec les prochaines versions). Le premier système à intégrer Wayland fut le projet MeeGo développé par Intel. C'est d'ailleurs Intel qui emploie Kristian Høgsberg afin qu'il travaille à temps plein sur Wayland.

La célèbre distribution Ubuntu a informé dès la fin 2010 que celle-ci allait passer à Wayland afin de remplacer X.Org qui fait office de serveur X sur la distribution de Canonical ; Fedora et Mandriva devraient suivre. Cette migration se fera sur la longueur pour deux raisons :

  • le fonctionnement de X11 et de Wayland est totalement différent, mais le projet XWayland doit permettre d'émuler le fonctionnement d'un serveur X sur Wayland et permettra une transition en douceur ;
  • les drivers pour les systèmes Linux sont développés pour un serveur X et devront donc être modifiés pour prendre en charge Wayland. Si cela ne devait pas poser trop de problèmes pour les drivers open-source, ce sera plus compliqué pour les drivers propriétaires dont les mises à jour dépendront du bon vouloir du fabricant du matériel.

 Image utilisateur

Malgré tout, la transition vers Wayland pourrait être grandement facilitée, notamment par le fait que la plupart des programmeurs utilisent des bibliothèques comme Qt ou GTK+ pour leur interface graphique. Une fois que ces bibliothèques seront mises à jour pour Wayland, tous les programmes les utilisant devraient fonctionner sans problème avec ce nouveau serveur d'affichage. Cela aurait été beaucoup plus compliqué si les programmeurs avaient utilisé massivement la Xlib pour leurs développements. D'ailleurs la mise à jour de ces bibliothèques a déjà commencé, ainsi Qt5 devrait être compatible avec Wayland tout comme Gtk 3.4.

 

Sources