Une distribution libre et humanitaire: Emmabuntüs

Dans ma quête de la distribution libre et peu gourmande en ressource, je suis arrivé à la conclusion que Debian/LXDE est pour moi le couple idéal pour faire fonctionner mes machines sans avoir à me soucier de changer de processeur tous les 2 ans ni d’augmenter la quantité de mémoire vive tous les 4 ans. Je trouve en effet que c’est une bêtise de consommer 800Mo de RAM juste pour afficher le bureau… Cette solution est tellement économique en ressource que je peux faire fonctionner un portable de 2008 acheté en occasion et sur lequel j’ai dû malheureusement supprimer le système privateur installé par le reconditonneur.

Le bureau LXDE encore moins gourmand que XFCE s’avère être un choix de premier plan pour toutes les machines d’occassion. L’utilisation de matériel reconditionné n’est pas seulement une contrainte économique mais également un acte écologique et politique. Il ne manquait plus qu’une distribution dans ce sens à l’opposé de la surenchère de puissance que l’on constate dans les magasins en cette période de débauches festives où l’Hommo-economicus perd la raison. Cette distribution s’appelle Emmabuntüs disponible sur sourceforge

Ubuntu a-t-il mal vieilli ?

Je conseillais jusque là Ubuntu comme distribution linux pour débutant à cause de sa simplicité d’utilisation mais j’avais arrêté de mettre à jour mon système restant sur une LTS il y a 2 ou 3 ans. En effet l’interface Unity, de plus en plus gourmande ne m’intéressait plus. Finalement j’ai migré vers Debian il y a quelque mois. A vrai dire le couple Debian/LXDE me donne entièrement satisfaction !

On m’a demandé récemment quelle distribution pour un windosien ? J’ai répondu Ubuntu car c’est celle qui m’avait permis d’introduire Linux à la maison en 2006. Mais Ubuntu a mal vieilli. Le windosien est revenu vers moi, complètement perdu pas l’interface Unity, dérouté pas les explications et conseil du magazine Ubuntu dans lequel il avait eu des CD d’installation de la toute derniére version 14.10.

Si certains défauts sont classiques, comme celui de la dalle LCD de résolution non standard que l’installeur ne pourra configurer tout seul, d’autres posent problême lors du passage de windows à ubuntu. Celui qui est habitué à de vieux windows (Menu démarrer, Mes Programmes etc) risque d’être perdu par Unity. La présence d’une icône Amazon chantre du commerce electronique et producteur de la liseuse qui efface vos livres peut dérouter celui à qui on vanté les vertues du libre et de sa gratuité de fait. Le gestionnaire d’application d’ubuntu sélectionne également certaines applications pour effectuer des tâches données: quid de la liberté de l’utilisateur ?

Est-ce pour autant des défauts ? Ubuntu permet de choisir un bureau différent tel que LXDE pour celui qui comme moi préfère une interface vieillote. Le choix de Canonical de mettre en avant certains logiciels peut être mis sur le compte de la cohérence d’ensemble. Cela est le rôle du fournisseur de la distribution. Pour autant le gestionnaire de paquet synaptic permettra d’installer tous les paquets issus de Debian.

Heureusement dans le monde du libre, le choix n’est pas un vain mot. On pourra se retourner vers une distribution plus soucieuse de l’éthique telle que Debian ou pour les puristes gNewSense ou Trisquel adoubées par la FSF.

Du bonne usage de la commande LS

Sous Linux, le ls est sans doute une des commandes les plus utilisées. En effet une fois arrivé dans un répertoire, qui ne lance pas un ls pour visualiser son contenu ? Cette commande est un peu le coup d’oeil qu’on lance autour pour juger son environnement.

Usage du ls

La pluspart du temps l’utilisateur fait

ls

ou alors pour avoir plus d’information sur les fichiers

ls -l

Cela correspond à un usage normal de la commande ls qui est d’obtenir la liste du contenu d’un répertoire.

Détournement du ls

Malheureusement cela se gâte quand on est dans un répertoire avec de très nombreux fichiers et que l’on veut juste des information sur certains d’entre eux. On utilise alors un motif de complétion en * pour effectuer ce genre de commande:

ls -l toto*

On obtient ainsi la liste des fichiers (i.e.les informations sur) commençant par toto. L’utilisateur a alors l’impression que ls fait une recherche des fichiers commençant par toto. C’est faux. Pour s’en convaincre il suffit d’activer le débug du shell par

