Catégories
Open-source Planet-libre Reseau Systeme

Migrer de Centreon 2.3.x vers 2.4.0

–===–

Ce billet invité a été rédigé par @xhark du très bon Blogmotion.
Je vous invite à consulter son blog qui fourmille d’information sur les systèmes et réseaux informatique.

–===–

Si comme moi vous aviez suivi le tutoriel d’installation de Centreon, vous devriez être en possession de Centreon 2.3.8. Ce guide a également été testé avec la version 2.3.9.

La version 2.4.0 de Centreon apporte de nombreux changements. Merethis, société éditrice de Centreon, a voulu se passer  NDOutil à cause de sa lourdeur et de son manque d’efficacité sur des parcs d’une grande taille. On découvre alors un nouveau module broker maison « Centreon-broker », plus efficace et modulaire.

Dans mon cas j’ai souhaité préserver NDOutil dans un premier temps et faire une migration classique. Si vous souhaitez plus d’information sur Centreon-Broker vous trouverez des informations sur la documentation et je vous conseille ce guide. Si vous installez Centreon from scratch, ce guide (ou la doc officielle).

Mise à jour de votre système

Si vous utilisez une distribution Debian Like comme Ubuntu, vérifiez que vos paquets sont à jour :

# apt-get update && apt-get upgrade

Passons à la suite.

Mise à jour de Centreon

Avant tout, faites un snapshot si vous utilisez VMWare ou une copie de votre système (image) pour revenir en arrière en cas de pépin. Puis faire une sauvegarde du fichier sudoers :

# cp /etc/sudoers /root/etc-sudoers.bak

Si vous utilisez un serveur proxy pour accéder à internet, c’est le moment de le définir pour PEAR qui risque d’aller chercher des modules absents (c’était mon cas avec Archive_7zip) :

# pear config-set http_proxy "http://proxy:8080"
config-set succeeded

