alaux.net

Jail Skype!

2011-08-22T15:09:00+01:00

Skype is the most used voip software used accross the world. Unfortunately when you dig a bit about it you may find yourself surprised with its developers' way of understanding the word "privacy". Reports have been made about Skype binaries reading sensitive Linux password files and user personal data. As Skype is the perfect example of closed source application one cannot even know if these statements are true. Moreover, it seems Skype makes heavy use of obfuscation methods. It just so happens an Archer explained this simple way of jailing Skype into a reserved Linux account.

The idea is very simple: create a skype group and a skype user with its own home directory. Then just setup your regular user to launch the skype binary as this user using sudo. If you grant this skype user restricted rw rights, this will elegantly jail this impolite Skype software.

Tunnel vinagre-vino (VNC) through SSH

2011-08-22T14:39:00+01:00

Remote desktop connections with VNC is very useful when you need to help regular users stuck on their desktop environment. Gnome provides vino-server and its client side vinagre as VNC implementations. But vino is not fully secured. The password check between client and server looks OK but once the connection is made, the stream between the two is not encrypted. Using it through internet may be risky so why not tunnel it all through SSH?

Pros and cons

Pros:

Harden vino authentication
Encrypt stream between client and server

Cons:

A little bit geeky I agree but hey you are still reading!

How to procede

First of all we need to install vino an openssh on the server and vinagre and openssh on the client (Debian/Ubuntu users must be careful there: we need OpenSSH server part on the server and on the client side we need both the client and the server part). Archers can run:

On the server side:

$ pacman -Sy vino openssh

On the client side:

$ pacman -Sy vinagre openssh

We are then going to setup the server side: vino. This can be done with vino-preferences: allow connections, and specify a password (this is optional as we will tunnel everything).

On the 'client' side, we need to forward some SSH to our host (here specified as the variable ${REMOTE_HOST}):

$ ssh -C -NL 9999:localhost:5900 ${REMOTE_HOST} &

-L: paramater for port forwarding from on port 9999 on localhost and forward it to port 5900 to REMOTE_HOST. Port 5900 is the vino default port. Port 9999 can be changed to any port you are allowed to use
-N do not execute a remote command (ie "you do not get a prompt on the remote machine")
-C: compress data (optional)

On the client side we can now launch any VNC client and connect to localhost:9999. With vinagre this would be:

$ vinagre ::9999

You now should be prompted for your password if you set one up on the previous step. The client side may also be prompted for a connection authorization depending on what you configured. Click OK and you should see your remote desktop on a window.

Last but not least, let's prevent connections to vino-server on the remote side from other places than localhost. It seems this option used to be available in vino-preferences but it disappeared in the latest versions. We are thus goinf to use dconf-editor to setup this:

$ dconf-editor

Navigate the tree to the leaf desktop/gnome/remote-access and set value network-interface to lo. This network interface is of course the localhost you can see when issuing ifconfig lo.

There. You might need to re-login or at least restart /usr/lib/vino/vino-server for these last options to take effects. Once done you should get your fully secured VNC connection tunneled to SSH.

Note: Do not forget to kill the port forwarding after you are done using vinagre.

For automation, here is a script summarizing the client side:

#!/bin/bash
LOCAL_PORT=9999
REMOTE_HOST=192.168.1.21
REMOTE_PORT=5900

echo "Opening SSH tunnel"
# Do not use '-f' because '&' already forces background
# '-f' disables PID retrieval
ssh -C -NL ${LOCAL_PORT}:localhost:${REMOTE_PORT} ${REMOTE_HOST} &
SSH_PID=$!
echo "Connecting to ${REMOTE_HOST}"
vinagre ::${LOCAL_PORT}
kill ${SSH_PID}

Transparent encrypted partition unlocking/locking at login/unlogin in Arch Linux

2011-07-27T12:34:00+01:00

General overview for the impatients

In this article I first use cryptsetup to create a regular crypted partition. It needs to have the Linux users password as key to (un)lock the partition. I then use a pretty neat tool called pam_mount. This PAM module enables volume mounting and decrypting at login.

Pros

Quite simple to set up and pretty KISS
Usefulness of encrypted partitions but without the hassle of typing multiple passwords
Completely transparent for user

Cons

