Ce titre n'est peut-être pas très explicite, qu'est-ce que "dokuwiki", qu'est-ce qu'une "ferme", qu'est-ce que "créer" ?

Cet article va vous présenter ce qu'est dokuwiki, pourquoi je pense que c'est le meilleur moteur de wiki libre, ce qu'est une ferme de wikis et comment faire une ferme de dokuwikis.

I. Pourquoi Dokuwiki ?

DokuWiki est un moteur de wiki libre distribué sous licence GNU GPL créé par Andreas Gohr en juin 2004. Contrairement à la plupart des autres moteurs de wiki, Dokuwiki stocke ses données dans des fichiers textes sur la machine, aucune base de données n'est donc nécessaire (ce qui est, pour moi, un atout non négligeable et très appréciable) !

La dernière version de dokuwiki est disponible sur le site officiel.

Un autre gros avantage de Dokuwiki est sa grande communauté de contributeurs. En effet, dokuwiki est tellement souple que beaucoup de monde à décidé de développer dessus. Par exemple, si vous allez voir sur la page officielle des plugins, vous pourrez vous rendre compte qu'il y en a énormément (570 à l'heure où j'écris ces lignes), pour tous les goûts, du plus utile au plus futile :)
L'installation d'un plugin est également très pratique : tout est contenu dans un répertoire, donc pour supprimer un plugin, il vous suffit de supprimer ce répertoire. Rien ne reste, pas de configuration orpheline, pas de fichiers temporaires, pas d'inclusion dans d'autres fichiers, etc. De plus, tout est faisable via l'interface web d'administration de Dokuwiki.

Un autre avantage qui à été décisif pour l'adoption de Dokuwiki dans mon travail : ses très nombreux modes d'authentification. En effet, comme je vous l'ai dit, ce logiciel est tellement souple que la communauté à créé un grand nombre de modules d'authentification. Au programme, en plus des comptes locaux, vous pouvez vous identifier sur Dokuwiki via MySQL, LDAP, pgSQL, punbb, CAS, drupal, htaccess, radius, pam, shibboleth, imap, xmpp, etc. Vous pouvez coupler toutes ces authentifications, les utiliser séparément, et tout un tas d'autres méthodes.

