Auteur/autrice : nicolargo

Créateur de blog de Nicolargo, je suis un partisan des logiciels libres et un passionné des nouvelles technologies.

Gérer son compte Amazon S3 en ligne de commande

Auteur de l’article Par nicolargo
Date de l’article 17/12/2012
8 commentaires sur 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.

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.

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):

… 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:

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

Étiquettes amazon, s3, s3cmd

Open-source Planet-libre Systeme

Ubuntu 12.10 Quantal – Script de post install

Auteur de l’article Par nicolargo
Date de l’article 08/12/2012
4 commentaires sur 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 un Ubuntu 12.10 Unity (c’est le script utilisé par défaut)
pour Ubuntu 12.10 Gnome 3 (c’est celui que j’utilise sur mes machines ;))
pour Ubuntu 12.10 Cinnamon (~~fork de Gnome 2~~, un autre WM basée sur Gnome 3)

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.

Étiquettes 12.10, post install, quantal, script, ubuntu

Nagios Open-source Systeme

CheckGlances ou la rencontre de Glances et de Nagios

Auteur de l’article Par nicolargo
Date de l’article 05/12/2012
17 commentaires sur 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.

Étiquettes checkglances, glances, nagios, plugin, shinken

Open-source Planet-libre Reseau

Le difficile choix des outils de supervision des réseaux

Auteur de l’article Par nicolargo
Date de l’article 28/11/2012
54 commentaires sur 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 ?

Étiquettes solutions, supervision

Developpement Open-source Planet-libre

Internationaliser ses programmes Python

Auteur de l’article Par nicolargo
Date de l’article 15/11/2012
7 commentaires sur 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 🙂

Étiquettes i18n, python

Open-source Planet-libre Systeme

Glances 1.5 est arrivé

Auteur de l’article Par nicolargo
Date de l’article 08/11/2012
63 commentaires sur Glances 1.5 est arrivé

Update: La version corrige un bug qui peut, sur certain OS, empêcher le bon fonctionnement de la version 1.5. Je viens donc de publier une version correctrice (1.5.1) qui effectue les contrôles nécessaires avant le démarrage de Glances.

Quelques mois après la sortie de la version 1.4 et la riche actualité qui a suivi (buzz sur pas mal de sites et intégration dans les paquets Debian Sid), voici donc la nouvelle mouture de Glances.

Pour rappel, Glances est un logiciel de supervision système en ligne de commande (interface texte basée sur Curses) permettant de voir en un clin d’oeil l’état de sa machine. Un code couleur permet de mettre en avant les statistiques que Glances juge nominale, à surveiller, en alerte ou critique. Il peut également afficher la liste des dernières alertes/critiques. La lisibilité et l’économie de l’espace pour l’affichage sont des critères importants que j’ai essayé de garder en tête lors du développement et du choix des évolutions.

Nous allons dans ce billet aborder les principales nouveautés de la version 1.5, avec notamment un focus sur la fonction client/serveur permettant de surveiller les machines à distance.

Glances est disponible sous GNU/Linux, BSD, Mac OS X et même Windows (uniquement en mode serveur).

Installation et mise à jour

En attendant la disponibilité de la version 1.5 de Glances dans vos packets managers favoris, il est possible (et conseillé) d’utiliser le gestionnaire de paquet Python Pip pour installer ou mettre à jour le logiciel.

Installation:

# apt-get install python-pip build-essential python-dev
# pip install glances

Mise à jour:

# pip install -- upgrade glances

Si vous avez déjà une version antérieure de Glances installée, il se peut que la mise à jour ne ne fasse pas correctement. Il suffit alors de suivre la procédure suivante:

# rm -rf /usr/local/lib/python2.6/dist-packages/glances/
# rm -rf /usr/local/lib/python2.6/dist-packages/Glances-1.*
# rm -f /usr/local/bin/glances
# pip install glances

Note: si vous avez Python 2.7 ou supérieure, il faut adapter les chemins ci-dessus.

Pour tester que l’installation / mise à jour s’est bien passée, le plus simple est de lancer la commande:

$ glances -v
Glances version 1.5

