Rappel: le protocole DHCP permet la configuration automatique des paramètres IP des machines d’un réseau (plus de littérature sur le Wiki).

Introduction

ISC DHCP est un projet open-source disponible dans une suite qui comprend les éléments suivants:

• le fameux serveur DHCPd
• le client DHCPclient
• un serveur de relais DHCPrelay

Cette suite est disponible sur la plupart des OS: Linux, BSD, Mac OS X et Windows.

La dernière version stable à la date de l’éecriture de ce billet est la 3.0.6

Installation du serveur DHCPd

Sous FreeBSD la procédure est la suivante:

# pkg_add -r isc-dhcp3-server

Pour les puristes, il est également de compiler le serveur à partir des sources.

Quelques trucs utiles à savoir avant la configuration

DHCP est un protocole servant à distribuer des configurations réseaux (c’est à dire adresse IP, masque, routes, serveurs DNS…) sur un réseau local. Il faut donc que le serveur et les clients se trouvent sur un même réseau de niveau 2. En clair, il ne doit pas y avoir de routeur IP entre le serveur et les clients. Si vous ne pouvez pas faire autrement, le serveur relais pourra vous être utile…

Si vous avez un Firewall entre votre serveur et vos clients, il faut veillez à ajouter les règles suivantes:

Autoriser les paquets UDP/67 (source UDP/68) entre l’adresse 0.0.0.0 et l’adresse 255.255.255.255

Autoriser les paquets UDP/68 (source UDP/67) entre le serveur et les clients

C’est à dire autoriser vos clients qui n’ont pas encore d’adresse IP (0.0.0.0) à envoyer sur le réseau une requête DHCP (UDP/67) vers toutes les machines du réseau (255.255.255.255) afin de chercher le serveur DHCP. Le serveur DHCP répond (UDP/68) en offrant un bail DHCP (c’est à dire une configuration IP valable un certain temps).

Sous FreeBSD, la règle IPFW correspondante est:

# ipfw add allow udp from 0.0.0.0 68 to 255.255.255.255 67 keep-state

# ipfw add allow udp from @SERVEUR 67 to any 68 keep-state

Configuration du serveur DHCP

Toute la configuration est centralisée dans le fichier dhcpd.conf. Nous allons donc commencer par archiver la configuration par défaut.

# mv /usr/local/etc/dhcpd.conf.sample /usr/local/etc/dhcpd.conf

Puis éditer notre fichier dhcpd.conf:

# vi /usr/local/etc/dhcpd.conf

# C’est bien le serveur DHCP principal

authoritative;

# Nom de domaine de votre réseau

option domain-name “monboreseau.com”;

# Adresses des serveurs DNS

option domain-name-servers ns1.monboreseau.com, ns2.monboreseau.com;

# Définition de la durée du bail

default-lease-time 600;

max-lease-time 7200;

# On logue les messages dans le syslog

log-facility local7;

# Définition des plages d’adresses dynamiques du LAN

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.100 192.168.1.200 ;

option routers 192.168.1.1 ;

option broadcast-address 192.168.1.255 ;

}

# Définition des machines statiques (les entrées doivent exister dans le serveur DNS)

# Attention, elles doivent être en dehors du range dynamique définie ci-dessus.

host mamachine {

hardware ethernet 00:11:09:1A:-:- ;

fixed-address mamachine.alcasat.net ;

}

Les opérations de base sur votre serveur DHCP

Démarrage du serveur (sous FreeBSD):

# /usr/local/etc/rc.d/isc-dhcpd start

Arrêter le serveur DHCP (sous FreeBSD):

# /usr/local/etc/rc.d/isc-dhcpd stop

Pour connaître la liste des baux (leases) en cours:

# cat /var/db/dhcpd.leases

Exemple:

lease 192.168.1.112 {

starts 2 2008/05/13 10:22:43;

ends 2 2008/05/13 10:32:43;

binding state active;

next binding state free;

hardware ethernet 00:08:02:f4:-:-;

uid “\001\000\010\002\364o\310″;

client-hostname “port2″;

}

Et la redondance ?

Si vous souhaitez avoir deux serveurs DHCP en redondance sur votre réseau, vous pouvez suivre cette procédure.

Si vous êtes votre propre héberger, le service DNS est une des premières brique à mettre en place sur votre réseau. Nous allons dans ce billet décrire l’installation d’une architecture DNS avec deux serveurs (un primaire et un secondaire).

Pour illustrer ce billet nous allons prendre l’exemple du réseau suivant:

