Catégories
Open-source Reseau

Exemple de configuration de Nagios

Ce post fait suite à celui sur l’installation de Nagios sur une machine Linux. Nous allons y décrire les fichiers de configurations nécessaires pour surveiller (« to monitor ») un réseau simple comporant: une machine client, une machine serveur avec un serveur Web et une serveur FTP et une liaison Internet.

Note: les fichiers de configurations données en exemple dans ce post se basent sur la version 2.8 de Nagios.

Sous Fedora Linux, les fichiers de configurations de Nagios se trouvent dans le répertoire /etc/nagios/ (/usr/local/etc/nagios sous BSD). Le fichier nagios.cfg définie l’ensemble des sous fichiers de configurations grâce aux variables cfg_file:


#cfg_file=/etc/nagios/localhost.cfg
cfg_file=/usr/local/etc/nagios/timeperiods.cfg
cfg_file=/usr/local/etc/nagios/contacts.cfg
cfg_file=/usr/local/etc/nagios/contactgroups.cfg
cfg_file=/usr/local/etc/nagios/hosts.cfg
cfg_file=/usr/local/etc/nagios/services.cfg
cfg_file=/usr/local/etc/nagios/hostgroups.cfg

Il faut également configurer le fichier cgi.cfg (en partant de cgi.cfg-sample):

authorized_for_system_information=admin
authorized_for_configuration_information=admin
authorized_for_system_commands=admin
authorized_for_all_services=admin
authorized_for_all_hosts=admin
authorized_for_all_service_commands=admin
authorized_for_all_host_commands=admin

Définition des plages horaires

La première étape consiste à définir les périodes de temps que nous allons pouvoir utiliser dans les autres fichiers de configurations. Pour simplifier, nous allons juste créer la période 24×7 (tout les jours, toutes les heures…). Pour cela, il faut éditer le fichier /usr/local/etc/nagios/timeperiods.cfg:

# Time periods definitions
##########################
# 7d/7 24h/24
define timeperiod {
timeperiod_name 24×7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}

Définition des contacts

Nous allons ensuite définir les contacts. C’est à dire les personnes devant être prevenu par un moyen ou un autre (mail, SMS…) quand une alerte est générée par Nagios (par exemple quand votre serveur Web ne répond plus).

Il faut pour cela modifier deux fichiers, /usr/local/etc/nagios/contacts.cfg pour la définition du/des contacts:

# Contacts defintions
#####################
define contact {
contact_name nico
alias Nicolas
host_notification_period 24×7
service_notification_period 24×7
host_notification_options d,u,r
service_notification_options w,u,c,r
host_notification_commands host-notify-by-email
service_notification_commands notify-by-email
email nico@votreadressemail.com
}

Nous venons donc de créer un contact nommé « nico » qui sera joingnable 24 heures sur 24, 7 jours sur 7 par mail.

Le deuxième fichier (/usr/local/etc/nagios/contactgroups.cfg) permet d’intégrer le nouvel utilisateur dans un groupe:

# Contacts groups definition
############################
define contactgroup {
contactgroup_name admins
alias Administrators
members nico
}

Nous avons donc ajouté « nico » dans le groupe « admins ».

Définition des machines à surveiller

Entrons dans le vif du sujet en déclarant les machines que l’on veut surveiller. Cette définition sefait dans le fichier /usr/local/etc/nagios/hosts.cfg:

On commence le fichier en définissant un template:

# Nagios server – Hosts definitions
###################################
# Templates
#———-
define host{
name template-host
check_command check-host-alive
max_check_attempts 2
check_interval 5
active_checks_enabled 1
passive_checks_enabled 0
check_period 24×7
notification_interval 60
notification_period 24×7
obsess_over_host 0
check_freshness 0
event_handler_enabled 0
flap_detection_enabled 0
process_perf_data 0
retain_status_information 1
retain_nonstatus_information 1
contact_groups admins
register 0
}

Puis on ajoute la définition pour notre routeur d’accès à Internet (Freebox, 9box, OrangeBox, Trucbox…):

# Ma box
#————
define host{
use template-hosts
host_name monrouteuramoi
alias Mon routeur à moi c’est une Freebox
address 192.168.100.254
}