Puis de lancer Glances pour vérifier que les statistiques de votre machine s’affichent correctement:

$ glances

Les nouveautés de la version 1.5

Visuellement, les utilisateurs des anciennes versions ne seront pas perdus. On retrouve un découpage avec des statistiques essentielles en haut de l’écran (CPU, LOAD, MEM) avec une optimisation de l’espace. Puis sur la gauche des informations optionnelles comme le débit des interfaces réseau, les entrées/sorties disques et l’espace des différents points de montage (maintenant avec un affichage optimisé pour tenir compte des noms longs). Sur la droite, on a la possibilité de voir le détail des processus (avec par défaut un classement automatique et dynamique selon l’état de la machine). Enfin en bas de l’écran, le log des dernières alertes que l’on peut nettoyer avec les touches ‘w‘ pour supprimer uniquement les Warning et ‘x‘ pour supprimer toutes les alertes finies).

La touche ‘h‘ permet toujours d’afficher l’aide en ligne avec la liste des touches disponibles.

La liste complète des changements par rapport à la dernière version est disponible dans le fichier ChangeLog.

Focus sur le mode client / serveur

C’est la grosse nouveauté de cette version. La mise à disposition pour les utilisateurs d’un mode client /serveur permettant à partir d’un Glances client d’afficher les statistiques d’un Glances serveur. On peut ainsi à partir d’un client GNU/Linux surveiller une autre machine GNU/Linux ou même, idée folle, une machine Windows.

Quand Glances est lancé en mode serveur, il créé un serveur XMLRPC en écoute sur le port TCP/61209 (ce port est bien sur configurable). Quand un client se connecte, il met à jour les statistiques avec un système de cache pour éviter de surcharger la machine puis il envoie les statistiques au client qui se charge de l’affichage et de la gestion des alertes. Il est bien sûr possible d’avoir plusieurs clients différents connectés sur un même serveur.

Pour lancer Glances en mode serveur, il suffit d’utiliser l’option -s:

server$ glances -s
Glances server is running on 0.0.0.0:61209

On lance ensuite le client sur une autre machine avec l’option -c:

client$ glances -c server

Si tout se passe bien, vous devriez avoir les statistiques du serveur qui s’affiche sur l’écran de votre client. Pour vérifier que la connexion entre le client et le serveur fonctionne correctement, j’ai mis en place un indicateur en bas à gauche de l’écran:

Ce dernier passe change en cas de problème de connexion:

Et Windows ?

Comme je l’ai noté en introduction, la version server de Glances fonctionne sous Windows (moyennant l’installation de Python et de PsUtil). Je dois avouer que je n’ai pas testé à fond la compatibilité de Glances sur cet OS. Au démarrage, Glances vérifie si il est lancé sur une plate-forme Windows. Si c’est le cas, il se lancera automatiquement en mode serveur (sans avoir à mettre le flag -s).

Je suis preneur de tout retour sur le sujet et si une âme généreuse veut bien s’occuper de maintenir un binaire « all inclusive » pour Windows 32 bits et 64 bits, cela serait vraiment bien ! (c’est assez facile à faire avec outil comme PyInstaller).

Étiquettes glances

Nagios Open-source Planet-libre Systeme

Installation pas à pas d’un serveur de supervision Shinken

Auteur de l’article Par nicolargo
Date de l’article 06/11/2012
54 commentaires sur Installation pas à pas d’un serveur de supervision Shinken

Nous allons aborder l’installation et la configuration basique initiale d’un serveur de supervision basé sur Shinken. Ce billet est le premier d’une série sur le sujet. Dans la suite j’utiliserai une machine virtuelle sous Debian Squeeze 6.0.6 (version minimale) pour illustrer mes dires…

Installation de Shinken

Les commandes sont à saisir à partir du compte root ou en les précédants de la commande ‘sudo’ si celle-ci est installée.

apt-get install curl
curl -L http://install.shinken-monitoring.org | /bin/bash

Attendre quelques minutes…

Lors du premier re-démarrage, je suis tombé sur l’erreur suivante (/tmp/bad_start_for_arbiter):

