Marwan KHELIF » Tutoriel

Guide d’optimisation de vos applications Web

mkhelif — Tue, 20 Oct 2009 15:25:00 +0000

Bon ça fait un moment que je prépare cet article (j’en ai encore en préparation) mais je ne trouvai pas le temps pour finir de le rédiger. Cet article est une liste de conseils afin d’optimiser vos applications Web.

Optimisation du serveur

La première chose à faire lorsque vous êtes dans une démarche d’optimisation de vos applications Web est d’optimiser au maximum le serveur qui va héberger les applications. Car vous aurez beau passer tout votre temps à optimiser vos applications, si le serveur met du temps à servir les requêtes ça n’aura servi à rien.

Serveur privé

Si vous développez une application Web dans un but professionnel il est nécessaire d’avoir un serveur privé avec une adresse IP dédiée et un accès SSH. Cela permet d’avoir un accès complet à l’ensemble de la configuration du serveur et d’installer de nouveaux programmes : comment faites-vous si votre hébergement mutualisé ne contient pas l’extension cURL de PHP et que votre application ne peut être exécuté sans?

Si c’est une application personnelle (un blog par exemple) il est toujours bon d’avoir un accès complet à la configuration du serveur. Aujourd’hui il existe de nombreuses solutions de serveurs dédiés pour 30€ / mois ou moins.

Bénéfices : configuration, sécurité et stabilité.

Activer la compression

Le serveur Web reçoit des requêtes et envoi en réponse des contenus (HTML, CSS, images, …). Le temps de chargement complet d’une page Web représente le temps de chargements de toutes les ressources : le client demande d’abord la page HTML puis charge au fur et à mesure toutes les ressources référencées par la page.

L’objectif est donc de diminuer le temps réseau du téléchargement des ressources en compressant les données envoyées par le serveur avec gZIP. Compresser les données textuelles (HTML, JavaScript, CSS) est extrêmement efficace : environ 50% de gain (donc deux fois moins de temps de téléchargement pour le client).

Pour Apache il faut activer le module “deflate” ou “gzip” pour les anciennes versions (jusqu’à 1.3).

Bénéfices : gain important sur le temps de téléchargement du client.

Activer le cache

Lorsqu’un utilisateur se connecte à un serveur Web il télécharge toutes les ressources associées à la page Web qu’il consulte. Cependant sur la page, très peu de ressources ne sont modifiées au cours du temps : vous ne changez pas le logo de votre site tous les quatre matins. Quel est alors l’intérêt de forcer l’utilisateur à re-télécharger ces ressources?

Pour cela le protocole HTTP propose un système de cache des ressources qui permet au navigateur d’utiliser des ressources dont la version n’a pas changé. Par défaut les serveurs Web sont configurés avec le cache activé et vous n’avez donc rien à faire, mais il vaut mieux rappeler les bons conseils.

Pour Apache, il faut activer le module “expires” qui utilise l’en-tête “Expires” pour donner une date de péremption à la réponse, le client peut dont la mettre en cache et ainsi réduire considérablement le nombre de requêtes au serveur.

Pour ajouter le mode “expires” :

a2enmod expires

Ensuite vous devez modifier le fichier “expires.conf” pour référencer les fichiers pour lesquels vous souhaitez ajouter le header.

Bénéfices : réduction du nombre de requêtes au serveur Web et réduction des accès disques et de temps processeur.

Améliorer la configuration

Tous les serveurs Web ont une configuration par défaut : nombre de Threads maximum à démarrer, durée maximum de temps de traitement, mémoire allouée à chaque Thread, …

Vous devez modifier la configuration afin que le serveur Web réponde au niveau de qualité souhaité. Parmi toutes les propriétés que vous pouvez configurer, voici les plus courantes :

Désactiver le reverse DNS : lorsqu’un client se connecte à votre application Web, sa requête est enregistrée dans les logs du serveur. Le serveur va effectuer une requête DNS afin de récupérer le nom de domaine correspondant à l’adresse IP du client. En désactivant cette option vous économiserez de nombreuses requêtes inutiles.
Keep-Alive : cette option permet au serveur Web de ne pas fermer la connexion du client lorsque la requête a été servie. Cela économise de nombreuses ouvertures de connexions au client.

Au niveau de cette option il y a quelques paramètres à modifier : KeepAliveTimeout et Timeout. Le paramètre KeepAliveTimeout représente le temps maximum entre deux requêtes sur la même connexion. Le paramètre Timeout représente le temps maximum entre la connexion et la première requête. Ces deux paramètres étant à modifier en fonction de votre application.

Optimisation des ressources

Une fois que votre serveur Web est prêt avec une configuration optimale, vous pouvez optimiser les ressources que vous utilisez dans votre application : CSS, JavaScript, images.

Sprite CSS

Lors du chargement d’une page HTML, le navigateur Web va récupérer l’ensemble des ressources : CSS, JavaScript et souvent beaucoup d’images. Pour récupérer toutes les ressources, le navigateur utilise par défaut deux connexions au serveur Web et va attendre que l’une des connexions soit disponible pour récupérer la ressource suivante.

Les sprites CSS permettent de regrouper toutes ou une grande partie des images en une seule image. Il y a deux intérêts à cette technique : beaucoup moins de requêtes faîtes au serveur Web et l’image sera moins volumineuse (les informations de format et de compression ne sont stoquées qu’une seule fois).

Au niveau des feuilles de style CSS, il faut mettre la grande image en arrière-plan du composant et positionner le sprite (la parcelle de l’image) souhaité grâce à l’instruction background-position.

Au niveau du gain de volume de l’image voilà des statistiques :

Format	Taille six images	Taille image sprite	Différence
GIF	6046 b	1894 b	-69%
JPEG	5916 b	2187 b	-63%
PNG	4479 b	3844 b	-14%

Réduction des CSS

Les feuilles de styles sont les éléments principaux du design d’une application Web et peuvent rapidement devenir des ressources volumineuses. Le principal problème des feuilles de styles est quelles contiennent énormément de caractères inutiles : espaces, sauts de lignes, commentaires. Le navigateur Web quand il reçoit une feuille de style ignore c’est caractère, ils ne sont utilisés que par le designer afin de facilement comprendre les instructions.

Afin d’économiser de la bande passante et du temps de téléchargement d’une page Web il est possible de réduire considérablement la taille des feuilles de styles grâce à des services Web comme : CSS Optimizer, Icey’s CSS Compressor, Flumpcake CSS Optimizer, Clean CSS.

Si on regarde la différence sur certains sites avec un certain nombre de visiteurs :

Site Web	Feuille de styles	Feuille de styles optimisée	Différence
Free.fr	35.19 Kb	19.09 Kb	-46%
PC Inpact	37.14 Kb	27.31 Kb	-26%
Microsoft.com	30.7 Kb	22.41 Kb	-27%

Oui Twitter n’est pas présent, leur feuille de styles est déjà optimisée .

Afin d’économiser en nombre de requêtes, vous pouvez regrouper tous vos styles dans un seul fichier CSS.

Réduction des JavaScripts

De la même façon que pour les feuilles de styles, les fichiers JavaScript peuvent être optimisés afin de diminuer le temps de téléchargements de ces fichiers. Voici les services Web qui proposent de réduire vos JavaScripts : Dojo Shrinksafe, JavaScript Compressor. Il existe de très nombreuses applications qui font le même travaille.

Stockage des ressources

Lorsqu’un utilisateur arrive sur une page Web, il télécharge le HTML puis il récupère les ressources référencées par la page. Les ressources sont téléchargées en utilisant par défaut deux connexions par serveur. L’idée est donc de séparée le stockage des ressources statiques des données dynamiques : le HTML généré sur un serveur, les CSS et JavaScripts sur un autre serveur.

Bénéfices : le client va utiliser deux connexions pour récupérer uniquement des ressources statiques et ne va pas surcharger le serveur de traitement avec des requêtes “statiques”.

Optimisation de l’application

Voilà à partir d’ici vous devez avoir bien amélioré le temps de chargement de votre application. Les conseils suivants sont plus des conseils

Landing page

Une “landing page” est une page sur laquelle vous souhaitez que vos visiteurs arrivent depuis les moteurs de recherches et autres. L’objectif de cette page est que l’utilisateur n’arrive pas sur une page d’accueil mais directement sur l’information qu’il cherche. Il faut donc que cette page soit rapide et présente l’information de façon simple et concise.

Pour cela évitez au maximum d’effectuer de long traitement ou d’effectuer des appels à une base de données si ce n’est pas nécessaire. Préférez une version statique d’une landing page qui sera servie très rapidement.

Éviter les redirections

Évitez au maximum le nombre de redirections, à chaque fois que le serveur renvoie une redirection (301, 302, …), le client effectue une nouvelle requête. Si en plus vous n’avez pas activé le Keep-Alive, il va faire une nouvelle connexion.

Ne garder les redirections que pour du SEO afin de ne pas perdre le référencement d’une page dont vous changez l’URL.

Plugin Wordpress

Si vous utilisez Wordpress il existe de nombreux plugins qui permettent d’améliorer la vitesse de chargement de votre blog.

WP Super Cache

WP Super Cache est un plugin qui va générer une version statique de vos pages (billets, pages, …). Ainsi votre blog servira la version statique au lieu de re-générer la page HTML pour chaque visiteur. La version statique est re-générée à chaque nouveaux commentaires, billets ou pages.

Réduire son nombre de plugins

À chaque fois qu’un utilisateur effectue une action sur un blog wordpress, le serveur appelle les plugins nécessaires pour servir la page. Si vous avez beaucoup de plugins, cela peut ralentir radicalement votre blog.

Faîtes le ménage dans vos plugins et ne garder que les essentiels.

Outils d’analyse

Afin de voir les différences de temps de chargement d’une page il faut avoir de bons outils d’analyse. Que ce soit un outils spécialisé ou un module du navigateur Web, il est nécessaire de mesurer les différences entre deux configurations.

Firebug