celle de mon PC client:

# Mon PC client
#————
define host{
use template-hosts
host_name monpcamoi
alias Mon MacBook Pro à moi
address 192.168.100.2
}

et enfin celle de mon serveur:

# Mon serveur
#————
define host{
use template-hosts
host_name monserveuramoi
alias Mon serveur Linux à moi
address 192.168.100.1
}

on termine en surveillant la liaison Internet (pour cela on va pinguer un serveur Web):

# Mon liaison Internet
#————
define host{
use template-hosts
host_name maliaisonamoi
alias Ma liaison ADSL à moi
address www.free.fr
parents monrouteuramoi
}

Vous pouvez remarquer dans cette dernière définition que nous avons définie « monrouteuramoi » comme père de ma « maliaisonamoi ». Ainsi, si le routeur n’est plus accéssible, Nagios n’essayera plus de surveiller la liaison Internet.

Définition des services à surveiller

Une fois les machines définies, nous devons décider ce que nous allons surveiller dessus. Cette configuration se fait grâce au fichier /usr/local/etc/nagios/services.cfg.

Nous allons commencer par un template:

# Templates
#———-
define service{
name template-services
active_checks_enabled 1
passive_checks_enabled 0
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 0
event_handler_enabled 0
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_period 24×7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups admins
notification_interval 240
notification_period 24×7
notification_options c,r
register 0
}

Puis par la surveillance du routeur:

# monrouteuramoi
#———
define service {
host_name monrouteuramoi
use template-services
service_description Ping
check_command check-host-alive
}

De mon PC client:

# monpcamoi
#———
define service {
host_name monpcamoi
use template-services
service_description Ping
check_command check-host-alive
}

mon serveur (on surveille également le serveur HTTP et le serveur FTP):

# monserveuramoi
#———
define service {
host_name monserveuramoi
use template-services
service_description Ping
check_command check-server-alive
}
define service {
host_name monserveuramoi
use template-services
service_description Web serveur
check_command check_http
}
define service {
host_name monserveuramoi
use template-services
service_description FTP serveur
check_command check_ftp
}

et enfin la liaison Internet:

# maliaisonamoi
#———
define service {
host_name maliaisonamoi
use template-services
service_description Ping
check_command check-server-alive
}

Définition des groupes de machines

La dernière étape consiste à définir un groupe de machine dans le fichier /usr/local/etc/nagios/hostgroups.cfg:

# Mon réseau à moi
define hostgroup{
hostgroup_name monreseauamoi
alias Mon reseau
members monrouteuramoi, monpcamoi, monserveuramoi, maliaisonamoi
}

et voila la configuration touche à sa fin, il ne reste plus qu’a vérifier la syntaxe de vos fichiers de configuration avec la commande suivante:

# nagios -v <nagios.cfg>

Si tout est ok, vous pouvez relancer le serveur Nagios:

# service nagios reload

That’s all folk !

Pour une description précise des options des fichiers de configuration de Nagios, c’est par ici.

Pour consulter l’ensemble des posts sur Nagios, c’est par là.

Catégories
Reseau

Nagios et Fast Ping (check_fping)

Si vous souhaitez utiliser fping en lieu et place de ping avec votre configuration de Nagios, il faut suivre les étapes suivantes:

Installer fping:

# wget http://fping.sourceforge.net/download/fping.tar.gz
# tar zxvf fping.tar.gz
# cd fping-x.y.z
# ./configure
# make
# make install

Autoriser l’utilisateur nagios à executer fping:

# chmod u+s /usr/local/sbin/fping

Installer ou re-installer les plugins Nagios (par exemple sous FreeBSD):

# cd /usr/ports/net-mgmt/nagios-plugins/
# make install
ou
# make deinstall ; make reinstall

Puis changer le fichier de configurations de Nagios (/usr/local/etc/nagios/commands.cfg):


define command {
command_name check_ping
command_line $USER1$/check_fping $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -n 5
}

define command{
command_name check-host-alive
command_line $USER1$/check_fping $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -n 1
}

Il ne reste plus qu’a relancer Nagios:

#/usr/local/etc/rc.d/nagios.sh reload

>

Et « f »hop…

Catégories
Open-source Reseau

Connexion d’Asterisk au serveur SIP de Free

Suite à l’article d’hier sur la configuration d’un serveur Asterisk SIP sous Fedora, voici un tutoriel permettant de le connecter au serveur SIP de l’opérateur Free (Freephonie), ou à toutes autres opérateur SIP.

Ce que nous voulons obtenir:
– les appels sortant (vers fixes, portables) depuis un client SIP (X-Lite dans notre exemple).
– les appels entrant sont automatiquement basculés vers le client SIP, puis vers le téléphone branché sur la Freebox (si le client SIP ne décroche pas) et enfin vers la messagerie (si le téléphone ne décroche pas).

Êtes-vous prêt ? Alors c’est partie…

Configuration de votre compte SIP Free

La première chose à faire est d’aller sur l’interface d’administration de votre compte Free afin d’activer votre compte SIP (dans le menu Gestion de mes services de téléphonie).

Cette opération a pour but de rediriger les appels en SIP.

Il faut redémarrer la Freebox pour que la configuration soit prise en compte.

Configuration du serveur Asterisk

Nous allons apporter quelques modifications à notre fichier de configuration SIP (/etc/asterisk/sip.conf).

[general]
context=default
srvlookup=no
externip=81.54.223.16
localnet=192.168.1.0/255.255.255.0
defaultexpirey=1800
dtmfmode=auto
qualify=yes
register = utilisateur:motdepasse@freephonie.net
[freephonie_appelsortant]
type=peer
allow=all
host=freephonie.net
fromuser=utilisateur
username=utilisateur
secret=motdepasse
dtmfmode=inband
qualify=yes
fromdomain=freephonie.net
[freephonie_appelentrant]
type=peer
context=depuisfreephonie
host=freephonie.net
qualify=yes
allow=all

[nicolargo]
type=friend
username=nicolargo
secret=motdepasse
context=maison
quality=yes
nat=no
canreinvite=no
auth=md5
host=dynamic
dtfmode=rfc2833
allow=ulaw
context=internal

Il faut remplacer ‘utilisateur’ et ‘motdepasse’ par ceux fournis par Free dans l’interface d’administration Free.
‘exterip’ doit être remplacée par votre adresse IP publique (aussi récupérable sur l’interface d’administration Free).
‘localnet’ doit être remplacé par l’adresse réseau et le masque de votre réseau local.

Ensuite, on édite le fichier de plan de numérotation (/etc/asterisk/extensions.conf):

[maison]
; Numéros « maison »
exten => 10,1,Dial(SIP/nicolargo) ; quand on compose le 10, le softphone « nicolargo » sonnera
; numéros externes
exten => _9.,1,Dial(SIP/freephonie-out/${EXTEN:1}) ; quand on compose un numero qui commence par 9, on utilise le lien « freephonie » et on passe le numero au peer en ôtant le premier digit.
[depuisfreephonie]
; Contexte pour les appels recus depuis Free
exten => s,1,Ringing
exten => s,2,Dial(SIP/nicolargo)
exten => s,3,Congestion

Il ne reste plus qu’à faire prendre en compte la nouvelle configuration par votre serveur Asterisk:

# asterisk -r
*CLI> restart gracefully

Et voila, vous pouvez tester 😉

Mise à jour du billet

Dans le Linux magazine n°90, un article très complet sur comment configurer son serveur Asterisk avec le service Freephonie de l’opérateur Free.

Catégories
Open-source Reseau

Installation d’Asterisk sur Fedora

Asterisk est un serveur de téléphonie open-source permettant de disposer sur un simple PC de fonctions jusque là réservées aux PABX professionnel. Nous allons dans ce post installer un serveur Asterisk sur PC fonctionnant sous Fedora (Core 6). Nous nous limiterons à la configuration d’un serveur VoIP SIP sans passerelle vers le monde téléphonique.

Attention: si vous voulez utiliser une carte téléphonique de tpy eDigium dans votre serveur, il faudra l’installer AVANT d’installer Asterisk.

