Catégories
Open-source

Actualité open-source de la semaine #37

L’actualité open-source de la semaine…

L’image de la semaine

dlgoog113.jpg
Google G1… c’est pas encore comme un iPhone mais c’est libre !

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

  • Google donne sa liberté à Android: quelques jours avant la commercialisation du premier « google-phone », Google rend le système d’exploitation Android open-source.
  • Open-source = matcho ? Seulement 2% de femmes dans les projets de développement open-source…
  • OO 3.0 dans Ubuntu 8.10 ? C’est pas si sûr….

Autres choses ?

Catégories
Open-source Reseau Systeme

Durées et fréquences des checks Nagios

nagios_logo.pngPour surveiller votre réseau, Nagios utilise un certain nombre d’objets (machines, services, contacts…). Par défaut, un objet hérite une grande partie de ses paramètres du template nommé « generic-* ». Nous allons dans ce billet nous focaliser sur les notions de temps et de fréquences de ces objets.

Pour rappel, à un instant t, un objet peut avoir un des les états suivants:

  • OK: tout va bien, votre objet fonctionne correctement
  • WARNING: votre objet ne fonctionne pas nominalement
  • CRITICAL: votre objet ne fonctionne plus
  • UNKNOWN: impossible de déterminer l’état de votre objet

Un exemple: imaginons un service qui surveille la débit de votre liaison Internet…

  • OK: le débit est inférieure à 70% de la bande passante totale
  • WARNING: la débit est supérieure à 70% de la bande passante totale
  • CRITICAL: la liaison Internet est DOWN (plus de connectivité avec Internet)
  • UNKNOWN: impossible de récupérer les valeurs du débit

Définition de la période d’activité d’un objet

La variable check_period permet de définir l’intervalle de temps durant lequel l’objet est actif. On définie une période de temps en utilisant la structure timeperiod.

Par exemple pour définir une période de temps correspondant aux heures ouvrées de votre entreprise vous pouvez utiliser la définition suivante:

define timeperiod {

timeperiod_name workhours

alias Heures ouvrées

monday 09:00-18:00 ; Lundi

tuesday 09:00-18:00; Mardi

wednesday 09:00-18:00; Mercredi

thursday 09:00-18:00; Jeudi

Friday 09:00-18:00; Vendredi

}

La déclaration de cette période de temps dans notre objet (par exemple un service) se fera ainsi:

define service {

check_period workhours

}

Définition des intervalles de vérification d’un objet

Quand on se trouve dans une période d’activité d’un service, plusieurs paramètres rentrent en jeu pour fixer la durée et la fréquence des vérifications (checks) du objet en question.

Quand un objet est OK, il est vérifié toutes les check_interval minutes. Si il passe WARNING, CRITICAL ou UNKNOWN, il est alors vérifié max_check_attempts fois à un intervalle de retry_interval minutes. Si l’état de l’objet n’est pas revenu à OK au bout des max_check_attempts essais, l’intervalle de vérification redevient de check_interval minutes…

Je sais ce n’est pas très simple mais ce schéma devrait vous aider à comprendre.

nagios-check.jpg
Un exemple de paramètrage avec un valeur de check_interval (quand tout va bien) à 10 minutes puis un retry_interval (quand cela commence à aller mal) à 2 minutes et un nombre de max_check_attempts à 3:

define service {

check_interval 10

retry_interval 2

max_check_attempts 3

}

Et les notifications ?

Il existe des variables permettant de fixer comment les notifications sont remontés aux administrateurs.

La première variable est first_notification_delay. Elle permet de définir le temps (en secondes) que Nagios doit attendre avant d’envoyer une notification quand un objet passe d’un état OK à un état WARNING, CRITICAL ou UNKNOWN. Une valeur de 0 permet d’envoyer la notification dès ce changement d’état.

La variable notification_interval permet, en cas de problème sur un objet, de fixer l’intervalle de temps (en minutes) entre deux notifications. Pour que Nagios n’envoie qu’une seule fois une alerte, il faut fixer cette variable à 0.

Par exemple, pour que la première notification se fasse immédiatement, sans répétition, un objet doit être défini ainsi:

define service {

first_notification_delay 0

notification_interval 0

}