Pour les développeurs Web qui ont l’habitude de tester leurs applications avec Firefox, la plupart utilisent le plugin Firebug qui permet entre autres d’analyser en détail (et de modifier en direct) le contenu HTML, le CSS, le JavaScript et de visualiser les requêtes/réponses avec l’application Web.

De nombreux plugins ont été développés sur Firebug pour fournir des informations sur le chargement de la page.

Page Speed

Page Speed est une extension pour Firebug, réalisée par Google, qui analyse la page Web qui vient d’être chargée et vous informe des améliorations que vous pouvez apporter à votre serveur / configuration / application pour diminuer le temps de chargement de votre page.

YSlow

YSlow a été développé par Yahoo est analyse aussi les points à améliorer.

Tests de charge

Enfin une fois que vous avez optimisé votre application Web il est bon de savoir si elle va tenir la charge face au nombre d’utilisateurs prévus. Pour cela il existe de nombreux outils de test en charge d’application Web, mais je n’en conseillerai qu’un : NeoLoad, par la société ~~où je bosse~~ Neotys.

L’objectif est de faire simuler par le logiciel un nombre d’utilisateurs virtuels qui vont exécuter un scénario sur l’application et d’analyser les résultats (temps de réponses, erreurs, …) afin de corriger ou d’optimiser l’application.

Conclusion

Le secret pour avoir une application Web rapide et efficace est de tester votre configuration, d’analyser les points à améliorer et de les optimiser puis de re-tester, … et ainsi de suite jusqu’à ce que vous atteignez la qualité de service souhaitée.

Et vous comment faîtes vous pour optimiser vos applications Web? Quels outils utilisez-vous?

Pour suivre votre lecture

Ruby on Rails : déployer une application sur Tomcat avec JRuby

mkhelif — Mon, 07 Sep 2009 15:46:18 +0000

Ruby on Rails est un framework qui permet de développer très rapidement des applications Web en suivant le modèle MVC.

Le problème de ce framework est qu’il se base sur le langage Ruby et qu’il embarque un serveur Web. Les applications ainsi créées ne peuvent pas être déployées comme des applications Web dans Tomcat ou autres serveurs d’applications.

Le but de ce tutoriel est de vous permettre de déployer les applications Ruby on Rails (RoR) sur un serveur Tomcat en utilisant la librairie JRuby.

Installation Tomcat

On commence par télécharger la dernière version de Tomcat (en ce moment c’est la version 6.0.20) :

1 2	wget http://mirror.mkhelif.fr/apache/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.tar.gz tar –xzf apache-tomcat-6.0.20.tar.gz

Voilà Tomcat est installé, je passerai ici la configuration du serveur. Si vous souhaitez, suivez mon tutoriel pour connecter Apache avec Tomcat.

Installation JRuby

Télécharger JRuby et placez le là où vous souhaitez :

1
2
3

wget http://dist.codehaus.org/jruby/1.3.1/jruby-bin-1.3.1.tar.gz
tar –xzf jruby-bin-1.3.1.tar.gz
mv jruby-1.3.1 /usr/local/jruby

Ajouter ensuite le chemin vers JRuby dans votre environnement en éditant votre fichier ~/.profile :

1	export PATH=$PATH:/usr/local/jruby/bin

Vous pouvez vérifier l’installation de JRuby en exécutant la commande suivante :

1 2	$ jruby -v jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM) Client VM 1.5.0_16) [i386-java]

Installation de Ruby on Rails

À partir de là nous allons installer les gems pour : rails (le coeur de ROR), mysql et surtout warbler (qui crée un WAR à partir de l’application rails).

1
2
3

$ jruby -S gem install rails
$ jruby -S gem install activerecord-jdbcmysql-adapter
$ jruby -S gem install warbler

Déploiement de votre application

Pour déployer votre application dans Tomcat, il faut commencer par la convertir en WAR. Placez vous dans le dossier de votre application et lancez la commande suivante :

1	$ warble config

Cela va créer un fichier /config/warble.rb pour configurer votre application pour la convertir en fichier WAR, ouvrez le fichier et dé-commentez la ligne :

1	config.gems += ["activerecord-jdbcmysql-adapter"]

Cela pour inclure dans votre fichiers WAR la gem MySQL (ajoutez les gems que votre application utilise ici).

Maintenant nous allons créer le fichier WAR de votre application, lancez simplement la commande :

$ warble

Et voilà votre fichier WAR est créé, vous pouvez alors le déployer sur Tomcat (je passerai sur cette étape).

Pour suivre votre lecture

Première utilisation du plugin Eclipse GWT

mkhelif — Fri, 10 Apr 2009 15:30:35 +0000

Suite à mon premier billet qui présentait Google Web Toolkit, je vais maintenant vous présenter la nouvelle version de GWT et comment créer un premier projet en utilisant le plugin Eclipse.

Mise en place de l’environnement de développement

Pour commencer à développer une application GWT et/ou GAE (Google App Engine), il faut télécharger la dernière version de Eclipse.