Installation d’Asterisk

Nous allons compiler la dernière version d’Asterisk (1.4.2) au moment de l’écriture de ce post à partir des sources (téléchargeable ici).Une fois le fichier téléchargé, il faut commencer par le décompresser:

# tar zxvf asterisk-1.4.2.tar.gz

On lance la compilation avec les commandes suivantes:

# cd asterisk-1.4.2
# ./configure
# make
# make install
# make samples
-> Seulement nécessaire pour un installation initiale. Écrase les fichiers de configuration actuels.
# make progdocs

PS: si vous souhaitez mettre à jour unes version existante d’Asterisk, il faut utiliser les commandes suivantes:

# cd asterisk-1.4.2
# ./configure
# make update
# make clean# make upgrade

Une fois l’installation terminée, vous pouvez tester Asterisk:

# /usr/sbin/asterisk -VAsterisk 1.4.2

L’installation est réussie, on peut passer à la phase de configuration.

Configuration d’Asterisk

Avant de nous attaquer aux fichiers de configuration. Voici la liste des répertoires utilisées par Asterisk:

  • /etc/asterisk contient les fichiers de configuration.
  • /usr/lib/asterisk/modules contient les modules utilisés par Asterisk (codec, applications tierces…).
  • /var/lib/asterisk/agi-bin contient vos scripts.
  • /var/lib/asterisk/firmware contient les drivers pour les cartes compatible Asterisk (par exemple Digium).
  • /var/lib/asterisk/images contient des images pour les applications les supportant.
  • /var/lib/asterisk/keys contient les clès publiques et privées (RSA)
  • /var/lib/asterisk/mohmp3 contient les musiques d’attente au format MP3 (CBR uniquement et pas de tag ID3).
  • /var/lib/asterisk/sounds contient les annonces vocales
  • /var/log/asterisk contient les logs du processus Asterisk

Comme nous allons nous limiter à une configuration purement SIP du serveur Asterisk (sans interface vers le monde téléphonique), la configuration est relativement simple.Il faut commencer par éditer le fichier /etc/asterisk/sip.conf:

[general]
context=default
srvlookup=no
[nicolargo]
type=friend
username=nicolargo
secret=password
quality=yes
nat=no
canreinvite=no
auth=md5
host=dynamic
dtfmode=rfc2833
allow=ulaw
context=internal

Nous venons de créer un utilisateur nicolargo sur le serveur.

Lancement d’Asterisk

Pour lancer la console d’administration Asterisk, il suffit de taper la ligne suivante:

# /usr/sbin/asterisk -c
*CLI>

Nous pouvons alors vérifier que l’utilisateur SIP a bien été créé:

*CLI> sip show users
Username Secret Account
code Def.
Context ACL NAT
nicolargo password default No RFC3581

Puis voir les détails de la configuration de l’utisateur nicolargo:

*CLI> sip show user
nicolargo* Name : nicolargoSecret : <Set>MD5Secret : <Not set>Context : defaultLanguage :AMA flags : UnknownTransfer mode: openMaxCallBR : 384 kbpsCallingPres : Presentation Allowed, Not ScreenedCall limit : 0Callgroup :Pickupgroup :Callerid : « nicolargo » <1208>ACL : NoCodec Order : (gsm:20,ulaw:20,alaw:20)Auto-Framing: No

Pour arrêter le serveur, il faut saisir la commande suivante:

*CLI> stop gracefully

Test du serveur à partir d’un client SIP

Pour mes tests j’ai utilisé X-Lite (disponible sous Linux, Mac et Windows), qui a le bon goût d’être gratuit et parfaitement compatible avec la norme SIP.La configuration doit être la suivante:

L’enregistrement sur le serveur Asterisk (192.168.29.246 dans mon cas) se passe alors sans problème:

Si vous avez un problème pour vous connecté à votre serveur Asterisk, pensez à regarder du coté des règles de Firewall (iptables). Il faut ajouter la règle suivante:

# iptables -A RH-Firewall-1-INPUT -p udp -m udp –dport 5061 -j ACCEPT