set -x

Cela permet de voir ce que le shell exécute, puis lancez la commande:

ls *

On constate que l’expansion de shell remplace l’étoile par tous les fichiers présents dans le répertoire avant d’evaluer la commande ls suivie des paramètres ainsi constitués. Donc a en fait lancé la commande :

ls fichier1 fichier2 fichier3

C’est l’expansion de shell qui fait la soit disant recherche et ls ne fait que donner des informations sur les fichiers trouvés. Comme on ne passe pas de commutateur tel que -l, on n’obtient ni plus ni mpoins confirmation que les fichiers existent bien (travail effectué par l’expansion de shell).

Mauvais usage du ls

De la se servir de ls pour tester l’existense de fichier, il n’y a qu’un pas qu’il ne faut pas franchir. En effet on vu que c’est l’expansion de shell qui fait le boulot. Cela conduit à un effet désagréable quand l’expansion de shell ramène beaucoup trop de fichiers si bien que le shell ne peut exécuter la commande ls avec tant d’argument. Sur un linux récent faire n ls * dans un répertoire avec 100000 fichiers dont le nom fait 20 caractères chacun, conduit à:

ls *
bash: /bin/ls: Liste d'arguments trop longue

Laissons à ls ce qui appartient à ls: donner des informations sur des fichiers (taille, droits etc.). Pour la recherche de fichier il y a find

find -name "toto*"

En mettant entre guillemet le motif du nom de fichier, on empêche l’expansion de shell. On garde une ligne de commande courte. find interprête le meta-caractère étoile pour faire la recherche.

Existence de fichier selon un motif

Si on veut juste vérifier l’existence de fichier ayant un certain motif, on peut faire sur un Linux récent:

find -name "toto*" -print -quit | wc -l

Cela permet de chercher en s’arrêtant sur le premier trouvé puis de compter le nombre de fichier trouvé: soit 0 soit 1.

Si findutils n’est pas au moins en version 4.2.3 sur votre système alors l’option -quit n’est pas disponible. Son absence aura pour effet de vous priver d’un arrêt de la commande au premier fichier trouvé…. et donc obligera de faire une recherche complète.

Si l’on veut récupérer l’information d’existence où non de fichier via un code retour, on pourra avantageusement utiliser grep combiné à un ls comme ceci

if (ls | grep "2014*" 1>/dev/null 2>&1) then echo "trouve"; else echo "pas trouvé"; fi

Compression de log Tomcat 6 avec log4j 1.2

Le sujet est largement débattu mais il n’est pas trivial de trouver la solution de bout en bout. Diversité des cas, obsolescence de Tomcat 6 ou de log4j 1.2 ? En tout cas voici comment on peut mettre en place la compression de log de Tomcat 6 à l’aide de log4j 1.2.15 !

D’abord pourquoi mettre en place de la compression de log ? La log de Tomcat (ex catalina.out) ne devrait contenir que peu de messages et seulement de rare erreurs, non ? La diversité des programmeurs peut amener ces log à grossir et les framework qui génèrent des URL mal formées existent (caractère illégal). La rotation des fichiers de log si elle limite la taille ne permet pas de garder un historique c’est pourquoi je lui préfère la compression.

La documentation de Tomcat 6 permet de mettre en place rapidement log4j 1.2.17 et de disposer de la log de  Tomcat configurée par un fichier log4j.properties. L’activation de la compression des log se fait par l’utilisation de l’appender RollingFileAppender mais il ne s’agit pas de celui du paquet log4j mais plutôt du sous-paquet rolling (en gras dans l’exemple suivant). Ensuite il faut choisir la politique de rotation basée sur le temp TimeBasedRollingPolicy et enfin en spécifiant un motif de nom de fichier avec extension gz ou zip, le fichier sera compressé. Pour tester immédiatement la compression des log catalina.out, vous pouvez utiliser le fichier de configuration suivant où le niveau de log est passé à DEBUG et génère un fichier compressé par seconde.

log4j.rootLogger=DEBUG, CATALINA

# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.CATALINA.File=${catalina.base}/logs/catalina.
log4j.appender.CATALINA.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.CATALINA.RollingPolicy.ActiveFileName =${catalina.base}/logs/catalina.log
log4j.appender.CATALINA.RollingPolicy.FileNamePattern=${catalina.base}/logs/catalina.%d{yyyyMMdd.HHmmss}.gz
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.LOCALHOST=org.apache.log4j.DailyRollingFileAppender
log4j.appender.LOCALHOST.File=${catalina.base}/logs/localhost.
log4j.appender.LOCALHOST.Append=true
log4j.appender.LOCALHOST.Encoding=UTF-8
log4j.appender.LOCALHOST.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout
log4j.appender.LOCALHOST.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MANAGER.File=${catalina.base}/logs/manager.
log4j.appender.MANAGER.Append=true
log4j.appender.MANAGER.Encoding=UTF-8
log4j.appender.MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.HOST-MANAGER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.HOST-MANAGER.File=${catalina.base}/logs/host-manager.
log4j.appender.HOST-MANAGER.Append=true
log4j.appender.HOST-MANAGER.Encoding=UTF-8
log4j.appender.HOST-MANAGER.DatePattern='.'yyyy-MM-dd'.log'
log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout
log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Encoding=UTF-8
log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern = %d [%t] %-5p %c- %m%n

# Configure which loggers log to which appenders
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=INFO, LOCALHOST
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=\
  INFO, MANAGER
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=\
  INFO, HOST-MANAGER

Cette configuration fonctionne avec log4j 1.2.17 mais pas seulement. En remplaçant le jar log4j.jar par celui de la version 1.2.16, cela fonctionne aussi. En rétrogradant en version 1.2.15 il faudra utiliser un fichier de configuration au format XML (car le support du fichier dde conf en propriété a été introduit dans la version suivante 1.2.16). Voici un exemple de fifichier de configuration au format XML:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="//jakarta.apache.org/log4j/">
  <appender name="console"> 
      <param name="file" value="${catalina.base}/logs/catalina."/>        
       <rollingPolicy>
      <param name="FileNamePattern" value="${catalina.base}/logs/catalina.%d{yyyyMMdd.HHmmss}.gz"/>
      <param name="ActiveFileName" value="${catalina.base}/logs/catalina.log" />
    </rollingPolicy>
    <layout> 
      <param name="ConversionPattern" value="%-5p %c{1} - %m%n"/> 
    </layout> 
  </appender> 

  <root> 
    <priority value ="debug" /> 
    <appender-ref ref="console" /> 
  </root>
  
</log4j:configuration>

Cinelerra et shmmax

Cinelerra est un logiciel de montage vidéo un peu austère mais très puissant. Il permet de faire travailler sans destruction des média originaux, de faire de rendu en tâche de fond afin d’avoir un aperçu en cours d’édition plus fluide et surtout il permet de faire du rendu distribué. Tout cela à un coût processeur et mémoire. Pour la mémoire il faudra non seulement des Go mais aussi paramétrer la mémoire partagée interprocessus. C’est rassurant car ça montre que Cinelerra fait grand usage du parallélisme.

Ce paramétrage étant global au système il faudra veiller à le définir en fonction des différentes applications selon le principe du qui peut le plus peut le moins. Sous débian 7 il faut jouter dans le fichier /etc/sysctld.d/local.conf

#cinelerra
kernel.shmmax=2147483647

Puis de faire un

sysctl -f

Statistique Dollar Universe ou Baby Perl

Je n’apprends de nouveau langage que si nécessaire…. ainsi il y a 4 ans j’ai appris le python qui fut un véritable plaisir ou bien le WLangage (avec moins de plaisir….). Hier je devais produire des statistiques d’exécution de batch lancés par l’ordonnanceur Dollar Universe (connu aussi sous le nom $U), un outil obsolète, propriétaire dont la fonction statistique est vraiment minimaliste.

En effet la commande obscure livrée avec $U permet d’avoir sous forme textuelle, l’état de chaque batch avec la date d’exécution, l’heure de début et l’heure de fin. Quid des traitements qui démarrent avant minuit et finissent après… on aurait aimé avoir la date de fin également, mais bon $U est un outils basique et payant, n’en demandons pas trop.

Afin d’agréger le résultats par batch et faire quelques statistiques (max, min, moyenne dans un premier temps), un petit programme Perl semblait tout indiqué. Voilà ce que cela donne après avoir lu 2 livres: Modern Perl et Impatient Perl , du baby perl tout craché! Le couteaux suisse de l’administrateur Unix/Linux ne dément pas sa réputation: il fait le boulot !