Pour la petite histoire, dans mon travail (DSI de l'Université Nancy 2), j'ai mis en place une authentification qui peut-être différente en fonction des fermes parmi CAS, comptes locaux, shibboleth, le tout couplés ou séparément.

Bref, je pourrais m'étendre encore longtemps sur les vertus de ce moteur de wiki mais pour résumer, je peux dire qu'il s'agit d'une vraie mine d'or :)

II. Qu'est-ce qu'une ferme de wikis ?

Voici en l'arborescence simplifiée d'un répertoire Dokuwiki :

|_conf (répertoire de configuration du wiki)
|_data (contient les données du wiki comme les pages, les images, les documents joints, etc.)
|_lib (contient les plugins, les templates du wiki)
|_inc (contient les fichiers de langue, les modules d'authentification, etc.)

Admettons que vous souhaitez héberger plusieurs wikis sur une machine (par exemple 24 wikis). Avec un système de wiki "classique", il faudrait 24 répertoires avec 24 répertoires conf, data, lib, inc, etc., il faudrait installer 24 fois les mêmes plugins, 24 fois les mêmes modules d'authentification et faire 24 mises à jour si besoin est.
Bref, un vrai calvaire (surtout quand on dépasse les 50 wikis) !

Le principe des fermes est le suivant :

Il y a un répertoire maître qui contient tous les modules, tous les plugins, tous les templates et après, pour chaque nouveau wiki, il y a un répertoire contenant un sous-répertoire conf (qui contiendra la configuration de chaque wiki) et un sous répertoire data (qui contiendra les données de chaque wiki). C'est tout. Chaque wiki (appelé aussi animal) ira chercher des modules, ses templates, ses librairies dans le répertoire maître.

Au final, nous obtiendrons donc une arborescence de ce type :

|_master
  |_lib
  |_inc
|_wiki1
  |_conf
  |_data
|_wiki2
  |_conf
  |_data
|_wiki3
  |_conf
  |_data

Plusieurs gros avantages à cela :

• Limitation de la place occupée sur le disque dur : nous n'avons plus 50 fois le même répertoire lib/ ou inc/
• Facilité de maintenance : il suffit d'installer une seule fois un plugin sur le wiki master pour que tout le monde y ai accès, de même, il suffit de mettre à jour un plugin ou même l'intégralité de Dokuwiki uniquement sur le master pour que les changements soient appliqués à tous les animaux.
• Une création rapide : pour créer un nouveau wiki, on utilise un script (fourni ci-dessous) auquel on passe en paramètre le nom du wiki. En clair, dans un terminal on tape ./addanimal.sh wiki4 et tout est créé automatiquement !

III. Comment mettre en place une ferme de wikis avec DokuWiki ?

1. Introduction

Avant tout, il faut savoir qu'il existe deux "types"de fermes de wiki :

1. Une version avec des wikis accessibles via ce genre d'URL : monsite.fr/wiki1, monsite.fr/wiki2, etc. (c'est cette version que je présenterai ici)
2. Une version avec des URL du type cname (wiki1.monsite.fr, wiki2.monsite.fr, etc.)

Dans cet article, je vais parler de la première solution. Pourquoi ? Tout simplement parce que c'est cette solution que j'ai du mettre en place à mon travail et que je maîtrise donc le mieux.

De plus, sachez que je ne parlerai que d'une authentification via les comptes locaux de dokuwiki (afin de ne pas tout embrouiller). Pour info, dokuwiki est extrêmement complet au niveau des modules d'authentification. Par exemple, à mon travail, j'ai mis en place une authentification plain (compte locaux) ainsi que LDAP, CAS et Shibboleth.

2. Préparation

Rendez-vous sur la page de téléchargement officielle de dokuwiki et téléchargez la dernière version. Ensuite il faut extraire cette archive en tant que dossier master sur votre serveur.

Note : Ici, j'appelle mon répertoire principal "master" mais vous pouvez l'appeler autrement, il faut juste le renseigner dans les différents fichiers de configuration. De plus, je pars du principe que vous utilisez une arborescence comme celle-ci (avec, pour document root : /var/www/wiki/php):

|_var
  |_www
    |_wiki
      |_addanimal.sh
      |_php
        |_master
          |_lib
          |_inc
        |_wiki1
          |_conf
          |_data
        |_wiki2
          |_conf
          |_data

• Nous avons donc notre répertoire master, créez un fichier ./master/inc/preload.php et copiez-y ces lignes :

<?php
// the home directory for all animals and the farmer located in subdirectories
$farmdir = '/var/www/wiki/php/';
 
// don't do anything if the animal doesn't exist
if(isset($_REQUEST['animal'])) {
    if(!is_dir($farmdir . $_REQUEST['animal'])) {
        nice_die("Ce wiki n'existe pas !");
    }
    if($_REQUEST['animal']=="master") {//si on appelle le master
    nice_die("Interdit d'appeler le master");
    }
    if(!defined('DOKU_CONF')) {
        define('DOKU_CONF', $farmdir . $_REQUEST['animal'] . '/conf/');
    }
    //  correct paths according to animal and make nice looking in HTML source
    if(!defined('DOKU_URL')) define('DOKU_URL',preg_replace('/(.+)\/([^\/]+)\//','$1/'.$_REQUEST['animal'].'/',getBaseURL(true)));
    if(!defined('DOKU_REL')) define('DOKU_REL',preg_replace('/([^\/]+)\/\/([^\/]+)\/(.+)\//','/$3/',DOKU_URL));
 } else {
    // don't do anything on the farmer instance
    return;
}

• Ensuite, il faut créer un fichier .htaccess dans le répertoire wiki contenant ceci :

#Définition des règles de redirection
RewriteEngine On
RewriteRule index - [L]
RewriteRule ^([^/]+)/(.*) /home/www/wiki/php/master/$2?animal=$1 [QSA,L]
RewriteRule ^([^/]+)$ http://wiki.votre-site.fr/$1/ [QSA,L]

• Enfin, il vous faut créer un fichier addanimal.sh (ou n'importe quel autre nom) que vous placerez dans /var/www/wiki/ (pas dans le répertoire php, de manière à ce que le serveur apache n'ai pas accès à ce fichier). Voici le fichier addanimal.sh pour des comptes locaux :

#!/bin/bash
#
# Création d'animal pour une ferme dokuwiki
# benjamin@generation-linux.fr - 10/12/09
#
 
MASTER_DIR=/var/www/wiki/php/master
FARM_DIR=/var/www/wiki/php
 
if [ $# -ne 1 ]; then
    echo "Usage: $(basename $0) [animal_name]"
   exit 1
fi
 
if [ ! -d $MASTER_DIR ]; then
    echo "ERREUR : $DOKUWIKI n'existe pas !"
    exit 1
fi
 
if [ ! -d $FARM_DIR ]; then
    echo "ERREUR : $FARM_DIR n'existe pas !"
    exit 1
fi
 
 echo ">> Ajout de la ferme $1" 
  FARM=${FARM_DIR}/$1
  FARM_TITLE=$1
 
if [ -d $FARM ]; then
    echo "ERREUR : $FARM existe deja !"
    exit 1
fi
 
 echo ">> Creation des repertoires"
mkdir -p ${FARM}/{data,conf}
chmod 755 ${FARM}/{data,conf}
cp -a ${MASTER_DIR}/data/* ${FARM}/data
cp -a ${MASTER_DIR}/conf/* ${FARM}/conf
find ${FARM}/data -type d -exec chmod 755 {} \;
touch ${FARM}/conf/{local.php,local.protected.php,acl.auth.php,users.auth.php}
chmod 666 ${FARM}/conf/{local.php,acl.auth.php,users.auth.php}
 
 echo ">> Creation des fichiers de configuration"
  echo "<?php
  \$conf['title'] = '${FARM_TITLE}';
  \$conf['lang'] = 'fr';
  \$conf['savedir']     = '${FARM}/data';
  \$conf['useacl'] = 1;
  \$conf['template']    = 'nancy2';
  \$conf['plugin']['sidebar']['enable'] = 1;
  \$conf['authtype'] = 'plain';
  \$conf['superuser'] = '@admin';" > ${FARM}/conf/local.php
 
 echo ">> Creation des comptes admin"
  echo "# <?php exit()?>
  admin:d51ba34ef116c2cffacfa2125b87e6b5:Administrateur:votre@mail.fr:admin,user" > ${FARM}/conf/users.auth.php

 
echo ">> Mise en place des permissions"
echo "# <?php exit()?>
* @admin 255
* @ALL 1" > ${FARM}/conf/acl.auth.php
 
 
chown -R apache2:apache2 ${FARM}
echo ">> Ferme $1 installee !"
 
exit 0

Note : Attention à l'antépénultième ligne, j'ai mis apache:apache car je suis sous RedHat, sous Ubuntu et Debian cela doit être www-data:www-data et peut-être d'autres noms sous d'autres systèmes.

Il ne vous reste plus qu'à rendre ce fichier exécutable grâce à cette commande : chmod +x /var/www/wiki/addanimal.sh

Pour créer un nouvel animal, il suffit de taper : ./addanimal.sh nom_animal

Simple non ? :)

3. Personnalisation

Afin de supprimer les liens dans l'administration (gestion des plugins, gestion de la configuration, gestion des réversions, etc.), il faut créer des fichiers disabled dans chaque répertoires :

• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/plugin/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/revert/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/config/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/popularity/disabled

4. Conclusion

Ainsi s'achève ce tutoriel sur la mise en place d'une ferme de wikis avec Dokuwiki. Comme vous avez pu vous en rendre compte, cela est très simple à mettre en œuvre et s'avère très pratique pour les fans de wikis (moi même j'en utilise plusieurs régulièrement).

Pour la petite anecdote, voici un screenshot de mon wiki au boulot (c'est moi qui ai fait le design à partir ce celui-ci) :

De plus, je vous met à disposition le (petit) diaporama de ma présentation de cette solution : presentation-DW.pdf.

Pour ceux que ça intéresse, je vais bientôt mettre en place ce système sur mon serveur pour offrir à qui le souhaite son ou ses wikis rapidement et gratuitement. Si cela vous intéresse, n'hésitez pas à me le faire savoir ;)

Pour tout ceux qui souhaitent avoir un agenda toujours à porté de main, voici un outil bien pratique qui fonctionne en ligne de commande. Vous aurez accès à un calendrier en moins de deux, avec vos événements de surplus ! Voyons tout cela de plus près ...

Rédigé par Plonstic (que j'ai contacté suite à son commentaire, merci à lui !)

Avant propos :
Cet article contient quelques lignes de code. En tant qu'auteur j'ai pris soin de les vérifier sur mon système. Cependant, dans votre cas, il se peut que certains résultats ne soient pas ceux escomptés.
De manière générale, il faut TOUJOURS vérifier les lignes de code que l'on vous fait exécuter (c'est la première faille des OS ;D). Les risques restent toutefois limités, car rien n'est fait en root ici.
Toutes les actions peuvent être effectuées graphiquement (décompression d'archive, édition de fichiers, etc.). Pour des raisons "d'universalité" j'ai préféré présenter les lignes de commandes (de toute façon c'est un calendrier en ligne de commandes !)
Bonne lecture...

Présentation

pal est un calendrier en ligne de commande qui affiche des événements à la manière de la commande cal des distributions UNIX, de gcal de GNU ou de calendar des distributions BSD.

Les avantages :

• Un calendrier avec mise en évidence des jours auxquels sont associés un/des événements
• Organisation des événements par type et couleurs
• Recherche d'événements par expressions régulières
• Prise en charge des événements officiels (vacances, saints, journées historiques, etc.)
• Les événements peuvent être ponctuels ou répétitifs (quotidiens, hebdomadaire, mensuels, annuels) avec date de début et date de fin
• Ajout des événements en ligne (option -m ) ou en externe (éditions de fichiers)
• Exportation en HTML ou LATeX.

Les inconvénients :

• Ne peut pas récupérer les événements sur internet
• N'est pas compatible vcal
• En ligne de commande (hum mais c'est l'intérêt ça, non ?!)

Mais ça peut se faire avec des scripts (ce n'est pas expliqué ici).

1. Installation

Pour les distributions Debian ou Ubuntu, on installera le paquet pal :
sudo aptitude install pal


Pour les autres, vous trouverez les sources ici.

2. Utilisation

2.1. Lancement

2.2. Édition

2.3. Recherche

2.4. Exportation

Note : l'option -c permet de spécifier le nombre de "lignes"
(exemple)

2.5. Autres

3. Configuration

Le dossier de configuration de pal pour les utilisateurs est .pal/ dans votre home ($HOME/.pal/).

3.1. Fichier de configuration pal.conf

Pour éditer les préférences de pal (nombre de lignes, jour du début de semaine, etc.), il faut éditer le fichier pal.conf

Avant tout, on part du fichier de configuration par défaut que l'on copie dans le dossier de configuration personnel :
cd
mkdir .pal
cp /etc/pal.conf ~/.pal/


Puis on l'édite avec un éditeur de textes (ici nano car il est fourni par défaut en général) :
nano ~/.pal/pal.conf


Le fichier étant très bien commenté, je vous laisse le parcourir et adapter pal comme bon vous semble.
Notons tout de même les lignes commençant par 'file'. Elles permettent d'ajouter des événements contenus dans des fichiers externes. Ces fichiers d'événements, par défaut, sont pour les États-Unis, commentez/supprimer toutes les lignes qui ne vous intéressent pas.

3.2. Fichiers d'événements

Les fichiers d'événements permettent de définir en externe des événements. Ils vont être plus pratiques que l'option -m pour ajouter un grand nombre d'événements au calendrier.
Pour vous montrer comment ça marche, on créera un fichier d'événements pour les jours notables en France (nouvel an, fêtes nationales, etc.).

Commençons par télécharger des définitions d'événements (bsdcalendar), ce qui nous facilitera la tâche :
cd /tmp #on se met dans le dossier temporaire
# téléchargement
wget http://downloads.sourceforge.net/project/bsdcalendar/bsdcalendar/0.9/bsdcalendar-0.9.tar.bz2?use_mirror=freefr
tar -xvjf bsdcalendar-0.9.tar.bz2 #décompression


Ainsi, le dossier /tmp/caledar/calendars/fr_FR.ISO-8859-1 contient des fichiers d'événements dont il nous faudra adapter le contenu pour pal.
Copions le fichier calendar.jferies dans le dossier de configuration de pal :
cp /tmp/calendar/calendars/fr_FR.ISO-8859-1/calendar.jferies ~/.pal/

Dans un premier temps, il faut changer les commentaires. En effet, les commentaires de pal sont des lignes commençant par #, tandis qu'ils sont délimités par /* ... */ dans le fichier que l'on a :
sed -i 's/^[ \t]*\/\?\*\/\?/#/' ~/.pal/calendar.jferies
sed -i 's/LANG/#LANG/' ~/.pal/calendar.jferies


Ensuite, pal définit les événements récursifs en mettant des zéros (0) pour les années (événement annuels) et pour les mois (événement mensuels) :
sed -i 's:\([0-9][0-9]\)/\([0-9][0-9]\)\*\?:0000\1\2:' ~/.pal/calendar.jferies


Continuons avec les événements référencés par rapport à Pâques (Easter). pal utilise le mot clé 'Easter' pour référencer par rapport à Pâques.  'Easter+nnn'  définit  un événement intervenant  nnn jours après Pâques (il faut mettre 3 chiffres) :
sed -i 's/Easter+\([0-9]\)[ \t]/Easter+00\1\t/' ~/.pal/calendar.jferies
sed -i 's/Easter+\([0-9][0-9]\)[ \t]/Easter+0\1\t/' ~/.pal/calendar.jferies


Occupons nous maintenant de la fête des mères (dernier dimanche de mai), celle des pères (troisième dimanche de juin) et les changements d'heures.
pal permet de définir un événement qui intervient le Nième jour d'un mois avec '*mmnd'. 'mm' est le mois (10 pour octobre), 'd' le jour (1=lundi, 7=dimanche).
Exemple : *0547  (06=mai; 4="quatrième";  7=dimanche  ==> dernier dimanche de mai).
On fait la modif avec :
sed -i 's/May Sun+2/*0547/' ~/.pal/calendar.jferies
sed -i 's/June Sun+2/*0637/' ~/.pal/calendar.jferies
sed -i 's:03/SundayLast:*0347:' ~/.pal/calendar.jferies
sed -i 's:10/SundayLast:*1047:' ~/.pal/calendar.jferies


Il faut aussi définir, en début du fichier, les caractères d'affichage des événements (de par et d'autre de la date) et leur type. Pour cela on ajoute en première ligne : 'FR France' où 'FR' sont les caractères d'affichage et 'France' le type :
sed -i '1i\FR France' ~/.pal/calendar.jferies


Pour que les caractères accentués soient acceptés par pal il est nécessaire de convertir le fichier en utf-8 avec iconv (paquet du même nom sous Débian et dérivés)
iconv -f ISO8859-1 -t utf-8 ~/.pal/calendar.jferies calendar.jferies >temp
mv temp ~/.pal/calendar.jferies


Enfin on ajoute le fichier d'événements dans pal.conf pour qu'il le prenne en compte :
sed -i '1i\file calendar.jferies (magenta)' pal.conf


Il ne vous reste plus qu'à créer vos propres fichiers d'événements (pour les anniversaires c'est bien pratique :D).
N'oubliez pas de regarder le manuel de pal pour plus d'information (je n'ai pas tout décrit ici).

4. Conclusion

Voili, voilou, vous connaissez un nouveau logiciel bien sympathique.
J'ai essayé de vous montrer l'essentiel des fonctionnalités et configurations. Il en reste encore donc n'hésitez pas à consulter le manuel (je sais, je me répète, mais il y a tout dedans, ça évite les questions inutiles ...).

Vous pouvez l'ajouter dans votre .bashrc pour l'avoir au démarrage des terminaux.
Je vous conseillerai de ne pas trop abuser des événements (les saints et autres proverbes), ça devient vite ennuyeux et on ne voit plus l'essentiel. Mais bon, je dis ça, c'est à vous de voir !

Il existe d'autres calendriers en ligne de commande (voir le haut de l'article) et graphiques (je vous laisse le plaisir de chercher avec votre moteur de recherche favori :D).

À plus ..!

Voici aujourd'hui une petite astuce que j'utilise très régulièrement et que je souhaitais partager avec vous : avoir, en une seconde, un calendrier entier dans votre terminal.

C'est un truc tout bête mais je sais que moi je ne peux plus m'en passer ! Vous voulez en savoir plus ? Dans ce cas, lisez la suite !

I. La commande

La commande pour faire apparaitre un calendrier dans votre termanal est toute simple :

cal

Si vous la tapez comme ça, sans option, vous verrez apparaitre le mois courant (avec le dimanche comme premier jour de la semaine) et la date d'aujourd'hui surlignée.

II. Les options intéressantes

Voici les option intéressantes de cette commande :

• cal -3 : affiche les 3 mois "en cours", c'est à dire le mois précédent, le mois ne cours et le mois suivant

• cal -y : affiche toute l'année en cours

• cal -m : affiche le calendrier avec les semaines commençant par le lundi

Vous pouvez bien entendu coupler ces paramètres. Par exemple, cal -ym :

III. Astuce

L'astuce que j'utilise sur mes machines : je créé un alias (voir cet article) caly qui est en fait la commande ci-dessus : cal -ym.

Voila, un petit article rapide mais, je pense, qui peut être très utile :)

À bientôt !

J'ai découvert il y a quelques temps un navigateur web léger et rapide. Il s'agit de Midori.

Midori est basé sur GTK+2 et WebkitGTK+ (un portage de Webkit pour GTK+). C'est d'ailleurs le navigateur web du projet XFCE.

La dernière version est la 0.2.1 sortie le 14 novembre 2009.

Pour ceux qui se le demande, ce logo représente une patte de chat verte stylisée.

C'est un navigateur encore jeune, mais il est déjà assez complet et performant. Personnellement j'utilise la version git, de développement, pour suivre les évolutions qui sont assez rapides, mais qui est quand même relativement stable, je dois avoir un crash toutes les quelques heures au maximum.

Un aperçu des fonctionnalités :

• Intégration avec GTK+2.
• Rendu rapide et respectueux des normes grâce à Webkit.
• Onglets et gestions des fenêtres et session.
• Gestion des signets (marques-pages).
• Scripts et styles utilisateur.
• Barre d'adresse "intelligente".
• Vérification orthographique.
• Interface configurable.
• Suppression des données personnelles (historiques, cookies, "cookies Flash") et gestionnaire de cookie.
• Page d'appel rapide (comme FastDial ou SpeedDial).
• Personnalisation des barres d'outils.

Utilisation et paramétrage:

Midori à une interface semblable à la plupart des navigateurs, vous ne serez pas trop surpris.

Midori à un tableau latéral qui permet d'afficher les extensions, l'historique, les télechargements...

• Les scripts utilisateurs permettent principalement d'agir sur les pages, comme Greasemonkey sous Firefox, d'ailleurs beaucoup de scripts Greasemonkey peuvent être utilisés avec Midori. Ces scripts sont à placer dans le répertoire ~/.local/share/midori/scripts, les styles dans le répertoire ~/.local/share/midori/styles. Un exemple : FlashBlock WannaBe. Les styles sont des feuilles de style (CSS) appliqués à certains/tous les sites. Pour en trouver : http://userstyles.org/.
• Parmi les extensions proposées avec Midori, il y a un bloqueur de pub, une fonction "cadre" pour afficher plusieurs pages en parallèle, la gestion des mouvements de souris ("mouse gesture"), un cache web,...
• Il faut préciser la langue pour le correcteur orthographique. Il doit être paramétré avec "fr_FR" pour le français.
• Il est possible de choisir son agrégateur de flux RSS, qu'il soit local ou en ligne. Pour les navigateurs en ligne, il suffit d'entrer  : « midori » suivi d'une espace et du lien de souscription terminé par les caractères « %s » (par exemple, pour Netvibes : midori http://www.netvibes.com/subscribe.php?url=%s).

En conclusion, je dirait que si vous cherchez un navigateur web léger, rapide, configurable et en GTK+2 je vous conseille fortement Midori. Il n'a peut être pas toutes les extensions de Firefox, mais grâces aux scripts et aux extensions présente par défaut , il présente les fonctions essentielles et d'autres très pratique.

Si vous préférez Qt je vous conseille aussi Arora. Je vous ferais aussi bientôt un article sur un navigateur un peu plus particulier : uzbl.

Site officiel.

La page de documentation pour ubuntu, pour les PPA de la versions de développement.

Maintenant que nous avons un serveur sécurisé avec SSL (voir Dépôt Mercurial sur CentOs, Part 1), nous allons mettre en place le dépôt mercurial.

La structure qui sera mise en place permettra la gestion de multiprojets.

Installation de mercurial :

Ici rien de plus simple étant donné que celui-ci est déjà packagé :

yum install mercurial

Pour afficher le numéro de version de Mercurial mais aussi vérifier que celui-ci fonctionne bien avant de continuer quoi que ce soit il vous faut taper:

hg --version

Il faut maintenant créer un dossier où les dépôt seront stockés :

mkdir -p /srv/hg/cgi-bin

Note: Libre à vous de le changer si celui-ci ne vous convient pas.

Dans le répertoire cgi-bin nous allons y copier le cgi de mercurial :

cp /usr/share/doc/mercurial-1.2/hgwebdir.cgi /srv/hg/cgi-bin/

Note: Il existe deux cgi un pour la gestion de projet unique (hgweb) et un pour la gestions de plusieurs projets (hgwebdir). C'e sont ces scripts qui vont se charger de tout !

Il faut maintenant créer le fichier de configuration hgweb.config dans /srv/hg/cgi-bin/ et y ajouter ces deux lignes :

[collections]
/srv/hg = /srv/hg

Voilà c'est à peu près tout pour la mise en place de Mercurial, reste la configuration d'Httpd.

Configuration d'Httpd

Il faut rajouter les éléments permettant d'indiquer l'emplacement du cgi de mercurial  dans /etc/httpd/conf.d/ssl.conf 


Alias /hg /srv/hg/cgi-bin
<Directory "/srv/hg/cgi-bin/">

DirectoryIndex hgwebdir.cgi
SetHandler cgi-script
AllowOverride All
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/httpd/hg.log

Création d'un projet 

Nous allons créer notre premier dépot dans /srv/hg/MonProjet et donner les droits d'écriture dans le dépôt à apache:

sudo -u apache hg init /srv/hg/MonProjet

Rendez-vous sur https://serveur/hg/hgwebdir.cgi où vous retrouverez votre projet !

Permettre le push

 Avoir accès au dépôt ce n'est pas tout, il faut aussi pouvoir y écrire !

Pour celà il faut créer le fichier /srv/hg/MonProjet/.hg/hgrc et y mettre:

[web]
allow_push = *

L'étoile donne accès à n'importe qui, il faudra changer celle-ci par les noms d'utilisateurs devant avoir accès au dépôt. Il serait malencontreux que tout le monde puisse envoyer des données sur le dépôt.

Sécuriser le dépôt

Il est intéressant et même indispensable de protéger son répertoire pour éviter d'avoir des ennuis.

il faut tout d'abord commencer par créer un fichier qui contiendra les logins et password des personnes autorisées :

htpasswd -c /etc/mercurial/htpasswd remi

Note: Il est important de mettre le htpasswd en dehors des répertoires accessibles par les internautes.

Note: le '-c' n'est à mettre que si le fichier n'existe pas (afin de le créer). 

Pour rajouter un autre utilsateur à la liste il suffira de faire :

htpasswd /etc/mercurial/htpasswd remi

Il faut maintenant placer un fichier .htaccess dans /srv/hg/cgi-bin  :

AuthUserFile /etc/mercurial/htpasswd
AuthGroupFile /dev/null
AuthName "Identification"
AuthType Basic
<LimitExcept GET>
Require valid-user
</LimitExcept>

Désormais lors d'un push, un nom d'utilisateur et un mot de passe seront demandés !

Importation du dépot sur une machine de travail

Maintenant que notre repository est opérationnel, il faut l'importer sur les machines de travail !

Cela se fait très simplement au travers de la commande :

hg clone AdresseWebDuRepo RepertoireDeDestination

Conclusion

Et voilà, à vous les joies de Mercurial !

Améliorations

Un point intéressant serait de modifier le chemin d'accès actuel (https://serveur/hg/hgwebdir.cgi/MonProjet) par quelques chose de plus propre comme : https://hg.serveur/MonProjet.

N'ayant pas de certifs wildcard pour le moment pour mon domaine je ne l'ai pas encore fait. Cet article sera modifié quand je trouverai un peu de temps pour mettre ca en place ;)