A partir de maintenant (et en définissant d’autres utilisateurs), vous devez être capable d’effectuer des appels SIP à l’intérieur de votre réseau.Voila donc une première étape de faite. Dans un prochain post nous verrons comment interfacer notre nouveau serveur vers un serveur père (par exemple chez votre fournisseur d’accès Internet)…
Pour ceux que cela intéresse, cet article raconte le retour d’expérience de l’installation d’une serveur Asterisk en entreprise.

Catégories
Open-source Reseau Systeme

Authentification avec OpenID

Nous allons dans ce post expliquer comment mettre en place une authentification OpenID à partir du nom de domaine de votre site perso/blog.

OpenID est un système d’authentification décentralisé permettant une authentification unique à partir d’un nom de domaine DNS. Il vous permet donc de vous authentifier sur plusieurs sites avec le même profil (login, password, nom, adresse…). Plus d’info ici.

Ce que nous voulons obtenir: Une authentification dont l’OpenID sera: http://blog.nicolargo.com (à remplacer par votre nom de domaine dans le reste de ce tutoriel).

Creation d’un OpenID sur un serveur de confiance

La première chose à faire est de créer un ID chez un fournisseur d’identité. J’ai choisi de passer par le site https://www.myopenid.com/, mais d’autres fournisseurs existent. Il suffit de choisir un login (nicolargo dans mon cas), le serveur va créer un OpenID de la forme: http://nicolargo.myopenid.com.

Utilisation d’un nom de domaine personnel comme OpenID