Using Linux users passwords as uncrypting passphrase may be seen as a flaw in the security of your box because your session password (thus your uncrypting passphrase) is stored in /etc/shadow. This file resides in your root partition which, in this method, must not be crypted. See the ending comment for a "solution".
Any user password change will need to be "applied" to this setup. ie removing the password from the luks keyring and adding the new one.
Will only work for 8 different users as all users passwords must be able to unlock the crypted parition and luks only allows 8 different passwords on its keyring.

With these pros and cons, I must say this solution suits me well: a single user on a laptop (with no real sensitive data) who knows how to modify a key on the unlocking keyring when changing the session password. So let's get started.

Warning

This howto is made for GDM but with few adaptations it should work for any kind of login manager.
I use pam_mount which is provided in Arch Linux in AUR aka "Not officially supported". Paranoid users should check the PKGBUILD (and the sources ;)).
For this to work you will have to use the same locking passphrase for your partition as the one used when login to your Linux account.
In this howto I encrypt my home partition (/dev/sda4) but of course one could unlock/lock any other EXCEPT ROOT.

How to procede

The first step when crypting a partition is to backup your data as this will erase it all on the target partition. The second step beeing to properly erase all data on the parition (why and how to do so).
To create a crypted partition, let's be sure that we have all the tools in that intention:

    % pacman -Qs
    local/cryptsetup 1.3.1-2 [0.50 MB] (base)
        Userspace setup tool for transparent encryption
        of block devices using the Linux 2.6 cryptoapi

Cryptsetup belongs to the "base" group in Arch Linux so you should be fine but otherwise just "pacman -Sy cryptsetup". Now let's load the kernel modules depending on your architecture:

    modprobe dm-crypt aes-i586

    modprobe dm-crypt aes-x86_64

We are then going to create a regular crypted partition. I usually use the following command for that purpose but any other cypher, keysize etc would work. This will ask you for the passphrase you want to use in order to crypt/decrypt your partition. As already said, you NEED to specify here the same password as the one for your Linux account. Change /dev/sda4 with your partition:

    cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4

Also remember that in order for other accounts to still be able to unlock this partition, you need to add all Linux account passwords as keys to unlock the partition. This is made possible through the following command. To be done for all Linux account passwords. Beware that the fist password asked here is the master password you supplied in the previous step:

    cryptsetup luksAddKey /dev/sda4

Let's open the newly created partition:

    cryptsetup luksOpen /dev/sda4 home

You should be able to see the mapped device:

    ls /dev/mapper/home

Create a filesystem on it (such as ReiserFS in this example or any other):

    mkfs.reiserfs /dev/mapper/home

There! We have an encrypted partition. Now let's get it opened/closed and mounted/unmounted at login time.

For that matter we will need pam_mount from AUR that enables volume mounting at login:

    yaourt pam_mount

Add the following line to /etc/fstab (notice the "noauto". We just declare it but ask it not to be mounted. Also be sure to specify the filesystem you used instead of 'reiserfs' if required):

    /dev/mapper/home  /home  reiserfs  defaults,noauto  0  0

Add the following line to /etc/security/pam_mount.conf.xml with the corresponding path:
<pam_mount> ... <volume fstype="crypt" path="/dev/sda4" mountpoint="/home" /> ... </pam_mount>
Add the following lines to /etc/pam.d/gdm (and/or /etc/pam.d/login to perform encryption when on console):

    ...
    auth    optional    pam_mount.so
    ...
    session optional    pam_mount.so
    ...

There! Just reboot and enjoy your fully automated encrypted home opening when you log in. If that fails well... then you can't login so there should not be any complaint ;)

Explanation

At login time, gdm uses pam to authenticate the user. PAM will check all modules we asked it to "activate" when GDM asks for login (/etc/pam.d/gdm). PAM will thus launch pam_mount which opens and then mounts our encrypted partition.

As said in the introduction, using Linux users passwords as uncrypting passphrase may be seen as a security hole because your these passwords are stored in /etc/shadow. This file resides in your root partition which in this method must not be crypted. A possible hardening of this is just to use SHA passwords in /etc/shadows.

HTMLUnit et JSFUnit : tester la couche de présentation

2010-09-14T18:01:00+01:00

