Catégorie : Open-source

Catégories
Open-source Planet-libre Reseau Systeme

Utiliser Munin avec des hôtes SNMP

Avec le temps, je suis devenu un grand adepte de Munin, le logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools.

Sa simplicité de prise en main et d’administration y est pour beaucoup. En effet, en une ligne de commande il est possible d’analyser une nouvelle machine à superviser. Munin va s’occuper de générer automatiquement tous les graphes possibles et imaginables. Cette simplicité est notamment dû à l’architecture client/serveur de Munin qui masque en grande parti la complexité des mécanismes de récupération de données à grapher.

Pour superviser un hôte comme des équipements réseaux (routeur Cisco, Switch…) ou des appliances (NAS…) sur lesquels il est impossible d’installer le client Munin, il faut passer par une configuration spécifique au niveau du serveur, utilisant le protocole SNMP, que nous allons détailler dans ce billet.

Comment ça marche ?

Contrairement au fonctionnement nominal de Munin, le serveur ne va pas passer par le client Munin pour récupérer les données mais par un plugin installé directement sur le serveur.

Dans le schéma suivant, honteusement copier/coller du site officiel, le serveur Munin (Dumbledore) va utiliser le le munin-node local pour aller chercher, via SNMP, les informations sur la machine hôte (Netopia).

Munin-SNMP

 

Comment ajouter un hôte SNMP à superviser ?

Avant tout il faut avoir installé le serveur Munin sur une machine GNU/Linux (vous pouvez suivre cet article pour vous aider).

Ensuite, depuis votre serveur, il suffit de saisir la commande suivante pour ajouter l’hôte « netopia ». Il faut bien sûr remplace netopia par le nom (FQND) ou l’adresse IP de votre hôte.

dumbledore:~# munin-node-configure --shell --snmp netopia
ln -s /usr/share/munin/plugins/snmp__if_ /etc/munin/plugins/snmp_netopia_if_1
ln -s /usr/share/munin/plugins/snmp__if_err_ /etc/munin/plugins/snmp_netopia_if_err_1
...

Comme vous pouvez le voir, la commande munin-node-configuration avec le tag –snmp  va scanner la MIB SNMP de votre machine hôte et proposer une configuration automatique de tout les plugins (graphes) reconnus dans le répertoire /usr/share/munin/plugins. Vous pouvez ensuite les activer dans votre configuration de Munin en faisant un copier/coller de toutes les lignes ln -s … ou bien plus simplement en remplaçant la commande précédente par:

dumbledore:~# munin-node-configure --shell --snmp netopia | sh

Par défaut, munin-node-configuration utilise public comme communauté SNMP, il est possible de la configurer en ajoutant:

--snmpcommunity public

La version de SNMP à utiliser peut également être configurée:

--snmpversion 3

Il faut ensuite ajouter les lignes suivantes à votre fichier de configuration du serveur Munin (en laissant bien l’adresse IP 127.0.0.1 !!!):

[netopia]
    address 127.0.0.1
    use_node_name no

 Appliquer la nouvelle configuration à votre serveur Munin

Une fois vos différents hôtes ajoutés selon la procédure précédente,  vous devez faire prendre en compte la nouvelle configuration avec la commande:

service munin-node restart

Les nouveaux graphes devraient apparaître après quelques minutes:

muninsnmp

Dans certains cas, si les graphes n’arrivent pas, il peut être utile de relancer complètement le serveur Munin en saisissant:

su - munin --shell=/bin/sh

/usr/share/munin/munin-update

Conclusion

Avez vous des avis sur Munin, l’utiliser vous avec un pooling SNMP ?

Des scripts et astuces à partager ?

Source: Site officiel de Munin. 

Catégories
Open-source Planet-libre Systeme

Glances 1.6: Les nouveautés

Ce week-end, j’ai mis en ligne la dernière version de Glances. Cette version 1.6 apporte son lot de correction de bugs et de nouveautés que nous allons détailler dans ce billet.

On commence par un aperçu de l’interface de Glances 1.6 dans un terminal:

Glances 1.6

Mise en place d’un fichier de configuration

Jusqu’à la version précédente, il était impossible pour l’utilisateur de fixer lui même les limites déclenchant les alertes. La version 1.6 introduit donc un fichier de configuration permettant de répondre à ce besoin. Sur un système GNU/Linux, le fichier de configuration par défaut se trouve dans dans le répertoire /etc/glances et se  nomme glances.conf.

C’est un fichier au format texte de la forme: https://gist.github.com/4647457

Comme vous pouvez le voir il défini pour chaque section de statistique (CPU, LOAD, MEM…) les limites de type Careful (à surveiller), Warning (à traiter), Critical (à traiter en urgence). Les limites utilisées sont maintenant accessibles dans la fenêtre d’aide sous la forme d’un tableau:

capture_015

Je pense dans les prochaines versions utiliser ce même fichier pour configurer d’autres aspects de Glances, comme les couleurs ou l’emplacement des statistiques.