[1351082314] Error :   Opening the log file 'arbiterd.log' failed with '[Errno 13] Permission denied: u'/usr/local/shinken/var/arbiterd.log''

Pour la résoudre ce problème de droit, j’ai effectué les actions suivantes:

service shinken stop
chown -R shinken:shinken /usr/local/shinken
service shinken start

L’installation se fait dans le répertoire /usr/local/shinken. Pour identifier les éventuels problèmes que vous pouvez rencontrer lors de l’installation, vous pouvez consulter le fichier de log /tmp/shinken.install.log.

Configuration initiale de Shinken

Les fichiers de configuration se trouvent dans le répertoire /usr/local/shinken/etc/.

Avant de commencer à jouer avec cette configuration, il est important d’avoir une connaissance générale de l’architecture de Shinken. Je vous conseille donc la lecture de cette page sur le wiki officiel.

La première chose à faire et de sécuriser l’accès à l’interface WebUI installé par défaut. Pour cela, il faut éditer la section module / WebUI du fichier shinken-specific.cfg en ajoutant le module Mongodb et en changeant le mot de passe auth_secret:

define module {
  module_name WebUI
  module_type webui

  host 0.0.0.0
  port 7767
  auth_secret MOTDEPASSE

  modules Apache_passwd,ActiveDir_UI,Cfg_password,PNP_UI,Mongodb

  manage_acl 1
  play_sound 0
  allow_html_output 0
  max_output_length 100
}

Puis en éditant le mot de passe du compte admin (par défaut: admin) dans le fichier contacts.cfg:

define contact{
    use             generic-contact
    contact_name    admin
    email           votre@mail.com ; adresse mail
    pager           0600000000   ; telephone
    password        motdepasseadmin ; mot de passe
    is_admin        1
}

Comme vous pouvez le voir c’est également dans cette section que vous pouvez changer l’adresse IP (par défaut en écoute sur toute les adresses IP des interfaces) et le port découte (par défaut TCP/7767) de l’interface WebUI.

On peut ensuite relancer Shinken pour prendre en compte la modification:

service shinken restart

Il ne reste plus qu’à acceder à la l’interface Shinken WebUI en saisissant l’URL suivante dans votre navigateur (en remplacant @IP par l’adresse IP de votre serveur): http//@IP:7767/

Lors de mon installation (sur une VM), je ne disposais que de 3 Go de libre sur le montage /var. La configuration par défaut de MongoDB, qui est la base de donnée utilisé par la WebUI pour stocker les informations utilisateurs, à besoin d’un fichier journal de plus de 3 Go. J’avais donc le message suivant au niveau de l’interface:

Et le log suivant dans le fichier /var/log/mongodb/mongodb.log:

Wed Oct 24 16:02:26 [initandlisten] ERROR: Insufficient free space for journal files
Wed Oct 24 16:02:26 [initandlisten] Please make at least 3379MB available in /var/lib/mongodb/journal or use --smallfiles
Wed Oct 24 16:02:26 [initandlisten]
Wed Oct 24 16:02:26 [initandlisten] exception in initAndListen: 15926 Insufficient free space for journals, terminating
Wed Oct 24 16:02:26 dbexit:

Pour forcer MongoDB a être moins gourmand, j’ai changer sa configuration dans le fichier /etc/mongodb.conf:

smallfiles = true

Puis on relance MongoDB:

service mongodb restart

A ce stade vous devriez avoir une interface WebUI fonctionnelle mais désespérément vide (mis à part votre serveur de supervision)…

Il est donc temps de passer à la prochaine étape.

Superviser votre système d’information avec Shinken

Selon la taille de votre réseau, la tache qui consiste à entrer les machines à superviser dans la configuration de Shinken peut s’averer pour le moins lourde. Heureusement, Shinken fournit un outil permettant de découvrir automatiquement les machines présente sur votre réseau (j’en avais déjà parlé dans ce billet) et même sur votre serveur de virtualisation VMWare (via vCenter).

Cet outil se base sur:

nmap pour la découverte sur le réseau
un plugin nommé check_esx pour découvrir les machines sur un serveur VMWare vCenter