Le script suivant prend en entrée le résultat de la commande d’état des batchs de $U et recrache sur la sortie standard un CSV. Alternativement on peut lui passer en argument le fichier issu de $U et le fichier de sortie CSV.

#!/usr/bin/env perl
use warnings;
use DateTime::Format::Strptime;
use Text::CSV;

my %batch_stat = ();

sub get_input{
    my $num_arg =  $#ARGV + 1;
    unless ($num_arg==0) {
    open my  $input_fd , '<', $ARGV[0]
        or die "Impossible d'ouvrir le fichier $ARGV[0]";
    return $input_fd
    } 
    my $input = STDIN;
    return $input;
}

sub get_output {
  my $num_arg =  $#ARGV + 1;
    unless ($num_arg < 2) {
    open my  $output_fd , '>', $ARGV[1]
        or die "Impossible d'ouvrir le fichier $ARGV[1]";
    $output_fd -> autoflush(1);        
    return $output_fd;

    }
    my $output = STDOUT;
    return $output;
}

sub handle_line {
    my ($line) = @_;
    my $date_format = qr/\d{2}\/\d{2}\/\d{4}/;
    my $heure_format = qr/\d{4}/;
    if (  $line =~ /TERMINE\s*(?<date_exec>$date_format)\s(?<heure_debut>$heure_format)\s(?<heure_fin>$heure_format)/) {
    my @splitted = split(/\s+/,substr($line,19, length($line)));
    my $batch =  $splitted[0];
    my $date =  "$+{date_exec}";
    my $heure_debut =  "$+{heure_debut}";
    my $heure_fin =  "$+{heure_fin}";
    #print "$batch $date $heure_debut $heure_fin\n";

    my $analyseur = DateTime::Format::Strptime ->new (pattern => '%d/%m/%Y %H%M');
    my $dt_debut = $analyseur -> parse_datetime ($date .  ' ' .  $heure_debut);
    my $dt_fin = $analyseur -> parse_datetime ($date . ' ' .  $heure_fin);
    # la commande de stat de dollar univers ne précise pas la date de fin
    # mais uniquement l'heure de fin
    if ($dt_fin < $dt_debut){
        my $un_jour = DateTime::Duration -> new (days => 1);
        $dt_fin -> add_duration($un_jour);
    }
    my $duree = $dt_fin - $dt_debut;
    my $duree_minutes = $duree -> in_units('minutes');

    unless(exists($batch_stat{$batch})){
        #my %info = qw (min 0 max 0 moyenne 0 nb 0);
        $batch_stat{$batch}= {
        min => $duree_minutes,
        max => $duree_minutes,
        moyenne => 0,
        nb => 0        
        };
        #print "nouveau stat de batch cree \n";
    }
    my $current_nb = $batch_stat{$batch}{nb};
    $batch_stat{$batch}{nb} = $current_nb + 1;
        $batch_stat{$batch}{'min'} = $duree_minutes if $duree_minutes < $batch_stat{$batch}{'min'};
        $batch_stat{$batch}{'max'} = $duree_minutes if $duree_minutes > $batch_stat{$batch}{'max'};
    $batch_stat{$batch}{'moyenne'} = ( $batch_stat{$batch}{'moyenne'} * $current_nb + $duree_minutes ) / $batch_stat{$batch}{nb};

    }

}

my $real_input = get_input();

while (<$real_input>)
{
    handle_line($_);

}
#print Dumper \%batch_stat;

my $real_output = get_output();

my @entetes = ('batch','nb_exec','temp_min','temp_max','temp_moy');

$csv = Text::CSV -> new();
$csv -> print($real_output, \@entetes);
$real_output -> say();

foreach my $batch_name (keys(%batch_stat)) {
    my @column = ($batch_name,  $batch_stat{$batch_name}{nb}, $batch_stat{$batch_name}{min}, $batch_stat{$batch_name}{max}, $batch_stat{$batch_name}{moyenne} );
    $csv -> print($real_output, \@column);
    $real_output -> say();
}

Les exceptions Java