Conclusion

Comme on vient de le voir il est relativement facile de configurer finement les fréquences et durées de vérifications en fonction de l’importance des objets à surveiller.

Catégories
Open-source Reseau Systeme

Enfin un livre de référence sur Nagios en Français

Il n’y a qu’à voir les demandes des lecteurs de ce blog concernant Nagios et les outils de supervision open-source pour comprendre qu’il y a manifestement un manque de documentations en Français sur le sujet. Heureusement, quelques bons samaritains prennent les choses en main.

Ainsi, en plus de se lancer dans la traduction de la documentation officielle et de maintenir le portail Nagios-fr, Olivier va publier dans les prochains jours un livre nommé « Nagios et la supervision Open Source ».

ojan-nagios.png

« NAGIOS et la supervision Open Source – De l’installation à l’optimisation » (Olivier JAN)

Ce bouquin a de forte chance de devenir le livre de chevet des administrateurs réseaux. Vous pouvez dès à présent en commander un exemplaire (livraison prévue mi-novembre 2008).

Catégories
Open-source Systeme

Installation d’un serveur NTP

A partir du moment ou votre réseau est composé de plusieurs machines, il est utile d’avoir une base de temps commune. Heureusement, il existe un protocole (NTP) permettant de fixer la même heure sur l’ensemble des machines.

Installation d’un serveur de temps

Nous utiliserons le serveur de temps libre NTPd disponible sous GNU/Linux et BSD.

La configuration est centralisé dans un seul fichier /etc/ntp.conf:

server 0.fr.pool.ntp.org

server 1.fr.pool.ntp.org

server 2.fr.pool.ntp.org

server 3.fr.pool.ntp.org

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

logfile /var/log/ntp.log

driftfile /var/db/ntp.drift

On lance alors le serveur avec la commande:

ntpd -g -p /var/run/ntpd.pid -c /etc/ntp.conf

Tout comme le protocole DNS, NTP travaille avec des serveurs hiérarchisés. Les serveurs racines sont retournés par les alias x.fr.pool.ntp.org

La commande restrict permet de limité l’accès au serveur au seul réseau 192.168.1.0/24 (il est possible d’avoir plusieurs lignes restrict).

Avant de tester votre serveur de temps, il faut attendre que ce dernier se synchronise avec ses pères (au moins 30 minutes).

Configuration d’un client

La plupart des OS récents inclus la prise en charge de la partie cliente NTP. Lors de la configuration, il vous siffira de saisir l’adresse IP (ou le nom DNS) du serveur sur lequel est installé NTPd.

Vous avez aussi un moyen simple de tester votre serveur en ligne de commande (par exemple sous GNU/Linux Ubuntu):

sudo ntpdate -dv -b 192.168.29.108

Si votre serveur fonctionne normalement, vous devriez avoir le message suivant:

17 Oct 16:20:21 ntpdate[6570]: step time server 192.168.29.108 offset -6.080239 sec

Si vous avez l’erreur suivante:

17 Oct 16:09:52 ntpdate[6244]: no server suitable for synchronization found

Il y a de forte chance que votre serveur ne soit pas encore prêt à répondre aux clients (attendre environ 30 minutes). Si l’erreur persiste, vous pouvez lancez la commande suivante sur votre serveur afin de voir l’état de la synchrnonisation:

# ntpq -cpe

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+goelette.net    145.238.203.14   2 u  254  512   37   22.615  -62.193   2.902
*ntp2.cines.fr   195.83.180.3     2 u   62   64  377   12.394   -0.253   4.034
+ntp.dr-j.eu     194.2.0.28       3 u  246  512   37   23.764    1.954   3.927
+ns2.kamino.fr   193.52.184.106   2 u   59   64  377   23.397   -1.449   4.540

Il ne vous reste plus qu’a passer sur toutes vos machines pour votre « tout nouveau, tout beau » serveur NTP.

Catégories
Open-source

Séminaire « open-source et l’entreprise performante »

Smile est un des sponsors de votre blog préféré (comment ça lequel…). En plus de proposer des whites papers gratuitement sur son site, il vous invite à un séminaire intitulé: « l’open source et l’entreprise performante ».