HTMLUnit est une extension de JUnit qui propose de tester une application live, c'est à dire en permettant au développeur d'exécuter des tests d'application de bout en bout. Ce framework se décrit comme un navigateur web sans interface puisqu'il offre la possibilité d'appeler les éléments HTML de pages et ainsi de simuler une navigation. Le développeur peut donc remplir des formulaires, cocher des checkbox, renseigner des champs et ensuite simuler un clic sur un bouton, un lien ou valider un formulaire.

HTMLUnit peut être directement utilisé comme une extension de JUnit. Pour ce faire, il suffit d'inclure les JARs nécessaires dans le CLASSPATH pour avoir accès aux fonctionnalités de test web. Ci-après un exemple dans lequel on retrouve l'annotation @Test qui témoigne de l'utilisation de JUnit. Celui-ci invoque une page via la classe WebClient et en vérifie le nom ainsi que certains éléments constitutifs.

@Test
public void homePage() throws Exception {
  final WebClient webClient = new WebClient();
  final HtmlPage page =
    webClient.getPage("http://htmlunit.sourceforge.net");
  assertEquals("Welcome", page.getTitleText());

  final String pageAsXml = page.asXml();
  assertTrue(pageAsXml.contains(""));

  final String pageAsText = page.asText();
  assertTrue(pageAsText.contains("Support for HTTP(S)"));
}

À la vue de cet exemple, on comprend les possibilités d'un tel outil : test de disponibilité, test de présence de certains éléments (techniques ou fonctionnels) mais aussi vérification du caractère bien formé d'une page HTML/XML. HTMLUnit pousse la technique jusqu'à simuler un navigateur spécifique. Cette possibilité n'est pas superflue quand on connait le respect très variable de la norme HTML des différents navigateurs du marché.

Le parti pris de HTMLUnit de traiter avec la partie présentation est intéressant car il teste la pile complète de l'application et cela au plus près du résultat visible par l'utilisateur. Cela implique cependant que l'application complète soit démarrée et disponible pour être testée, ce qui peut s'avérer lourd à prendre en charge.
Le framework offre beaucoup de possibilités de tests mais attention à ne pas se perdre à tester trop d'éléments HTML inutiles. Écrire les tests de pages HTML avec ce type d'outil reste fastidieux. Pour y pallier, il existe des outils de plus haut niveau comme JWebUnit, WebDriver ou JSFUnit (voir la suite) qui s'appuient justement sur HTMLUnit.

JSFUnit quant à lui est le concept de test de la partie présentation telle que vue par HTMLUnit (vu au paragraphe précédent) appliqué à JSF.
Les tests JSFUnit sont - comme tous les tests JUnits – des méthodes d'une classe Java. Dans le cas particulier de JSFUnit, il est nécessaire que cette classe hérite de ServletTestCase afin de lui faire prendre en compte la spécificité Servlet de JSF. Une fois les JARs de JSFUnit intégrés au CLASSPATH, il est possible d'utiliser les classes du framework et ainsi de tester les Managed Beans, la navigation de page en page, les composants visuels, les résultats de sortie ainsi que la configuration de l'application. L'exemple suivant du site officiel montre le test de la page de présentation d'une application :

public class JSFUnitTest extends ServletTestCase
{
  public static Test suite()
  {
    return new TestSuite(JSFUnitTest.class);
  }

  public void testInitialPage() throws IOException
  {
    // Send an HTTP request for the initial page
    JSFSession jsfSession = new JSFSession("/index.faces");

    // A JSFClientSession emulates the browser
    // and lets you test HTML
    JSFClientSession client = jsfSession.getJSFClientSession();

    // A JSFServerSession gives you access to JSF
    JSFServerSession server = jsfSession.getJSFServerSession();

    // Test navigation to initial viewID
    assertEquals("/index.jsp", server.getCurrentViewID());

    // Assert that the prompt component
    // is in the component tree and rendered
    UIComponent prompt = server.findComponent("greeting");
    assertTrue(prompt.isRendered());

    // Test a managed bean
    assertEquals("Stan",
                 server.getManagedBeanValue("#{foo.text}")
                 );
  }
}

Afin de pouvoir lancer ces tests, il est nécessaire d'inclure dans le fichier web.xml les lignes suivantes :

<filter>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <filter-class>
    org.jboss.jsfunit.framework.JSFUnitFilter
  </filter-class>
</filter>

<filter-mapping>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
</filter-mapping>