Une fois Eclipse installé et démarré, il faut installer le plugin GWT/GAE de Google. Pour cela allez dans le menu « Help / Software updates…« . Allez dans l’onglet « Available Software » et ajouter un nouveau site ( »Add site… ») et entrez l’URL : http://dl.google.com/eclipse/plugin/3.4.

Sélectionnez alors les éléments Plugin et SDKs, puis cliquez sur « Install« . Une fois l’installation terminée, vous devez redémarrer Eclipse. Là une nouvelle barre d’outils est apparue :

Le premier bouton sert à créer une nouvelle application Web GWT/GAE, le second à compiler une projet GWT et le troisième à déployer une application GAE dans le cloud Google.

Voilà votre environnement de développement est prêt à être utiliser.

Création de mon premier projet

Pour créer un nouveau projet cliquez sur le bouton . Cela va démarrer l’assistant de création de projet :

Les principaux champs à renseigner sont le nom du projet : GWTDemo, et le package racine de l’application : fr.mkhelif.gwt.demo. Pour l’exemple je n’ai sélectionné que GWT, je ferais un autre billet sur GAE.

Structure du projet

Une fois le projet créé, voilà la structure que l’on obtient :

On voit donc un nouveau dossier war, c’est celui-ci qui représente l’archive WAR qui sera exportée/déployée. Lors de la compilation du projet, les fichiers seront créés dans un sous-dossier de celui-là. Le répertoire lib du WEB-INF contient la librairie nécessaire au fonctionnement des service GWT-RPC sur le serveur.

On peut voir que le dossier public du package par défaut à disparu. Maintenant, toutes les ressources (images, css, …) doivent être placées dans le répertoire war à l’instar d’une application Web classique.

Notre nouveau projet contient par défaut deux fichiers : GWTDemo.html et GWTDemo.css. Le fichier HTML sert à charger l’application GWT et le fichier css représente le style de l’application.

Au niveau du répertoire de sources src, on retrouve les packages client et server, et le fichier GWTDemo.gwt.xml. Au niveau de ce fichier, il n’y a pas de changements notables.

Le nouveau projet contient un exemple de service RPC : GreetingService. Voilà le code de l’interface du service :

package fr.mkhelif.gwt.demo.client;
 
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
 
/**
 * The client side stub for the RPC service.
 */
@RemoteServiceRelativePath("greet")
public interface GreetingService extends RemoteService {
    String greetServer(String name);
}

On remarque que l’interface étend toujours RemoteService, par contre une nouvelle annotation est présente : @RemoveServiceRelativePath( »greet »). Cette annotation permet de s’affranchir au niveau du code client d’enregistrer l’URL de la servlet du service :

1	((ServiceDefTarget) service).setServiceEntryPoint (GWT.getModuleBaseURL () + "greet");

Par contre il n’y a aucune différence au niveau de son implémentation et de son clone asynchrone.

Compilation du projet

Voilà le projet est créé, il faut maintenant le compiler en cliquant sur le bouton . Le wizard suivant apparait :

Il suffit de sélectionner le projet GWT, le niveau de log du compilateur et le style de sortie du JavaScript compilé. Sélectionnez ensuite les points d’entrées de votre application GWT, dans notre exemple il n’y en a qu’un.

On peut remarquer que grâce au plugin on peut spécifier des arguments de compilation. Le paramètre localWorkers permet de définir le nombre de workers utilisés pour compiler les permutations JavaScript. D’autres options sont disponibles mais ne concerne que les dossiers de compilation : workDir, war et extra.

Ayant un dual-core, je demande au compilateur d’utiliser 2 workers pour compiler. Le gain de temps est d’environ 30% : 28 secondes sans l’option et 19 secondes avec.

Utilisation de l’application

Une fois l’application GWT compilée, il faut la tester grâce au hosted mode. Il n’y a pas de grande différence au niveau du hosted mode, sauf que maintenant il est possible de modifier le serveur utilisé par GWT pour démarrer l’application.

On remarque un nouveau bouton Restart Server dans la fenêtre du hosted mode. Ce bouton permet de redémarrer le serveur, et donc de redéployer le WAR, sans avoir à relancer le hosted mode.

Conclusion

C’est un très beau coup de pub qu’à fait Google en nous servant en même temps le support de Java par Google App Engine, la version 1.6 de GWT et un plugin Eclipse pour gérer très facilement le tout. Cela va donner un coup de boost aux développeurs qui étaient encore hésitant sur la fiabilité de GWT.

Pour suivre votre lecture

Chrome : comment créer une extension ?

mkhelif — Tue, 24 Mar 2009 09:18:04 +0000

La version 2.0 beta du navigateur Google Chrome est disponible en téléchargement. Une des évolutions majeures de cette version est la possibilité de rajouter des extensions (attention, ne vous attendez pas à la puissance de XUL des produits Mozilla).

Développement

Pour développer une extension pour Chrome, il faut tout d’abord télécharger la dernière version 2.0 beta. Ensuite créer un répertoire qui va contenir l’arborescence de l’extension : C:\MyChromeExtension\. Dans ce répertoire on va créer deux fichiers : manifest.json et MyExtension.js.

Le fichier manifest.json qui décrit l’extension :