Ce séminaire vous permettra de connaître les origines et la philosophie de l’open source, les licences, les business models, les principes de support et les modèles de développement.
Mais surtout, il vous permettra d’apprécier les bénéfices de solutions open source dans le contexte des entreprises, bénéfices qui vont bien au delà des économies.

  • Quelles sont les implications des licences open source pour l’entreprise ?
  • Comment obtenir du support sur des composants open source communautaires ?
  • De quoi vivent les développements open source ?
  • Quel est le coût total de possession (TCO) d’une solution open source ?
  • Comment évaluer la pérennité d’un produit ?
  • Quels sont les meilleurs produits de l’open source dans chacun des grands domaines ?
  • Quelles opportunités offre le monde de l’open source pour l’ingénieur ?

Exceptionnellement, ce séminaire se tiendra en fin de journée, le jeudi 23 octobre, de 18h à 20h à Paris – Saint-Lazare.

Vous pouvez donc profiter d’une bonne journée de travail, avant d’apprendre à connaître le monde de l’open source et ses gammes de solutions, et d’apprendre à connaître Smile par la même occasion! A l’issue des présentations, un cocktail vous sera offert, et vous pourrez discuter librement avec les experts et les managers de Smile.

Vous pouvez vous inscrire ici.

Catégories
Open-source Reseau

Mise à jour de Nagios 3.0.4

La nouvelle version de Nagios (3.0.4) est en ligne. La liste des changements est disponible içi. Comme toujours, il est fortement conseillé de mettre à jour vos serveurs. Pour celà vous pouvez suivre une de ces procédures:

Je viens de tester la migration d’une version 3.0.3 vers 3.0.4 sans problème:

A vous de jouer !

Catégories
Open-source

Actualité open-source de la semaine #36

L’actualité open-source de la semaine…

L’image de la semaine

Image 1.jpg
OpenOffice victime de son succès…
Les serveurs n’ont pas tenu la charge 🙂

Tout le monde en parle, sauf moi…

L’actualité du libre et de l’open source en vrac:

Autres choses ?

Catégories
Open-source Reseau Systeme

Supervision d’Asterisk avec Nagios

Les plugins pour surveiller son serveur SIP Asterisk à partir de Nagios sont assez nombreux. Mais aucun d’eux ne me convenait parfaitement. J’ai donc écrit un petit script nommé Nagisk (quel humour…) a exécuter localement sur le serveur Asterisk. J’utilise NRPE pour récupérer la sortie de ce script et l’intégrer à Nagios.

Nagisk permet de:

  • récupérer la version d’Asterisk (et donc au passage de savoir si le serveur est lancé…)
  • récupérer le nombre de d’utilisateurs SIP (online et offline)
  • récupérer le nombre de communications actives (appels en cours)

Récupération de Nagisk

J’ai créé un nouveau projet sous GitHUB ou vous pouvez télécharger la dernière version disponible de Nagisk.

Installation de Nagisk

Avant d’installer Nagisk sur votre serveur Asterisk, il faut d’abord y installer NRPE (par exemple en suivant ce tuto).

On commence par décompresser l’archive préalablement récupérée:

tar zxvf nagisk-1.2.tgz

Puis on copie le script Perl dans le répertoire des plugins Nagios:

cd nagisk

cp nagisk.pl /usr/local/nagios/libexec

On lui donne les bons droits:

chown nagios:nagios /usr/local/nagios/libexec/nagisk.pl

chmod 750 /usr/local/nagios/libexec/nagisk.pl

Certaines variables sont en durs dans le code (rien de méchant, juste le path pour accèder à Asterisk). J’utilise personnellement la commande sudo pour executé les commandes sur Asterisk afin que le script soit lancé par l’utilisateur nagios. Pour celà j’ai ajouté la ligne suivante dans le fichier /etc/sudoers:

nagios    ALL= NOPASSWD: /usr/sbin/asterisk

Configuration de NRPE pour lancer Nagisk

Il suffit d’ajouter les lignes suivantes dans le fichier de configuration de NRPE (/usr/local/nagios/etc/nrpe.conf):

command[check_asterisk_version]=/usr/local/nagios/libexec/nagisk.pl -c version

command[check_asterisk_peers]=/usr/local/nagios/libexec/nagisk.pl -c peers