L'authentification est ici de type 'Basic' ce qui signifie que les logins/mots de passes seront visibles sur le réseau si le SSL n'est pas activé (ce qui n'est pas notre cas).

Pour toutes remarques/observations n'hésitez pas à m'en faire part !

L'année dernière, comme certains le savent déjà, j'étais en licence professionnelle ASRALL : Administration des Systèmes, Réseaux et Application à base de Logiciels Libres (j'ai déjà présenté cette licence dans cet article).

Tout au long de cette année (au rythme d'une réunion par mois en moyenne), j'ai eu l'occasion de participer à l'élaboration d'un scénario pour un film de promotion de cette licence. Nous avons souhaité faire une présentation humoristique et décalée, je vous laisse admirer le résultat.

N'hésitez pas à commenter et à diffuser cette vidéo !

J'ai le plaisir de vous annoncer la sortie de la nouvelle version de GaCoMa, il s'agit de la version 0.6.

Rappel : GaCoMa est un gestionnaire de collection de jeux vidéos en ligne open source, que vous pouvez installer chez vous, sur un serveur web.

Voici les améliorations apportées sur cette version :

• Suppression du lien “Connexion” dans le formulaire de login
• Correction de la faille XSS dans les fiches des jeux, accessoires et consoles (interprétation des balises HTML)
• Mise en place d'un installeur automatique
• Optimisation du code du calendrier
• Ajout du module lightbox pour la visualisation des photos
• Affichage du mois en lettres pour les dates d'acquisition
• Ajout du filtrage des jeux, accessoires ou consoles en vente ou à l'échange dans les listes de collections

Je pense que cette version peut désormais être installée sur un serveur. Les trous de sécurité les plus importants ont été corrigés et je peux dire que cette version est désormais stable et prête pour une utilisation normale.

Comme toujours, si vous découvrez des bugs, si vous avez besoin d'aide (que ce soit pour l'installation ou pour l'utilisation) ou si vous voulez participer au projet, je vous invite à vous rendre sur notre forum !


Pour obtenir cette nouvelle version, rendez-vous sur la page des téléchargements de GaCoMa.

Bonjour à tous, voila bien longtemps que je n'ai pas posté d'article sur ce blog. Voila qui est donc fait :)

Comme je vous l'avais dit, je n'écrivais plus beaucoup sur Génération Linux car j'étais très pris par un autre projet qui me tiens beaucoup à coeur : GaCoMa.
Voici donc plus de détails sur cette application qui viens tout juste de voir le jour et que vous pouvez télécharger et utiliser à votre guise !

I. Pourquoi GaCoMa

Comme vous le savez peut-être,je suis un grand nostalgique des vieux jeux vidéos (la console la plus récente à laquelle je joue est la Nintendo 64). Pour cette raison, il y a un peu plus de deux ans, je me suis mis à commencer une collection de jeux de Nintendo NES.
Ma collection commençant à prendre de l'ampleur, j'avais besoin d'un logiciel qui me permettait de gérer cette collection, de classer mes différents jeux, accessoires ou consoles.

Après avoir un peu fouillé du côté des logiciels libres, j'ai trouvé GCstar qui était intéressant. Malheureusement, cette application est une application "lourde", il faut l'installer sur son ordinateur est votre collection n'est accessible que depuis votre ordinateur. Le problème étant que je suis sur beaucoup de machines différentes tout au long de la semaine, il me fallait une application web me permettant de gérer tout ça. Ainsi, ma collection serait accessible depuis n'importe où.

J'ai cherché et cherché encore mais n'ai rien trouvé...

J'ai donc décidé de créer cette application. Après tout, j'ai quelques compétences (certes limitées) en dev' web, pourquoi ne pas en profiter ! C'est ainsi qu'est né GaCoMa.

II. Qu'est-ce que GaCoMa

Comme vous l'avez compris, GaCoMa  (qui est l'acronyme de Game Collection Manager) est un gestionnaire de collection de jeux vidéos en ligne. Autrement dit, c'est une application à installer sur un serveur web (apache/php/mysql) qui va vous permettre de faire principalement deux choses :

• Gérer votre collection

Vous pouvez ajouter, modifier et supprimer des jeux, consoles ou accessoires, triés par constructeur et par catégories (NES, SNES, etc.). Vous pouvez y inclure des photos, spécifier que vous voulez vendre ou échanger ce jeu/accessoire/console, etc.

• Montrer à tout le monde votre collection

Votre collection ainsi créée, vous pouvez la montrer à tout le monde ;)