Nous allons commencer par récupérer la dernière version de Centreon sur le site officiel. Pensez à remplacer le lien de téléchargement de Centreon (http://download.centreon.com/index.php?id=4264) ainsi que la version (centreon-2.4.0  au moment de la rédaction de ce billet) par la dernière version disponible.

Toutes les commandes sont effectuées avec le compte root (« su -« ) sur une distribution Ubuntu 12.04.2 LTS 32 bits.

cd /tmp/
wget http://download.centreon.com/centreon/centreon-2.4.0.tar.gz
cd centreon-2.4.0
./install.sh -u /etc/centreon

La trace complète est disponible ici, voyons les étapes importantes :

Do you want to use the last Centreon install parameters ?
[y/n], default to [y]:
> y

Using:  /etc/centreon/instCentCore.conf
/etc/centreon/instCentPlugins.conf
/etc/centreon/instCentStorage.conf
/etc/centreon/instCentWeb.conf

Do you want to install : Centreon Web Front
[y/n], default to [n]:
> y

Do you want to install : Centreon CentCore
[y/n], default to [n]:
> y

Do you want to install : Centreon Nagios Plugins
[y/n], default to [n]:
> y

Do you want to install : Centreon Snmp Traps process
[y/n], default to [n]:
> y

Where is your Centreon binaries directory
default to [/usr/local/centreon/bin]
>

Where is your Centreon data informations directory
default to [/usr/local/centreon/data]
>

Do you want me to create this directory ? [/usr/local/centreon/data]
[y/n], default to [n]:
> y

What is the Centreon group ? [centreon]
default to [centreon]
>

Do you want me to create this group ? [centreon]
[y/n], default to [n]:
> y

What is the Centreon user ? [centreon]
default to [centreon]
>

Do you want me to create this user ? [centreon]
[y/n], default to [n]:
> y

What is the Broker user ? (optional)
>

What is the Monitoring engine log directory ?
> /usr/local/nagios/var 

Where is your monitoring plugins (libexec) directory ?
default to [/usr/lib/nagios/plugins]
> /usr/local/nagios/libexec/

------------------------------------------------------------------------
        Configure Sudo
------------------------------------------------------------------------

What is the Monitoring engine init.d script ?
> /etc/init.d/nagios

Where is the configuration directory for broker module ?
> /usr/local/nagios/etc ou /etc/nagios3

Where is the init script for broker module daemon ?
> /etc/init.d/ndo2db
Your sudo has been configured previously

Do you want me to reconfigure your sudo ? (WARNING)
[y/n], default to [n]:
> y

Do you want to reload your Apache ?
[y/n], default to [n]:
> y

Do you want me to install CentCore init script ?
[y/n], default to [n]:
> y

Do you want me to install CentStorage run level ?
[y/n], default to [n]:
> y

------------------------------------------------------------------------
        Start CentCore Installation
------------------------------------------------------------------------

Do you want me to install CentCore init script ?
[y/n], default to [n]:
> y

Do you want me to install CentCore run level ?
[y/n], default to [n]:
> y

On peut maintenant ce rendre à l’URL suivante pour finaliser la mise à jour par l’interface Web:

http://<adresseIPserveur>/centreon/

REMARQUE: ne pas oublier le / à la fin…

centreon1

centreon3

centreon4

Vérification du fonctionnement

Si vous le pouvez, redémarrez votre serveur pour être sûr que les services démarrent correctement.

Pour vérifier que Centreon fonctionne correctement, exportez la configuration vers Nagios : Configuration > Monitoring Engines (anciennement appelé « nagios »). Cocher (en plus de celles déjà cochées) : Move Export Files et Restart Monitoring Engine.

centreon5

Si comme moi vous obtenez le message d’erreur :

Preparing environment… OK
Generating files… OK
Moving files…NOK

Il s’agit d’un problème de droit, bien que l’erreur ne soit pas très parlante… après de nombreuses prises de tête pas mal de caféine, voici la solution :

# chown www-data:nagios /usr/local/nagios/ -R

centreon6

A titre d’information, voici le contenu de mon fichier /etc/group :

nagios:x:1001:nagios,www-data,centreon
centreon:x:999:www-data,nagios
www-data:x:33:nagios

Vous verrez aussi que la page d’accueil de Centreon a pas mal évolué, avec des widgets mais c’est loin d’être intuitif car il faut tout configurer en dur. Pour l’instant, on s’en passera.

Si vous avez besoin d’aide je vous conseiller de lire ce billet sur l’utilisation de Centreon.

Enfin, je vous conseille d’installer Centreon Entreprise Server (CES) sur un serveur de test, il permet de tester toutes les configurations possibles (avec ou sans broker, NDO, poller standard, central, etc.). Le produit est libre en version Standard et il est basé sur CentOs 5.9 x64, des services supplémentaires payants sont disponibles pour les autres versions.

Catégories
Developpement Open-source Planet-libre Systeme

Package d’installation pour Glances sous Windows

Grâce au travail de Nicolas Bourges, Glances dispose désormais d’un installeur pour sa version Windows. Vous pouvez donc installer Glances 1.6.1 en version 32 ou 64 bits sans avoir à installer les pré-requis (Python, librairie PsUtil…) puisque tout est « packagé » dans le binaire.

On commence par télécharger le programme d’installation:

download
Télécharger Glances 1.6.1 en version 64 bits
(ou en version 32 bits)

MD5sum

glances-1.6.0-x64.exe                         a347ec5097d6d4d5039c7233872757a8

glances-1.6.0-x86.exe                         13d5be664599f80152f8f1ae47400576

Puis on se laisse guider dans le wizard d’installation qui va mettre, par défaut, le binaire Glances.exe dans le répertoire C:\Program Files\Glances puis créer un raccourci sur votre bureau.

En cliquant sur ce raccourci, Glances va se lancer automatiquement en mode serveur. Pour ajouter d’autres paramètres (comme le mot de passe) il suffit de modifier ce raccourci pour y ajouter les options voulues (par exemple -P <motdepasse>).

Il ne vous reste plus qu’à revenir sur un vrai OS (ndlr: Nicolargo, tu me copieras 100 fois « Je ne trollerai plus. ») puis à lancer la commande:

glances -c <addresse IP machine Windows>

glancesonwin7

Et hop, vous pouvez maintenant surveiller vos machines Windows en une ligne de commande !

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
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 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 Systeme

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

Catégories
Nagios Open-source Planet-libre Systeme

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:

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.

Thruk, une alternative à Shinken WebUI

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.