<filter-mapping>
  <filter-name>
    JSFUnitFilter
  </filter-name>
  <servlet-name>
    ServletRedirector
  </servlet-name>
</filter-mapping>

<servlet>
  <servlet-name>
    ServletRedirector
  </servlet-name>
  <servlet-class>
    org.jboss.jsfunit.framework.JSFUnitServletRedirector
  </servlet-class>
</servlet>

<servlet>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
  <servlet-class>
    org.apache.cactus.server.runner.ServletTestRunner
  </servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>
    ServletRedirector
  </servlet-name>
  <url-pattern>
    ServletRedirector
  </url-pattern>
</servlet-mapping>

<servlet-mapping>
  <servlet-name>
    ServletTestRunner
  </servlet-name>
  <url-pattern>
    ServletTestRunner
  </url-pattern>
</servlet-mapping>

Une fois l'application déployée, il est possible de lancer les test via une page de celle-ci. Le site officiel donne un exemple en utilisant un rapport Cactus :

De même que HTMLUnit, l'avantage de ce genre de framework est de tester et d'utiliser l'application de bout en bout. On ne teste plus de petites parties mais bien l'application dans sa totalité. Cette aspect a les défauts de ses qualités : il est nécessaire de conserver une application complète démarrée pour pouvoir effectuer les tests.

Les possibilités de tests sont de plus nombreuses. Ce qui peut paraître ici comme un avantage peut aussi constituer un inconvénient au développeur : il peut se retrouver perdu au milieu de pages Jsp qu'il serait tenté de tester dans leur intégralité. En cas d'adoption d'un tel outil, il est donc nécessaire de borner les tests à certains éléments précis, au risque de voir les développeurs se perdre dans des lignes de code de tests inutiles.

JSFUnit étant une extension de HTMLUnit pour JSF, il sera plus adapté pour tester les applications JSF.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.

Tests unitaires avec DBUnit et Jailer

2010-07-02T19:01:00+01:00

Dans le domaine du développement, et particulièrement le développement Java, les outils Open Source sont très largement utilisés en entreprise. Quand il s'agit de mettre en place des tests unitaires en Java, le nom de JUnit revient souvent. Même si quelques alternatives ont vu le jour (en particulier TestNG), ce framework reste le leader dans son domaine.

Pour ceux qui utilisent déjà JUnit, voici deux outils complémentaires qui en facilitent l'emploi : DBUnit et Jailer.

DBUnit
DBUnit est une extension de JUnit dont la tâche principale est de gérer des jeux de données qui seront retournés comme s'ils étaient le résultat d'une requête sur la base de données. Le premier avantage est de maintenir l'indépendance du code des tests vis-à-vis de la base de données réelle. Ensuite, DBUnit garantit que tous les tests unitaires retrouveront la base de données dans le même état et non dans l'état dans lequel le test précédent a pu la laisser.

Les jeux de données de DBUnit sont conservés sous forme XML. La première étape à son utilisation est donc de constituer les fichiers XML qui contienent les données (On pourra se référer au paragraphe suivant qui traite d'une méthode d'automatisation de cette étape). Voir ci-après un exemple de fichier XML de données :

<!DOCTYPE dataset SYSTEM "dataset.dtd">
<dataset>
    <table name="TEST_TABLE">
        <column>COL0</column>
        <column>COL1</column>
        <column>COL2</column>
        <row>
            <value>row 0 col 0</value>
            <value>row 0 col 1</value>
            <value>row 0 col 2</value>
        </row>
        <row>
            <null/>
            <value>row 1 col 1</value>
            <null/>
        </row>
    </table>
    <table name="SECOND_TABLE">
        <column>COLUMN0</column>
        <column>COLUMN1</column>
        <row>
            <value>row 0 col 0</value>
            <value>row 0 col 1</value>
        </row>
    </table>
    <table name='EMPTY_TABLE'>
        <column>COLUMN0</column>
        <column>COLUMN1</column>
    </table>
</dataset>

Comme les autres frameworks de test, DBUnit nécessite d'inclure ses JARs dans le CLASSPATH pour accéder aux classes natives. Le codage même d'un test passe ensuite par l'habituel héritage de la classe mère (ici DBTestCase). La première action à entreprendre est d'initialiser les propriétés de la base de données que DBUnit simulera puis d'y attacher le fichier XML de données précédemment créé comme dans l'exemple suivant :

public class SampleTest extends DBTestCase
{
    public SampleTest(String name)
    {
        super( name );
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_DRIVER_CLASS,
            "org.hsqldb.jdbcDriver");
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_CONNECTION_URL,
            "jdbc:hsqldb:sample");
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_USERNAME,
            "sa" );
        System.setProperty(
            PropertiesBasedJdbcDatabaseTester
                .DBUNIT_PASSWORD,
            "");
    }

    protected IDataSet getDataSet() throws Exception
    {
        return new FlatXmlDataSetBuilder().build(
            new FileInputStream("dataset.xml")
        );
    }
}

Outil puissant et offrant une réelle valeur ajoutée, DBUnit devrait avoir sa place dans tous les environnements de tests. L'indépendance et la stabilité qu'il induit par rapport à la couche de persistance est un réel confort et un garant d'exécution correcte des tests. La mise en place est de plus simple. La constitution des fichiers XML peut cependant être fastidieuse et il est conseillé d'utiliser des outils automatiques de génération tels que Jailer.

Jailer
Comme on l'a vu précédemment, il est utile de s'affranchir de la partie persistance quand on teste une application afin de s'assurer du déterminisme des réponses de requêtes (et aussi pour rendre les tests moins consommateurs en ressources). De ce point de vue, des outils comme DBUnit sont des mocks de base de données. Mais écrire les jeux de données de DBUnit peut être fastidieux et il vaut mieux souvent automatiser cette tâche. Dans ce sens, Jailer permet d'extraire des jeux de tests DBUnit cohérents d'une base de données. La cohérence est assurée sur le plan des relations fonctionnelles des données tout en respectant les relations d'intégrité. Les sous-ensembles extraits présentent donc une « vue » pleinement utilisables par les tests et nettoyée des données superflues.

Jailer est une application lourde qu'un développeur lance et connecte à la base de données : Après quelques paramétrages optionnels de plus, Jailer permet la sélection de données choisies comme le montre la capture suivante d'une base exemple d'employés :

Dans la capture précédente issue du site officiel, on a demandé un export SQL mais on peut voir que l'outil permet de créer un fichier XML (au format DBUnit).

Jailer est simple d'emploi et il permet de créer voir d'enrichir des jeux de données au fil des développements très rapidement. Le gain de temps qu'il assure au développeur est conséquent et il lui évite une tâche laborieuse et rébarbative. Allié à DBUnit, Jailer est l'outil parfait pour envisager des tests unitaires de façon sereine. Pas de problème de cohérence ou de déterminisme des données.

Le binôme DBUnit-Jailer apporte la flexibilité et la rapidité de mise en place aux tests unitaires. Pas d'hésitation donc sur ces deux outils : les tests, même s'ils devraient toujours être un passage obligatoire dans un projet informatique ne sont pas une finalité. Tout processus visant à les accélérer ou les faciliter est donc bon à prendre.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.

Neo4j, un SGBD en graphe pour Java

2010-07-01T18:55:00+01:00

Le NoSQL, ce mouvement qui plaide pour un relâchement de certaines règles sur le stockage des données, a le vent en poupe. Son nom évocateur se veut en opposition avec les principes de stockage en base de données SQL, très répandu et régis par des règles de stockage très strictes. Il est le sujet de beaucoup d'articles sur internet et on le retrouve dans les projets de géants du web comme Facebook et Twitter. Dans la lignée du NoSQL, Neo4j propose l'idée originale de stocker des données sous la forme d'un graphe.

Fini donc les tables et les colonnes des bases de données relationnelles: Neo4j est une SGBD embarqué pour Java qui se repose sur des graphes. Comprendre par là des graphes mathématiques faits de noeuds, de relations nommées entre ces nœuds, à l'exception que les nœuds deviennent des objets de la vie réelle avec leurs propriétés. Les relations entre ces objets sont conservées et peuvent de fait porter un nom. Dans l'exemple suivant, les développeurs de Neo4j recrééent le réseau des personnages du film Matrix :

NeoService neo = ... // Utilisation d'une factory
// Création de Thomas Anderson
Node mrAnderson = neo.createNode();
mrAnderson.setProperty( "name", "Thomas Anderson" );
mrAnderson.setProperty( "age", 29 );