{
  "format_version": 1,
  "id": "00123456789ABCDEF0123456789ABCDEF0123456",
  "version": "1.0",
  "name": "My First Extension",
  "description": "The first extension that I made.",
  "content_scripts": [
    {
      "matches": ["http://www.google.fr/"],
      "js": ["MyExtension.js"]
    }
  ]
}

Voilà les différents champs :

format_version : permet de définir quelle version du format du manifest est utilisée. Pour l’instant il n’y a que la version 1 de disponible.
id : à l’instar des extensions Mozilla, c’est un identifiant qui doit être unique pour chaque extension. C’est une chaîne de 40 caractères.
version : version de l’extension. N’importe quel numéro de version peut être utilisé à condition que ce soit des nombres séparés par un point : 1.0.0.0.
name : le nom de l’extension.
description (optionnel) : une description optionnelle de l’extension.
content_scripts : les scripts à exécuter lorsque l’URL de la page valide le modèle.
- matches : modèle d’URL qui permet d’appliquer le script.
- js : fichier JavaScript qui sera exécuté si l’URL courante valide le modèle.

Ensuite il faut créer le fichier JavaScript qui va être exécuté au chargement de la page de Google. Modifier le fichier MyExtension.js :

1	alert ('Hello World!');

Utilisation de l’extension

Pour utiliser l’extension que l’on vient de développer, il faut démarrer Chrome dans un mode permettant de charger les extensions : chrome.exe –enable-extensions –load-extension= »C:\MyChromeExtension ».

Et naviguer sur votre moteur de recherche favoris pour voir que votre extension fonctionne bien.

Distribution de l’extension

Pour distribuer l’extension il faut la packager au format CRX. Pour cela il faut que Python 2.6 soit installé sur votre machine et télécharger ce script. Ensuite lancer la commande suivante :

1	chromium_extension.py --indir="C:\MyChromeExtension" --outfile="MyExtension.crx"

Pour voir les extensions qui sont installées dans Chrome, il suffit d’aller à l’URL suivante : chrome-ui://extensions/. Cette page liste les extensions chargées et les erreurs qui on été rencontrées dans l’exécution des extensions.

Conclusion

Même si ce n’est pas du tout du même niveau que celui des produits Mozilla cela permet de mettre en place un système d’extensions qui, je l’espère, sera amélioré dans les futures versions.

Sources : Chrome Extension HOWTO ‎(Chromium Developer Documentation).

Pour suivre votre lecture

Authentification SSH par clé privée/clé publique

mkhelif — Mon, 24 Nov 2008 14:36:44 +0000

En voyant l’intérêt que les visiteurs de mon blog porte à l’installation d’un serveur de mail multi-domaines, j’ai décidé d’écrire un autre tutoriel sur la configuration d’un serveur SSH pour utiliser une connexion par clé publique/clé privée.

Fonctionnement

L’objectif d’une authentification par clés est de supprimer l’envoi de mots de passe par le réseau. Pour cela il faut deux clés : une clé privée (seul l’utilisateur doit pouvoir y avoir accès) et une clé publique (doit être déployée sur toutes les machines où l’on souhaite se connecter).

La clé publique peut crypter les données et seule la clé privée peut les décrypter. Dans l’autre sens la clé privée signe les messages, la clé publique permet alors de s’assurer que le message vient bien du bon utilisateur. C’est le cryptage asymétrique.

Pour SSH, c’est exactement la même chose. Le serveur envoi un challenge au client : message crypté à partir de la clé publique. La connexion ne sera acceptée uniquement si le client répond correctement à ce message (c’est à dire qu’il a réussi à décrypter le message).

Configuration du serveur SSH

Par défaut le serveur SSH n’accepte pas les connections par clés mais uniquement par mot de passe. On va donc activer cette méthode d’authentification :

Dans le fichier : /etc/ssh/sshd_config

RSAAuthentication    yes
PubkeyAuthentication yes
AuthorizedKeysFile   %h/.ssh/authorized_keys

Pour des questions de sécurité vous pouvez désactiver la connexion avec le login root :

PermitRootLogin no

Il suffit de redémarrer le serveur SSH : /etc/init.d/ssh restart

Si vous souhaitez refuser l’authentification par mot de passe (pour éviter les attaques bruteforce et ainsi que les logs se remplissent pour rien) il faut positionner l’option suivante :

PasswordAuthentication no

Création des clés

Il y a deux manières pour créer les clés :

Sur un poste Linux :
1. Lancer la commande suivante : ssh-keygen -t rsa
2. Laisser les noms par défaut et entrer le mot de passe pour la clé privée.
Sur un poste Windows :
1. Utiliser PuttyGen pour générer les clés.

Ensuite il faut copier la clé publique id_rsa.pub sur le serveur auquel on souhaite se connecter et conserver la clé privée sur le poste client.

Dans le répertoire de l’utilisateur on crée un répertoire .ssh (répertoire par défaut où le serveur SSH va chercher les clés publiques) et on renomme le fichier en authorized_keys.

Ensuite il faut absolument que ce fichier ai les droits suivants : chmod 600 authorized_keys.