• Adressage privée en 192.168.1.0/24
• Adressage public en 80.80.80.0/24
• Adresse du serveur primaire: 80.80.80.1 avec comme nom ns1
• Adresse du serveur secondaire: 192.168.1.1 avec comme nom ns2
• Nom de votre domaine: monboreseau.com

Installation des serveurs DNS

Nous allons nous baser sur l’implémentation ISC Bind pour nos serveurs DNS. Le processus à lancer s’appelle named, il doit logiquement être présent sur votre système GNU/Linux ou BSD.

Pour vérifier que named est bien installé et que vous avez une version à jour:

# named -v

BIND 9.4.

Le site officiel pour vérifier la version est ici.

Configuration du serveur primaire

C’est le serveur maître qui doit être accessible depuis Internet sur le port TCP/53.

La configuration est centralisé dans le répertoire /etc/namedb.

Nous commençons par éditer le fichier named.conf:

# vi /etc/namedb/named.conf

options {

directory “/etc/namedb”;

query-source address * port 53;

};

logging {

channel lames {

file “/var/log/named.run”;

severity debug;

};

category default { lames; };

};

zone “.” {

type hint;

file “named.root”;

};

zone “0.0.127.IN-ADDR.ARPA” {

type master;

file “localhost.rev”;

};

// Zone MONBORESEAU.COM

zone “monboreseau.com” {

type master ;

file “master/monboreseau.com” ;

} ;

// Zone 192.168.1.0

zone “0.1.168.192.in-addr.arpa” {

type master ;

file “master/0.1.168.192.in-addr.arpa” ;

} ;

// Zone 80.80.80.0

zone “0.80.80.80.in-addr.arpa” {

type master ;

file “master/0.80.80.80.in-addr.arpa” ;

} ;

Il faut ensuite remplir les fichiers des zones avec vos machines. Nous commençons par la zone primaire (qui donne l’adresse IP en fonction du nom):

# vi /etc/namedb/master/monboreseau.com

$ORIGIN .

$TTL 86400 ; 1 day

alcasat.net IN SOA ns1.monboresau.com. support.monboreseau.com. (

2008042902 ; serial

21600 ; refresh (6 hours)

3600 ; retry (1 hour)

604800 ; expire (1 week)

86400 ; minimum (1 day)

)

NS ns1.monboreseau.com.

NS ns2.monboreseau.com.

MX 10 mail.monboreseau.com.

$ORIGIN monbeaureseau.com.

ns1 A 80.80.80.1

machine1 A 80.80.80.2

ns2 A 192.168.1.1

machine2 A 192.168.1.2

…

Puis par les zones reverses (qui donne le nom par rapport à l’adresse IP):

# vi /etc/namedb/master/0.80.80.80.in-addr.arpa

$ttl 86400

@ IN SOA ns1.monboreseau.com. support.monboreseau.com. (

2008040101 ;

21600 ;

3600 ;

604800 ;

86400 ) ;

@ IN NS ns1.monboreseau.com.

@ IN NS ns2.monboreseau.com.

1 IN PTR ns1.monboreseau.com.

2 IN PTR machine1.monboreseau.com.

# vi /etc/namedb/master/0.1.168.192.in-addr.arpa

$ttl 86400

@ IN SOA ns1.monboreseau.com. support.monboreseau.com. (

2008040101 ;

21600 ;

3600 ;

604800 ;

86400 ) ;

@ IN NS ns1.monboreseau.com.

@ IN NS ns2.monboreseau.com.

1 IN PTR ns2.monboreseau.com.

2 IN PTR machine2.monboreseau.com.

Vous pouvez maintenant lancer votre serveur DNS primaire:

Sous GNU/Linux:

# /etc/init.d/named start

Sous BSD:

# /etc/rc.d/named start

Pour valider que le serveur marche bien, il faut se mettre sur une machine de votre réseau et utiliser la commande dig:

# dig @80.80.80.1 machine1.monboreseau.com

…

;; ANSWER SECTION:

machine1.monboreseau.com. 86400 IN A 80.80.80.1

…

Configuration du serveur secondaire

Vous voilà donc avec un serveur primaire en état de marche, pour des raisons de fiabilité et/ou de performanace, il peut être utile de disposer d’un second serveur dit secondaire sur votre réseau.

La encore nous allons utiliser le daemon named avec une configuration spécifique:

On commence par le fichier de configuration:

# vi /etc/namedb/named.conf

options {

directory “/etc/namedb”;

query-source address * port 53;

notify yes;

version “Bind”;

};