Les exceptions en Java constituent un mécanisme puissant de traitement des erreurs aussi bien dans une phase d’exécution normale de l’application que dans les phases de débogage. J’aime comparer Java et Pascal ou C. Dans le premier, tout événement anormal (utilisation d’un pointeur null ou un problème d’entrée/sortie par exemple) doit provoquer un arrêt du flot d’exécution… immédiatement ! Alors que dans le second, il peut se passer de nombreuses instructions entre l’origine d’un problème et sa manifestation, rendant le débogage plus difficile.

La perception des exceptions par le programmeur est malheureusement souvent mauvaise. Le programmeur ressent la gestion des exceptions comme une contrainte et s’en débarrasse en la masquant ou en la laissant remonter, par paresse. Cela entraîne un mauvais usage des exception et c’est bien la mauvaise gestion des exceptions en Java par le programmeur qui font dire à certain que java ne sait pas gérer les exceptions.

Pourtant il suffit de respecter quelques principes simples pour tirer le plus grand bénéfice de ce mécanisme de gestion d’erreur.

Une exception doit être rattrapée si on sait comment la traiter

Par traitement on entend une action spécialement prévue dans le cas de l’exception. Par exemple une IOException pourrait être traitée en réessayant un certain nombre de fois ou en demandant à l’utilisateur de changer un paramètre (chemin de fichier par exemple). Mais attention, rattraper une exception ne suffit pas à la traiter correctement. Il ne suffit pas d’encadrer une un appel pouvant lever une exception avec un try catch pour s’assurer d’une bonne gestion. En effet, considérons le code suivant:

instruction1();  // lève une exception
instruction2()

Il ne suffit pas de faire:

try {
  instruction1();
}
catch (Exception e){
  // on gère l'exception
}
instruction2();

Le code précédent assume que la gestion de l’exception doit permettre l’exécution de instruction2(), mais est-ce que la gestion de l’exception le fait réellement ? un simple log sera bien sûr insuffisante, ne vaudrait-il pas mieux ne pas exécuter instruction2() ? Ou bien mettre la 2e instruction dans le bloc try également ? La réponse dépasse le cadre de la gestion des exceptions pour entrer dans celui de la robustesse du code.

Si on ne sait pas comment réagir face à l’exception la solution la plus simple est de ne pas la rattraper.

Sinon on ne rattrape pas et on la déclare

Déclarer l’exception signifie que la méthode doit la porter dans sa signature. C’est le point le plus important. Déclarer l’exception permet de la remonter correctement. Le code appelant qui peut être la méthode main() devra alors gérer l’exception, ce qui nous garantit un traitement correcte de l’exception: au moins par un arrêt du flot d’exécution.

Trop d’exceptions à déclarer: on encapsule

Les programmeurs non habitués à la gestion des exceptions seront alors gênés de devoir déclarer de nombreuses exceptions en signature de méthode.  Il faut alors prévoir une hiérarchie d’exception applicative plus simples qui va permettre d’encapsuler des exceptions plus techniques afin de limiter le nombre d’exception à déclarer dans les méthodes. Le programme va alors devoir rattraper les exceptions (technique ou de base) afin de les encapsuler dans des exceptions applicatives.

Cas des conteneurs d’application

Arrêter le flot d’exécution voire même la JVM est possible quand le programme est seul au monde. Dans le cas d’application web ou de conteneur d’EJB, le code ne doit pas arrêter la JVM car il s’inscrit dans un serveur d’application: il n’est pas seul au monde. Les conteneurs (tel que tomcat) sont bien écrits et une application ne peut pas arrêter la JVM à cause d’une exception qui remonterait toute le pile d’appel. Il y aura un appel qui va rattraper l’exception et en faire quelque chose comme par exemple l’écrire sur la sortie de la JSP. Cela est souvent vu comme une mauvaise chose pour l’utilisateur mais doit être vue comme une bénédiction par le programmeur. C’est la solution minimale qui assure un débogage de l’application.

Empiler ou découpler ?

Un reproche fait aux piles d’exception de Java c’est sa verbosité. C’est un reproche qui peu s’entendre. En effet prenons le cas d’une application multi-tiers où une erreur d’accès à la base de donnée remonte jusqu’à la couche de présentation sous forme d’une pile d’appel qui dévoile toutes les couches de l’application: action de l’utilisateur, appel de service, appel à la couche de persistance et finalement une belle erreur JDBC avec un code obscure en provenance du SGBD. Vous connaissez ce scénario  ? Il arrive quand on laisse filer l’exception ou que l’on encapsule en faisant référence à l’exception original via un appel à :