// Création de Morpheus
Node morpheus = neo.createNode();
morpheus.setProperty( "name", "Morpheus" );
morpheus.setProperty( "rank", "Captain" );
morpheus.setProperty( "occupation", "Total bad ass" );

// Création de la relation
// afin de représenter le lien entre ces personnages
mrAnderson.createRelationshipTo( morpheus, RelTypes.KNOWS );
// Traduction : "mrAnderson KNOWS morpheus"

On retrouve cette relation, ainsi que d'autres, dans le graphe suivant :

L'utilisation des données que le code précédent a créé est assez triviale ; par exemple pour retrouver les amis de "Mr Anderson" :

// Instantiation d'un mécanisme de parcours (traverser)
// qui retourne les amis de mrAnderson
Traverser friendsTraverser = mrAnderson.traverse(
   // recherche en largeur d'abord
   Traverser.Order.BREADTH_FIRST,
   StopEvaluator.END_OF_NETWORK,
   // ne pas retrourner mrAnderson
   ReturnableEvaluator.ALL_BUT_START_NODE,
   RelTypes.KNOWS,
   Direction.OUTGOING );

// Utilisation de ce mécanisme de parcours
// pour afficher le résultat
System.out.println( "Mr Anderson's friends:" );
for ( Node friend : friendsTraverser )
{
   System.out.printf( "At depth %d => %s%n",
       friendsTraverser.currentPosition().getDepth(),
       friend.getProperty( "name" ) );
}

L'originalité de cette conception en graphe est de stocker les objets et leurs relations tels qu'ils existent dans les cas réels.

Le projet Neo4j n'est pas nouveau : depuis 10 ans déjà, cette implémentation de la base de données en graphes propose ses services et s'enorgueillit d'être utilisé en environnements de production depuis 7 ans. Les capacités annoncées n'ont pas à pâlir devant un SGBD relationnel : ses développeurs annoncent de bonnes qualités de scalabilité et de performances ainsi que la capacité à stocker jusqu'à plusieurs milliards de noeuds!

C'est un point de vue original sur le stockage de données que proposent les SGBD objets comme Neo4j. À l'heure où les SGBD leaders du marché se basent tous sur le modèle relationnel, voilà une solution qui prend le contrepied de la tendance. Un grand bravo donc à ces projet originaux comme db4o, Zope Object Database et Neo4J qui semble bien détenir une réponse efficace au problème du stockage de données objets.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.

OSGi pour l'architecture Java EE

2010-05-26T18:53:00+01:00

Bien qu'ayant de nombreux avantages, Java EE génère souvent des applications ou frameworks monolithiques, aux tailles conséquentes et donc peu flexibles. Plusieurs sociétés très impliquées dans le développement logiciel se sont donc posé la question de classifier, trier, organiser et homogénéiser les tâches que l'on retrouve régulièrement dans les WARs et EARs. C'est le but du standard Open Services Gateway initiative (OSGi), qui définit un modèle de gestion de cycle de vie d’une application, un répertoire (registry) de services, un environnement d'exécution et des modules.

Pour combattre la horde insoumise de fonctionnalités récurrentes des applications Java EE, il fallait bien une Alliance : l'OSGI Alliance ! Celle-ci a été créée en 1999 par des entreprises conscientes dès lors de ce besoin d'harmonisation. On y retrouve les grands noms habituels de l'industrie informatique mondiale tels qu'Oracle, IBM, Red Hat, feu SUN, etc. Le résultat de leurs travaux est la spécification du standard ouvert OSGi aujourd'hui dans sa version 4.

Un des premiers chantier de l'OSGi a été d'identifier les services habituels des applications et frameworks Java EE :

Journalisation
Configuration, administration
Accès aux périphériques
Authentification
Connections d'entrée/sortie
Préférences
...

Voir la liste exhaustive sur Wikipedia ainsi que le graphique suivant qui décrit l'architecture.

Le standard OSGi préconise ainsi à tout projet Java souhaitant implémenter la norme de découper son code selon ces catégories et d'utiliser un sous-format de bundle, un JAR contenant les informations de nom, versions et autres dans un fichier MANIFEST spécifique. Cette proposition d'agencement apporte une grande modularité entre les différents services qui pourront s'appeler entre eux ou proposer leurs services. La norme OSGi spécifie aussi tout un cycle de vie des bundles qui doivent pouvoir être installés, démarrés, utilisés, arrêtés, redémarrés et désinstallés automatiquement et à chaud comme le schématise le diagramme ci-contre. Ceci implique la possibilité de mettre à jour et de redémarrer une partie de l'architecture sans impact lourd pour la plate-forme ; une fonctionnalité assez rare en Java.