À partir de ce moment toutes les personnes ayant la clé privée et le mot de passe ayant servi à la générer peuvent se connecter au serveur.

Première connexion

Afin de se connecter avec Putty vous devez spécifier la clé privée : Connection / SSH / Auth.

Si vous avez créé votre paire de clés grâce à ssh-keygen, vous devez convertir votre clé privée au format Putty. Pour cela vous devez utiliser PuttyGen : menu Conversions / Import key, entrer alors le mot de passe de la clé, puis Save private key.

Lors de chaque connexion Putty vous demande le mot de passe de la clé, quel intérêt alors de se connecter en utilisant une paire de clé si on doit rentrer à chaque fois le mot de passe de la clé privée. C’est là qu’intervient Pageant, c’est un outils de la suite Putty qui permet de stocker pour une clé privée son mot de passe. L’utilisation de ce programme est extrêmement simple, je n’en parlerai donc pas ici. Pour Linux il suffit d’installer ssh-agent qui joue exactement le même rôle.

Pour suivre votre lecture

GWT : « The Great GWT roundup »

mkhelif — Thu, 02 Oct 2008 12:32:57 +0000

Il y à quelques jours a été publié un tutoriel pour les débutants sur Google Web Toolkit.

Celui ci présente, en anglais, les grandes fonctionnalités de ce framework et surtout comment les utiliser en tant que développeur.

Voilà le lien : http://css.dzone.com/news/the-great-gwt-roundup

Pour suivre votre lecture

GWT : Créer un service RPC

mkhelif — Mon, 07 Jul 2008 16:05:59 +0000

Le framework GWT permet depuis le client JavaScript de faire des appels RPC (Remote Procedure Call ou appels de procédures distantes) au serveur GWT.

L’objectif est de permettre au JavaScript client d’exécuter des méthodes sur le serveur et d’en récupérer le résultat. Tout cela de façon totalement asynchrone (Ajax). Les échanges entre le client et le serveur sont faites de façon asynchrone car la plupart des navigateurs n’accordent qu’un seul Thread pour exécuter le JavaScript.

Infrastructure RPC

Pour permettre à JavaScript de faire des appels RPC il faut écrire le service côté serveur et la vue qu’en a le client. Le code d’un service RPC est séparé en deux packages : fr.mkhelif.gwt.client et fr.mkhelif.gwt.server.

Dans ce tutoriel nous allons créer un service Hello qui va tout simplement dire bonjour.

Package client

Le package client doit contenir les interfaces décrivant les méthodes du service.

/**
 * @author Marwan KHELIF
 */
public interface HelloService extends RemoteService {
	public String sayHello (String name);
} // HelloService

Voilà le code du service côté client qui sera utilisé pour effectuer des appels RPC en JavaScript.

On crée alors une interface qui sera utilisé par GWT pour effectuer les appels asynchrone. Cette interface est identique à celle que l’on vient d’écrire sauf que toutes les méthodes doivent retourner void et posséder un dernier argument en plus.

/**
 * @author Marwan KHELIF
 */
public interface HelloServiceAsync {
	public void sayHello (String name, AsyncCallback callback);
} // HelloServiceAsync

La classe AsyncCallBack contient deux méthodes qui permettent de gérer le résultat de l’appel :

public void onSuccess (Object result)
public void onFailure (Throwable ex)

Package server

Le package server (peut être nommé différemment) contient le code des services définis dans le package client.

Voilà donc notre implémentation du service Hello :

/**
 * @author Marwan KHELIF
 */
public class HelloServiceImpl extends RemoteServiceServlet implements HelloService {
	public String sayHello (String name) {
		return "Hello " + name + "!";
	} // sayHello ()
} // HelloService

Voilà notre service est prêt à fonctionner, il faut maintenant le rendre disponible aux clients. Pour cela il faut modifier le fichier de l’application GWT : MyApplication.gwt.xml

>
	
	 name="com.google.gwt.user.User" />
 
	
	 path="/hello" class="fr.mkhelif.gwt.server.HelloServiceImpl" />
>

Voilà notre service RPC est prêt à l’emploi.

Échange de données

Afin d’échanger des données entre le client (JavaScript) et le serveur (Java) il faut sérialiser les données pour qu’elles puissent transiter par le protocole HTTP. La sérialisation fournie avec GWT est différente de celle de Java.

Un type d’objet peut être utilisé en paramètre ou en retour d’une méthode de Service si c’est :

un type primitif : int, char, byte, double, boolean…
un objet de type : String, Date ou un wrapper de type primitif (Double, Long, Integer, Float, Boolean, …).
un tableau d’objets sérialisables.
une classe utilisateur qui implémente com.google.gwt.user.client.rpc.IsSerialisable ou java.io.Serialisable.

Dans notre exemple nous n’utilisons que le type String, il n’y a donc aucun problème de sérialisation.

Appel d’un service GWT

Une fois notre service crée, il faut effectuer des appels a sa méthode sayHello. Pour cela il faut demander à GWT de nous donner une référence vers ce service puis on appelle la méthode.

Instanciation du service