Si vous disposez comme moi d’un nom de domaine (http://blog.nicolargo.com), il est très simple de l’utiliser en lieu et place de l’OpenID que vous venez de créer (http://nicolargo.myopenid.com). Pour cela, il faut ajouter les 2 lignes suivante dans la section <header> de votre page Web principale. Si comme dans mon cas votre site est un blog WordPress, il faut les ajouter dans le fichier header.php de votre thème.


<link rel=“openid.server” href=“https://www.myopenid.com/server” />
<link rel=“openid.delegate” href=“http://nicolargo.myopenid.com” />

Ces deux lignes vont automatiquement rediriger l’authentification depuis http://blog.nicolargo.com vers le serveur de confiance https://www.myopenid.com/server en utilisant l’OpenID http://nicolargo.myopenid.com.

Comment vérifier que cela marche ?

C’est très simple, il faut se rendre sur un des nombreux sites supportant l’OpenID (voir une liste ici) et s’enregistrer en utilisant votre nouvel OpenID (http://blog.nicolargo.com dans mon cas). Par exemple sur Ziki, lors de l’enregistrement, on est rediriger vers cette page:

Voila vos premiers pas accomplis dans le SSO !

Catégories
Reseau

Cacti, le complement idéal de Nagios !

Nous allons dans ce post parler de l’installation de Cacti, qui me semble offrir des fonctions complémentaires à Nagios déjà évoqué dans ce blog.

C’est quoi donc ?

Cacti est une interface Web écrite en PHP permettant de gérer des graphes RRD. Ces graphes RRD peuvent avoir comme source le résultat de n’importe quelle requêtes SNMP ou d’un simple script. Cela permet donc une large possibilitée d’utilisation. La gestion se fait par des menus relativement simple à utiliser (il faut tout de même un temps de prise en main mais la documentation est très bien faite).

Configuration nécessaire

Un operating system (Unix de préference)
Un serveur Web fraichement installé (Apache par exemple).
Une base de données MySQL.
Les sources de Cacti ou un package pour votre operating system.

Installation de cacti (exemple donnée pour une Fedora Core 6)

Update: cliquez ici pour voir un nouvel article sur une procédure d’upgrade en version 0.8.7 

Il faut commencer par installer les utilitaires SNMP:

# yum install net-snmp net-snmp-utils

Puis Cacti en lui même (on utilise le package du repos extra):

# yum install cacti

Avant toute chose, nous allons ajouter la configuration nécessaire pour que le serveur Web (Apache) prenne en compte cacti:

# cd /etc/httpd/conf.d/
# vi cacti.conf
Alias /cacti/ /usr/share/cacti/
<Directory /cacti/>
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
# apachectl restart

Après vous être placé dans le répertoire d’installation, il faut créer la base de donnée MySQL (on part sur l’hypothése ou la base de donnée est sur le même serveur):

# mysqladmin –user=root create cacti
# mysql cacti < cacti.sql
# mysql –user=root mysql
mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY ‘somepassword’;
mysql> flush privileges;

… et la configurer en éditant le fichier include/config.php:

# vi include/db.php
<?
/* make sure these values refect your actual database/host/user/password */
$database_type = « mysql »;
$database_default = « cacti »;
$database_hostname = « localhost »;
$database_username = « cactiuser »;
$database_password = « password »;
$database_port = « 3306 »;
?>

Nous pouvons alors lancer un navigateur Web sur l’URL: http://votreadresseip/cacti/
Au premier lancement, une page de configuration va apparaître. Vous devez choisir RRD (dernière version).

Il est parfois nécessaire de changer les droits du répertoire de travail de Cacti:

# cd /usr/share/cacti/
# chown -R cacti rra/ log/

La dernière étape va automatiser le lancement de cacti toutes les 5 minutes:

# crontab -e -u cacti
*/5 * * * * /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1

Et voila, vous avez maintenant un bel outils pour générer toutes les courbes RRD possibles 😉

Catégories
Blog Reseau Web

Mon blog interdit en Chine ?

Je viens de tester le site « Great Firewall of Chine » et mon site est interdit en Chine…

Nicolargo en Chine…

Ce service, localisé aux Pays-Bas, permet de tester si votre blog (ou touts autres sites Internet) est accessible depuis le territoire Chinois. Le principe est simple: l’URL du site à tester est envoyée sur une machine hébérgée chez un founisseur d’accès Chinois. Cette machine teste l’accès à votre site depuis la Chine. Si le Firewall, mis en place par le gouvernement bloque votre adresse, un message d’erreur est renvoyé.

Comme vous pouvez le voir, mon blog est bloqué. Pourquoi ? Je pense tout simplement que les URL contenant le mot clés blog (comme blog.nicolargo.com) sont bloquées. Ainsi, en faisant le même test avec l’adresse www.nicolargo.com, je n’ai pas de message d’erreur. Le gouvernement Chinois doit donc penser que tous les blogs contiennent des posts hostilles… bizarre comme raisonnement…

Bref si vous voulez « attaquer » le marché Chinois, mieux vaut bien choisir le nom de votre site ;).

Catégories
Reseau

Tester la performance de votre réseau avec Iperf

Iperf est un des outils indispensable pout tout administrateur réseau qui se respecte. En effet, ce logiciel de mesure de performance réseau, diponible sur de nombreuses plateformes (Linux, BSD, Mac, Windows…), se présente sous la forme d’une ligne de commande à executer sur deux machines disposées aux extrémités du réseau à tester.

Iperf fonctionne comme un client/serveur selon le diagramme suivant:

Iperf

Iperf doit être lancé sur deux machines se trouvant de part et d’autre du réseau à tester. La première machine lance Iperf en « mode serveur » (avec l’option -s), la seconde en « mode client » (option -c). Par défaut le test réseau se fait en utilsant le protocole TCP (mais il est également possible d’utiliser le mode UDP avec l’option -u).

Nous allons commencer par installer iperf en utilisant la commande suivante (sous Fedora):

# yum install iperf

Pour les autres système d »exploitation, vous pouvez vous rendre sur cette page.

Premier exemple d’utilisation

Ensuite, sur une des deux machines de test, nous allon slancer le serveur grâce à la commande suivante:

# iperf -s

Sur le client, il ne reste plus qu’a lancer le client en précisant l’adresse du serveur:

# iperf -c <adresse IP du serveur>

Vous devriez avoir le rapport qui s’affiche après 10 secondes de test.

————————————————————
Client connecting to 192.168.29.1, TCP port 5001
TCP window size: 65.0 KByte (default)
————————————————————
[ 3] local 192.168.29.157 port 50675 connected with 192.168.29.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 110 MBytes 92.6 Mbits/sec

Avec les options par défaut, le test est fait en TCP sur une durée de 10 secondes. Sur un réseau local vous devriez donc obtenir un valeur proche de la capacité de commutation de vos équipements (par exemple 92.6 Mbits/sec qui est une valeur proche de 100 Mbits/sec).

Pour afficher des rapports intermédiaires (par exemple toutes les secondes) , il suffit d’ajouter l’option (-i 1) sur le client et/ou le serveur.

# iperf -s -i 1
————————————————————
Server listening on TCP port 5001
TCP window size: 56.0 KByte (default)
————————————————————
[ 6] local 192.168.29.1 port 5001 connected with 192.168.29.157 port 50692
[ 6] 0.0- 1.0 sec 10.1 MBytes 84.8 Mbits/sec
[ 6] 1.0- 2.0 sec 11.1 MBytes 93.0 Mbits/sec
[ 6] 2.0- 3.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 3.0- 4.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 4.0- 5.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 5.0- 6.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 6.0- 7.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 7.0- 8.0 sec 11.2 MBytes 93.8 Mbits/sec
[ 6] 8.0- 9.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 9.0-10.0 sec 11.2 MBytes 93.9 Mbits/sec
[ 6] 0.0-10.0 sec 111 MBytes 92.9 Mbits/sec

Une autre option de base est (-t) qui permet de fixer au niveau du client le temps du test (en secondes). Par exemple pour effectuer un test pendant 1 minute:

# ipert -c <adresse IP du serveur> -t 60

Exemple de test en utilisant le protocole UDP

Iperf permet également de générer un traffic de type UDP (-u). Dans ce cas là, il faut penser à fixer la bande passante cible (contrairement au protocole TCP, UDP ne peut pas faire de contrôle de flux). On utilise pour cela l’argument -b au niveau du client:

Sur le serveur:

# iperf -s -u

Sur le client:

# ipert -c <adresse IP du serveur> -u -b 512k

Ce couple de commandes va générer un test avec un flux réseau UDP de 512 Kbits/sec.

Comme vous pouvez le voir Iperf est également un bon outil de génération de flux. Je l’ai déjà testé pour générer un flux UDP constant pendant plusieurs jours.

Exemple de test en multicast (UDP)

Iperf peut fonctionner en mode multicast (-B). Il faut le lancer de la manière suivante:

Sur le serveur:

# iperf -s -u -B 226.10.11.12

Sur le/les clients:

# iperf -c 226.10.11.12 -u -T 32 -b 512k

Ce couple de commandes génére un flux multicast UDP (sur l’adresse 226.10.11.12, avec un TTL de 32) de 512 Kbits/sec.

Autres options

NOUVEAU: Consultez cet autre article (cliquez ici) pour une description des options avancés de Iperf.

Et bien entendu, il reste la fameuse commande:

# iperf –help

…pour avoir la liste complète des options. Si vous avez des questions, n’hésitez pas !

Sur le même sujet

Pour mes propres besoins, j’ai ecrit un programme nommé SJitter permettant, comme le fait Iperf (c’est à dire sous la forme d’un client/serveur), de mesurer la gigue réseau (ou jitter en anglais). Paramètre très important si vous souhaitez mettre en place de la voie sur IP sur votre réseau.

Catégories
Reseau

Monter un répertoire distant en SSH

Je me sers exlusivement du protocole SSH pour administrer mes machines via une console. Ce protocole permet également d’effectuer des transferts de fichiers via le protocole SCP. Cependant, il était jusqu’a maintenant nécessaire d’utiliser un client (scp sous Linux/BSD, WinSCP sur Windows ou Fugu sur Mac). Cette contrainte n’est plus d’actualité depuis l’apparition de Fuse.

« Pour rappel, Fuse (pour Filesystem in Userspace) permet à un utilisateur (non root) de créer son propre système de fichier sans avoir à modifier le noyau du systeme. Il existe par exemple une extension pour accéder à votre compte Gmail comme si celui-ci était un répertoire de votre disque dur (GmailFS). Fuse a de plus le bon goût d’être développé sous licence open-source GPL et LGPL. »

Pour notre besoin, nous allons utiliser le module SSHFS (SSH sur Fuse).

Installation (sur Fedora)

# yum install fuse-sshfs

Utilisation (sur Linux)

La première chose à faire est de créer, sur votre machine cliente, le répertoire dans lequel sera monté le répertoire distant:

# mkdir /mnt/test

Ensuite, on monte le répertoire distant /home/test qui se trouve sur la machine 192.168.0.2:

# sshfs 192.168.0.2:/home/test/ /mnt/test/

On vérifie en faisant un ls dans le répertorie /mnt/test. Il doit afficher le contenu du répertoire distant.

# ls /mnt/test
test.zip

Pour démonter le répertoire distant, il faut taper la commande suivante:

# fusermount -u /mnt/test

Et voila le travail…

Catégories
Reseau

Creation d’un plugins pour Nagios

Nous allons dans ce post écrire un plugins (très simple) pour Nagios. Le corps de ce plugins pourra vous servir de base pour réaliser des plugins plus complexes.

Suite à un post sur l’installation de Nagios, je me suis penché sur l’écriture d’un plugins permettant de vérifier qu’un processus est bien lancé sur un serveur distant.

Voici ce que je l’on attend de notre plugins:

  • Ouvrir une session SSH vers le serveur distant
  • Lancement d’un script vérifiant si un processus (testd) est lancé
  • Renvoie de l’état du processus (OK / ERROR / WARNING)
    • OK: Le processus (testd) est lancé et fonctionne correctement
    • ERROR: Le processus n’est pas lancé
    • WARNING: Le processus est lancé mais ne fonctionne pas correctement

Avant d’entrer dans le vif du sujet, il faut savoir que les plugins Nagios sont de simple « scripts shell » retournant un code de status. Ces plugins sont localisés dans le répertoire /usr/lib/nagios/plugins (sous Linux). Un petit coups de ls donne la liste des plugins installés par défaut:

# ls
check_http check_pgsql check_smtp check_udp2 check_imap check_mysql check_ping check_spop check_udrelay term_power check_clamd check_jabber check_mysql_query check_pop check_ssmtp check_dns check_ldap check_nntp check_scheduler check_tcp check_ftp check_ldaps check_nntps check_simap check_udp …

Nous allons donc dans un premier temps créer le plugins qui va lancer la commande sur le serveur distant:

# vi check_testd
#!/bin/sh

##################################################################
# Creation: Nicolargo
# Last Modification:
# This script checks testd daemon is running on a server
##################################################################

ssh nagios@$1 /usr/local/bin/nagios_testd.pl

Une fois l’automatisation du SSH effectuée entre votre serveur Nagios et votre serveur distant (il ne faut pas que le script demande le password…). Il reste à créer le script nagios_testd.pl (je l’ai developpé en perl mais rien n’empêche de le faire en SH) dans le réperoire /usr/local/bin du serveur distant.

# vi /usr/local/bin/nagios_testd.pl
#!/bin/sh

##################################################################
# Creation: NicoLargo
# Last Modification:
# This script is polling if testd daemon is running
##################################################################

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

ps auxw | grep [t]estd | grep -v nagios > /dev/null
STATE=$?
if [ « $STATE » = « $STATE_OK » ]
then
echo « TESTD OK »
exit 0
else
echo « TESTD Failed »
exit $STATE_CRITICAL
fi

Pour tester votre plugins, rien de plus simple, il suffit de lancer la ligne de commande sur votre serveur Nagios:

# /usr/lib/nagios/plugins/check_testd.sh monserveurdistant.mondomaine.com
TESTD OK

Si cela ne fonctionne pas, il faut d’abord vérifier que les fichiers ont les bons droits (lecture et execution) et que le SSH fonctionne correctement entre les deux machines.

Une fois le plugins validé, il ne reste plus qu’a l’intégrer dans vos fichiers de configuration.

# vi /etc/nagios/checkcommands.cfg

# ‘check_testd’ command definition
define command{
command_name check_testd
command_line $USER1$/check_testd $HOSTADDRESS$
}

et enfin:

# vi /etc/nagios/services.cfg

define service{
use generic-service
host_name monserveurdistant.mondomaine.com
service_description TESTD
check_command check_testd
}

Voili a+