command[check_asterisk_channels]=/usr/local/nagios/libexec/nagisk.pl -c channels

command[check_asterisk_zaptel]=/usr/local/nagios/libexec/nagisk.pl -c zaptel

command[check_asterisk_span]=/usr/local/nagios/libexec/nagisk.pl -c span -s 1

ps: il est possible de faire plus propre en utilisant les arguments NRPE mais je trouve cette solution plus lisible…

Une fois le fichier mofifié, il faut relancer NRPE:

/etc/init.d/nrpe restart

Configuration de Nagios pour surveiller son serveur Asterisk

Si vous souhaitez superviser un serveur SIP Asterisk dont le host_name est sip, il suffit d’ajouter les lignes suivantes dans un de vos fichiers de configurations:

define service{
use                     generic-service
host_name               sip
service_description     Check SIP
servicegroups           sip
check_command           check_nrpe!check_asterisk_version
}

define service{
use                     generic-service
host_name               sip
service_description     Check SIP peers
servicegroups           sip
check_command           check_nrpe!check_asterisk_peers
}

define service{
use                     generic-service
host_name               sip
service_description     Check SIP channels
servicegroups           sip
check_command           check_nrpe!check_asterisk_channels
}

define service{
use                     generic-service
host_name               sip
service_description     Check Zaptel card
servicegroups           sip
check_command           check_nrpe!check_asterisk_zaptel
}

define service{
use                     generic-service
host_name               sip
service_description     Check Zaptel Span 1
servicegroups           sip
check_command           check_nrpe!check_asterisk_span
}

Et voilà le résultat:

Conclusion

Nagisk semble remplir sa fonction, le script tourne depuis quelques temps chez moi sans problème. Il est distribué sous licence libre GPL v3 et il est bien sûr possible de le modifier pour l’adapter à vos besoins.

Catégories
Open-source Reseau Systeme

Installation de NRPE depuis les sources

Afin de disposer de la dernière version de NRPE (le plugin pour superviser vos serveurs GNU/Linux, BSD ou Mac OS X sous Nagios), il est parfois nécessaire de la compiler depuis les sources. Voici donc une simple procédure pour installer NRPE 2 et les plugins Nagios « standards » sous une distribution GNU/Linux.

Récupération des sources

Nous partons, bien sûr, sur l’hypothèse ou votre machine cible (c’est à dire celle ou vous aller compiler NRPE) dispose des logiciels de développement de base (configure, make, gcc…).

Si votre machine dispose d’un accès internet, vous pouvez saisir les commandes suivantes (en remplacent les numéros de versions par les dernières disponibles):

wget http://surfnet.dl.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

wget http://heanet.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz

Préalablement à l’installation de NRPE, il faut créer un utilisateur ‘nagios’ sur votre machine:

adduser nagios

Pour des raisons de sécurité, il est préférable que cet utilisateur n’ait pas de shell:

vipw

Remplacer la ligne:

nagios:x:500:500::/home/nagios:/bin/bash

Par:

nagios:x:500:500::/home/nagios:/bin/noshell

Installation de NRPE

On lance la fameuse séquence:

tar zxvf nrpe-2.12.tar.gz

cd nrpe-2.12

./configure

make all

make install

Lors de la compilation il est possible qu’il manque des dépendances. Par exemple, si vous avez le message suivant:

checking for SSL headers… configure: error: Cannot find ssl headers

Il faut installer les librairies SSL (libssl-dev sous Ubuntu):

apt-get install libssl-dev

Installation des plugins Nagios standards

Pareil que miguel…:

tar zxvf nagios-plugins-1.4.13.tar.gz

cd nagios-plugins-1.4.13

./configure

make install

Puis une initialisation du script de configuration (/usr/local/nagios/etc/nrpe.conf):

mkdir /usr/local/nagios/etc

cp sample-config/nrpe.cfg /usr/local/nagios/etc

Correction des droits sur les fichiers

De base, les plugins sont installés avec les droits de l’utilisateur qui à lancé la compilation. Pour être sûr que NRPE puisse lancer les plugins, on doit saisir la commande suivante:

chown -R nagios:nagios /usr/local/nagios/

Lancement automatique au démarrage