Pour instancier le service il suffit d’appeler :

1	HelloServiceAsync service = (HelloServiceAsync) GWT.create (HelloService.class);

Le cast de HelloService vers HelloServiceAsync est toujours sûr car l’objet Proxy créé implémente l’interface asynchrone.

Association du service à l’URL

Une fois notre service instancié il faut le lier avec le point d’entrée du service sur le serveur : /hello. Pour cela on effectue l’appel suivant :

((ServiceDefTarget) service).setServiceEntryPoint (GWT.getModuleBaseURL () + "/hello");

Voilà le service est mappé avec le serveur, on peut effectuer l’appel à la méthode.

Appel d’une méthode de service

Pour appeler la méthode du service :

service.sayHello ("Marwan KHELIF", new AsyncCallBack () {
	public void onFailure (Throwable caught) {
		// Traitement en cas d'erreur
	} // onFailure ()
 
	public void onSuccess (Object result) {
		// Traitement en cas de succès
		Window.alert ((String) result);
	} // onFailure ()
});

Voilà la méthode a été appelée sur le service RPC.

Conclusion

Les services RPC est l’un des points les plus importants du framework GWT. Ils permettent d’effectuer très simplement des appels au serveur en JavaScript et ainsi mettre à jour l’interface graphique grâce aux données.

Pour suivre votre lecture

GWT : Introduction au framework

mkhelif — Thu, 03 Jul 2008 14:48:03 +0000

Je travaille actuellement sur un plugin pour le logiciel NeoLoad permettant d’enregistrer des requêtes RPC effectuer par le framework GWT (Google Web Toolkit). Je vais donc en profiter pour présenter ce framework.

Qu’est ce que GWT?

Google Web Toolkit est un framework qui permet de créer un RIA (Rich Internet Application) sans avoir à écrire des centaines de lignes de JavaScript. GWT est un compilateur qui génére à partir de code source Java des fichiers JavaScript, XML et HTML.

Pour rendre dynamique le site vous pouvez ajouter une couche client-serveur RPC (Remote Protocol Call) entre le JavaScript côté client et le Java côté serveur. Cela permet de faire transiter par HTTP des objets Java entre le client et le serveur et des objets JSON entre le serveur et le client.

Afin de simplifier les étapes de tests et de débug, GWT fourni une JRE permettant d’exécuter l’application en local : Hosted Mode. Ceci évite la compilation de l’application et le déploiement sur le serveur.

GWT a donc pour but principal de simplifier et d’unifier le développement d’application Web : le développeur crée les classes Java nécessaire à l’application et GWT s’occupe du reste.

Le compilateur GWT

Dans cet objectif le compilateur GWT génère du code Javascript compatible pour la plupart des navigateurs : Firefox (version 1 à 3), IE (version 6 et 7), Safari (version 2) et Opéra (version 9).

Le code Java écrit par le développeur doit être compatible Java 1.4 minimum. GWT simule le comportement d’une JRE pour générer le Javascript, mais seulement certaines classes de l’API sont supportées : classes supportées par GWT.

Démarrage de l’application GWT

Chargement des paramètres du navigateur

Afin d’avoir une application qui fonctionne peu importe les paramètres de l’utilisateur (langue, version du navigateur, …) GWT va générer à la compilation un fichier JavaScript par type de navigateur supporté et par langue de l’application.

Lorsqu’un utilisateur accède à la page d’acceuil de l’application GWT va charger le fichier JavaScript correspondant à la configuration de l’utilisateur.

Page HTML

La page HTML d’entrée dans l’application ne contient qu’une frame vide qui va charger le JavaScript adéquat selon la configuration de l’utilisateur.

L’application démarre en plusieurs étapes :

Chargement de la page HTML par le navigateur.
Chargement et exécution du JavaScript .nocache.js.
Le code JavaScript récupère la configuration du navigateur et récupère à partir d’une table (générée par GWT) le nom du fichier HTML à utiliser.
Le JavaScript crée alors une frame cachée qui est insérée à la fin du body de la page.
Lorsque le fichier HTML est chargée l’application est démarée.

Fichiers générés par le compilateur

Fichier JavaScript .nocache.js

Ce fichier permet de chargée une version de l’application compatible avec le navigateur du client.

Ce fichier contient une table avec en clé la configuration du client et en valeur l’URL du fichier HTML à charger. Par exemple ce fichier contiendra une entrée avec ‘Firefox en français’, ‘IE en anglais’, ‘Opera en allemand’, …

Chaque navigateur ayant une interprétation du JavaScript différent, cela permet de tirer parti de toutes les spécificités du navigateur.

Ce fichier nocache doit être re-téléchargé par le navigateur à chaque chargement de la page car il est recréé lorsque l’on recompile l’application. Cependant le nom ne change pas.

Fichier HTML .cache.html

Ces fichiers HTML (il y en à un par navigateur et par langue) contient uniquement le JavaScript compressé de l’application. Le fichier JavaScript n’est pas envoyé directement car certains navigateur ne supporte pas le JavaScript compressé. Il est donc inclus dans du HTML afin d’éviter les problèmes de compatibilité.