On commence donc par installer ces deux pré-requis sur notre serveur de supervision:

apt-get install nmap
/usr/local/shinken/install -p check_esx3

Si vous avez un serveur VMWare vCenter, vous pouvez vérifier le bon fonctionnement du plugin check_esx3 en le lancant en ligne de commande:

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l cpu
CHECK_ESX3.PL OK - cpu usage=376.00 MHz (0.59%) | cpu_usagemhz=376.00Mhz;; cpu_usage=0.59%;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l mem
CHECK_ESX3.PL OK - mem usage=30413.32 MB (23.20%), overhead=652.43 MB, swapped=0.00 MB, memctl=0.00 MB | mem_usagemb=30413.32MB;; mem_usage=23.20%;; mem_overhead=652.43MB;; mem_swap=0.00MB;; mem_memctl=0.00MB;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l net
CHECK_ESX3.PL OK - net receive=2.00 KBps, send=1.00 KBps, all 2 NICs are connected | net_receive=2.00KBps;; net_send=1.00KBps;; OK_NICs=2;; Bad_NICs=0;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l vmfs
CHECK_ESX3.PL OK - Storages : 'datastore1'(free)=279348.00 MB (99.65%), 'datastore2'(free)=548125.00 MB (57.51%) | datastore1=279348.00MB;; datastore2=548125.00MB;;

rm /tmp/cwpss_*

Il faut ensuite donner à Shinken les informations sur les réseaux (et serveurs vCenters) ou le logiciel de découverte doit être lancé. Pour cela, il faut éditer le fichier /usr/local/shinken/etc/resource.cfg (section Discovery):

#-- Discovery
# default snmp community
$SNMPCOMMUNITYREAD$=public
# what to discover by default
$NMAPTARGETS$=192.168.1.0/24
# If your scans are too slow, try to increase minrate (number of packet in parallel
# and reduce the number of retries.
$NMAPMINRATE$=1000
$NMAPMAXRETRIES$=0
# VMWare vCenter
$VCENTER$=vcenter.mondomaine.com
$VCENTERLOGIN$=LOGINVCENTER
$VCENTERPASSWORD$=MOTDEPASSEVCENTER

Il est bien sur possible d’ajouter des réseaux ou de machines à la variable $NMAPTARGETS$ en séparant chaque entrée par un espace.

On peut lancer shinken-discovery qui va effectuer la découverte automatique:

/usr/local/shinken/bin/shinken-discovery -c /usr/local/shinken/etc/discovery.cfg -o /usr/local/shinken/etc/objects/discovery/ -r nmap,vsphere

shinken-discovery va générer la configuration des machines découvertes dans le répertoire /usr/local/shinken/etc/objects/discovery/ (configurable dans la commande ci-dessus avec l’option -o).

On relance Shinken pour intégrer les machines ainsi découvertes:

service shinken restart

En allant dans l’interface graphique, vous allez sûrement rencontrer des erreurs de check car tous les plugins ne sont pas installés par défaut. Par exemple :

... BigProcesses CRITICAL3m 10s /bin/sh: /usr/local/shinken/libexec/check_wmi_plus.pl: not found ...

Il faut donc utiliser le script d’installation pour installer les plugins manquant.

Sur ma configuration j’ai ainsi fait:

/usr/local/shinken/install -p check_mysql_health
/usr/local/shinken/install -p manubulon
/usr/local/shinken/install -p check_snmp_bandwidth
/usr/local/shinken/install -p check_netint
/usr/local/shinken/install -p check_nwc_health
/usr/local/shinken/install -p check_wmi_plus

Il faut procéder ainsi jusqu’à avoir installé tous les plugins manquants nécessaires. Pour avoir une liste exhaustive des plugins dont l’installation est supporté par le script Shinken install, il suffit de saisir la commande suivante:

/usr/local/shinken/install -h
...
    -p | --plugin           Install plugins. Argument should be one of the following:
                               check_esx3
                               nagios-plugins
                               check_oracle_health
                               check_mysql_health
                               capture_plugin
                               check_wmi_plus
                               check_mongodb
                               check_emc_clariion
                               check_nwc_health
                               manubulon (snmp plugins)
                               check_hpasm
                               check_netapp2
                               check_mem (local enhanced memory check plugin)
                               check_snmp_bandwidth (check bandwidth usage with snmp)
                               check_netint (enhanced version of check_snmp_int plugins)
                               check_IBM
                               check_IBM_DS
                               check_rsync
...

La découverte automatique est vraiment un plus mais ce n’est pas le Saint Grall. En effet pour configurer finement ce que l’on veut suppervier, il faudra obligatoirement reprendre la configuration à la main en éditant les fichiers se trouvant dans le répertoire /usr/local/shinken/etc/objects/discovery. De plus, la notion de groupe étant plus une problématique fonctionnelle que technique, il vous faudra configurer ces derniers manuellement à partir du fichier /usr/local/shinken/etc/hostgroups.com.

Un exemple de configuration de groupe:

define hostgroup{
   hostgroup_name VirtualisationServers
   alias Virtualisation Servers
   members vcenter, virt1, virt2, virt3, virt4
}

Attention à bien sauvegarder ce répertoire avant de relancer un shinken-discovery, histoire de ne pas perdre vos modifications.

Reste ensuite la phase la plus longue mais également la plus importante de la configuration de Shinken: ne surveiller que les choses importantes pour votre système d’information.

En effet, le mode de découverte automatique n’est pas assez fin pour déterminer par lui même ce qu’il faut superviser. La CPU du PC de la secrétaire monte régulièrement au dessus de 90% d’utilisation ? What else… Par contre si on constate la même consommation CPU sur le serveur Web de votre entreprise, il faut aller y jeter un coup d’oeil…

Le plus simple pour effectuer cette lourde tache est de manipuler la WebUI (voir le chapitre suivant), puis de parcourir l’ensemble des hosts et des services en supprimant ce que l’on juge peu important.

Prise en main de Shinken WebUI

A ce stade, vous devriez avoir un serveur de supervision qui commence à remonter un certain nombres d’informations dans l’interface WebUI.

Je vous encourage ensuite à vous familiariser avec cette nouvelle interface WebUI qui peut être un peu déroutante pour les personnes habituées à manipuler d’autres solutions de supervision. A ce sujet, il est également possible d’utiliser des interfaces alternatives comme Thruk qui se rapproche plus de l’interface native de Nagios.

Personnellement, je trouve qu’une fois la première impression passée (c’est quoi ces gros icônes ? Ou sont mes hosts !). La modularité apportée par le Dasboard, les filtres et les bookmarks permet d’adapter cette interface à vos besoins. Si les développeurs de Shinken lisent cet article (et je suis sûr qu’ils vont le faire, coucou @naparuba :)), il serait bon près configurer le Dashboard par défaut et quelques filtres bien pensées histoire que les nouveaux utilisateurs ne se trouvent pas devant des pages blanches.

On peut également se créer des filtres personnels (par exemple toutes les machines appartenant au groupe « serveur » ou tout les services remontant la charge des machines…) et créer des bookmarks dans la page All de la WebUI.

Et après ?

Nous arrivons au terme de ce premier article sur une configuration pas à pas de Shinken. Au prochain épisode, nous allons nous pencher sur la notion d’impacts/dépendances et de business rules qui sont de grosses valeurs ajoutées de Shinken par rapport à Nagios.

Étiquettes shinken

Open-source Planet-libre Systeme

Bêta test de Glances 1.5

Auteur de l’article Par nicolargo
Date de l’article 02/11/2012
13 commentaires sur Bêta test de Glances 1.5

Je viens de figer en bêta la version 1.5 de Glances, mon outil de supervision système. J’ai donc besoin de vous pour tester cette nouvelle mouture (oui je sais, c’est moche de vous faire bosser un week-end).

Glances 1.5 est une évolution majeure car elle apporte une fonction qui était demandée depuis pas mal de temps par les utilisateur. Cette fonction est le mode client/serveur qui permet de surveiller à distance une machine (ou le serveur Glances en lancé) depuis une autre (Glances fonctionnera sur cette dernière en mode client).