server 80.80.80.1 {

transfer-format many-answers ;

};

logging {

channel lames {

file “/var/log/named.run”;

severity debug;

};

category default { lames; };

};

zone “.” {

type hint;

file “named.root”;

};

zone “0.0.127.in-addr.arpa” IN {

type master;

file “localhost.rev”;

};

// Zone MONBORESEAU.COM

zone “monboreseau.com” {

type slave ;

file “slave/monboreseau.com” ;

masters { 80.80.80.1 ; } ;

} ;

// Zone 192.168.1.0

zone “0.1.168.192.in-addr.arpa” {

type slave ;

file “slave/0.1.168.192.in-addr.arpa” ;

masters { 80.80.80.1 ; } ;

} ;

// Zone 80.80.80.0

zone “0.80.80.80.in-addr.arpa” {

type slave ;

file “slave/0.80.80.80.in-addr.arpa” ;

masters { 80.80.80.1 ; } ;

} ;

Le téléchargement des fichiers de zones entre le serveur primaire et le serveur secondaire se fera automatiquement au démarrage du daemon named.

Vous pouvez maintenant lancer votre serveur DNS secondaire:

Sous GNU/Linux:

# /etc/init.d/named start

Sous BSD:

# /etc/rc.d/named start

Il faut d’abord vérifier que les fichiers de zones sont bien présent dans le répertoire /etc/namedb/slave/, puis pour valider que le serveur marche bien, il faut se mettre sur une machine de votre réseau et utiliser la commande dig:

# dig @192.168.29.1 machine1.monboreseau.com

…

;; ANSWER SECTION:

machine1.monboreseau.com. 86400 IN A 80.80.80.1

…

Vous voilà maintenant avec une belle architecture DNS sur votre réseau. Il ne faut pas oublier de mettre à jour régulièrement le daemon named et aussi mettre en place une sauvegarde de vos zone primaire (au cas ou…).

L’OS FreeBSD est très bien classé en ce qui concerne la stabilité (voir le top des uptimes ici) et la qualité de son stack IP. C’est donc un candidat idéal pour y bâtir le routeur/firewall de votre réseau. Nous allons dans ce billet faire une installation “from scratch” d’un Firewall sous FreeBSD 7.0 et la configuration des services de bases.

Installation de FreeBSD depuis les sources

On insère le CD d’installationdans le lecteur et après le démarrage sur ce média, on lance une installation de type Custom avec les caractéristiques suivantes:

Partition: on choisi une partition libre sur un disque dur. On y installe le boot manager standard

Label: on met le label SWAP sur un disque de taille 2xRAM puis le label / sur le reste du disque

Distribution: on ne chipote pas et on selectionne la distribution Developer

Media: CD

Commit: On lance l’installation

Une fois l’installation faite, on reboote et on se logue avec l’utilisateur root (ne pas oublier de changer le password grâce à la commande passwd).

On garde les ports à jour

Un “port” dans le langage FreeBSDien, est une application packagée pour cet OS. La liste des “ports” ainsi que les sources, se trouve dans le répertoire /usr/ports. Pour installer un port la méthode la plus simple est la suivante:

# pkg_add -r <nom du port>

Les puristes préféreront aller dans le répertoire /usr/ports/<categorie>/<nom du port> et faire la fameuse séquence: make install; make clean. 

Avant de commencer la configuration du Firewall, on va s’assurer que le serveur est à jour et qu’il le restera dans l’avenir (cad que les ports sont bien à jour). Pour cela, nous allons utiliser la commande Csup et les utilitaires PortUpgrade.

# pkg_add -r portupgrade

# mkdir /usr/local/etc

# mkdir /usr/local/etc/csup

# cp /usr/share/example/cvsup/ports-supfile /usr/local/etc/csup

  > Penser à éditer le fichier et à remplir le champs *default host=cvsup.fr.FreeBSD.org

# cp /usr/share/example/cvsup/stable-supfile /usr/local/etc/csup

  > Penser à éditer le fichier et à remplir le champs *default host=cvsup.fr.FreeBSD.org

# chown 644 /usr/local/etc/csup/*

# export alias cvsup=”csup”

Pour lancer une mise à jour du répertoire /usr/ports, il faut utiliser les commandes suivantes:

# /usr/bin/csup /usr/local/etc/csup/ports-supfile

# /usr/local/sbin/portsdb -Fu

La première ligne met à jour les ports, la seconde met à jour la base de donnée des ports.

Afin d’automatiser tout cela, je vous propose d’utiliser un petit crontab de famille:

# vi /usr/local/bin/daily.sh