Amélioration du mode client/serveur

La version 1.5 de Glances introduisait un mode client/serveur basée sur XMLRPC pour surveiller à parti d’un client local une machine distante (GNU/Linux, BSD, MAC OS X et même Windows).

En rapport avec l’ajout d’un fichier de configuration, j’ai modifié le mode client/serveur  pour que le serveur envoie son jeu de limite au client. Ainsi, il est possible à partir d’une même machine cliente de superviser plusieurs serveurs ayant des limites différentes.

Autre nouveauté attendue par pas mal d’utilisateurs: l’ajout « d’un peu » de sécurité pour l’accès à un serveur Glances. J’ai ainsi ajouté le tag -P password (notez le P majuscule) permettant de définir un mot de passe à partager entre le client et le serveur. Ce n’est bien sûr pas une sécurité totale car le client de communication TCP/JSON n’est pas chiffré. Pour encore plus de sécurité le mieux est de passer par un tunnel SSH (il existe pas mal de tutos sur le sujet sur la toile).

Débits d’Entrées/Sorties (IO Rate) par processus

Lorsque que la taille de votre fenêtre le permet, Glances permet d’afficher les débits (en octets/seconde) des processus. Ainsi, si une alerte est détectée sur la valeur CPU iowait alors les processus seront automatiquement classé par débit d’entrée/sortie.

capture_012

Attention, ces valeurs sont uniquement accessible sous GNU/Linux et par un utilisateur disposant des droits administrateurs.

Modification de l’affichage par CPU

Lors de l’activation de l’affichage par CPU (touche ‘1‘) et si l’information est disponible sur votre système d’exploitation, alors Glances affiche les statistiques de CPU iowait en lieu et place de CPU nice:

capture_016

Cette information peut être utile si des processus perdent du temps lors des accès disques. C’est un indicateur trsè important pour la supervision des serveurs (lire le très bon billet de ScoutApp sur le sujet).

Amélioration de l’affichage du type de tri des processus

Je trouvais que l’affichage du type de tri sur les processus (automatique vs manuel) n’était pas clair. J’ai donc modifié celui-ci pour afficher clairement si:

on est en tri automatique ou manuel:

capture_018

capture_017

puis de voir quel est le critère de tri dans le colonne (souligné en mode automatique, en gras pour le mode manuel):

capture_020
capture_019

Mise à jour de l’API

Dernier point pour cette version, j’ai ajouté une nouvelle interface à l’API pour récupérer les limites du serveur via getAllLimits (méthode RCP).

Installation et mise à jour de Glances

Convaincu par cette nouvelle version ?

Il est donc temps de mettre à jour votre installation. Deux solutions:

  • attendre que les packets managers fassent leur boulot pour votre distribution favorite
  • lire la documentation officielle pour mettre à jour vous même votre Glances

J’attend vous retours 🙂

Quelques liens pour finir:

Catégories
Developpement Open-source Planet-libre

Besoin de bêta testeurs pour Glances 1.6

Glances 1.6 est en plein développement. Une version bêta vient d’être mise à disposition sur le GitHub officiel. J’ai donc besoin de VOUS pour tester, trifouiller, charger cette version avant sa publication. Je prend en charge de mon coté les tests sous Ubuntu et Debian mais je n’ai pas le temps de mener tous les tests sur les autres distributions et OS.

ineedyou

Comment tester ?

Le plus simple pour tester cette version sans casser son installation existante est de suivre la procédure donnée dans cette page du Wiki pour GNU/Linux (sous Windows, il faut au préalable installer quelques logiciels).

Si vous rencontrez un bug, merci de suivre cette procédure pour me le remonter.

Quoi tester ?

Un peu tout… C’est à dire dans un premier temps un lancement de Glances en mode standalone:

~/tmp/glances/glances/glances.py

En mode standalone avec le module sensor actif (si vous avez lm-sensors sur votre OS):

~/tmp/glances/glances/glances.py -e

En chargeant le nouveau fichier de configuration qui permet de changer les limites des alertes (c’est une des grosses nouveauté de cette version):

~/tmp/glances/glances/glances.py -C ~/tmp/glances/glances/conf/glances.conf

Note: vous pouvez bien-sur modifier le fichier de configuration (glances.conf) pour l’adapter à vos besoins.

Puis en mode client/serveur en lançant d’abord le serveur:

~/tmp/glances/glances/glances.py -s

Puis le client (sur la même machine):

~/tmp/glances/glances/glances.py -c localhost

Besoin de qui ?

Une liste non exhaustive de bêta-testeurs dont j’ai besoin et qui utilisent les systèmes suivants:

  • Arch Linux
  • Centos
  • Redhat
  • Gentoo
  • FreeBSD
  • NetBSD
  • OpenBSD
  • Mac OS
  • Windows 7
  • Windows 8
  • n’importe quel OS sous Python 3.x

Merci d’avance à vous !