Le principal avantage de cette fonction est d’éviter d’avoir à se connecter sur les machines à surveiller. On lance Glances server une fois pour tout et on peut ensuite se connecter à partir de n’importe qu’elle autre machine. Un autre avantage est le fait d’ouvrir Glances à la supervision des machines sous Windows. En effet, il est possible de lancer Glances serveur sur une machine Windows et de surveiller la majorité des informations systèmes (presque toutes…) à partir d’une machine Linux, Mac ou BSD.

Il y a bien sûr d’autres nouveautés à consulter ici.

Comment installer cette version bêta ?

Le plus simple pour ne pas casser son Glances déjà installé est de se faire une installation à la main:

mkdir -p ~/tmp/glances
cd ~/tmp/glances
rm -f ./glances.py
wget https://raw.github.com/nicolargo/glances/master/glances/glances.py
chmod a+x ./glances.py

Attention, Glances 1.5 nécessite une version 0.4 ou supérieure de la librairie PsUtil pour fonctionner.

Vous pouvez installer la dernière version de PsUtil en utilisant Pip:

pip install psutil

Comment tester cette version bêta ?

On lancera ensuite Glances avec la commande:

~/tmp/glances/glances.py

Merci de tester le maximum de chose (redimensionnement du terminal, test des fonctions: cliquez sur ‘h’ pour avoir la liste complète).

Pour le mode client serveur, la syntaxe est assez simple.

Sur le serveur:

~/tmp/glances/glances.py -s

Note: par défaut le serveur va se mettre en écoute sur le port TCP/61209 (à ouvrir si vous avez un Firewall) et sur toutes les interface de votre machine. Il est possible de configurer le port avec l’option (-p PORT) et l’adresse de binding avec l’option (-B @BIND).

Le serveur Glances est compatible XML/RPC… donc potentiellement accessible depuis des applications tierces 🙂

Sur le client:

~/tmp/glances/glances.py -c @server

Il faut donc fournir l’adresse IP ou le nom d’hôte public de la machine serveur à superviser.

Note: par défaut le client va se connecter en utilisant le port TCP/61209. Il est possible de configurer le port avec l’option (-p PORT).

Comment me remonter les erreurs / problèmes de cette version bêta ?

Le mieux pour moi est que vous utilisez GitHub en créant un bug avec une description précise du problème rencontré. Si vous avez un compte GitHub, il suffit de remplir le formulaire.

Sinon, vous pouvez laisser un commentaire directement sur le blog !

D’avance merci à vous 🙂

Étiquettes beta, glances

Open-source Planet-libre Reseau Systeme

De Network Manager à une configuration manuelle

Auteur de l’article Par nicolargo
Date de l’article 17/10/2012
15 commentaires sur De Network Manager à une configuration manuelle

S’il y a bien une fonction que je trouve mal faite dans Gnome c’est le « Network Manager ». Ce logiciel, accessible depuis la barre de menu, permet de configurer, à partir d’une interface graphique, les interfaces réseaux de sa machine. Ce n’est pas la première fois que je tombe sur une configuration que je n’arrive pas à appliquer en utilisant ce logiciel. Il faut dire que celle-ci mélange plusieurs interfaces réseaux avec des configurations DHCP, statiques et des routes spécifiques. J’ai donc décidé de désactiver Network Manager et de configurer mon réseau à la mimine.

Avant de pouvoir configurer manuellement son réseau à partir du fichier /etc/network/interfaces, il faut préalablement désactiver la gestion des interfaces par Network Manager. Nous allons voir comment procéder sur une distribution GNU/Linux Ubuntu 12.04.

Préparation de la manipulation

Avant toute chose, il faut arrêter toutes vos applications. En effet, nous allons toucher à la couche réseau du noyau Linux et il y a de forte chance que vous perdiez la connectivité. Il est bien sûr totalement impossible de faire cette manip à distance (via SSH ou remote desktop).

Pour pouvoir revenir en arrière, nous allons sauvegarder la configuration de Network Manager:

sudo cp /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/NetworkManager.conf.OLD