/usr/bin/csup /usr/local/etc/csup/ports-supfile

/usr/local/sbin/portsdb -Fu

/usr/local/sbin/portversion -v -l | /usr/bin/mail support@mondomaineamoi.com

La dernière ligne du script permet d’envoyer un mail quand des ports installés ne sont plus à jour.

# crontab -e

23 0 * * * /usr/local/thales/bin/daily.sh 2>&1 >>/dev/null

et le noyau aussi…

Le noyau (ou kernel) est un élément important pour la sécurité de votre Firewall. Je vous invite à lire le billet suivant pour apprendre à le maintenir à jour.

On commence les choses sérieuses

A ce point, vous devez maintenant avoir un système à jour, près a affronter les différentes étapes pour la transformation en Firewall de compétition.

Comme on aime bien commencer par la base, nous allons d’abord recompiler le noyau (kernel) afin d’y mettre les options dont nous allons avoir besoin. Pour faire un Firewall, il faut un outil de filtrage de paquets IP. FreeBSD est fourni en standard avec PF (Packet Filter). Plus par habitude que pour des raisons cartésiennes, je lui préfère IPFW. Nous allons donc inclure les options suivantes dans le fichier de configuration du noyau (cette étape est seulement nécessaire si vous voulez faire du NAT avec votre Firewall, sinon, vous pouvez charger IPFW comme un module).

# cd /usr/src/sys/i386/conf/

# cp GENERIC FIREWALL

# vi FIREWALL

…

options    IPFIREWALL

options    IPFIREWALL_VERBOSE

options    IPFIREWALL_VERBOSE_LIMIT=5

options    IPFIREWALL_DEFAULT_TO_ACCEPT

Pour l’activation du NAT, il faut ajouter dans le même fichier, l’option suivant:

options    IPDIVERT

Enfin si vous souhaitez “router” des paquets multicast (rien que ça…) il faut ajouter l’option:

options    MROUTING

Pour recompiler le noyau, il suffit de suivre cette procédure. (il n’est pas nécessaire de faire les étapes de type world si vous ne souhaitez que recompiler le noyau)

Une fois votre nouveau kernel actif, il faut modifer le fichier de démarrage rc.conf pour lancer le Firewall et le NAT:

# vi /etc/rc.conf

…

firewall_enable=”YES”

firewall_script=”/etc/ipfw.rules”

ipnat_enable=”YES”

ipnat_script=”/etc/ipnat.rules”

Installation de Dia sous Mac OS X

Dia est un logiciel Gnome (c’est à dire à la base prévu pour les OS Linux), il faut donc installer un certain nombre de pré-requis sur votre Mac OS X. Nous allons commencer par les Darwin Ports:

1) Télécharger et installer la dernière version des Darwin Ports

2) Mettre à jour vos ports à partir d’un terminal:
# sudo port -d selfupdate

On installe ensuite Dia

# cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/gnome/dia/
# sudo port install dia

Pour lancer l’application:

# dia
> Rien ne vous empêche de créer une icône de raccourcie…

Si vous rencontrez l’erreur suivante lors de l’installation de Dia:

….
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -D_REENTRANT=1 -I/opt/local/include/libxml2 -I/opt/local/include -I/opt/local/include/python2.5 -c libxml2-py.c -o build/temp.macosx-10.3-i386-2.5/libxml2-py.o
unable to execute -DNDEBUG: No such file or directory
error: command ‘-DNDEBUG’ failed with exit status 1
…

Il faut effectuer les actions suivantes:

# sudo /opt/local/bin/port
> install py25-libxml2
> quit

Puis relancer l’installation:

# sudo port install dia

Configuration de Dia pour les schémas réseau (optionnel)

Les icônes fournies par défaut ne sont pas très classes… En surfant un peu sur Google, je suis tombé sur ce billet proposant des icônes SVG “à la Visio”.

La méthode pour découper cette image en autant d’icônes au format SVG (merci à Thomas Dubois pour le script Python) est décrite ci-dessous. Mais comme je suis un bon gars, je vous propose de télécharger une archive TGZ à décompresser dans votre répertoire local ~/.dia.

Pour les geeks, voici la procédure à suivre pour générer les fichiers. Attention, il faut avoir Inkscape installé sur son Mac. Les opérations à faire sont les suivantes:

# cd ~
# mkdir svg
# cd svg
# wget http://www.softia-systems.net/contribs/dia_split_svg.py
# wget http://www.jcartier.net/ini/hardware.svg
# vi dia_split_svg_py
Remplacer la ligne
xmldoc = minidom.parse(’/path/to/file.svg’)
et
popen2.popen3(”/usr/bin/inkscape svg/%s.svg -e shape/%s.png -d 90 -z -D”%(i,i))
par:
xmldoc = minidom.parse(’./hardware.svg’)
et
popen2.popen3(”/Applications/Inkscape.app/Contents/Resources/bin/inkscape svg/%s.svg -e shape/%s.png -d 90 -z -D”%(i,i))
# python dia_split_svg.py

Vous allez obtenir:

• un répertoire svg avec les fichiers SVG des objets
• un répertoire shape avec les fichiers shapes correspondant
• un fichier Youshape.sheet

Il ne reste plus qu’a les insérer dans votre configuration de Dia:

# cp YourSheet.sheet Network.sheet
# vi Network.sheet
Remplacer:
<name>Sample</name>
par:
<name>Network</name>
# cp Network.sheet ~/.dia/sheets
# cp shape/* ~/.dia/shapes/Network

Test final

Et voilà, vous pouvez maintenant relancer Dia

Nous allons dans ce billet créer un routeur multicast (PIM-SM) sur une machine Linux Ubuntu. Nous allons pour cela utiliser le daemon MRD6.

Installation de MRD6

Récupérer la dernière version (0.9.6 au moment de l’écriture de ce billet), puis utiliser l’installateur de paquets pour l’installation sur votre Ubuntu.

Si vous préférez une installation depuis les sources, il faut d’abord installé les pré-requis suivants (exemple pour Ubuntu ou Debian, à adapter si vous êtes sur une autre distribution Linux):

# apt-get install dialog
# apt-get install g++

puis enfin compiler MRD6:

# wget http://fivebits.net/files/mrd6/mrd6-0.9.6.tar.gz
# tar xvf mrd6-0.9.6.tar.gz
# cd mrd6-0.9.6
# make config

# make install

Configuration de MRD6

Un petit “man mrd6″ nous indiques que le fichier de configuration doit se trouver sous /etc/mrd6.conf

# sudo vi /etc/mrd6.conf
log {
/* Generation des logs dans /var/log/mrd6.log */
attach default “/var/log/mrd6.log” extradebug;
}
load-module console;
load-module mld;
load-module pim;
pim {
enable bsr-candidate;
enable rp-candidate;
}
groups {
ff00::/8 {
pim {
enable rp_adv;
}
}
}

On lance le daemon MRD6 avec la commande suivante:

# sudo /usr/local/sbin/mrd -f /etc/mrd6.conf

On peut vérifier les messages générés par le daemon en regardant le fichier de log:

# tail -f /var/log/mrd6.log
[Jan 29 14:25:45:413840] This is `pc-nico-ubuntu’ running mrd6 0.9.6 ($Rev: 1711 $) the IPv6 Multicast Routing Daemon, in Linux 2.6.22-14-generic[Jan 29 14:25:45:414542] [eth0] PIM, Has link-local address, changed to LOCAL_READY.

Si tout marche bien vous avez donc une machine permettant de faire du routage multicast en utilisant les protocoles IGMP pour les clients et PIM-SM pour la communication avec les autres routeurs du réseau.

Le mode FTP actif

C’est le mode par défaut des clients FTP. Le client établi dans un premier temps une session TCP sur le port 21 (FTP) du serveur (”control channel”). Une fois la session établie et l’authentification FTP acceptée, c’est le serveur qui établi une session TCP (avec le port source 20, FTP-DATA) vers un port dynamique du client (”data channel”).

Le mode FTP passif

Il faut garder en mémoire que le mode passif est conseillé à partir du moment ou les clients peuvent se trouver derrière un Firewall/NAT. En effet dans ce mode, toutes les initialisions de sessions TCP se font à partir du client.

Comme pour le FTP actif, le client établi une première session TCP sur le port 21 (FTP) du serveur (”control channel”). Une fois la session établie et l’authentification FTP acceptée, on demande au serveur de se mettre en attente de session TCP grâce à la commande PASV. Alors le client peut établir une seconde session TCP sur un port dynamique vers le serveur (”data channel”).

Le numéro de port dynamique est transmis du serveur vers le client suite à la commande PASV. On peut réduire la plage de port en configurant le serveur FTP. Par exemple, pour le serveur pro-ftpd:

# vi /usr/local/etc/proftpd.conf
…
PassivePortRange 30000 32000
…

Installation

Exemple d’installation donnée sous Linux Ubuntu (à adapter selon votre distribution)

Sur Ubuntu:
# sudo apt-get install gnugk

Sur Fedora:
# yum install gnugk

Configuration

Les options sont réunies dans le fichier /etc/gatekeeper.ini. Une description des options est disponible en Français ou en Anglais (souvent plus à jour).

On commence par sauvegarder le fichier par défaut (si il existe):

# sudo mv /etc/gatekeeper.ini /etc/gatekeeper.ini.default

Ensuite on édite un nouveau fichier avec nos options:

# sudo vi /etc/gatekeeper.ini
[Gatekeeper::Main]
Fortytwo=42
Name=MonGK
StatusPort=7000
[GkStatus::Auth]
rule=password
gkadmin=secret

Premier test en ligne de commande

Nous allons lancer le daemon GNUgk en mode foreground:

# gnugk -tt -c /etc/gatekeeper.ini

Ensuite on lance un premier client ohphone (très utile pour les tests, c’est en fait un client H.323 en ligne de commande). On déclare donc ce client H.323 avec un nom d’utilisateur Nicolargo (-u nicolargo) en mode écoute (-l) et avec un décrochage automatique appel (-a).

# ohphone -l -a -u nicolargo

GNUgk dispose par défaut d’un mécanisme permettant de déclarer son existence sur le réseau. Selon la configuration de ce dernier, il se peut que l’auto-détection du Gatekeeper par OHphone ne fonctionne pas:

…
Searching for gatekeeper…
No gatekeeper found.
…

Dans ce cas il faut ajouter l’option suivante à la commande ohphone: -g <adresse IP du Gatekeeper>

Si tout se passe bien, vous devrier voir la ligne suivante dans les logs gnugk:

2008/04/10 16:54:54.903 2 RasSrv.cxx(413) GCF|192.168.29.125|nicolargo:h323_ID|terminal;

Sur une autre machine du réseau, vous pouvez lancer une autre commande ohphone qui va déclarer un deuxieème utilisateur (-l popof) et appeler l’utilisateur nicolargo:

# ohphone -u popof nicolargo

Deux nouvelles lignes vont alors apparaître au niveau des logs gnugk. La première confirme l’enregistrement du client H.323 popof. La seconde montre qu’il y a eu un appel entre

2008/04/10 17:01:26.446 2 RasSrv.cxx(413) GCF|192.168.29.77|popof:h323_ID|terminal;

ARJ|192.168.29.125:1720|nicolargo:h323_ID|popof [::ffff:192.168.29.77]:h323_ID|true|routeCallToGatekeeper;

La configuration est maintenant validé. Vous pouvez donc tuez le processus gnugk et le relancer proprement via les commande système:

Sur Ubuntu:
# /etc/init.d/gnugk start

Sur Fedora:
# service gnugk start

Test avec un “vrai” client H.323

J’utilise Xmeeting, un très bon client open-source sur mon Mac. Voici la configuration à faire pour déclarer ce client sur notre serveur GNU Gatekeeper (cette procédure est applicable sur d’autres clients H.323, software ou hardware).

On directement dans les propriétés puis dans la section Comptes:

Ensuite, on va dans l’onglet Configurations pour y associer le Gatekeeper:

Enfin on vérifie que l’enregistrement c’est bien déroulé:

Administration de GNU Gatekeeper

Il est possible de se connecter à distance à GNU Gatekeeper en utilisant un telnet sur le port 7000:

# telnet <adresse IP gatekeeper> 7000
…
?
AllRegistrations
RCF|192.168.1.100:1720|popof:h323_ID|terminal|1420_endp
RCF|192.168.29.77:1720|nicolargo:h323_ID|terminal|4393_endp
Number of Endpoints: 2
quit

Et voilà, vous avez maintenant à disposition un bon Gatekeeper libre performant et stable !

Backup de l’ancienne version

Il est préférable de sauvegarder son ancienne configuration… au cas ou..

# cd /tmp
# tar zcvfh ./nagios-backup.tgz /usr/local/nagios

Si quelque chose se passe mal au niveau de la mise à jour, il sera toujours possible de revenir en arrière en saisissant les commandes suivantes:

# cd /tmp
# tar zxvf ./nagios-backup.tgz

Téléchargement de la dernière version

Il faut au préalable des opérations suivantes, se loguer en tant qu’utilisateur nagios afin que les fichiers soient générés avec les bons droits.

Sur Fedora:

# su -l nagios

Sur Ubuntu ou Debian:

# sudo -s nagios

Puis télécharger la dernière version stable (3.0.1 au moment de l’écriture de ce billet).

# mkdir src
# cd src
# wget http://switch.dl.sourceforge.net/sourceforge/nagios/nagios-3.0.1.tar.gz

Compilation et installation

On décompresse puis on lance la compilation:

# tar zxvf nagios-3.0.1.tar.gz
# cd nagios-3.0.1
# ./configure –with-command-group=nagios
# make all

Si la compilation se termine sans erreur, vous pouvez l’installer sur votre système, sinon je vous conseille de poster votre erreur dans le forum officiel de Nagios:

# make install

Vérification de la configuration et redémarrage de Nagios

On va dans un premier temps vérifier que nos fichiers de configurations sont compatibles avec cette nouvelle version:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Si vous avez ce rapport à la fin:
Total Warnings: 0
Total Errors: 0

C’est bon pour vous

Finalement on relance Nagios (en repassant en mode root) dans la nouvelle version:

Sur Fedora:

# service nagios restart

Sur Ubuntu ou Debian:

# /etc/init.d/nagios restart

Et voilà le travail !

Nous allons pour cela utiliser le logiciel open-source WeatherMap4RRD. Ce dernier peut produire des cartes de ce type:

Vous avez besoin de quoi:

• d’un logiciel permettant de produire des fichiers RRD (par exemple MRTG ou CACTI). Ces fichiers servirons de sources pour la production de la carte.
• d’une carte de votre infrastructure (par exemple une carte de France ou de votre bâtiment) au format PNG mais n’est pas obligatoire…
• d’un système d’exploitation de type Linux ou Windows avec un Apache/PHP correctement configuré.
• de ce tutorial…

Installation de WeatherMap4RRD

La dernière version (1.2) date de décembre 2005 et elle est téléchargeable à cette adresse. Il existe deux versions: une version Perl (à lancer automatiquement par crontab et qui génère la carte sous la forme d’un fichier) et une version PHP qui génère directement une page HTML avec la carte. J’ai choisi pour ce tutorial d’installer cette deuxième version (le Linux magazine de mars 2008 parle de la version Perl).

# wget http://weathermap4rrd.tropicalex.net/get_file.php?id=19&path=/code&filename=weathermap4rrd-php-1.2final.tgz

# tar zxvf weathermap4rrd-php-1.2final.tgz
# cp -R weathermap4rrd-php-1.2final /var/www/html/weathermap4rrd
(remplacer /var/www/html/ par la racine de votre serveur Web)

En pointant un navigateur Web vers l’adresse de votre serveur vous devriez voir une carte par défaut.

http://localhost/weathermap4rrd

Si vous rencontrez l’erreur suivant:

WeatherMap4RRD 1.2 : An error occured : file /weathermap.conf not found. You should check that /weathermap.conf file exists.

Il est fort possible que cela vienne du fait que le script PHP n’arrive pas à trouver le fichier weathermap.conf dans votre arborescence de fichier. Le plus simple est alors de le passer un paramètre au script PHP:

http://localhost/weathermap4rrd/index.php?config=/var/www/html/weathermap4rrd/weathermap.conf

Configuration de WeatherMap4RRD

Il faut éditer le fichier weathermap.conf avec votre éditeur de texte favori.

La première chose à faire est de déclarer le nom de l’image de fond (si vous n’en avez pas, commentez la ligne avec un #). Il faut préciser au script la taille de l’image (comme si il ne pouvait pas le faire tout seul…)

BACKGROUND macarte.png

HEIGHT 800

WIDTH 421

On continue en fixant la taille de la fonte (valeur de 1 à 5), personnellement, je trouve que 1 est une bonne valeur pour la lisibilité.

FONT 1

Ensuite on fixe la position et les caractéristiques de la légende.

LEGENDPOS 500 380

LEGENDSTYLE line

Ensuite on fixe la position et les caractéristiques du titre de la cartee

TITLE “Ma carte à moi”

TITLEPOS 0 1

TITLEBACKGROUND 255 255 255

TITLEFOREGROUND 0 0 0

On doit ensuite configurer l’emplacement des fichiers HTML et PNG générés par le script (attention, le répertoire doit être en lecture/écriture pour l’utilisateur apache):

OUTPUTFILE /var/www/html/weathermap4rrd/weathermap.png

HTMLFILE /var/www/html/weathermap4rrd/weathermap.html

On entre enfin dans le vif du sujet en définissant les noeuds de notre réseau et les liaisons entre ces noeuds.

NODE PointA
POSITION 300 300
LABELTYPE round

NODE PointB
POSITION 550 75
LABELTYPE round

LINK A-B
NODES PointA - PointB
TARGET /usr/share/cacti/rra/firewall_traffic_in_130.rrd
INPOS 2
OUTPOS 1
UNIT bytes
BANDWIDTH 2000 4000
DISPLAYVALUE 1

La principale difficulté est de trouver l’emplacement du fichier RRD correspondant à cette liaison. Sous Cacti, le plus simple est d’aller dans le menu “Data sources” de la console d’administration, d’aller dans les détails de la liaison et de regarder le nom du fichier RRD.

Une fois le fichier de configuration sauvegardé, votre nouvelle carte devrait s’afficher sans aucun problème !

Si vous avez besoin d’aller plus loin dans la configuration, je vous conseille cette lecture sur le site officiel (en Anglais).

Source: Nagios 2.x sous Fedora Core 6 (installation par RPM)
vers
Cible: Nagios 3.0 (à partir des sources)

Préparation de la migration

Sauvegarder toute votre configuration actuelle (version 2.x):

# tar cvf nagioscfg-backup-v2.tar /etc/nagios /usr/lib/nagios/plugins

# tar cvf nagioslog-backup-v2.tar /var/log/nagios

# tar cvf nagioslib-backup-v2.tar /usr/lib/nagios/plugins

On commence par arrêter le daemon Nagios existant:

# service nagios stop

Puis on désinstalle le package RPM de la version 2.x:

# yum -y remove nagios

Installation de la version 3.0

On télécharge la dernière version stable:

# wget http://heanet.dl.sourceforge.net/sourceforge/nagios/nagios-3.0.tar.gz

On décompresse:

# tar zxvf nagios-3.0.tar.gz

# cd nagios-3.0

Puis on compile:

# ./configure –with-command-group=nagios

PS: il faut remplacer le nom du groupe “nagios” par celui configurer dans le fichier nagios.cfg

# make all

Et on installe:

# make install

# make install-init

# make install-config

# make install-commandmode

On installe également l’interface Web:

# make install-webconf

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

# service httpd restart

Résumé de l’installation:

• Répertoire racine de l’installation: /usr/local/nagios
• Script de démarrage: /etc/rc.d/init.d/nagios
• Répertoire des fichiers de configurations: /usr/local/nagios/etc

Configuration de la version 3.0 à partir des fichiers de la version 2.x

C’est là que cela se complique un petite peu. Il faut reprendre les fichier de configuration (.cfg) sauvegarder préalablement et les copier dans le nouveau répertoire.

Je vous conseille de sauvegarder le fichier initial de configuration de la version 3.0:

# cd /usr/local/nagios/etc

# cp nagios.cfg nagios.cfg.v3

# tar zxvf nagioscfg-backup-v2.tar

On recharge ensuite la configuration de la v2:

# cd /usr/local/nagios/etc

# tar xvf nagioscfg-backup-v2.tar

# chown -R nagios:nagios *

# cd /usr/local/nagios/var

# tar xvf nagioslog-backup-v2.tar

# chown -R nagios:nagios *

# cd /usr/local/nagios/libexec

# tar xvf nagioslib-backup-v2.tar

# chown -R nagios:nagios *

On lance alors une vérification de la syntaxe du fichier de configuration (compatibilité v2 avec la v3):

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Il faut juste penser à changer le chemin du “lock file PID”:

# vi /usr/local/nagios/etc/nagios.cfg
…
#lock_file=/var/run/nagios.pid
lock_file=/usr/local/nagios/var/nagios.lock…

Personnellement j’ai eu à résoudre les problèmes suivants:

Warning: comment_file variable ignored. Comments are now stored in the status and retention files.
-> Corrigé en commentant la ligne suivante:
# comment_file=/var/log/nagios/comments.dat

Warning: downtime_file variable ignored. Downtime entries are now stored in the status and retention files.
-> Corrigé en commentant la ligne suivante:
# downtime_file=/var/log/nagios/downtime.dat

Warning: aggregate_status_updates directive ignored. All status file updates are now aggregated.
-> Corrigé en commentant la ligne suivante:
# aggregate_status_updates=1

Error in configuration file ‘/usr/local/nagios/etc/nagios.cfg’ - Line 433 (UNKNOWN VARIABLE)
-> Corrigé en commentant la ligne suivante:
# check_result_buffer_slots=4096

Une fois les fichiers de configuration validés sans erreurs ni warning, on peut relancer Nagios:

# service nagios start

Et voilà le travail, vous devriez maintenant disposer d’un beau Nagios en version 3.0 !