Chaque fichier HTML a pour nom la signature MD5 de son contenu afin d’éviter que plusieurs fichiers HTML aient le même nom. Ainsi si vous modifiez le code de votre application, les fichiers n’auront pas le même nom.

Ces fichiers étant différents à chaque compilation, ils peuvent être mis en cache par le navigateur. D’où leurs noms cache.html.

Fichier .gwt.rpc

Si votre application utilise des appels RPC vers le serveur et que les requêtes utilisent les objets Java que vous avez créé, ces objets doivent être sérialisés pour pouvoir transiter par le protocole HTTP.

Ces fichiers définissent quels objets doivent être sérialisés et leur politique de sérialisation.

Conclusion

Voilà une première introduction au framework GWT. Ce framework est très prometteur car il permet de s’abstraire de tous les problèmes que l’on rencontre pendant le développement d’une application AJAX.

Pour suivre votre lecture

Apache2 : système de blacklist

mkhelif — Mon, 23 Jun 2008 14:43:06 +0000

Après avoir installé mon serveur web (Apache) et un serveur d’applications J2EE (GlassFish) je me suis vite rendu compte, après une semaine d’exécution, que les logs du serveur prennaient de plus en plus de place.

En regardant rapidement les fichiers de logs on se rend très vite compte que le serveur se fait « spammer » des URL du type : phpmyadmin, admin, mysql, …

J’ai décidé de mettre en place un système de blacklistage instégré à Apache.

Configuration de Apache

Pour cela il faut installer le module mod_rewrite (inclus par défaut avec Apache2).

On ajoute donc les règles dans le fichier de configuration d’apache (/etc/apache2/sites-avaible/)

RewriteEngine On

RewriteMap hosts-deny txt:/etc/apache2/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F]

Ainsi les adresses IP ou nom de domaine listés dans le fichier /etc/apache2/hosts.deny recevront le code réponse : 403 Forbidden.

On crée le fichier /etc/apache2/hosts.deny :

adresse_ip -
nom_de_domaine -

Penser à ajouter le tiret « - » à la fin de chaque entrée dans ce fichier.

Page d’erreur personnalisée

Si vous voulez rediriger les adresses blacklilstées vers une page personnalisée il faut modifier les règles dans le fichier de configuration de Apache :

Remplacez :
RewriteRule ^/.* - [F]

Par :
RewriteRule ^/.* /blacklisted.html [L]

Créez alors le fichier blacklisted.html.

Source : http://httpd.apache.org/docs/2.0/misc/rewriteguide.html

Pour suivre votre lecture

Passerelle entre Apache et Tomcat

mkhelif — Wed, 18 Jun 2008 09:53:04 +0000

Dans le but de déployer mes applications J2ee j’ai installé GlassFish (avec Tomcat). Je souhaitais pouvoir utiliser ce serveur sur le port 80 tout en ayant Apache qui écoute sur ce port.

Apache et Tomcat étant des produits développés par la même équipe il existe une solution très simple pour faire interagir les deux serveurs.

Configuration de Apache

Il faut installer le module Jk de Apache :

apt-get install libapache2-mod-jk
a2enmod mod_jk

On va ensuite créer un VirtualHost dans la configuration de Apache /etc/apache2/sites-available/default :


    ServerName demo.mkhelif.fr
    ServerAdmin webmaster@mkhelif.fr
    JkMount / worker1
    JkMount /* worker1

On configure le module Jk /etc/apache2/mods-available/jk.load :

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so

JkWorkersFile /etc/apache2/workers.conf
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

On crée alors le fichier /etc/apache2/workers.conf :

workers.java_home=/path/to/jre/
ps=/
worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactory=1

Apache est désormais configuré pour rediriger toutes les requêtes du domaine demo.mkhelif.fr vers Tomcat par AJP. Il faut configurer Tomcat pour écouter sur ce port.

Tomcat en standalone

Pour configurer Tomcat en version standalone (sans serveur d’applications), il suffit de modifier le fichier server.xml pour ajouter le connecteur AJP :

Il suffit alors de redémarrer Tomcat et Apache. Lorsque vous accédez à la page : http://demo.mkhelif.fr/ vous arrivez sur la page d’accueil de Tomcat.

Tomcat inclus dans GlassFish

Lorsque Tomcat est inclus dans un serveur d’applications (comme GlassFish) il faut ajouter certaines librairies au serveur :

commons-logging.jar
commons-modeler.jar
commons-digester.jar

Ces librairies peuvent être téléchargées sur le site de Jakarta.

Il faut ensuite copier la librairie permettant d’activer le connecteur AJP pour Tomcat. Cette librairie est fournie avec Tomcat… il faut donc télécharger Tomcat… la version inclue avec GlassFish ne contient pas cette librairie.

Tomcat 5.x et antérieur :
/server/lib/tomcat-ajp.jar

Tomcat 6.x :
/lib/tomcat-ajp.jar

Copier toutes ces librairies dans le répertoire : /lib/

Il faut redémarrer GlassFish et la passerelle entre Apache et GlassFish est activée.