Catégories
Open-source Planet-libre Reseau Systeme

Installation et prise en main d’OpenVAS, le fork de Nessus

Depuis sa version 3, Nessus, le logiciel phare dans le petit monde des scanners de vulnérabilités des systèmes d’information est passé sous licence propriétaire. Comme c’est souvent ce genre de cas un fork de sa version 2 (qui était sous licence GPL) a rapidement vu le jour: OpenVAS. Nous allons dans ce billet en détailler l’installation et la première utilisation.

Scanner de vulnérabilités ? Kezako ?

Tout comme Nessus, OpenVAS est donc un scanner de vulnérabilités. On pourrait aussi l’appeler un logiciel d’aide aux audits de sécurités. Il se présente sous la forme d’un client / serveur.

OpenVAS4-Software

Le client permettant de définir le périmètre (plage d’adresse, type de machine) et les paramètres de l’audit (audit externe ou interne). Il se décline en CLI (ligne de commande), GUI (interface graphique) et API (Python notamment). Il est disponible sous GNU/Linux et Windows.

Le serveur effectuant le scan des différentes vulnérabilités (appelés NVT pour « Network Vulnerability Test ») disponibles dans sa base (plus de 25.000 NVTs à l’heure de rédaction de ce billet). Le serveur existe uniquement sous GNU/Linux.

Installation du serveur OpenVAS

Pour mes tests, je dispose d’une machine sous Ubuntu 12.04 LTS. La procédure suivante est donc donnée à titre indicatif pour ce système d’exploitation.

On commence par installer le package OpenVAS Serveur disponible dans les dépôts d’Ubuntu:

sudo apt-get install openvas-server

On doit ensuite créer un couple login/password pour limiter l’accès au serveur:

sudo openvas-adduser
sudo service openvas-server restart

Il est possible que le premier lancement du serveur prenne un peu de temps car il charge l’ensemble des NVTs.

Installation du client OpenVAS

Il est possible d’installer le client sur n’importe quelle machine du réseau ou bien directement sur le serveur (c’est ce que j’ai fait pour mes tests).

On installe les packages:

sudo apt-get install openvas-client htmldoc

Note: le module htmldoc sert uniquement pour l’export au format HTML des rapports.

Première utilisation d’OpenVAS

Le client graphique OpenVAS se nomme openvas-client, il faut donc le lancer via un terminal ou votre launcher Unity/Gnome. Au premier lancement, il faut commencer par se connecter au serveur via le menu Fichier > Connecter. On doit saisir le login/password.

Pour créer son premier audit de sécurité, le plus simple est de passer par le wizard disponible via le menu Fichier > Scan assistant.

Il est alors possible de choisir le contexte de l’audit (description) et la cible (une machine, un réseau…).

Le lancement de l’audit se fera automatiquement. Le temps d’exécution dépend du nombre de machines, de la rapidité de votre réseau et du nombre de services à tester sur vos cibles.

capture_085

 

A la fin, un rapport est généré et accessible en archive:

capture_086
Il est bien sur possible d’exporter le rapport (format XML, HTML, PDF…) via le menu Rapport > Exporter.

Si l’interface de GUI est pratique pour des audits « one shot », il peut être également utile de regarder du cité de l’API Python qui permet une utilisatino avancé du serveur OpenVas et pourquoi pas une automatisation des lancements.

Configuration avancée d’OpenVAS

C’est dans le fichier de configuration /etc/openvas/openvasd.conf que l’on trouve la définition du chemin vers les NVT (sortes de plugins pour OpenVAS):

# Directory where plug-ins are to be found
plugins_folder = /var/lib/openvas/plugins

Ce répertoire contient des fichiers au format .nasl avec:

Si vous souhaitez développer vos propres scripts, il va falloir se plonger dans la documentation officielle. Le plus simple est de partir du template.nasl de référence et de tester pas à pas mais avant cela, je vous conseille de regarder la base des 25.000 NVT disponibles, régulièrement mise à jour, vous trouverez sûrement votre bonheur.

Catégories
Developpement Open-source Planet-libre Systeme

Glances 1.5.2: Les nouveautés

Il y a quelques jours, j’ai mis en ligne la dernière version stable de Glances, mon outil de supervision système, dont nous allons, dans ce billet, découvrir les nouveautés de cette version 1.5.2.

Screenshots

On commence par l’aperçu général de Glances 1.5.2 dans une console (80×24):

screenshot-console

et dans un terminal (terminator):

screenshot-wide

Les nouveautés

CPU

J’ai repris la zone de statistique CPU pour afficher les attributs suivants: IDLE, IOWait et IRQ. Ces informations sont affichés si l’espace est disponible.

cpu-wide

En cliquant sur la touche ‘1’, Glances va switcher vers l’affichage des statistiques CPU par « core ».

percpu

Mémoire