Vous pouvez également faire plusieurs comptes utilisateurs au sein d'une même application. Ainsi, tout un groupe de collectionneurs peuvent se partager la même instance de GaCoMa.

Pour avoir une présentation illustrée, rendez-vous sur le wiki de gacoma !

III. Améliorations

GaCoMa est, à l'heure actuelle, disponible en version 0.5. Le principal problème actuel est la sécurisation des données dans la base de données. En effet, je ne suis pas un pro de la sécurité, je ne sais pas trop quels sont les précautions à prendre pour l'ajout de données dans une base (pour éviter des attaques de type injection SQL).
Pour l'instant, j'ai fais quelques tests et n'ai pas trouvé de failles mais on ne sait jamais.

J'attends donc de la communauté un retour et pourquoi pas une petite contribution pour la codage de cette partie :)

D'autres améliorations sont prévues et notées sur la ToDo list du projet.

VI. Téléchargement

GaCoMa est disponible sur le site officiel du projet : gacoma.org
Vous pouvez le télécharger, l'essayer, le modifier, bref, GaCoMa est sous licence CC BY, ce qui signifie qu'il est ouvert au maximum :)

Si vous découvrez des bugs, si vous avez des idées d'amélioration ou si vous souhaitez faire parti de cette aventure, rendez-vous sur le forum du projet.

