La nouvelle version instable (bien que tout à fait utilisable) d'OpenNMS est sortie.

OpenNMS est une solution de supervision réseau écrite en Java qui prend en charge la plupart des activités liées à ce domaine d'application : découverte d'équipements et de services, suivi de disponibilité de ces équipements et services, collecte de données (SNMP, HTTP, JMX) et présentation graphique de ces données (RRD, jrb), traitement d'événements (traps SNMP, syslog), alarmes, corrélation d'événements (drools) et enfin rapport.

OpenNMS possède une branche stable 1.6 (1.6.5) et une branche instable 1.7 (1.7.4). Instable mais pas inutilisable : les nouveautés de la dernière version portent sur l'intégration d'un éditeur de cartes SVG utilisable sous Firefox, la mise en œuvre de nouvelles méthodes de découvertes d'équipements ou de services, l'intégration avec RANCID, l'inter-opérabilité avec de nombreux outils de gestion de tickets de dérangement/maintenance (OTRS…).

Enfin et surtout, OpenNMS est réellement libre : il ne repose pas sur une "version entreprise" comme le font (malheureusement) de plus en plus de pseudo "logiciels ouverts" (à moins qu'il ne faille dire "logiciels pseudo ouverts").

D'ailleurs le meneur du projet et principal investisseur (Tarus Balog) aime à souligner cet engagement vers le libre

1. en explicitant son "business model" dans son blog ;
   
2. en usant ou abusant de termes spécifiques ("opencore", "fauxpensource") dans ce même blog ;
   
3. en affichant le logo de la FSF sur son site commercial.

NdM: OpenNMS est distribué sous Licence GPL v2. Des paquets sont disponibles pour les distributions à base de RedHat (yum), Mandriva (urpmi), Debian (apt-get) ainsi que pour Mac OS X et Microsoft Windows.

Faute de temps disponible, la revue de presse du mois de mai dernier a été malheureusement passée sous silence. Cependant, on se rattrape en juin. En effet, à part Linux Mag, tous sont encore disponibles chez votre marchand de journaux car la plupart sont des bimestriels. La tendance de ces 2 mois tourne clairement autour

• d'Ubuntu, la version 9.04 « Jaunty » est présente un peu partout : Linux Pratique Essentiel, Linux Identity, Distri Linux (le petit frère de Planète Linux), etc.
  
• Debian qui revient sur le devant de la scène avec la 5.0 Lenny qui a pointé le bout de son nez à la Saint Valentin (Linux Magazine, Linux Pratique, Open Source Magazine, Linux Identity, etc.)
  
• Gimp, incontournable, que l'on retrouve dans OpenSource Magazine, Linux Pratique, Linux+ DVD, ...
• la sécurité Web avec pas moins de 3 articles dans 3 revues différentes (La sécurité des Web Services chez MISC, le piratage par la méthode POST chez Linux Pratique et les attaques calibrées pour le web 2.0 chez GLMF)
  

Bonnes lectures

PS : La revue de presse est ouverte et est plus que jamais à la recherche de contributeurs. N'hésitez pas à y participer régulièrement en prenant en charge la "responsabilité" d'un magazine par exemple (actuel ou non encore traité). Vous pouvez utiliser la tribune des rédacteurs ou contribuer directement sur le wiki dédié pour LinuxFr.

Quand vous partagez un serveur Linux entre plusieurs équipes et plusieurs projets, chacun se retrouve isolé dans son propre répertoire (éventuellement sur son propre système de fichiers). Pour utiliser les logiciels installés sur le système, vous n'avez pas d'autres choix que de réécrire vos scripts de contrôle (arrêt, démarrage, statut, etc.). Plutôt que de refaire des scripts qui seront, dans la majorité des cas, moins bons que ceux livrés avec le système vous pouvez utiliser PKGI.

PKGI est un logiciel sous licence LGPL, fonctionnant sous Debian et vous permettant de déployer dans un répertoire quelconque une arborescence applicative autonome. Vous pourrez ainsi utiliser et gérer en tout indépendance : Apache, MySQL, Tomcat, OpenLDAP, phpMyAdmin, tmpreaper, logrotate, cron, ... (à développer).

Bien sûr, à la place, on pourrait utiliser une machine virtuelle mais cela oblige chaque équipe à maîtriser l'administration d'un système complet. Ce qui demande des compétences qu'un développeur n'a ou ne veut pas avoir. On pourrait également, à la manière des FAIs, utiliser les capacités de mutualisation de certain logiciel (apache et ses virtuals hosts par exemple). Mais cela rend les équipes interdépendantes, cela oblige à mettre en place une architecture mutualisée (ce qui augmente le coût de gestion du système pour ses administrateurs), mais surtout cela ne permet pas de répondre aux besoins spécifiques de chaque projet.