Grâce au travail d’Alessio Sergi, les statistiques concernant la mémoire sont agrémentés, si la place sur l’écran est disponible, des informations suivantes:

  • active: RAM actuellement utilisée
  • inactive: RAM non utilisée actuellement
  • buffers: zone mémoire pour les informations systèmes (par exemple metadata des systèmes de fichiers)
  • cached: zone mémoire de cache

Processus

Egalement avec la particition d’Alessio, nous avons repris la zone de processus qui affiche maintenant le résumé sur une seule ligne ainsi qu’une optimisation de l’espace.

capture_082

Sensors

Suite à une demande récurrente, j’ai également ajouté un module optionnel pour afficher les températures remontées par les capteurs. Pour cela Glances utilise la librairie Python nommé PySensors qu’il faut installer sur son système et qui va chercher les informations via LM-Sensors (qui doit bien sûr être installé et configuré sur votre système). A ma connaissance, seul les OS Linux sont compatibles.

Pour utiliser ce module, on doit commencer par installer PySensors:

sudo pip install pysensors

Puis on lance Glances avec l’option -e:

glances -e

Et voilà le résultat sur une machine avec 4 capteurs:

capture_083

Amélioration de l’interface RPC

L’interface RPC/JSON est la base du mode client serveur permettant de surveiller à distance une machine. Par exemple pour surveiller depuis la machine B l’état du système de la machine A, il faut:

A> glances -s

Puis

B> glances -c <@IP ou Nom de A>

On peut facilement voir que l’on regarde les statistiques d’une machine distante grâce au message en bas à gauche de l’écran:

capture_084

La liste exhaustive des méthodes RPC disponible est:

getSystem
{"linux_distro": "debian 6.0.6", "platform": "64bit", "os_name": "Linux", "hostname": "frodo", "os_version": "2.6.32-5-amd64"}

getCore
4

getCpu
{"iowait": 0.32641336989226583, "system": 0.26113069591476262, "idle": 97.401749576581707, "user": 1.9845932889502962, "irq": 0.0, "nice": 0.0}

getLoad
{"min1": 0.0, "min5": 0.059999999999999998, "min15": 0.01}

getMem
{"inactive": 1631744000, "cached": 1974865920, "used": 1384603648, "buffers": 585797632, "active": 1932537856, "total": 4080373760, "percent": 33.899999999999999, "free": 2695770112}

getMemSwap
{"total": 1069277184, "percent": 12.800000000000001, "free": 932536320, "used": 136740864}

getSensors
[]

getNetwork
[{"interface_name": "eth0", "rx": 169437, "tx": 2082677}, {"interface_name": "eth1", "rx": 0, "tx": 0}, {"interface_name": "lo", "rx": 385562, "tx": 385562}]

getDiskIO
[{"read_bytes": 0, "write_bytes": 0, "disk_name": "sda1"}, {"read_bytes": 24576, "write_bytes": 458752, "disk_name": "sda2"}, {"read_bytes": 0, "write_bytes": 0, "disk_name": "sda3"}]

getFs
[{"mnt_point": "/", "used": 22333382656, "device_name": "/dev/sda2", "avail": 910442115072, "fs_type": "ext4", "size": 982693486592}, {"mnt_point": "/boot", "used": 24039424, "device_name": "/dev/sda1", "avail": 164789248, "fs_type": "ext4", "size": 199108608}, {"mnt_point": "/dev", "used": 94208, "device_name": "udev", "avail": 2034892800, "fs_type": "tmpfs", "size": 2034987008}, {"mnt_point": "/lib/init/rw", "used": 0, "device_name": "tmpfs", "avail": 2040184832, "fs_type": "tmpfs", "size": 2040184832}]

getProcessCount
{"running": 1, "total": 143, "sleeping": 142}

getNow
"2012-12-30 12:13:45"

Installation et mise à jour

Le mieux est de suivre la procédure adaptée à votre système en consultant le site officiel de Glances ou vous pourrez également consulter la documentation complète.

Contributeurs ? J’ai besoin de vous !

En plus de toutes les remontées de bug / demandes d’améliorations que vous pouvez effectué via cette interface Web sur le GitHub officiel du projet, j’aurai également besoin de contributeurs pour:

  • maintenir le PPA officiel du site et proposer des versions packagées de Glances pour Ubuntu et ses forks (juste pendant une période temporaire vu que Glances est maintenu officiellement dans Debian Sid et devrait donc être intégré de base dans la prochaine version d’Ubuntu)
  • maintenir un packaging « all in one » de Glances pour Windows 32 bits et 64 bits (c’est à dire en suivant la procédure d’installation sur le site officiel et en utilisant le module PyInstaller pour générer un binaire). Je pourrai ensuite héberger ces binaires sur mon espace Amazon S3.
  • participer au développement de la prochaine version de Glances, j’ai nommé la 1.6 dont la roadmap, en cours de conception, est disponible ici.

Il ne me reste plus qu’à vous souhaitez une bonne fin d’année 2012 !

See you soon on the moon.