Désactivation de Network Manager

On commence par éditer le fichier /etc/NetworkManager/NetworkManager.conf:

sudo vi /etc/NetworkManager/NetworkManager.conf

Puis passer la clé de configuration managed à true:

[ifupdown]
managed=true

Configuration manuelle des interfaces réseau

On passe ensuite à la configuration manuelle des interfaces réseau de notre machine en éditant le fichier /etc/network/interfaces. Le contenu du fichier dépend bien sûr de votre besoin. J’avais écris un billet sur le sujet il y a quelques années. Mais le mieux est de lire la documentation officielle et complète sur le site de Debian.

Il ne reste ensuite plus qu’à relancer le démon networking pour appliquer les changements et faire chauffer le semiconducteur de la carte mère:

sudo service networking restart

Bye bye Network Manager et son horrible interface graphique ! Bienvenu au fichier interfaces et sa syntaxe simple et claire.

Revenir en arrière ?

En cas de problème, pour revenir à votre configuration initiale ou les interfaces sont gérées par Network Manager, il suffit de saisir les commandes suivantes:

sudo cp /etc/NetworkManager/NetworkManager.conf.OLD /etc/NetworkManager/NetworkManager.conf
sudo service networking restart

Et hop, retour à la case départ.

Étiquettes manual, network manager

Open-source Planet-libre Systeme

Il n’y a pas qu’Ubuntu dans la vie…

Auteur de l’article Par nicolargo
Date de l’article 14/10/2012
26 commentaires sur Il n’y a pas qu’Ubuntu dans la vie…

En mettant de côté le monde des serveurs et des smartphones, les systèmes GNU/Linux représentent plus ou moins 1 % des parts de marché sur les PC clients. Si ce chiffre peut paraître ridicule par rapport au nombre de machines sous Windows, il l’est encore plus quand on regarde les parts des systèmes GNU/Linux autres qu’Ubuntu.

Pourtant, en ne donnant pas une chance à ces distributions exotiques, vous pourriez passer à côté d’un système adapté à votre configuration. Le fond du problème est là. La cible de Canonical (l’éditeur d’Ubuntu) est la même que Microsoft : des PC costauds, avec des cartes graphiques supportant l’accélération 3D et une mémoire confortable pour faire tourner vos applications en même temps que l’environnement graphique système (Gnome3 ou KDE).

Hors, tout le monde n’a pas les moyens ou tout simplement l’envie de dépenser plus de 700€ pour avoir un PC bureautique performant. C’est pourtant sur ce créneau spécifique des PC « low cost » que ces distributions apportent toute leur valeur ajoutée. En effet, elle sont pour la plupart basée sur des interfaces graphiques moins consommatrice de ressources hardware. Je pense notamment à LXDE et XFCE porté par Canonical sur les distributions dérivées Lubuntu et Xubuntu mais aussi à OpenBox comme dans le très bon CrunchBang Linux que j’ai testé sur un boîtier « Linutop 4 » dans un dernier article. Le choix de l’interface graphique n’est pas le seul avantage de ces distributions. Elles sélectionnent également les applications proposées en standard aux utilisateurs, en préférant par exemple Midori ou Chromium à la place de Firefox.

Les plus barbus d’entre vous vont me retourner qu’il est tout à fait possible de prendre n’importe quelle distribution GNU/Linux (si possible la plus proche de la philosophie libre) et d’y installer à la main l’interface graphique et les applications de son choix. Cependant, cette démarche est justement réservée aux barbus et pas à Monsieur Lambda que l’on souhaite faire venir du bon côté de la force.

Alors que pouvons-nous faire ? Nous, défenseurs des logiciels libres. Pourquoi pas en donnant sa chance à une distribution alternative, en sortant un peu des pistes que l’on connait si bien (ne vous inquiétez pas, vous ne serez pas perdu bien longtemps). En choisissant tout simplement un système en adéquation avec nos besoins et le matériel associé. En ne refaisant pas les mêmes erreurs qui ont conduit et conduisent encore des utilisateurs vers des OS propriétaires et fermés.

Étiquettes alternative, linux, ubuntu