Lassé d'utiliser SVN de part plusieurs points j'ai décidé de donner sa chance à Mercurial.

Comme SVN, Mercurial est un système de gestion de versions mais ayant pour avantage la décentralisation des données (dans la même lignée on retrouve aussi GIT).

Introduction

Différents éléments m'ont amené à tenter l'expérience Mercurial :

J'étais désespéré de voir des .svn dans chacun des répertoires de mes projets. Par exemple envoyer son projet 'propre' à quelqu'un nécessitait un peu de bidouille. Avec Mercurial il n'y a qu'un répertoire .hg et pas plus !
Une gestion centralisée/décentralisée est possible, on peut ainsi 'commiter' sur sa propre machine avant de tout envoyer au serveur principal. Très pratique pour sauvegarder une petite mise à jour que l'on ne trouve pas assez 'conséquente' pour un upload sur le serveur. Mais aussi en cas d'absence d'Internet ! On peut ainsi committer quand on veut et où l'on veut !

De plus je trouve la structure générale de Mercurial moins chaotique à mes yeux (J'ai l'impression qu'une installation d'un dépôt SVN met des morceaux un peu partout, ça n'engage que moi). 

Install Time !

Le point qui sera abordé dans ce billet est la mise en place du SSL afin de 'protéger' nos différents envois au serveur. Nous allons voir ici comment créer son certificat et le faire signer par une Autorité de Certification externe.

Clé Privée et CSR

La première étape consiste à se créer une Clé privée ainsi qu'un Certificate Signing Request (Demande de signature de certificat).

La clé sera à conserver très précieusement et ne doit pas être communiquée. Le CSR sera fourni à l'Autorité de Certification qui nous donnera un beau certificat signé !

La création de ces fichiers se fait très simplement :

openssl req -nodes -newkey rsa:2048 -keyout serveur.key -out serveur.csr

Note : Personnellement je remplace le 'serveur' par le nom du domaine qui détiendra le certificat.

Différentes informations vont nous être demandées :

Country Name (2 letter code) [AU]: FR
State or Province Name (full name) [Some-State]: .
Locality Name (eg, city) []: Nancy
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Pulsar
Organizational Unit Name (eg, section) []: IT
Common Name (eg, YOUR name) []: serveur.fr
Email Address []:
A challenge password []:
An optional company name []:

Note : Les trois derniers champs sont optionnels.
Note 2: Le Common Name doit être le nom du domaine à protéger

On obtient désormais nos deux fichiers : serveur.key et serveur.csr !

Il faut maintenant fournir le fichier csr à une Autorité de Certification (dans mon cas Gandi) pour que celui-ci nous fournisse un certificat.

Pour ceux ne souhaitant pas débourser de sousous, le site www.cacert.org signe des certificats gratuitement.

Une fois que l'Autorité de Certification nous fournit le certificat on se retrouve donc avec :

• serveur.key => la clé privée
• serveur.csr => la demande de signature de certificat
• serveur.crt => le certificat signé

Nous allons maintenant copier ces fichiers aux bons endroits :

mv serveur.crt /etc/pki/tls/certs
mv serveur.key /etc/pki/tls/private/serveur.key
mv serveur.csr /etc/pki/tls/private/serveur.csr

On notera que  serveur.key et serveur.csr sont dans le répertoire private afin de les séparer du certificat publique.


Httpd

Il nous faut désormais installer le module SSL pour Httpd :

yum install mod_ssl

Configurons maintenant Httpd pour prendre en compte nos fichiers créés. Pour cela ouvrez le fichier /etc/httpd/conf.d/ssl.conf avec votre éditeur favoris !
Recherchez et changez les champs en fonctions du nom de vos fichiers  :

SSLCertificateFile /etc/pki/tls/certs/serveur.crt
SSLCertificateKeyFile /etc/pki/tls/private/serveur.key

Sauvegardez et relancez Httpd :

service httpd restart

Tentez d'accéder à votre site via https://serveur pour vérifier le bon fonctionnement des manipulations !


Dans le prochain épisode
Nous attaquerons la mise en place du dépôt !

Bonjour à tous,

De nos jours, les entreprises sont de plus en plus dépendantes de leur système d'information d'où l'importance de la disponibilité et de la performance des infrastructures informatiques en place afin de ne pas nuire à la productivité de ces entreprises. Les administrateurs réseaux doivent alors être vigilants et être le plus rapidement informé lors d'une panne. Cet chronique a pour mission de vous guider lors de l'installation et la configuration d'un serveur de "monitoring" sous Nagios qui vous permettra alors d'avoir une vue d'ensemble de l'état de votre réseau informatique.

Introduction

La surveillance d'un réseau informatique de moyenne ou grande taille peut s'avérer cauchemardesque... Il est alors important de se doter d'un bon logiciel de surveillance réseau afin de vous aider, il existe certes des logiciels propriétaires ou vous devrez débourser des milliers de dollars en licences et en support technique. Si vous désirez plutôt opter pour un logiciel open source, gratuit et qui offre des performances exceptionnelles comparables au solutions propriétaires, Nagios est la solution tout indiqué pour être votre assistant.

Mon but n'est pas de vous expliquer les concepts de la surveillance réseau mais de vous démontrer des cas pratiques qui pourrons vous aidez lors de l'implantation de votre serveur Nagios. Plusieurs excellents sites web vous expliquent déjà le concept de la supervision réseau.

Installation

L'installation de Nagios était, auparavant, un exercice fort difficile, il fallait installer Nagios, ensuite il fallait installer les "add-ons" et les "plugins" et s'assurer que toutes les dépendances soient satisfaites, cela devenait alors un véritable puzzle ou l'on ne voyait pas la fin. Jusqu'au temps ou je tombe sur le site web de "Fully automated Nagios" ou quelques contributeurs Linux ont décidé d'offrir une distribution CentOS 5.2 avec Nagios, les "add-ons" et "Plugins" tous déjà installés et prêt à fonctionner. Voici ce qui est déjà installé avec cette distribution:

• Nagios: Coeur de l'application de surveillance réseau.
• Nagios Plug-in: Plug-in pour effectuer le monitoring des équipements réseaux.
• Centreon: Interface web pour Nagios
• Nagvis: Outil permettant de configurer des "maps" réseaux.
• Nareto: Excellent outil permettant de créer des rapports de disponibilité.
• NDOUtils: Module dans Nagios permettant le stockage de données dans une base MySQL.
• NPRE: Module permettant le monitoring actif des équipements réseaux.
• NSCA: Module permettant le monitoring passif des équipements réseaux.
• NSClient++: Application permettant d'effectuer le monitoring de machines Windows.

Téléchargez la dernière version de "Fully automated Nagios" sous forme d'ISO sur le site web et procédez à l'installation en téléchargeant le documentation à cet adresse web :

Documentation d'installation

Les commandes utiles

• Service nagios start (démarrer le service Nagios)
• Service nagios stop (arrêter le service Nagios)
• Service nagios restart (redémarrer le service Nagios)
• Nagios –v /etc/nagios/nagios.cfg (tester  la configuration de Nagios)
• System-config-network (configurer adresse IP statique)
• Service network restart (Reset des interfaces réseaux)

La configuration

Si l'installation est plutôt conviviale et facile, il en est autrement pour la configuration. Tout se fait principalement en ligne de commande à travers divers fichiers, je vais vous montrer la syntaxe général de chaque fichier en tirant un extrait de configuration du fichier. Si vous avez besoin d'aide n'hésitez pas à me laissez vos questions.

Nagios.cfg (/etc/nagios)

- Le fichier de configuration principal de Nagios. Il contient beaucoup d’informations qui vous permettent de le configurer. Par exemple : de modifier l’intervalle de temps entre chaque vérification de services, d’ajouter des fichiers de configurations, etc. En voici un petit extrait. À consulter…

------------------------------------------------------------------------------------------------------

cfg_file=/etc/nagios/contactgroups.cfg
cfg_file=/etc/nagios/contacts.cfg
cfg_file=/etc/nagios/dependencies.cfg
cfg_file=/etc/nagios/escalations.cfg
cfg_file=/etc/nagios/hostgroups.cfg
cfg_file=/etc/nagios/hosts.cfg
cfg_file=/etc/nagios/services.cfg
cfg_file=/etc/nagios/timeperiods.cfg
cfg_file=/etc/nagios/servicegroups.cfg

------------------------------------------------------------------------------------------------------

Commands.cfg (/etc/nagios)

- Le fichier contient toutes les commandes génériques (définition des commandes) qui vous permettent de récupérer de l’information sur vos hôtes et services. Vous aurez probablement à rajouter des commandes dans ce fichier qui vous permettront de pouvoir superviser différents hôtes et services.

------------------------------------------------------------------------------------------------------

# Check_nt command definition
define command{
      command_name check_nt  
command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$ $ARG3$
}

------------------------------------------------------------------------------------------------------

Contactgroups.cfg (/etc/nagios)

- Dans ce fichier, vous pouvez créer des groupes de contact qui regroupent plusieurs personnes qui seront contactés par Nagios en cas de défaillance d’un hôte ou d’un service.

------------------------------------------------------------------------------------------------------

define contactgroup {
contactgroup_name serveur-admin
alias Serveurs
members nagios-admin,Vincent Lepine
       }
define contactgroup {
contactgroup_name routeurs-admin
alias Routeurs
members nagios-admin,Vincent Lepine
       }

------------------------------------------------------------------------------------------------------

Contacts.cfg (/etc/nagios)

- Le fichier contient les personnes ressources qui seront contactés automatiquement par Nagios en cas de défaillance d’un hôte ou d’un service. Vous déterminez également, dans ce fichier, la méthode dont le contact doit être avisé (Courriel, SMS, Netsend,etc.). Vous devez configurer sendmail sur votre serveur Nagios pour qu'il sert de relais SMTP afin d'envoyer des courriels de notifications (voir plus bas).

------------------------------------------------------------------------------------------------------

define contact{
        contact_name                    nagios-admin
        alias                           Nagios Admin
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-by-email
        host_notification_commands      host-notify-by-email
        email                           nagios-admin@localhost
        }

define contact{
        contact_name                    Vincent Lepine
        alias                           Vincent Lepine
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-by-email
        host_notification_commands      host-notify-by-email
        email                           vlepine@domain.com
        }

------------------------------------------------------------------------------------------------------

Hostgroups.cfg (/etc/nagios)

- Ce fichier est bien utile car il vous permet de  structurer efficacement vos hôtes par groupes d’hôtes. Par exemple : si votre entreprise possède plusieurs bureaux dans différentes villes, ce fichier vous permet alors de regrouper les hôtes par ville ou région afin de mieux vous retrouver dans Nagios.

------------------------------------------------------------------------------------------------------

define hostgroup {
hostgroup_name Serveurs Laval
alias Serveurs Laval
members serveur1
       }
define hostgroup {
hostgroup_name Serveurs Quebec
alias Serveurs Quebec
members serveur2
       }
define hostgroup {
hostgroup_name Serveur Ottawa
alias Serveurs Ottawa
members serveur3
       }

------------------------------------------------------------------------------------------------------

Hosts.cfg (/etc/nagios)

- Le fichier contient tous les hôtes (serveurs, routeurs et commutateurs) de votre réseau informatique. Dans le cas présent, j’ai préféré créer d’autres fichiers de configuration telles que « routeurs.cfg  » afin d’éviter de surcharger le fichier hosts.cfg qui peut devenir volumineux si vous possédez un vaste parc informatique. Si vous procéder ainsi, il est alors important de ne pas oublier de modifier le fichier nagios.cfg pour indiquer ou trouver le fichier précédemment créé.

------------------------------------------------------------------------------------------------------

define host{
name  generic-host
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
notification_period 24x7
register 0
}

define host{
use generic-host

host_name Serveur1
#check_period 24X7
max_check_attempts 23
contact_groups serveur-admin
check_command check-host-alive
notification_interval 60
notification_options d,u,r
alias serveur1
address 192.168.1.100
       }

------------------------------------------------------------------------------------------------------

Servicegroups.cfg (/etc/nagios)

- J’ai créé ce fichier car il nous permet, tout comme hostgroups.cfg, de mieux structurer l’ensemble de nos services supervisés dans l’interface de Nagios. Vous pouvez alors regrouper les « Ping » tous ensemble pour voir un aperçu globale de la connectivité de votre réseau.

------------------------------------------------------------------------------------------------------

#Servicegroup Ping
define servicegroup {
servicegroup_name Ping
alias Ping
       }
#Servicegroup Cpu Load
define servicegroup {
servicegroup_name Cpu_load
alias Cpu_load
       }
#Servicegroup Memory Load
define servicegroup {
servicegroup_name Memory_load
alias Memory_load
       }
#Servicegroup Disk Usage c:
define servicegroup {
servicegroup_name Disk_Usage_C:
alias Disk_Usage_C:
       }

------------------------------------------------------------------------------------------------------

Services.cfg (/etc/nagios)

- C’est dans ce fichier que vous allez inscrire vos commandes personnalisés permettant d’effectuer la surveillance réseau de vos hôtes et services. Vous déterminez ici les commandes telles que : charge du processeur, charge de la mémoire, espace disque, ping, etc. N’oubliez pas que ce fichier est lié au fichier commands.cfg ou sont inscrites les commandes génériques.

------------------------------------------------------------------------------------------------------

#Commande général

define service{

name  generic-service

active_checks_enabled 1

passive_checks_enabled 1

parallelize_check 1

obsess_over_service 1

check_freshness 0

notifications_enabled 1

event_handler_enabled 1

flap_detection_enabled 1

failure_prediction_enabled 1

process_perf_data 1

retain_status_information 1

retain_nonstatus_information 1

is_volatile 0

register 0

}

 

# Commande Ping au serveur

define service {

use generic-service

service_description PING

is_volatile 0

check_period 24x7

max_check_attempts 1000

normal_check_interval 5

retry_check_interval 1

contact_groups serveur-admin

notification_interval 240

notification_period 24x7

notification_options c,r

servicegroups Ping

host_name serveur1,serveur2,serveur3

check_command check_ping!100.0,20%!500.0,60%

}

 

# Commande charge CPU

define service {

use generic-service

host_name serveur1,serveur2,serveur3

service_description CPU Load

servicegroups Cpu_load

check_period 24x7

max_check_attempts 1000

normal_check_interval 5

retry_check_interval 1

contact_groups serveur-admin

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_nt!CPULOAD!-l 5,95,99

}

 

# Commande charge mémoire

define service {

use generic-service

host_name serveur1,serveur2,serveur3

service_description Memory Load

servicegroups Memory_load

check_period 24x7

max_check_attempts 1000

normal_check_interval 5

retry_check_interval 1

contact_groups serveur-admin

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_nt!MEMUSE! -w 95 -c 99

}

 

# Commande espace disque c:

define service {

use generic-service

host_name serveur1,serveur2,serveur3

service_description Hard Disk Usage C:

servicegroups Disk_Usage_C:

check_period 24x7

max_check_attempts 1000

normal_check_interval 5

retry_check_interval 1

contact_groups serveur-admin

notification_interval 120

notification_period 24x7

notification_options c,r

check_command check_nt!USEDDISKSPACE! -l c -w 95 -c 99

}

------------------------------------------------------------------------------------------------------

Timeperiods.cfg(/etc/nagios)

- Ce fichier est implicitement lié aux fichiers contacts.cfg et contactgroups.cfg dans la mesure où il s’agit de période (temps) de notifications aux responsables lorsqu’un hôte ou service de nagios fait défaillance, vous pouvez alors déterminer si vous devez êtes alerté soit 24X7, durant les heures d’ouvertures de l’entreprise, etc. 

------------------------------------------------------------------------------------------------------

#24X7 Period
define timeperiod {
timeperiod_name 24x7
alias 24 Hours A Day, 7 day 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
       }

#nonworkhours Period
define timeperiod {
timeperiod_name nonworkhours
alias  Non business hours
sunday 00:00-24:00
monday 00:00-07:00,17:00-24:00
tuesday 00:00-07:00,17:00-24:00
wednesday 00:00-07:00,17:00-24:00
thursday 00:00-07:00,17:00-24:00
friday 00:00-07:00,15:00-24:00
saturday 00:00-24:00
       }

#workhours Period
define timeperiod {
timeperiod_name workhours
alias Business hours
sunday 00:00-00:00
monday 07:00-17:00
tuesday 07:00-17:00
wednesday 07:00-17:00
thursday 07:00-17:00
friday 07:00-15:00
saturday 00:00-00:00
       }

------------------------------------------------------------------------------------------------------

Dependencies.cfg (etc/nagios)

Ce fichier contient les dépendances des hôtes et services. C'est à dire que si vous avez plusieurs succursales et que un des routeurs de la succursale, Montréal par exemple, tombe en panne, vous ne voulez pas recevoir de notifications comme quoi tous les hôtes de Montréal sont "down" alors que le problême se situe au niveau du routeur. Cela évite que l'administrateur réseau soit surchargé de notifications

-------------------------------------------------------------------------------------------------------

#Routeur Laval
define hostdependency {
dependent_host_name routeur1
host_name serveur1,serveur2
inherits_parent 1
execution_failure_criteria d,u
notification_failure_criteria d,u
       }

#Routeur Quebec
define hostdependency {
dependent_host_name routeur2
host_name serveur3,serveur4
inherits_parent 1
execution_failure_criteria d,u
notification_failure_criteria d,u
       }

Nsclient++ (Supervision de serveur Windows)

Nsclient++ est un petit logiciel gratuit qui permet de récolter de l'information telles que (cpu,mémoire et espace disque) et agit comme agent de transmission entre Windows et Nagios. Voici la procédure d'installation qui est d'ailleurs fort simple...

      1. Técharger la version 32 ou 64 bits sur le site web : http://nsclient.org/nscp/

      2. Sur le serveur Windows cible, exécutez «  NSClient++-0.3.6-Win32.msi ».

      3. Procéder à l’installation, faire « Next » 4 fois, vous arrivez alors à la fenêtre ou vous devez précisez l’adresse IP de votre serveur Nagios et cochez également les trois premières cases comme démontré ci-dessous.

      4. Ensuite faire « Next » et « Install ». À la fin de l’installation, ne pas cochez la case « Start service » immédiatement et cliquez sur « Finish ».

      5.  Allez ensuite dans les « Outils d’administration » du serveur Windows  et sélectionner « Services ». Trouvez le service « NSClient++ » et effectuer un clic droit sur le service, alors choisir « Propriété » et par la suite se dirigez dans l’onglet « Connexion ». Finalement, cochez la case « Autoriser le service… » comme le démontre la figure ci-dessous.

      6. Ensuite faire « Ok » et ne pas oublier de démarrer le service « NSClient++ ».

      7. Si vous avez un pare-feu, vérifiez à ce qu’il ne bloque pas la communication entre le serveur Nagios et le serveur Windows.

     Configuration de Sendmail servant de relais SMTP pour l'envoi de courriel de notification dans Nagios.

Puisque Nagios n'est pas un serveur de messagerie, il ne peut vous envoyer de courriel de notifications. Il faut alors configurer Sendmail qui agira à titre de relais SMTP afin de transmettre les courriels. Suivre la procédure à l'adresse ci-dessous :

Configuration de Sendmail (relais SMTP)

Nagios en images

Pour voir un apercu de Nagios, Nagvis, Centreon et Nareto, voir le lien web ci-dessous:

Nagios en images

Recommandation (qui vous feront économiser du temps!!!)

• Faire l'inventaire et un plan de votre réseau informatique.
• Il est inutile de tout superviser votre réseau, faite un tri sélectif de ce qui sera à surveiller (ex Serveurs, Routeurs,etc.).Il est inutile de surcharger votre réseau de requête en faisant le monitoring d'imprimantes ou d'ordinateurs de bureau.
• Bâtir des fichiers de configurations avec une belle nomenclature et des commentaires!
• Bien penser avant d'écrire les fichiers de configurations(Dépendances, Contacts, Timeperiods,etc).

Linuxomètre

Notes d'appréciation globale: 9/10

Avantages:

• Coût=0$
• Vaste communauté de développeur (Plugins)
• Beaucoup de documentation
• Facilité d'installation (Avec "Fully Automated Nagios")
• Performance et efficacité
• Entièrement paramétrable
• Support technique disponible (Payant$$$)
• Interface Web agréable

Inconvénients:

• Complexité de la configuration
• Base Linux (avancé) nécessaire
• Ergonomie du logiciel
• Entrées des données fastidieuse

Conclusion

Nagios s'avère un merveilleux outil pour l'administrateur réseau. La prise en main est un peu difficile avec la ligne de commande, mais une fois maîtrisé, vous prendrez plaisir et facilité à modifier les différents fichiers de configurations. Les possibilités sont quasi-infinies grâce aux nombreux "plugins" fournis par la vaste communauté de développeur de Nagios. Pourquoi payer des milliers de dollars pour des logiciels propriétaires qui ne vous laissent pas personnaliser le logiciel à votre goût quant vous pouvez avoir une solution performante,efficace et qui permet de modeler votre logiciel aux besoins de votre entreprise. Comme dirait le proverbe, posez la question, c'est y répondre!

Références

-Site officiel de Nagios (Anglais)
-Site officiel de Fully Automated Nagios (Anglais)
-Plugins,Add-ons et extensions de Nagios (Anglais)

Le mois prochain

IPCOP FIREWALL

Contact

 Vincent Lépine
 Rédacteur de la chronique Linuxconomie 101 chez generation-linux.fr
 Québec, Canada
 
Si vous avez des questions ou commentaires, n'hésitez pas à m'écrire un commentaire, je vais vous répondre le plus rapidement possible.