Catégories
Open-source Planet-libre Web

Gérer son compte Amazon S3 en ligne de commande

Il y a quelques jours, un billet sur le blog officiel de GitHub a particulièrement attiré mon attention. Pour faire court, GitHub vient de supprimer le « Tab Download » qui proposait un moyen simple d’héberger le téléchargement des sources/binaires en dehors du gestion de configurationen version. J’utilisais cette solution pour héberger les archives des différentes versions de Glances  que j’utilisais dans mon script d’installation setup.py.

capture_057

J’ai donc du trouver une solution alternative pour héberger ces fichiers. Trois solutions se présentaient à moi:

  • Utiliser le « Tab Tag » de Github dans lequel est automatiquement généré les versions tagués (au sens Git). J’ai rapidement écarté cette solution car j’ai besoin d’un système plus souple (pour héberger par exemple des versions bêta, non taguées) et ouvert (par exemple pour héberger les futures binaires pour Glances Windows).
  • Héberger ces fichiers sur mon serveur dédié. C’est la solution la plus logique mais qui ne présente pas, à mon goût, assez de robustesse. En effet, en cas de panne/problème de mon serveur (ou de l’hébergeur) je souhaite que les utilisateurs puissent continuer à mettre à jour ou installer Glances.
  • Utiliser un service en ligne fait pour cela comme Amazon Simple Storage Service (Amazon S3 pour les intimes).

C’est donc sur cette dernière solution que je suis parti.

Amazon S3 ? C’est quoi donc ?

C’est un service dans « les nuages » permettant de stocker des objets (répertoires, fichiers) dans des buckets (librairies). On peut ensuite accéder à nos objet via une simple URL (par exemple: https://s3.amazonaws.com/glances/glances-1.5.1.tar.gz).

Il est payant mais relativement peu coûteux pour l’hébergement de petits fichiers (voir la grille tarifaire ici et le détail de l’offre là).

J’ai donc commencé par créer un compte puis par tester le stockage de mes premiers fichiers à partir de la console en ligne proposée par Amazon.

capture_058

Comme la plupart des interfaces de ce type, elle est très simple à utiliser mais montre ces limites quand on souhaite automatiser les taches comme par exemple publier par script un nouveau fichier dans une librairie.

s3cmd, le couteau suisse de Amazon S3

Heureusement, la ligne de commande vient à notre secours grâce au logiciel open-source s3cmd.

On commence par installer s3cmd sur notre système GNU/Linux (Debian / Ubuntu):

sudo apt-get install s3cmd

Puis on effectue la configuration initiale qui va permettre de donner les autorisation nécessaire à votre machine pour accéder à votre espace S3. Pour cela, nous avons besoins des clés publique (1) et privé (2) de notre compte Amazon AWS (via cette page):

capture_055

… de saisir la commande suivante:

s3cmd --configure

et de se laisser guider…

Une fois cette commande terminé, vous devriez pouvoir accéder à votre compte Amazon S3 depuis la ligne de commande de votre machine.

Guide d’utilisation de s3cmd

Créer un bucket (mb)

Un bucket est le conteneur de plus haut niveau dans la terminologie d’Amazon S3. On peut le voir comme un disque dur dédié ou comme une librairie. Dans mon cas précis, j’ai donc commencé par créer le bucket glances en utilisant la commande suivante:

s3cmd mb s3://glances

Affiche la liste de vos buckets

On peut vérifier que l’opération c’est bien passée en affichant la liste des buckets disponibles:

s3cmd ls
2012-12-14 14:35 s3://glances

Ajouter un nouveau fichier (objet) dans un bucket

On peut ensuite ajouter un objet de type fichier dans ce bucket.

Par défaut, un objet est privé (donc seulement accessible avec les clés privée et publique de votre compte).

 

s3cmd put glances-1.5.1.tar.gz s3://glances/glances-1.5.1.tar.gz

Pour créer le même objet mais de manière publique (donc accessible depuis une URL), on doit saisir:

s3cmd put --acl-public --guess-mime-type glances-1.5.1.tar.gz s3://glances/glances-1.5.1.tar.gz

Afficher le contenu d’un bucket

Pour afficher le contenu d’un bucket:

s3cmd ls s3://glances
2012-12-14 14:36 647418 s3://glances/glances-1.5.1.tar.gz

Comment télécharger ces objets ?

Pour télécharger un fichier depuis un bucket, on peut soit directement utiliser son URL publique (pour les objets publics) : https://s3.amazonaws.com/glances/glances-1.5.1.tar.gz

ou en ligne de commande (pour tous les objets):

s3cmd get s3://glances/glances-1.5.1.tar.gz glances-1.5.1.tar.gz

Supprimer un fichier dans un bucket

On doit saisir la ligne de commande:

s3cmd del s3://glances/glances-1.5.1.tar.gz

Supprimer un bucket

Un bucket doit être vide avant d’être supprimé par la commande:

s3cmd rb s3://glances

Synchronisation

Si vous souhaitez, avec s3cmd, gérer des structures de données plus complexes sur votre espace Amazon S3, il est également possible d’utiliser les fonctions de synchronisation (voir la documentation ici).

Mot de fin

Pour finir j’ai donc modifié mon script de génération de nouvelle version de Glances pour automatiser l’upload vers Amazon S3 et aussi changé mon script setup.py de cette façon:

capture_060

Et vous ? Que pensez-vous d’Amazon S3 ? Utlisateur ? Avec s3cmd ?

Catégories
Open-source Planet-libre Systeme

Ubuntu 12.10 Quantal – Script de post install

Je viens de mettre à jour mon dépôt GitHub des scripts de post installation d’Ubuntu pour prendre en compte le version 12.10 (Quantal). Pour rappel, ces scripts sont un moyen simple et modulaire de faire automatiquement un ensemble d’actions après l’installation standard du système d’exploitation.

Ce script fonctionne avec un fichier de configuration que vous pouvez adapter à vos besoins en suivant la documentation. Trois fichiers de configurations sont disponibles sur le GitHub:

Pour lancer le script avec le fichier de configuration pour Gnome 3, il suffit de saisir les lignes de commandes suivantes:

wget https://raw.github.com/nicolargo/ubuntupostinstall/master/ubuntu-12.10-postinstall.py
chmod a+x ubuntu-12.10-postinstall.py
sudo ./ubuntu-12.04-postinstall.py -c https://raw.github.com/nicolargo/ubuntupostinstall/master/ubuntu-12.04-gnomeshell-postinstall.cfg

L’objectif principal de ce script est bien sur de s’adapter à vous besoins. Je vous conseille donc de récupérer un fichier de configuration et de le modifier à votre convenance. Il suffira ensuite de lancer le script en passant en paramètre votre fichier de configuration. Vous pouvez pour vous aidez dans cette tache lire le précédant billet sur le sujet qui reste valable pour la nouvelle version du script.

Catégories
Nagios Open-source Systeme

CheckGlances ou la rencontre de Glances et de Nagios

Ce billet a comme objectif de présenter mon dernier développement qui est un plugin Nagios|Shinken pour récupérer des informations systèmes sur des machines hôtes faisant tourner Glances.

Je vous présente donc CheckGlances.py.

Quoi ?

CheckGlances est un plugin compatible avec Nagios et ses forks (Icinga, Centreon…) / ré-implémentations (Shinken). Il respecte au maximum les spécifications données par Nagios.

Développé en Python, il permet d’aller récupérer les statistiques d’un serveur Glances (c’est à dire un glances lancée avec l’option -s) via un lien XML RCP sur HTTP.

Pourquoi ?

Le principal avantage de cette solution est que Glances se base sur une librairie Python nommé PsUtil (pour la récupération des statistiques) et qui a le bon goût d’être multi-plateforme. On a donc un plugin permettant de manière unique de récupérer les statistiques sur des hôtes GNU/Linux, BSD, Mac OS ou Windows.

Un autre avantage est l’ouverture de ce système à des statistiques plus fines. Bien que cette première version se limite à CPU, charge, mémoire et swap. CheckGlances, pourra à terme remonter vers votre serveur de supervision toutes les données traitées par Glances (débit des interfaces réseaux, disk IO, processus, température…).

Comment ?

Je ne vais pas copier/coller la documentation qui se trouve sur le site officiel mais l’installation se fait comme pour n’importe quel autre plugin et dépend donc de votre serveur de supervision et de sa configuration.

Il est également possible de tester le plugin en ligne de commande.

Voici quelques exemples (en partant sur Glances server est lancé sur votre machine locale):

CPU

./checkglances.py -H localhost -s cpu
CPU consumption: 2.96% | 'percent'=2.96 'kernel'=0.73 'iowait'=0.20 'idle'=97.04 'user'=1.89 'irq'=0.00 'nice'=0.00

 LOAD

./checkglances.py -H localhost -s load
LOAD last 5 minutes: 0.22% | 'min1'=0.13 'min5'=0.22 'min15'=0.29

MEM

./checkglances.py -H localhost -s mem
MEM consumption: 59.50% | 'used'=3411509248.00 'cache'=1071792128.00 'total'=3934547968.00 'percent'=59.50 'free'=523038720.00

SWAP 

./checkglances.py -H localhost -s swap
SWAP consumption: 3.70% | 'used'=150159360.00 'total'=4080005120.00 'percent'=3.70 'free'=3929845760.00

Le futur…

Il reste encore pas mal de travail du coté de Glances pour proposer une interface XML RCP industrialisable. En effet, outre le fait que seules quelques statistiques sont remontées, il n’y a pour l’instant pas de sécurité. C’est donc une solution qui est utilisable sur un réseau local mais pas dans une architecture Internet. Mais promis, l’authentification client / server est prévue dans la prochaine version de Glances.

Comme toujours, je suis preneur de toutes les remarques, questions et retour de test sur ce nouvel outil.

 

Catégories
Open-source Planet-libre Reseau

Le difficile choix des outils de supervision des réseaux

Je viens de lire le mail d’un lecteur concernant ses interrogations sur le choix des logiciels permettant de surveiller son réseau. Comme c’est une question récurrente dans ma boîte mail et que je pense que ses questions et nos réponses peuvent intéresser d’autres personnes, j’ai décidé de lui répondre directement sur le blog.

On commence par le mail en question:

—

Bonjour Nicolas,

Je me permet de te contacter car je recherche à faire de la supervision sur mon réseau mais je ne sais pas vers quel outils me tourner.

Sachant que mon réseau est relativement petit, quelques switchs, firewalls, routeurs, serveurs, j’aimerais trouver un outils pour surveiller le traffic entrant sortant (réseau LAN connecté à Internet), pinger, savoir la consommation CPU et RAM des serveurs, etc…

J’ai pu voir sur internet et sur ton blog que tu conseillais nagios/centreon/cacti.
Mais j’ai aussi vu une autre solution se commant « The Dude » qui est une appli tournant sur Windows.

Je voulais savoir si avec nagios n’était pas trop lourd pour cela ? Nagios ne nous permet pas de sortir des statistiques sur les performances ? Nous sommes obligé de le couplé à cacti pour que ce soit plus « lisible » ? A ce que j’ai compris Centreon permet de rendre Nagios plus « user frendly », mais qu’apporte-t-il de plus ?

En abstraction de cela, existe-t-il une solution plus simple, plus légère ou plus adapté à ma petite infra au lieu de Nagios ?

Désolé, je sais que vous ne répondez normalement pas aux questions par mail mais je tente quand même ma chance en espérant que vous lisez ce mail un bon jour. 🙂

Kévin

 —

Comme la grande majorité des professionnels de l’informatique, ce lecteur est un peu perdu dans la nébuleuse des solutions de supervision. Ainsi, il mélange la supervision pure (Nagios), la métrologie (Cacti) et les outils de diagnostics élémentaires (ping, iftop…).  A sa décharge, il est vrai qu’il n’y a aucun cours digne de ce nom dans les écoles d’ingénieurs, les DUT ou les cursus universitaires en informatique.

Pour répondre à la question de Kévin, il faut, je pense, commencer par revenir à son besoin.

Il parle de la supervision d’un réseau avec des machines diverses et variées (firewall, routeur, switch, serveurs). On est donc en présence d’un petit réseau (moins de 100 noeuds) avec comme besoin principal un suivi de la consommation des ressources: bande passante de la liaison Internet, CPU et mémoire pour les serveurs. Kévin parle également de ‘ping’, c’est à dire d’un moyen simple de vérifier qu’une machine est bien opérationnelle. D’un autre coté, il n’aborde pas la problématique de la gestion des alertes, c’est à dire des solutions dynamiques pour prévenir une ou plusieurs personnes en cas d’incident.

Dans ce cas précis, je conseillerai donc à Kévin de s’orienter vers la mise en place d’un serveur Munin (lire mon billet sur le sujet), ce qui lui permettra assez facilement de surveiller les serveurs GNU/Linux ou Windows et même les routeurs et switchs Cisco (voir les scripts suivants). Le principal avantage de cette solution est la facilité de mise en place et la légéreté de l’infrastructure. On peut sans problème héberger le serveur Munin sur une machine GNU/Linux existante.

Comme vous pouvez le noter, je ne propose pas de solution pour le ‘ping’ des noeuds. En effet, sans une gestion des alertes, c’est clairement le genre d’outil qui ne sert absolument à rien à moins que Kévin veuille passer ses journée à regarder une page remontant les éventuelles erreurs rencontrées.

Par contre, si son besoin évolue et qu’il est prêt à gérer un véritable serveur de supervision, avec toutes les contraintes de temps et de compétence que cela demande, alors je l’orienterai vers Shinken. Pourquoi Shinken et pas Nagios ? Tout d’abord pour la simplicité de mise en oeuvre (voir mon billet sur l’installation et la configuration initiale de Shinken) mais également pour son module de découverte automatique des noeuds qui est un véritable plus, même pour un petit réseau.

Les informations que je viens de donner ne sont que des pistes et d’autres solutions sont possibles. Je pense notamment à l’utilisation de distributions orientées supervision comme Eyes Of Network ou Fully Automated Nagios (à quand une version Shinken ?).

Qu’en pensez-vous ? Quelles autres pistes pouvez-vous proposer à Kévin ?

Catégories
Developpement Open-source Planet-libre

Internationaliser ses programmes Python

Bien que je pense qu’il vaille mieux utiliser un logiciel en Anglais plutôt qu’un logiciel (mal traduit) en Français, la problématique de l’internationalisation des développements viendra tôt ou tard sur le tapis si vous avez des utilisateurs de plusieurs pays.

Nous allons donc dans ce billet aborder le sujet spécifique de la traduction d’un logiciel écrit dans le langage Python. Pour cela nous allons nous baser sur un programme simple et connu de tous: un bon vieux Hello World !

J’ai créé un projet GitHub avec l’ensemble des fichiers don je parle dans ce billet.

On commence par créer, dans un répertoire de travail, la structure suivante:

mkdir -p i18n/fr/LC_MESSAGES
touch hello.py
 Ce qui va donner:
.
├── hello.py
└── i18n
 ├── fr
     └── LC_MESSAGES

On édite une première version du script Python hello.py:

#!/usr/bin/env python

__appname__ = 'hello'
__version__ = "1.0"
__author__ = "Nicolas Hennion <nicolas@nicolargo.com>"
__licence__ = "LGPL"

def main():
    print("Hello world !")

if __name__ == "__main__":
    main()

Sans surprise, l’exécution de ce programme donne:

$ python hello.py
Hello World !

1. Rendre son code compatible

La première étape est de rendre notre code compatible avec l’internationalisation: Pour cela, on édite notre programme en effectuant les modifications suivantes:

#!/usr/bin/env python

__appname__ = 'hello'
__version__ = "1.0"
__author__ = "Nicolas Hennion <nicolas@nicolargo.com>"
__licence__ = "LGPL"

import gettext
gettext.install(__appname__)

def main():
    print(_("Hello world !"))

if __name__ == "__main__":
    main()
On notera donc:
  • l’inclusion de la librairie gettext
  • l’appel à la fonction gettext.install permettant de charger, s’il existe, le fichier de langue correspondant à la langue du système
  • le repérage de la chaîne de caractère à traduire en la faisant précéder par le caractère _: print(_(« Hello world ! »))

2. Génération du modèle de traduction

On passe ensuite à la création du modèle de traduction général (.pot) qui va servir de support de base pour toutes les langues. On utilise l’outil système suivant:

xgettext --language=Python --keyword=_ --output=./i18n/hello.pot ./hello.py

Attention, ce n’est pas dans ce fichier qu’il faut effectuer la traduction. Ce n’est qu’un modèle.

3. Génération du fichier de traduction

On va donc se retrouver avec un fichier ./i18n/hello.pot. C’est à partir de ce modèle que nous allons créer le fichier de traduction pour un langage donnée.

Par exemple, la création du fichier de traduction Francais (fr_FR) se fait:

msginit --input=./i18n/hello.pot --output=./i18n/fr/LC_MESSAGES/hello.po

4. Traduire votre programme

Il reste ensuite le travail le plus manuel à faire: la traduction en elle même…

Pour cela, on édite le fichier i18n/fr/LC_MESSAGES/hello.po:

...
#: hello.py:12
msgid "Hello world !"
msgstr "Bonjour le monde !"
...

5. Compiler le fichier de traduction

Une fois ce fichier renseigné il faut le compiler. C’est le résultat de cette compilation, qui se présente sous la forme d’un fichier .mo qui sera exploité par votre logiciel.

Pour compiler le fichier i18n/fr/LC_MESSAGES/hello.po vers le fichier i18n/fr/LC_MESSAGES/hello.mo:

msgfmt ./i18n/fr/LC_MESSAGES/hello.po --output-file ./i18n/fr/LC_MESSAGES/hello.mo

Il ne reste plus qu’à installer le fichier de traduction compilé (donc le fichier .mo) dans le répertoire standard de votre système d’exploitation:

Installation du fichier de traduction compilé sur le système:

sudo cp i18n/fr/LC_MESSAGES/hello.mo /usr/share/locale/fr/LC_MESSAGES/hello.mo

Note: cette installation devra normalement être faite par votre script d’installation (Makefile ou setup.py).

Il ne reste plus qu’a tester votre programme et oh miracle:

$ python hello.py
Bonjour le monde !

6. Mettre à jour votre fichier de traduction

En cas de mise à jour de votre programme (ajout ou suppression de chaînes de caractères à traduire, il n’est pas la peine de out recommencer. Il faut dans ce cas, utiliser les commandes suivantes:

xgettext --language=Python --keyword=_ --output=./i18n/hello.pot ./hello.py
msgmerge --update --no-fuzzy-matching --backup=off ./i18n/fr/LC_MESSAGES/hello.po ./i18n/hello.pot

Compléter la traduction puis re-compiler pour obtenir la nouvelle version du fichier .mo:

msgfmt ./i18n/fr/LC_MESSAGES/hello.po --output-file ./i18n/fr/LC_MESSAGES/hello.mo

7. Automatisation

Il est bien sûr conseillé d’automatiser les taches que l’on vient de voir, idéalement par un script. Vous pouvez par exemple vous baser sur le script que j’utilise pour l’internationalisation de Glances (voir ici).

Reste maintenant le travail le plus long: trouver des contributeurs/traducteurs pour traduire vos applications 🙂