Les projets qui tombent dans le giron de cette norme sont très divers : on y retrouve pêle-mêle les serveurs d'applications GlassFish, JBoss, JOnAS et Weblogic, des frameworks comme EasyBeans ainsi que les IDE libres leaders du marché NetBeans et Eclipse. Ce dernier est d'ailleurs un très bon exemple OSGi puisque depuis sa version 3, son coeur (Equinox) est une pure implémentation de la norme OSGi dans sa dernière version.

La concertation des acteurs de l'industrie Java sur des normes telle que l'OSGi ainsi que l'adoption de celle-ci par de grand projets est le garant d'une interopérabilité aujourd'hui indispensable dans le puzzle des frameworks Java. On ne peut donc que saluer et encourager ce genre de travaux qui permettent de clarifier la conception d'applications.

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.

L'administration Tomcat facile avec PSI-probe

2010-04-26T21:07:00+01:00

Tomcat, le serveur web (conteneur de servlets) bien connu de la fondation Apache séduit par sa robustesse et sa simplicité. Robuste, simple, fiable, clusterisable, tout ça est très bien mais qu'en est il de la supervision ? Il est essentiel pour des équipes d'exploitation de garder une vue des métriques vitales des serveurs qu'elles administrent surtout en ces temps de clustering, qui rajoute une couche de complexité. Petit retour sur un projet qui renait de ses centres, pour garder la main sur Tomcat donc, rien de tel que PSI-probe.

L'historique de l'outil est tumultueux : initié sous le nom de "Tomcat-Probe", le projet a été renomé en Lambda-probe avant de rentrer dans une phase d'inactivité encore effective aujourd'hui. Alors Lambda-probe, projet mort? C'était sans compter sur la force des communautés Open Source. Sans nouvelles du développeur et confortés par la licence GPL, des utilisateurs du forum ont repris le développement de l'outil d'administration de serveur Tomcat en le forkant : PSI-probe.

Les mesures proposées par PSI-probe dans sa version 2.0.2 sont très diverses :

gestion des applications déployées (affichage des sessions et de leurs détails, désactivation de celles-ci), de leurs composantes (connexions JDBC)
gestion des datasources, visualisation de leurs taux d'engorgement
déploiement d'applications
affichage des logs Tomcat et des logs applicatifs
informations sur les processus en cours
gestion en clusters
informations système de l'hôte
état du serveur

La liste impressionantes de ses possibilités par rôle est à consulter sur le site.

PSI-probe gère en effet les utilisateurs en plusieurs rôles ce qui devrait intéresser les environnements fortement industrialisés dans lesquels plusieurs utilisateurs d'équipes différentes doivent accéder à certaines statistiques ou actions selon leurs fonctions. Les développeurs ont mis l'accent sur la gestion des instances de serveurs en cluster qui est implémentée nativement.

Le logiciel est proposé sous forme d'application web qui se déploie naturellement sous Tomcat mais aussi sous JBoss de façon triviale. L'ancien site de LambdaProbe propose des captures d'écran et une démonstration en ligne (d'une ancienne version 1.7) qui donnent une bonne idée des mesures déjà disponibles à l'époque ainsi que de l'interface utilisateur ergonomique, claire et complète que l'on peut retrouver en français. Pour info, PSI-probe nécessite une exécution en environnement privilégié afin de pouvoir administrer les WARs de son serveur ainsi que de l'activation de la console JMX dans la machine virtuelle Java.

Comme on a pu le voir au moment de l'inactivité du projet, le forum, véritable ligne de vie d'un logiciel Open Source, est actif et les demandes d'informations ne restent pas lettre morte. Les idées de développement futurs ne manquent pas comme par exemple le support de Tomcat 6 ou les avertissements par email. PSI-probe est le parfait exemple de projet Open Source : basé sur une communauté active et qualifiée, à même de reprendre le projet de bout en bout, et de proposer une réponse pertinente à un besoin souvent exprimé.

PSI-probe? Un incontournable!

Article publié sur LinuxFr dans le cadre de mon activité professionnelle à Linagora.