public Exception(Throwable cause)

Cette façon de faire permet de conserver l’exception d’origine et ainsi de ne pas perdre la pile d’exécution au moment de la levé de l’exception d’origine. C’est la façon de faire la plus sûr et la plus simple. c’est de l’empilage d’exception. Si on ne souhaite pas remonter dans les couches supérieures (appelantes) la pile d’exécution car on considère que cela n’est pas de leur ressort, on peut découpler i.e simplement lever une exception à destination des couches supérieures sans passer l’exception qui en est la cause mais alors il faut tracer (loguer) la cause de manière complète i.e. loguer la pile d’exécution. Ainsi on résout de manière élégante le problème des piles d’erreurs trop verbeuses dans la log des couches supérieurs tout en gardant dans les log des couches inférieurs la trace complète des exceptions à des fin de debug. Cette technique sera particulièrement efficace quand on choisit de mettre en œuvre des log par couche d’abstraction: une log pour la couche de présentation, une log pour la couche métier et une log pour la couche de persistance… ce qui nous amène à l’épineux problème de la gestion des log et c’est une autre histoire.

 

Analyse dump mémoire JVM sur AIX (ibm)

La JVM d’IBM sur AIX produit un dump mémoire au format non standard. La JVM de Sun (pardon Oracle….) crée un fichier HPROF tandis que la JVM d’IBM crée un fichier PHD (Portable Heap Dump). C’est un peu déconcertant car JVisualVM ne sait pas lire le PHD. La solution est alors d’utiliser Eclipse MAT dont l’ascendance génétique n’est pas étrangère à IBM.

Après avoir téléchargé la dernière version de MAT sur le site //www.eclipse.org/mat/ il faudra tout de même encore ajouter une extension pour qu’il puisse lire les PHD. Dans le menu “install new Software” on devra ajouter le site

//public.dhe.ibm.com/software/websphere/runtimes/tools/dtfj/

On peut également ajouter MAT (Memory Analyzer Tool) en temps que plugin dans un Eclipse standard. Pour cela il faudra ajouter le site suivant dans le menu “install new software”:

//download.eclipse.org/mat/1.4/update-site/

Ensuite pour pouvoir ouvrir des dump de JVM ibm il faut ajouter l’extension vue en premier.

Passons à TLS

Bien que SSL soit supplanté par son successeur TLS, il reste quand même encore utilisable car bien des serveurs le garde comme protocole au cas où un client ne supporterait pas TLS. L’enfer est pavé de bonnes intentions…. si SSLv2 est aujourd’hui considéré comme défaillant, ce n’est pas le cas de SSLv3 qui reste encore dans les bonnes grâces de la configuration de apache2 sous Debian 7. En effet dans le fichier /etc/apache2/mods-enabled/ssl.conf on trouve:

SSLProtocol all -SSLv2

Ce qui indique l’utilisation possible de  TLS et de SSLv3. Malheureusement une information parue sur le site américain NVD qui recense les vulnérabilités des logiciels, SSL est intrinsèquement vulnérable (y compris SSLv3) à l’attaque de l’homme du milieu. Cela veut dire qu’il faut absolument ne plus utiliser SSL mais son successeur TLS.

La mise en place du banissement de SSL dans nos serveurs web consiste à le supprimer de la liste des protocoles utilisables par apache. Dans le fichier ssl.conf il suffit de mettre:

SSLProtocol all -SSLv2 -SSLv3

On pourra également en profiter pour hausser si n’est déjà fait le niveau de cryptage (algorithmes utilisés) que le serveur accepte de faire. Le monde libre (et donc gratuit) ne laisse aucune excuse au client qui n’utilise pas un logiciel récent et supportant les algorithmes de chiffrement les plus sûrs. Toujours dans le fichier ssl.conf il suffit de mettre:

SSLCipherSuite HIGH:!ADH:!MD5

Chainsaw sous Debian 7

Debian 7 Wheezy propose open-jdk 6 comme JVM par défaut. Malheureusement cela pose un problème avec la fenêtre de popup au démarrage de Chainsaw qui propose d’ajouter un récepteur de log. Cette fenêtre reste vide sans aucun moyen de la fermer. Un open-jdk 7 ne change rien  à l’affaire et il faudra ce résoudre à utiliser la JVM Oracle.