Un script standard est fourni dans les sources:

cp init-script /etc/init.d/nrpe

chmod 755 /etc/init.d/nrpe

Configuration de NRPE

Sous GNU/Linux, suivre ce tutoriel, sous BSD et Mac OS X, suivre celui là.

Catégories
Hardware Open-source Systeme

RAID 1 logiciel sous FreeBSD

Certains serveurs de votre réseau sont plus sensibles que d’autres: on peut citer par exemple les serveurs DNS, LDAP ou base de données. D’un autre coté les pannes matérielles survenant sur ces mêmes serveurs viennent souvent des disques durs. En partant de ces deux constats, je vous propose dans ce billet d’utiliser la fonction de RAID 1 logicielle de FreeBSD pour sécuriser ces serveurs.

Petit rappel sur RAID 1

Le RAID 1 consiste à utiliser n disques redondants (n supérieur ou égal à 2). Chaque disque contient la même information.

150px-RAID_1.svg.png

Dans notre exemple, nous allons utiliser une configuration minimale pour du RAID 1: deux disques de taille et de caractéristiques équivalentes.

Préparation de l’installation

Il faut dans un premier temps identifier les disques sur lequel de RAID 1 va être installé. Pour celà la commande dmesg devrait vous aider:

# dmesg

ad4: 76319MB <WDC WD800AAJS-70TDA1 01.00A03> at ata2-master SATA150

ad6: 76319MB <WDC WD800AAJS-70TDA1 01.00A03> at ata3-master SATA150

Nous avons donc deux disques: ad4 et ad6.

Ensuite on regarde ou le système est installé:

# df

/dev/ad4s1a 71621288 1044946 64846640 2% /

FreeBSD est donc installé sur le disque ad4. Nous allons donc nous servir du disque ad6 pour créer le disque mirroir de ad4.

Configuration du RAID 1 sous FreeBSD

Nous allons utiliser l’utilitaire gmirror pour effectuer le « mirroring » de ad4 vers ad6.

La première chose à faire est de vérifier que votre version de FreeBSD supporte cette fonction.

# man gmirror

Si c’est le cas, le manuel de la commande devrait s’afficher.

On commence par préparer le disque « maître » (ad4 dans notre exemple):

# sysctl kern.geom.debugflags=17

# gmirror label -vb round-robin gm0 /dev/ad4

Le résultat de cette dernière commande devrait être:

Metadata value stored on /dev/ad4.

Done.

On charge ensuite le module gmirror dans le kernel.

# gmirror load

Si vous n’avez pas de message d’erreur vous pouvez automatiser le chargement du module au prochain démarrage du serveur en tapant la commande suivante:

# echo ‘geom_mirror_load= »YES »‘ >> /boot/loader.conf

On vient de créer un disque virtuel nommé gm0. Il faut donc remplacer, dans le fichier /etc/fstab, toutes les occurrences /dev/ad4 par /dev/mirror/gm0. Pour cela on utilise vi:

# cp /etc/fstab /etc/fstab.old

# vi /etc/fstab

:%s/ad4/mirror\/gm0/g

On redémarre ensuite le serveur:

# shutdown -r now

Une fois le serveur rebooté, il ne reste plus qu’a ajouter le disque ad6 (notre disque « esclave ») dans le mirroir RAID 1 (gm0).

# gmirror insert gm0 /dev/ad6

Vérification de l’état du RAID 1

On peut utiliser la commande suivante:

# gmirror status

Durant l’initialisation du disque esclave, le résultat devrait ressembler à:

Name Status Components

mirror/gm0 DEGRADED ad4

ad6 (1%)

Ensuite, le message suivant devrait apparaître:

Name Status Components

mirror/gm0 COMPLETE ad4

ad6

Et si un de mes disques plantes ?

Imaginons que le disque primaire (ad4) rende l’âme. Il suffit:

  • éteindre le serveur
  • retirer le disque ad4
  • le remplacer par un disque équivalent
  • redémarrer le serveur
  • Saisir les commande suivantes pour reconstruire le disque:

# gmirror forget gm0

# gmirror insert gm0 /dev/ad4

Il ne reste plus qu’a superviser votre RAID 1 avec votre serveur Nagios !