Demande d'information
Alignement des images
Les balises audio et video foirent
Planète Libre et Micro-blogging
Mis à jour du flux RSS
Partages ?
®om
4LW
Admin-Linux
agatzebluz
Aldevar
Another Pinky Punky
AnTav
Antistress
Antoine Millet
Antonin Moulart
archi02
arNuméral
Artisan Numérique
Asher256
Aternatik
Aurélien Bompard
Bastnic
Benkemoun
Bilbo Planet
Biscotte
Blogmotion
bochecha
botchchikii
bouleetbil
Boutor
Breizh ardente
Cairo-Dock
Cameleon
Capof's Space
Captaine74
Carl Chenet
Cedynamix
champtoussel dominique
ChEza
Chicha
Chimrod
Christophe-Marie
Clapico
Corbier
Costalfy
Creasy
CSM 'illovae' Seldon
CyberSDF
Cyrille BORNE
dada
dahu_fou
Damien Cougar
Damocles
Daria
David Dup
David Larlet
Davromaniak
Ddmdllt
Des nouvelles de Wikilivres
Desidia
Devil505
Dhoko
DigitalSpirit
djibux
Dorian Dd
Duchatelet
E-PhasE
Eddy33
Edouard
Effraie
eMerzh
Emilien Macchi
Emilpoe
Emmanuel Gontcho
Emmanuel Kasper
Equinoxefr
Eric
Exceed
FACIL
Facilinux
Feilong
fgallaire
Finss
florentg
floruby
Fonctionerd
Framablog
François
Franck Archange
FredBezies
Full Circle Magazine
Fuse
Génération Linux
G3L
Gaëtan Tenshu
Gilir
Grégory Gutierez
Gregory Colpart
Guillaume Kulakowski
Hugues
Hyla project
Il Palazzo-sama
inalgnu
Jérémy Verda
Jeff
jeremy2491
jeromeg
jesuislibre
JJL
Johan Cwiklinski
Jonathan Ernst
Jonathan Le Lous
Jopa
Jp Fox
Juky
Julien
Julius
ka.da
Kagou
kamagatos
Kate
Kiddo
KissCoolMan
Labo-Linux
LeDucDuBleuet
Lemarinel
Lenezir
Liberez le tux
Libre Astux
Linalis
Littlewing
Louis Roché
lowje
Luc
Macsim
Manu Absolacom
Marco
Matao
Mathieu Comandon
Maxime Carron
McKey
meepix
Michael Zwyssig
Michauko
Mickaël
Minimumserious
Monitoring-FR
Morot
Motarion
mozillaZine-fr
Mr.Yann
MrTom
Nÿco
Naparuba
Nicofo
Nicolargo
Nicosmos
Nicoz
NiKo
nizarus
Noplay
Olivier Faurax
Olivier Prieur
Omega
Oncle Tom
Op'Aisne Source
openSyd
opossum1er
Osku
OxyRadio
Paquet Fedora du Jour
Pascal Chevrel
pc-kc
Peck
Phil
Pianopenguin
Pingax
PlayOnLinux
Ploum
Pokemon_JOJO
Poupoul2
Rémi Samier
Raphaël Hertzog
Ravomavain
Renaud Littolff
Renault
Respawner
Retouche Libre
Ricard
Robin Millette
Roland Mas
RollsRox
Rydgel
Saïmon
Samuel Martin
Sauthier
SckyzO
Scoffoni
Scurz
Shnoulle
Silvyn
Skhaen
Slobberbone
Splitsch
StandarT
StephZ
Sylvain
System Linux
Taltan
Tbellemb
Tchouvince
theClimber
TheGlu
TheLinuxFr
Thibaut
Thierry Andriamirado
Thom1
Thomas Bassetto
Tigrou Damien
TitaX
toitoinebzh
Toorop
TrouveTonGull.info
Tuxargon
Tuxicoman
U-Classroom
Uggy
Ulrich Diplodocus
Une goutte de blog
Uselink
Vanaryon
VELCS
Vetsel
Warren Dumortier
Wattazoum
Wavemaker
Weedfast
Yannig
yeKcim
Yellowiscool
Yoho
Yves Gesnel
Zanko
Zic
Zippy
ZitrouilleCe 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.

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 :)
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 :
Avant tout, il faut savoir qu'il existe deux "types"de fermes de wiki :
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.
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
<?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;
}
#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]
#!/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 ? :)
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 :
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 !)


sudo aptitude install pal
palpal -mpal -s formule -r nbrjourspal -r 365 -s "\(p.ques\)\|\(easter\)"pal -r 365 -s "pâques"cat >> mon_calendrier.html << EOF
<html>
<head>
<title>Mon calendrier généré depuis pal</title>
<link rel="stylesheet"
type="text/css"
href="http://www.generation-linux.fr/usr/share/doc/pal/examples/example.css"
title="default" />
</head>
<body>$(pal --html -c 12)</body>
</html>
EOF pal --latex -c 12 > mon_cal.tex
sed -i '5i\\\usepackage[latin1]{inputenc}' mon_cal.tex
sed -i
'5i\\\usepackage[francais]{babel}' mon_cal.tex
sed -i 's/Monday/lundi/g' mon_cal.tex
sed -i
's/Tuesday/mardi/g' mon_cal.tex
sed -i 's/Wednesday/mercredi/g' mon_cal.tex
sed -i 's/Thursday/jeudi/g'
mon_cal.tex
sed -i 's/Friday/vendredi/g' mon_cal.tex
sed -i 's/Saturday/samedi/g' mon_cal.tex
sed -i
's/Sunday/dimanche/g'mon_cal.tex
pdflatex mon_cal.tex || latex mon_cal.tex man palcd
mkdir .pal
cp /etc/pal.conf ~/.pal/nano ~/.pal/pal.conf
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
cp /tmp/calendar/calendars/fr_FR.ISO-8859-1/calendar.jferies
~/.pal/ sed -i 's/^[ \t]*\/\?\*\/\?/#/' ~/.pal/calendar.jferies
sed -i 's/LANG/#LANG/' ~/.pal/calendar.jferies
sed -i 's:\([0-9][0-9]\)/\([0-9][0-9]\)\*\?:0000\1\2:'
~/.pal/calendar.jferies
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
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
sed -i '1i\FR France' ~/.pal/calendar.jferies
iconv -f ISO8859-1 -t utf-8 ~/.pal/calendar.jferies
calendar.jferies >temp
mv temp ~/.pal/calendar.jferiessed -i '1i\file calendar.jferies (magenta)' pal.confVoici 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 !

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.
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
cal -ym :
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.
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...
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 :
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 !

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.
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 :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 :
Note : Personnellement je remplace le 'serveur' par le nom du domaine qui détiendra le certificat.
openssl req -nodes -newkey rsa:2048 -keyout serveur.key -out serveur.csr
Différentes informations vont nous être demandées :
Note : Les trois derniers champs sont optionnels.
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 []:
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 :
On notera que serveur.key et serveur.csr sont dans le répertoire private afin de les séparer du certificat publique.
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
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 !
yum install mod_ssl
Sauvegardez et relancez Httpd :
SSLCertificateFile /etc/pki/tls/certs/serveur.crt
SSLCertificateKeyFile /etc/pki/tls/private/serveur.key
Tentez d'accéder à votre site via https://serveur pour vérifier le bon fonctionnement des manipulations !
service httpd restart
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.

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)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
}
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.
Pour voir un apercu de Nagios, Nagvis, Centreon et Nareto, voir le lien web ci-dessous: