Auteur/autrice : nicolargo

Créateur de blog de Nicolargo, je suis un partisan des logiciels libres et un passionné des nouvelles technologies.

Catégories
Hardware Open-source Planet-libre Systeme

Test d’un Linutop 4 avec Linutop OS 5

J’écris cet article depuis le Linutop 4 que j’ai eu gracieusement en test pendant quelques semaines (au passage merci à l’équipe Linutop). Pour rappel, le Linutop 4 est un mini PC Fanless et totalement silencieux (pas de disque dur mais une mémoire Flash) utilisant un OS maison nommé Linutop OS 5. Il a comme cible les entreprises souhaitant disposer d’un client bureautique léger et les utilisations de type bornes Internet ou affichages dynamique d’informations.

Les caractéristiques

On commence par un bref aperçu des caractéristiques du boîtier:

Note: le système Linutop OS 5, pré-installé par défaut, occupe environ 450 Mo des 2 Go de la mémoire flash interne.

Premier contact

C’est la première fois que j’utilise une machine totalement silencieuse et je dois avouer que lors du premier démarrage, j’ai vérifié que je n’avais pas oublié de brancher l’alimentation avant de voir apparaître la bannière de configuration sur mon écran. Même par rapport à l’utilisation d’un PC portable, le silence est vraiment total.

L’avantage d’utiliser l’OS maison (Linutop OS 5) est qu’il n’y a aucune configuration à faire sur la machine. Une simple fenêtre de configuration est affichée au première démarrage de la machine et permet de fixer les paramètres comme le langage, le clavier… Pour la majorité des utilisations, il n’y a rien à faire mis à part cliquer sur le bouton OK.

Une fois cette étape passée, on se retrouve sur une distribution GNU/Linux basée sur Ubuntu (et donc bénéficiant des paquets de cette distribution) avec XFCE comme gestionnaire graphique.

Les premières minutes d’utilisation ont été un peu difficile pour moi. En effet, étant habitué à travailler sur des machines puissantes (voir sur-dimensionnées), la relative lenteur du temps de réaction pour les opérations de bases (ouvrir et déplacer des fenêtres, charger des pages Web légères…) m’a sauté au yeux. Après quelques heures d’utilisation, je m’y suis habitué et si on ne demande pas des choses trop lourdes à ce boitier il s’acquitte parfaitement de ses tâches.

Une machine pour quoi faire ?

Les caractéristiques hardware de la machine limite l’utilisation à certain domaine. J’ai essayé, dans ce chapitre de résumer les choses que j’ai pu tester.

Machine parfaitement adapté pour:

  • naviguer sur Internet (sauf si vous essayez de lire des vidéos en 720p sur YouTube)
  • de la bureautique classique (document, tableur, présentation)
  • écouter de la musique (bien qu’il manque à mon goût une sortie numérique)
  • faire du déport d’affichage (VNC, RDP/TSE) ou de l’administration via SSH

Machine utilisable pour:

  • regarder des vidéos DivX, MP4, OGG au format SD 480p (le format HD Ready 720p peut passer mais risque de faire chauffer votre machine tandis qu’il faut oublier la lecture de fichier en Full HD 1080p)
  • développer (si vous utilisez des IDE légères Troll> et pas des usines à gaz comme Eclipse <Troll)

Machine inutilisable pour:

  • gérer votre bibliothèque de photos / retouche (j’ai essayé et cela n’est pas exploitable)
  • faire du post traitement vidéo
  • faire plusieurs choses en même temps… (la RAM du boitier que j’avais en test était de 1 Go mais il est possible en option de passer à 2 Go)

Résumé des + et des –

Le hardware: Linutop 4

Les +

  • Le silence total !
  • Qualité de fabrication du boitier. Cela paraît solide
  • Le boîtier chauffe mais pas de manière excessive

Les –

  • 1 Go de RAM en standard c’est vraiment trop peu
  • Impossible d’acheter un boîtier « vierge » sans l’OS Linutop (qui est vendu 79€ séparément). J’aurai donc aimé pouvoir acheter le Linutop OS 4 à 400-79 = 321 €…
  • Pas de port USB en version 3
  • Le prix (environ 400€), ce qui est cher pour la configuration hardware proposée

Le systéme: Linutop OS 5

Les +

  • Pack bureautique complet
  • VLC de base et qui fonctionne très bien sur les fichiers SD

Les + et –

  • Le choix de XFCE s’explique bien évidemment par la relativement faible consommation de ressource de ce gestionnaire. De mon point de vu, quitte à avoir un gestionnaire épuré et faiblement consommateur de CPU et de mémoire, autant partir sur une solution de type Openbox ou Fluxbox. J’ai donc essayé la distribution CrunchBang Linux (32 bits BTO) qui fonctionne parfaitement en version « live USBkey ». Et l’impression de lenteur est beaucoup moins importante qu’avec Linutop OS 5 pour une utilisation classique de surf Internet.

    CrunchBang Linux, une alternative intéressante à Linutop OS 5

Les –

  • Si vous souhaitez utiliser Linutop OS sur une autre machine, il vous faudra débourser 79 €. Je trouve cela un peu fort de café, surtout que des solutions libres et gratuites existent et fonctionnent parfaitement sur les boîtiers (par exemple CrunchBang Linux dont je parle ci-dessus)
  • Firefox qui est un peu trop lourd pour la RAM disponible. J’ai installé Chromium qui fonctionne sans problème.
  • Outil graphique: franchement c’est quoi ce mtPaint graphic editor ? C’est pour concurrencer Paint sous Windows ?

Quelques photos…

Pleins d’autres images à retrouver sur Flickr…

Alors j’achète ou j’achète pas ?

On arrive donc à la conclusion de cet article et à la question fatidique: est que, dans le rôle d’un décideur informatique (ce que je suis dans le cadre de mon boulot), j’achèterai cette solution…

Le hardware (Linutop 4) est vraiment de très bonne qualité, le silence total et il ne semble pas trop chauffer même après quelques jours d’utilisation sans extinction. Mais à plus de 400 € (avec livraison), je trouve quand même l’addition un peu salée. Donc à moins de négocier les prix à la baisse (321 € par exemple…) ou bien d’obtenir pour ce prix une configuration plus musclée (au minimum 2 Go de RAM et mémoire Flash plus importante), je regarderai attentivement du coté de la concurrence avant de lancer mes achats.

Donc j’achète le boîtier vierge (sans OS) au prix maximum de 320€.

Concernant l’OS Linutop 5, je suis beaucoup plus sévère. Bien que je comprenne la volonté de fournir aux utilisateurs un système clés en main, je ne trouve pas celui-ci adapté au hardware (XFCE, Firefox, pack logiciel graphique…). De plus, faire payer cet OS (qu’ils soit inclus dans le prix des boîtiers Linutop ou bien 79€) n’est pas constructif: cela limite la participation de la communauté et peut mettre à dos le clan des barbus qui peuvent y voir une vente liée de système GNU/Linux (un comble)…

Je n’achète pas l’OS Linutop 5, et j’utilise sur les boîtiers Linutop des OS GNU/Linux gratuits, léger et alternatifs.

Catégories
Developpement Open-source Planet-libre

Et si on jouait un peu avec Redis et Python ?

Dans la mouvance NoSQL, Redis se classe dans la catégorie « data structure server »  (que l’on peut traduire en Français par « serveur de dictionnaire distant »). C’est  un système permettant de traiter, de manière très performante, des données sous la forme clés/valeurs. Contrairement à des solutions comme MemCache, Redis est capable de gérer la persistance des données en stockant, sur demande, son contenu sur disque.

La clé, qui peut être comparée au nom d’une variable dans un langage de programmation, permet d’identifier de manière unique la donnée. Lors de la création de votre application, vous allez rapidement vous rendre compte que le choix de cette clé n’est pas négligeable. C’est elle qui définira « la structure » de votre base de donnée.

La clé est dans la définition de la clé.

Quant aux valeurs, elles peuvent appartenir aux types suivants:

  • chaînes de caractères (strings)
  • compteurs numériques (note: les données numériques seront stockées dans la base sous la forme de chaîne de caractères) (atomic counters)
  • listes (lists)
  • tableaux (set) et tableaux ordonnés (sorted set)
  • dictionnaires (hashes)

Comme on peut le voir, on retrouve la plupart des structures du langage Python. En étant un fervent admirateur, je me suis donc penché sur l’API Python Redis.

C’est parti pour un peu de bac à sable…

Installation de Redis

Pour mes tests, j’ai fait une installation standard depuis les paquets Ubuntu du serveur Redis, de l’API Python et de la CLI iPython pou illustrer mes exemples:

sudo apt-get install redis-server python-redis ipython

Les commandes de bases

La librairie Python permet d’envoyer des commandes (voir la liste des commandes ici) au serveur.

On commence par se connecter un serveur (local en écoute sur le port TCP par défaut).

J’utilise iPython pour mes tests de la librairie Python mais il est également possible de passer par la CLI Python classique.

# ipython

In [1]: import redis

In [2]: r = redis.Redis('localhost')

Premier exemple clés / valeur (chaîne de caractères):

In [3]: r.set("cles", "valeur")
Out[3]: True

In [4]: r.get("cles")
Out[4]: 'valeur'

Stocker des valeurs numériques:

In [5]: r.set("clesnum", 666)
Out[5]: True

In [6]: r.get("clesnum")
Out[6]: '666'

In [7]: r.incr("clesnum")
Out[7]: 667

In [8]: r.decr("clesnum")
Out[8]: 666

Attention, la méthode get retourne des chaines, il faut les convertir avant de s’en servir comme des entiers.

In [9]: a = 10

In [10]: a + r.get("clesnum")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/home/nicolargo/<ipython-input-10-06c75e85d988> in <module>()
----> 1 a + r.get("clesnum")

TypeError: unsupported operand type(s) for +: 'int' and 'str'

In [11]: a + int(r.get("clesnum"))
Out[11]: 676

Des listes comme valeurs:

In [12]: r.rpush("clesliste", "a")
Out[12]: 1L

In [13]: r.rpush("clesliste", "b")
Out[13]: 2L

In [14]: r.rpush("clesliste", "c")
Out[14]: 3L

In [15]: r.lrange("clesliste", 0, -1)
Out[15]: ['a', 'b', 'c']

In [16]: r.lindex("clesliste", 2)
Out[16]: 'c'

In [17]: r.llen("clesliste")
Out[17]: 3

In [22]: r.lpush("clesliste", "z")
Out[22]: 4L

In [23]: r.lrange("clesliste", 0, -1)
Out[23]: ['z', 'a', 'b', 'c']

Pour des listes avec des valeurs uniques (set), il faut utiliser les méthodes sadd (pour ajouter) et smembers (pour récupérer le set).

In [27]: r.sadd("clesset", "a")
Out[27]: True

In [28]: r.sadd("clesset", "b")
Out[28]: True

In [29]: r.sadd("clesset", "c")
Out[29]: True

In [30]: r.sadd("clesset", "a")
Out[30]: False

In [31]: r.smembers("clesset")
Out[31]: set(['a', 'c', 'b'])

Une autre structure de liste intéressante est la liste avec des valeurs uniques et ordonnées. On ajoute un troisième champs à notre couple clés/valeur qui s’appelle score (3em paramètre dans la méthode zadd). C’est ce score qui va déterminer l’ordre de la liste:

In [32]: r.zadd("clessetsort", "a", 4)
Out[32]: True

In [33]: r.zadd("clessetsort", "b", 1)
Out[33]: True

In [34]: r.zadd("clessetsort", "c", 3)
Out[34]: True

In [35]: r.zadd("clessetsort", "a", 5)
Out[35]: False

In [36]: r.zrange("clessetsort", 0, -1, withscores = True)
Out[36]: [('b', 1.0), ('c', 3.0), ('a', 5.0)]

In [37]: r.zrange("clessetsort", 0, -1)
Out[37]: ['b', 'c', 'a']

Pour stocker un dictionnaire, c’est également très simple:

In [38]: r.hset("cleshash", "a", "A")
Out[38]: 1L

In [39]: r.hset("cleshash", "b", "B")
Out[39]: 1L

In [40]: r.hset("cleshash", "c", "C")
Out[40]: 1L

In [41]: r.hgetall("cleshash")
Out[41]: {'a': 'A', 'b': 'B', 'c': 'C'}

In [42]: r.hget("cleshash", "b")
Out[42]: 'B'

Gérer l’expiration de vos données

… importance du garbage…

In [3]: r.set("key", "value")
Out[3]: True

In [4]: r.exists("key")
Out[4]: True

In [5]: r.expire("key", 10)
Out[5]: True

In [6]: r.exists("key")
Out[6]: True

Attendre 10 secondes ou plus...

In [7]: r.exists("key")
Out[7]: False

Egalement de manière statique avec la méthode expireat (http://redis.io/commands/expireat).

Pour être plus fin, il est aussi possible d’utiliser les « scores » avec les méthodes z* (zadd, zrangebyscore) pour supprimer les données qui ont des valeurs de clés les plus faibles (ou forte selon votre structure).  Par exemple pour supprimer les données de plus faible score (< 3) de notre liste « clesetsort » créée dans le chapitre précédant:

In [37]: r.zrange("clessetsort", 0, -1)
Out[37]: ['b', 'c', 'a']

In [60]: r.zremrangebyscore("clessetsort", 0, 3)
Out[60]: 2

In [61]: r.zrange("clessetsort", 0, -1)
Out[61]: ['a']

 

Les pipelines

Si Redis vous intéresse, c’est que vous avez à gérer un volume important de données. Les commandes que nous venons de voir dans le chapitre précédant sont unitaires. C’est à dire que pour une exécuter une commande, une requête (TCP) est faite au serveur Redis. Pour optimiser les performances et donc réduire le nombre de requêtes fait au serveur, nous disposons des Pipelines (lire ce billet comparatif sur le sujet).

Par exemple pour entrer 100.000 clés/valeurs dans votre serveur, il faut environ 11 secondes sur mon PC de test:

import time
import redis

_MAX_ITER = 100000

r = redis.Redis('localhost')

print "Start bench without Pipeline"
start=time.clock()
for i in range(_MAX_ITER):
   r.set("cles%d" % i, i)
stop=time.clock()
print "Result: %s" % str(stop-start)

alors qu’il faut un peu de plus de 4 secondes en utilisant une pipeline (soit un gain de plus de 50%):

import time
import redis

_MAX_ITER = 100000

r = redis.Redis('localhost')

print "Start bench with Pipeline"
start=time.clock()
p = r.pipeline()
for i in range(_MAX_ITER):
   p.set("cles%d" % i, i)
p.execute()
stop=time.clock()
print "Result: %s" % str(stop-start)

Ressources:

 

Catégories
Open-source Planet-libre Web

Installer facilement NodeJS et NPM sur une Debian Stable

A l’heure actuelle, il n’existe pas de dépôt officiel pour installer NodeJS et NPM sur une distribution Debian Stable. Voici donc un nouveau script d’installation automatique qui va installer sur votre système Debian:

  • la dernière version de NodeJS (depuis le GitHub officiel)
  • la dernière version de NPM  (Node Package Manager)

Comme toujours, mon script est hébergé sur GitHub. C’est à partir de là que vous pouvez me remonter vos questions et remarques…

Procédure à suivre

Le plus simple est de saisir les commande suivantes dans un terminal:

cd /tmp
wget https://raw.github.com/nicolargo/nodeautoinstall/master/nodeautoinstall.py
sudo python ./nodeautoinstall.py -d

Le script va normalement se dérouler sans problème en installant le tout dans le répertoire /opt/node (qu’il est possible de modifier avec l’option -o du script).

L’option -d permet de générer un fichier de log de l’exécution du script (à consulter en cas de problème…) dans le fichier /tmp/nodeautoinstall.log.

Pour que votre/vos utilisateurs puisse utiliser node, il faut également qu’ils ajoutent les lignes suivantes au fichier .profile:

# --- NodeJS
export PATH=$PATH:/opt/node/bin
export NODE_PATH=/opt/node:/opt/node/lib/node_modules
# ---

Le résultat…

Vous devriez alors disposer des dernières versions des deux composants:

Il ne vous reste plus qu’à suivre mon billet d’introduction à NodeJS en passant le chapitre sur l’installation que vous venez de faire automatiquement dans ce billet:)

Catégories
Open-source Planet-libre Systeme

Des outils de test pour stresser votre système

Le développement logiciel nécessite des phases de test et de validation qui sont souvent menées sur des machines non chargées. Je vous propose donc de découvrir, dans ce billet, une série de petits logiciels permettant de simuler une charge sur votre système et qu’il faudra donc lancer en parallèle de vos applications à valider. J’ai uniquement sélectionné des logiciels libres, légers, en ligne de commande et disponible dans les dépôts Ubuntu standards.

Comment stresser une machine ?

Plusieurs leviers permettent de « stresser » une machine:

  • consommation CPU
  • utilisation de la mémoire MEM
  • entrée/sortie IO
  • lecture/écriture disque DISK
  • entrée/sortie réseau NET

L’utilisation conjointe de ces leviers permet de simuler une charge sur une machine cible. L’amplitude des paramètres appliquées à ces leviers est bien sûr à adapter à votre configuration hardware et système.

Note: l’utilisation des logiciels décrits si-dessous peut entraîner le plantage pure et simple de votre machine (cela m’est arrivé pendant mes tests…). Je vous conseille donc vivement de ne pas les appliquer sur une machine en production…

Fuzz

Le premier logiciel est Fuzz. Contrairement aux autres solutions, ce dernier ne génère pas de « stress » par lui même mais demande à d’autres programmes de le faire.

Ainsi, la ligne de commande suivante:

fuzz grep foo

va lancer 10.000 fois la commande « grep foo » en lui donnant en entrée des données factices. Ainsi votre machine va chercher la chaîne de caractère foo dans un flot de données. Nous pouvons donc voir, grâce à Glances (un peu de pub…),  que la charge CPU (recherche de sous-chaine) et IO (entrée-sortie disque) augmentent.

Le nombre d’exécution (-r par défaut 10.000) et le time-out (-t par défaut 120 secondes) sont bien-sur paramétrable en ligne de commande (voir le man).

Si vous connaissez les applications qui tourneront en parallèle de la votre, il est facile de simuler votre environnement cible. Il manque par contre un peu de finesse pour tester votre application avec des contraintes pré-définies (par exemple avec une charge CPU de 75%).

Spew

Développé par HP et mis à disposition de la communauté, Spew est spécialisé sur le stress par entrée-sortie disque. Il permet d’écrire et/ou de lire des fichiers de test sur votre disque.

Pour générer un fichier de 5 Go nommé /tmp/bibi:

$ spew 5G /tmp/bibi
WTR:    90320.56 KiB/s   Transfer time: 00:00:58    IOPS:   180641.12

La même commande mais en forçant la relecture du fichier à la fin de l’écriture:

$ spew --read-after-write 5G /tmp/titi
WTR:    74740.25 KiB/s   Transfer time: 00:01:10    IOPS:   149480.49
RTR:  1761227.45 KiB/s   Transfer time: 00:00:02    IOPS:  3522454.90
On peut voir une montée en charge globale de la machine (LOAD) mais juste avec des entrées/sorties (IO):

Note: pensez à supprimer vos fichiers de test (/tmp/bibi)…

Stress et StressAppTest

Deux logiciels qui font fonctionnellement la même chose (jouer sur l’ensemble des leviers permettant de stresser une machine) mais de manière différente…

Stress est une application permettant de générer des processus (worker) ayant des caractéristiques communes:

  • CPU (consommation de la CPU grâce à l’exécution de la commande sqrt)
  • MEM (avec exécution des commandes malloc et free)
  • IO (avec execution de la commande sync)
  • DISK (execuiyon des commandes read et write)

Avec la commande suivante:

stress -m 10 --vm-bytes 512000000 -t 30

On se retrouve donc avec 10 processus consommant chacun 512 Mo:

Contrairement à Stress, StressAppTest ne génère par défaut qu’un seul processus qui va regrouper les caractéristiques de stress souhaitées.

Ainsi, la commande:

$ stressapptest -s 30 -M 256 -m 8 -C 8 -W

Log: Commandline - stressapptest -s 30 -M 256 -m 8 -C 8 -W
Stats: SAT revision 1.0.3_autoconf, 64 bit binary
Log: buildd @ allspice on Wed Jan 11 17:38:51 UTC 2012 from open source release
Log: 1 nodes, 4 cpus.
Log: Prefer plain malloc memory allocation.
Log: Using memaligned allocation at 0x7f9e9f157000.
Stats: Starting SAT, 256M, 30 seconds
Log: Region mask: 0x1
Log: Seconds remaining: 20
Log: Seconds remaining: 10
Stats: Found 0 hardware incidents
Stats: Completed: 458960.00M in 31.10s 14756.72MB/s, with 0 hardware incidents, 0 errors
Stats: Memory Copy: 458960.00M at 15298.83MB/s
Stats: File Copy: 0.00M at 0.00MB/s
Stats: Net Copy: 0.00M at 0.00MB/s
Stats: Data Check: 0.00M at 0.00MB/s
Stats: Invert Data: 0.00M at 0.00MB/s
Stats: Disk: 0.00M at 0.00MB/s
Status: PASS - please verify no corrected errors

Donne:

Je vous invite à consulter la documentation officielle du projet pour y découvrir les nombreuses options.

Pour finir…

Cette liste est très loin d’être exhaustive. L’idée étant de partager votre savoir…

Quel logiciel utilisez vous pour faire vos test de performances sur des machines chargées ?

Avez-vous des solutions multi-plateforme ?

A vos claviers 🙂

Catégories
Open-source Planet-libre Systeme

Quelques nouvelles de Glances (et sa version 1.4.1)

Cela faisait un moment que je ne vous avais pas parlé de Glances, mon petit logiciel en Python pour surveiller l’état du système des machines. Il y a quelques jours, il a été mis sur le devant de la scène en apparaissant sur la première page de Hackers News. Quelques centaines d’★ et une bonne dose de « pull request » plus tard, j’ai décidé de publier la version 1.4.1 qui apporte, en plus de la classique correction de bug, quelques nouveautés que nous allons détailler ici.

Affichage de la consommation CPU « par coeur »

Jusqu’à la version précédente, l’affichage de la consommation CPU se présentait ainsi:

Maintenant et si votre fenêtre est assez large, vous aller avoir le détail par « CPU Core »:

Il est bien sur possible de passer d’un mode à l’autre en appuyant sur la touche ‘1’ (mais seul le choix de l’affichage global sera possible si votre fenêtre est trop petite).

Plus d’informations sur les processus

Grâce au travail d’Allesio Sergi et un peu de ma part, le nombre information sur les processus a augmenté. A noter que comme pour la CPU, l’affichage s’adapte à la largeur de la fenêtre.

La liste est suivante:

  • VIRT: Virtual memory size (in byte)
  • REST: Amount of resident memory (in byte)
  • CPU%: % of CPU used by the process
  • MEM%: % of MEM used by the process
  • PID: Process ID
  • USER: Process user ID
  • NI: Nice level of the process
  • S: Process status
  • IO READ and WRITE: Per process IO read and write
  • TIME+: Cumulative CPU time used
  • NAME: Process name or command line

Sur une petit console/fenêtre cela donne:

et sur une grande:

Pour finir, voici un screenshot de la version 1.4.1 en action:

Je vous laisse consulter la page officielle pour les procédures d’installations / mises à jour selon votre système d’exploitation.

Si vous avez d’autres idées à soumettre pour améliorer Glances, les commentaires sont là (ou encore mieux directement sur GitHub).

Catégories
Nagios Open-source Planet-libre Reseau Systeme

Interview de Jean Gabes pour la sortie de Shinken 1.2

Pour la sortie de Shinken 1.2, Jean Gabes a eu la gentillesse de répondre à quelques questions que je me posais sur cette nouvelle monture.

Salut Jean et tout d’abord merci de nous consacrer un peu de ton temps.

Mais c’est bien normal !

C’est un été plutôt chargé pour toi avec la finalisation de la version 1.2 de Shinken et la rédaction du numéro spécial du GNU Linux Magazine. Comment arrives-tu à gérer cela en parallèle de tes activités professionnelles ?

Ce n’est pas simple, et ça l’est de moins en moins en fait. Avec le recul, même si la rédaction du hors série a pris du temps, c’est surtout la gestion du projet qui est la plus consommatrice en ce qui me concerne. Il y a de plus en plus d’intérêts pour le projet, ce qui est bien, et avec eux de plus en plus de contributeurs, ce qui est encore mieux.

Mais ceci à un coût en terme de temps de gestion, pour faire le “portier“ sur les patchs proposés, et demander (gentiment) par exemple, de revoir ce qui est proposé. Les forums sont de plus en plus actifs, heureusement, on a de plus en plus d’utilisateurs de la première heure qui prennent part au support sur le forum, et c’est une grande aide que j’apprécie vraiment.

Vue la progression de l’activité, je ne pourrais pas rester 100% administrateur et suivre le rythme, je vais devoir faire des choix pas très simples prochainement.

A titre personnel, je trouve que la principale évolution de cette version est apportée par le module de configuration (découverte automatique, gestion par “packs” et SKonf). Peux-tu nous en dire plus sur ce que cela va apporter aux utilisateurs ?

C’est également mon avis. Si l’on regarde bien, au tout début le projet était orienté pour les “power users” de Nagios, avec des modes distribués, plus de performances, des améliorations qui portent sur les très gros environnements. Je pensais que seuls ces utilisateurs avaient de gros soucis. Or ce n’est pas le cas.

Un peu dans la même philosophie que l’interface de visualisation “simple” WebUI, cette nouvelle interface de configuration est une réponse pour la majorité des administrateurs. Même si certains ne lâcheront pas leur sed, vi ou emacs, d’autres seront râvis de pouvoir ajouter dans la supervision une nouvelle machine en quelques secondes, avec des “tags” automatiques comme “Linux”, “Mysql” ou “DMZ”.

Cette tâche était si ingrate et complexe avec les anciens outils de configuration qu’elle était laissée à l’administrateur de la supervision (par exemple moi dans la société où je travaille…). Désormais tout le monde va pouvoir le faire très simplement et en quelques secondes. C’est un peu emprunté de l’esprit DevOps : l’administrateur de supervision va pouvoir définir des “règles” qui vont permettre de tagguer ses machines (par exemple : port 80 ouvert? -> tag http) et d’associer des services à ces tags (tag http? on lance la commande check_http). Les autres administrateurs vont désormais pouvoir ajouter “simplement” leurs hôtes sans avoir à se soucier des (nombreux!) paramètres de supervision, ni même savoir ce qu’est une sonde de supervision.

Un but avoué de l’outil est de ne plus avoir à s’occuper de notions de “services”. Seuls les hôtes et les templates d’hôtes (nos tags) sont importants dans la vie de tous les jours (demander à un administrateur système ce qu’il retient des notions d’hôtes et services Nagios, vous verrez qu’il aura beaucoup de mal au début avec les services, alors que pour l’hôte ce sera immédiat). Le but est donc de rentrer sa liste d’hôte, avec leurs propriétés (liste des volumes disques par exemple), et c’est tout…

Vu que l’outil se base sur la librairie de découverte, ce mode de fonctionnement peut être automatisé, comme par exemple “rescanner” des hôtes rajoutés précédement pour mettre à jour leur liste de volume disques, voir l’intégrer à un workflow automatique de création de machine virtuelle.

Les Packs sont également issus d’un constat que dans le microsome “Nagios” le partage de sondes est central, mais il n’en est rien de la bonne manière de les mettre en place et les utiliser. Si on prend comme exemple la supervision d’un serveur MySQL distant, la plupart des utilisateurs vont s’orienter vers la sonde check_mysql_health.pl, il y a alors beaucoup de manières de la mettre en place, de gérer les comptes et mots de passes, les seuils, etc. De même, comment bien représenter ces informations sur des outils comme PNP4Nagios ou Graphite et avec quel template ?

Les “packs” Shinken sont là pour cela. Ils sont un “concentré de bonnes pratiques” dans un fichier zip. Basiquement ce sont des fichiers de configuration, des icônes et des templates pour les graphiques, il n’y a rien de complexe ou de magique là dedans. C’est juste que lorsque l’on débute dans la supervision ou que l’on a un nouveau système d’exploitation ou autre, il est tout de même plus simple de partir d’un exemple de supervision que d’une page blanche. Les packs sont là pour que l’expérience des uns serve également au reste de la communauté.

Je suis donc tout à fait d’accord sur le fait que la gestion de configuration est bien l’élément central de cette version, bien plus que la page “dashboard” par exemple. Ce point sera encore central un bon moment, car cela reste la problématique N°1 des administrateurs aujourd’hui.

Par rapport à la version 1.0, on sent une certaine maturitée lors de l’utilisation de l’interface graphique de Shinken (WebUI). Quelles sont pour toi les axes d’améliorations encore possible ?

Question intéressante. Si l’on met de côté la nouvelle page de “dashboard”, il n’y a pourtant pas eu de profonds changements dans la manière de montrer les informations. C’est justement tout ce qui fait la complexité des interfaces graphiques. Il y a bien sûr les concepts centraux comme mettre en avant les problèmes importants pour le métier (et non pas la myriade d’impacts), ou encore de baser les droits sur les attributions des notifications pour les contacts.

Mais le ressenti des utilisateurs est également question de “détails” de présentations. Les détails seront par exemple la position des boutons d’actions pour lancer des actions sur la page d’hôte ou de service. Or ce que je nommais “détail” lorsque j’ai débuté WebUI n’en sont pas, et la question est là pour le prouver. Ils sont primordiaux dans le ressenti de l’utilisateur, sur la qualité même de l’interface.

Outre quelques nouvelles pages et widgets, la prochaine version sera encore améliorée un peu partout en terme d’ergonomie, pour que son utilisation soit la plus “naturelle” possible, si tant est qu’utiliser un outil de supervision puisse être “naturel” pour les utilisateurs. Disons qu’elle doit être là pour apporter le plus d’efficacité possible à ses utilisateurs, avec par exemple le fait d’avoir les boutons d’actions facilement utilisables sans que l’utilisateur ait besoin de les chercher un peu partout?

Quels sont les avantages apportés par les nouvelles fonctions de trigger par rapport aux classiques sondes ?

Pour rappel, les triggers sont du code Python fourni par l’utilisateur qui va être exécuté “en interne” de Shinken pour lire des états ou des données de performances d’hôtes et services puis pour ensuite lancer des actions, changer d’autres états ou créer des notifications.

C’est une très bonne question qui revient souvent dès que l’on a commencé à évoquer les triggers. Ils ne sont pas là pour remplacer les sondes de mesure de CPU ou d’espace disques, même si c’est techniquement possible. Dans 95% des cas de supervision, les bonnes vieilles sondes “à la Nagios” seront bien plus efficaces que les triggers, ne serait ce que du fait qu’il est facile des les tester (contrairement aux triggers).

Ils vont être utiles principalement pour deux choses :

  • la corrélation avancée
  • le traitement de données passives

Dans le premier cas, il est parfois utile d’agréger des informations en un seul indicateur. Par exemple si je veux présenter à mon responsable l’état du service mail fourni aux utilisateurs, je ne vais pas lui présenter la dizaine de serveurs et de services qui le composent. Je vais faire une règle “métier” avec des ET et des OU. Mais parfois ce genre d’opérateurs ne suffisent plus, et il faut sortir l’artillerie lourde qui compare des seuils les uns avec les autres pour savoir à quel point la situation est grave pour les utilisateurs. Ici les triggers vont permettre d’utiliser toute la puissance de Python pour “coder” une telle règle.

Dans le second cas, historiquement dans le monde Nagios, les commandes externes permettent de traiter des états envoyés par d’autres outils. Cependant, l’état doit déjà être calculé (comme OK ou CRITICAL). Il n’était pas possible d’importer une information et de l’analyser (comme par exemple un texte d’une TRAP SNMP). Désormais, des outils tiers peuvent envoyer des informations, la “vérification” sera alors faite en interne par Shinken.

Ce qui est intéressant lorsque l’on mélange les deux cas d’utilisation c’est que l’on obtient la définition de certains de l’Hypervision (en gros absorber des données d’outils de supervision, les traiter, les normaliser et en faire des états agrégés). Le plus drole c’est que le code qu’il a fallu pour ajouter les triggers au code de Shinken est ridiculement petit.

L’ouverture de Shinken vers des données recueillies par Collectd est très intéressante. N’as-tu pas peur de multiplier ainsi les interfaces et de complexifier l’administration ?

Dans le cas de Collectd, si ça alourdi la charge de développement, je ne pense pas que ceci ajoute une charge pour l’utilisateur. Il pourra choisir sa méthode de collecte de donnée favorite, et n’aura pas à utiliser les deux. Ce module était plus pour démontrer ce qu’il est possible de faire avec les triggers que pour remplacer les sondes classiques de supervision. Je ne pense pas que collecter les données de performances toutes les 10 secondes soit utile, donc je pense que beaucoup ne vont pas aller regarder du côté de Collectd, et vont se simplifier la vie en restant avec de la supervision “active”.

Le principe est cependant valable pour tout le reste du projet, et on tente d’avoir des fonctionalités le plus “ortogonales” possibles, donc qui ne se recoupent pas. Certains souhaitaient par exemple ajouter dans la configuration par défaut un “pack” linux basé sur le plugin check_by_ssh en plus de celui basé sur SNMP. J’ai refusé une telle chose car la plupart des utilisateurs vont devoir faire un choix qui est loin d’être simple. J’ai déjà raconté le temps qu’il m’avait fallu pour configurer mon premier Nagios (1 semaine pleine pour avoir une configuration convenable !) et je ne souhaite pas que les débutants de 2012 aient à passer par un tel “bizutage”…

Avec la nouvelle procédure d’installation en une ligne de commande, tu sembles vouloir prendre soin de tes utilisateurs. La phase de configuration initiale du réseau est encore longue et relativement complexe, vas-tu proposer des outils pour les aider ?

Grâce au gros travail de David Guenault, l’installation est désormais triviale, et c’est déjà une énorme victoire !

Ensuite vient la phase de configuration qui se passe en deux étapes:

  • identifier les types d’éléments que l’on a (linux, windows, mysql, mssql, exchange, etc etc) et pour chacun mettre en place des sondes de supervision
  • lister ses machines, et les entrer dans l’outil avec les bons types pour qu’elles aient toutes la bonne supervision adaptée et complète (car les soucis viendront toujours de quelque chose que l’on a oublié de supervisé, c’est bien connu).

C’est justement dans cette optique que nous avons développé les “packs” de supervision et la librairie de découverte avec son interface sKonf. Dans un environnement “classique” (linux, windows, mssql, mysql, apache, oracle …), une fois l’installation effectuée, il reste à lancer un scan de son réseaux et à configurer les bons mot de passe pour que l’on ait une supervision “acceptable”. Il restera toujours une phase d’adaptation, mais là où bon nombres d’administrateurs auraient déjà abandonnés avec un Nagios, là ils auront leur premiers résultats, et pourront commencer leur processus d’amélioration continue avec la supervision.

On passe à quelques questions plus générales. Pourquoi avoir choisi la licence Affero GPL pour la diffusion de Shinken ?

Dans bon nombre d’entreprises, la supervision est externalisée à une société de service, sur un serveur fourni par cette entreprise. Avec uniquement la license GPL, les utilisateurs n’auraient pas eu accès aux sources de l’application qui les surveille. Grâce à l’Affero, ils peuvent en exiger les sources, donc même si cela a fâché certaines personnes comme l’auteur de Nagios, j’ai préféré mettre le maximum de droits dans les mains des utilisateurs.

En face de toi, tu as une concurrence qui dispose de gros moyens commerciaux, marketing et de support technique. Comment te positionnes tu par rapport aux clients professionnels qui peuvent s’inquièter de la péréniter de Shinken ?

Heureusement pour le projet Shinken l’effet “communauté” tourne à plein régime et nous n’avons pas à rougir de l’activitéque ce soit en nombres de commits ou de commiters !

Le marketing et l’aspect commercial sont cependant deux points faibles. Ce n’est peut être pas un hasard car si je regarde bien, ceci reflète bien mes propres points faibles…

Or (malheureusement?) la technique ne fait pas tout. Il est bien plus logique pour un décideur d’aller vers une solution bien vendue avec des “petits déjeuners”, de jolies tablettes de présentations et un discours marketing bien rodé, que de prendre des “risques” et partir vers une solution pleinement communautaire, même si elle réponds au besoin.

La seule solution est de monter une structure professionnelle derrière le projet qui permette de rassurer les décideurs avec du support et une assurance de la perénité des produits. Or c’est bien plus complexe que l’on pourrait le croire, car monter un business dans le monde Open Source d’un point de vue “éditeur” est très difficile lorsque l’on se rapproche de la technique comme ici (même si voir la supervision comme de la pure technique est une erreur qui mène un projet de supervision à sa perte soit-dit en passant).

On a l’habitude de dire que la solution vient des “services”, surtout de l’intégration quand on écoute bien. Mais si l’on souhaite monter un pur “éditeur”, là la relation intégrateur-éditeur est très vite déséquilibrée pour l’éditeur, avec des intégrateurs qui vont vendre un pack de support complet avec leur intégration. L’éditeur n’a donc plus que la ressource de développement à la demande, quand ce n’est pas un intégrateur qui s’en occupe 🙂

Une solution simple serait de faire comme l’auteur de Nagios ou d’autres éditeur de supervision “open source” en proposant une surcouche graphique ou des modules sous licenses proprietaires et payantes. Si je comprends parfaitement comment ils en sont arrivés à une telle position, je n’ai pas envie de tomber dans le même piège. Je préfèrerai encore rester un simple administrateur de campagne que de faire de même 🙂

La problématique est complexe, car monter une société n’est pas déjà pas simple, mais quand c’est monter une offre “éditeur” dans ce domaine, c’est carément un défi ! Heureusement les mentalités commencent à bouger, et le projet d’entreprise Shinken est par exemple lauréat du concours de création d’entreprise innovante 2012 du ministère de la recherche!

D’autres solutions existent, comme par exemple monter une offre SaaS, ou la gestion à la RedHat avec un projet communautaire (fedora) et une version toujours libre (RedHat 6 par exemple) mais supportée quelques années. Trouver la solution idéale est l’activité qui occupe le peu de temps libre que j’ai encore. J’avoue que pouvoir travailler à 100% sur Shinken m’intéresse plus que fortement (ndlr: avis aux sponsors !)

Pour finir cette interview, peux-tu nous donner, en avant première mondiale, une ou deux nouveautées que tu souhaites intégrer dans la prochaine version de Shinken ?

 La curiosité est un très bon défaut 🙂

 Outre un gros effort pour “finir” sKonf (par exemple le fait qu’il puisse relancer Shinken serait intéressant….), il va y avoir de nouvelles pages dans WebUI, sur la supervision “End user” à la Cucumber, et une autre sur de la géolocalisation. Les plus curieux peuvent déjà en voir les premières versions déjà présentes dans le code 🙂

Plus proche du coeur de l’outil, une problématique me taraude l’esprit depuis quelques temps : comment changer ses seuils de supervision pendant certaines périodes de temps, genre augmenter les valeurs critique de charge pendant les backups? Un des membres du projet (Olivier Hanesse) a proposé une solution particulièrement élégante qui me plais tellement que je pense qu’elle va arriver très rapidement.

Un petit mot pour finir ?

J’aimerais remercier tous ceux qui font vivre le projet, que ce soit avec des remontées de bugs, des patchs, de la documentation ou même un petit merci par mail, car sans eux un projet ne pourrait pas tenir aussi longtemps et se serait sûrement arrété à la phase de la preuve de concept, il y a près de 3 ans.

S’il y en a qui souhaitent prendre part à cette belle aventure, qu’ils n’hésitent pas à me contacter !

Catégories
Open-source Planet-libre Systeme

Puppet, installation et première configuration

Il s’est écoulé quelques mois depuis mon premier billet sur les logiciels libres de gestionnaires de configurations de machines. Ce laps de temps m’a permis de consulter un nombre important d’articles, de forum et de littérature. Il est donc maintenant temps de partager cela avec vous.

J’avais initialement prévu de faire un seul gros article, mais devant le nombre important de choses à dire et la complexité du sujet, j’ai préféré le découper en plusieurs parties.

La première, que vous êtes en train de lire est une introduction à Puppet ou l’on va détailler l’installation (serveur et cliente) et la configuration initiale du système. Viendront ensuite des billets spécifiques sur la définition des sites et noeuds puis un ou plusieurs autres sur les modules.

Introduction

Puppet est donc un « gestionnaire de configurations de machines ». Derrière ce terme un peu barbare se cache la possibilité de centraliser la configuration système de vos machines au sein d’un référentiel unique. Le procédé peut très bien s’appliquer à une seule machine ou à un parc important et hétérogènes.

Puppet fonctionne sur le principe de clients (installé sur les machines de votre parc) et d’un serveur (installer sur un ou plusieurs serveurs de votre réseau). Puppet permet ainsi de s’assurer qu’à un instant t, toutes les machines clients sont dans un état de configuration défini sur le serveur.

Pour des besoins de tests il est tout à fait envisageable d’héberger à la fois le client et le serveur sur une seule et même machine. J’ai choisi, pour illustrer cet article, d’une architecture un peu plus proche de la réalité:

Puppet « testbed »

Pourquoi Puppet et non pas Chef ou CfEngine ?

Tout simplement la solution qui m’a semblé la mieux documentée et avec un nombre important de ressources (blog / forum) sur le sujet. Chaque solution a ses avantages, je vous laisse chercher sur votre moteur de recherche préféré les différents articles permettant de les comparer et de choisir celle qui s’adaptera le mieux à vos besoins et surtout avec votre manière de fonctionner.

Installation du serveur Puppet (aka PuppetMaster)

La version 2.6.6 est disponible dans les dépôts officiels de la Debian 6 (Squeeze) au moment de la rédaction de ce billet. Afin de permettre une utilisation avec les clients en 2.7 (version actuellement packagée sous Ubuntu 12.04), il est nécessaire de passer par le dépôt backports que l’on installe de la manière suivante:

# sudo vi /etc/apt/sources.list.d/backports.list

deb http://backports.debian.org/debian-backports squeeze-backports main

L’installation du serveur (module PuppetMaster) et de ses dépendances se fait sur une distribution GNU/Linux Debian 6 via les commandes suivantes (en root ou précédée de sudo):

sudo apt-get update
sudo apt-get -t squeeze-backports install puppetmaster

Une commande permet de s’assurer que le serveur est bien lancé:

$ sudo service puppetmaster status
master is running.

Attention: Si votre serveur est protégé par un Firewall alors il faut penser à ouvrir le port TCP/8140 qui est le port par défaut, sinon les clients n’arriveront pas à le joindre. Si votre serveur est hébergé derrière un réseau NAT, il faudra également rediriger le port TCP/8140 vers votre machine.

Installation d’un client Puppet (Debian ou Ubuntu)

Encore plus simple est l’installation d’un client Debian (sur laquelle le dépôt backport a été ajouté):

sudo apt-get -t squeeze-backports install puppet
 ou Ubuntu en utilisant la commande suivante (en root ou précédée de sudo):
sudo apt-get install puppet

Pour fonctionner, le client Puppet a besoin de connaitre l’adresse du serveur (PuppetMaster). On doit donc éditer, sur la machine cliente, le fichier /etc/puppet/puppet.conf et y ajouter la ligne suivante dans la section [main]:

server=<@IP ou NOM du serveur>

Attention: si vous utilisez un nom, ce qui est conseillé, il faut bien s’assurer que la résolution s’effectue correctement à la fois sur le serveur et sur les clients.

Pour sécuriser la connexion entre les clients et le serveur, Puppet utilise des tunnels SSL. Ces derniers nécessitent une phase d’initialisation à faire seulement une fois lors de la configuration du client. On commence par lancer la commande suivante sur le client (en root ou précédée de sudo):

client$ sudo puppetd -t -v -w 60

info: Caching certificate for ca
info: Creating a new SSL certificate request for optiplex790
info: Certificate Request fingerprint (md5): E2:D6:FB:1C:7C:36:96:D8:45:92:84:E3:71:F4:C6:BD
info: Caching certificate for optiplex790

On demande ensuite, sur le serveur, la liste des certificats SSL en attente de validation (en root ou précédée de sudo):

serveur$ sudo puppetca --list
  "optiplex790" (E2:D6:FB:1C:7C:36:96:D8:45:92:84:E3:71:F4:C6:BD)
Nous avons donc une machine identifié par le nom « optiplex790 » (le nom de ma machine cliente) qui nécessite d’être autorisé par le serveur. Pour effectuer cette tache d’autorisation, on doit valider son certificat (en root ou précédée de sudo):
serveur$ sudo puppetca --sign optiplex790      

notice: Signed certificate request for optiplex790
notice: Removing file Puppet::SSL::CertificateRequest optiplex790 at '/var/lib/puppet/ssl/ca/requests/optiplex790.pem'

Remarque: il est également possible de forcer l’authentification pour une plage d’adresses IP donnée. Cela représente tout de même une faille de sécurité qui est difficilement acceptable sur une réseau en production.

Il ne reste plus, sur le client, qu’à éditer le fichier /etc/default/puppet pour automatiser le lancement de Puppet au démarrage de la machine:

# Start puppet on boot?
START=yes

Et enfin à relancer le daemon du client en tache de fond:

sudo /etc/init.d/puppet start

Pour les phases de tests (par exemple lors de la mise en place de nouveaux modules), il est conseillé de désactiver le demon sur les clients…:

sudo /etc/init.d/puppet stop
… et de le lancer à la main et en mode « verbeux »:
sudo puppetd -t -v

Et sous Windows ?

Puppet propose un client open-source sous Windows.

La procédure d’installation se trouve ici. Sous Winddows 7, le fichier de configuration puppet.conf ou il faudra configurer l’adresse du PuppetMaster se trouve dans le répertoire C:\ProgramData\PuppetLabs\puppet\etc.

Pour lancer Puppet client, il suffit ensuite de lancer une premier fois Puppet à partir du menu Démarrer > Programmes > Puppet > Run Puppet Agent. Ce dernier va afficher un message comme quoi le serveur n’arrive pas à l’identifier. On doit, comme pour les client GNU/Linux forcer l’authentification avec la commande suivante sur le serveur:

sudo puppetca --sign win7

Le prochain lancement de Puppet (menu Démarrer > Programmes > Puppet > Run Puppet Agent) devrait se faire sans problème.

Et hop passons aux choses sérieuses…

Configuration de votre référence: le serveur Puppet

Toute la configuration (référentiel) de Puppet est centralisé dans l’arborescence /etc/puppet de votre serveur fraichement installé. Dans le « best practice » de Puppet, il est fortement conseillé de gérer ce répertoire (et ce qu’il contient) en configuration (sous CVS, SVN ou GIT). C’est dans ce répertoire que nous allons définir notre site (réseau), nos noeuds (machines) et les modules (actions) à appliquer lors de la mise en configuration.

Commençons par une rapide description des fichiers contenus dans ce répertoire:

  • /etc/puppet/manifests/site.pp: C’est le premier fichier analysé par PuppetMaster pour définir son référentiel. Il permet de définir des variables globales et d’importer des modules (ensembles de classes) ainsi que des fichiers templates et noeuds de votre réseau. Attention de ne pas définir directement les templates et les noeuds dans ce fichier… C’est techniquement faisable mais pas très propre à maintenir.
  • /etc/puppet/manifests/template.pp: (optionnel) Permet de définir ou d’étendre (notion d’héritage comme en POO) des classes spécifiques à votre réseau.
  • /etc/puppet/manifests/node.pp: Permet de définir les noeuds (machines) de votre réseau. Il est conseillé de défini le nom d’un noeud par le nom FQDN de la machine. Si votre réseau est important (plusieurs centaines de machines à gérer), il est tout à fait possible de créer une arborescence dédié avec un fichier node.pp par sous-réseau.
  • /etc/puppet/modules/<module>/: Sous répertoire contenant la définition du module (action). Un fichier <module>/manifests/init.pp contient la définition du module (en clair c’est ici que l’on va définir ce que l’on doit faire sur la machine cliente) et le répertoire <module>/files/l’ensemble des fichiers nécessaires à l’exécution de ce module. Voyons maintenant le détail de ces fichiers.

Définition de votre site (réseau Puppet)

Idéalement, le fichier site.pp ne doit contenir que des lignes import (permettant d’importer les autres fichiers de configuration) et la définition des variables globales (nécessaire à plusieurs modules).

filebucket { 'main': server => 'puppet.nicolargo.com' }
File { backup => 'main' }

import "node"

Les deux premières lignes définissent les paramètres permettant aux client d’accéder au serveur de fichier PuppetMastert en indiquant notamment le nom FQDN du serveur Puppet (à adapter à votre configuration). Attention de bien vérifier que les machines clients arrive bien à résoudre le nom FQDN en question. La troisième ligne demande au serveur de prendre en compte tous les noeuds disponibles dans le fichier node.pp.

Définition de vos noeuds (machines clientes Puppet)

Nous allons utiliser le fichier node.pp pour définir les configurations à appliquer sur les machines clientes de notre réseau. Par exemple pour définir le noeud nommé optiplex790 (machine dont nous avons validés l’authentification dans le chapitre précédant) et y appliquer le module dummy, il faut éditer le fichier /etc/puppet/manifests/node.pp en y ajoutant les lignes suivantes:

node 'optiplex790' {
	include dummy
}

Le module dummy va être défini dans le paragraphe suivant.

Définition des modules (actions à appliquer sur les machines clientes Puppet)

Chaque module dispose de son propre répertoire sous /etc/puppet/modules/<module>. Ainsi on commence par créer l’arborescence du module dummy:

mkdir -p /etc/puppet/modules/dummy/manifests
mkdir -p /etc/puppet/modules/dummy/files

Le premier répertoire (manifests) va contenir la définition de l’action. Le second (files), les optionnels fichiers permettant d’effectuer cette action. On défini l’action dummy en créant le fichier /etc/puppet/modules/dummy/manifests/init.pp avec le contenu suivant:

class dummy {
        file { "/etc/puppet.txt":
                owner => root,
                group => root,
                mode => 644,
                source => "puppet:///dummy/puppet.txt"
        }
}

Le module dummy va donc vérifier:

  • l’existence sur la machine cliente d’un fichier /etc/puppet.txt
  • appartenant à l’utilisateur root
  • appartenant au groupe root
  • avec les droits 644
  • et dont le contenu doit être égal au fichier /etc/puppet/modules/dummy/files/puppet.txt disponible sur le serveur

Prise en compte de la nouvelle référence par le serveur

Pour que PuppetMaster prenne en compte al nouvelle référence que nous venons de définir, il faut relancer le démon avec la commande (en root ou avec sudo):

sudo service puppetmaster restart

Forcer la mise en configuration sur vos clients Puppet

Pour tester la configuration, nous allons lancer la commande suivante sur le noeud optiplex790 (machine sous Ubuntu 12.04):

sudo puppetd -t -v

Si vous rencontrez l’erreur suivante sur votre client:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: No support for http method POST
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

C’est probablement que vous utilisez une version du client Puppet supérieure à PuppetMaster (par exemple un Puppet client 2.7 avec un PuppetMaster 2.6). Un bug report est disponible ici. Avec la même version des deux cotés et si tout ce passe bien le message suivant devrait s’afficher:

info: Caching catalog for optiplex790
info: Applying configuration version '1346169168'
notice: /Stage[main]/Dummy/File[/etc/puppet.txt]/ensure: defined content as '{md5}1425249a5cbdea520b7a1a23f7bc2153'
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 0.64 seconds

Dans le cas ou tout se passe correctement, vous devriez alors trouver un nouveau fichier puppet.txt  dans votre répertoire /etc:

$ ll /etc/puppet.txt
-rw-r--r-- 1 root root 35 août  29 15:02 /etc/puppet.txt

Ne pas réinventer la roue…

Maintenant que vous avez les bases permettant d’associer des actions à des machines, seule votre imagination vous posera des limites. Cependant, avant de partir bille en tête dans le développement de nouveaux modules, je vous conseille de regarder du coté de la Forge Puppet qui est un site communautaire permettant de partager, rechercher et récupérer des modules pour un nombre très important de cas. C’est également un très bon moyen d’apprendre le langage utilisé par Puppet en récupérant et lisant le code des modules.

 

Pensez également à partager vos modules !

En cas de problèmes…

Si vous rencontrez un problème lors de la configuration de votre Puppet Master, le plus simple est d’ouvrir une console et de surveiller la log des demons en filtrant un peu la sortie:

serveur$ tail -f /var/log/daemon.log | grep puppet

et de lancer la commande coté client en mode debug:

client$ sudo puppetd -t -v -d

Conclusion

Nous venons donc de faire nos premiers pas dans le très compl[et|exe] monde de Puppet. L’investissement nécessaire à l’administrateur est à la hauteur du gain de temps, de traçabilité et d’efficacité qu’il obtiendra en fin de projet.

A très vite pour la suite des billets sur Puppet !

Catégories
Blog Open-source Planet-libre Web

Sauvegarde incrémentale et automatisé de votre compte Gmail

Les prophètes du Web avaient prédit la fin des mails avec l’arrivée des réseaux sociaux. Force est de constater que la messagerie électronique « classique » est toujours bien ancrée dans les moeurs.  Pour une utilisation personnelle, la messagerie GMail de Google fait office de leader sur le marché. J’ai personnellement plus de 3 Go d’archives de mail sur mon compte personnel. Bien que très stable, le service de Google n’est pas à l’abri d’une perte de vos précieux messages. Nous allons donc voir dans ce billet comment conserver une archive locale de votre compte Gmail en utilisant le logiciel libre GetMail. GetMail est distribué sous licence GPL version 2 et il est disponible dans les dépôts des principales distributions GNU/Linux.

La procédure suivante va nous permettre de faire une sauvegarde incrémentale (seul les nouveaux messages sont téléchargés) d’un compte Gmail accessible via le protocole IMAP sur une machine Debian Squeeze (mais la procédure est la même sous Ubuntu).

Installation et configuration initiale de Getmail

On commence par installer le logiciel:

sudo apt-get install getmail4

On créé ensuite les sous-répertoires suivants (à adapter à votre configuration):

  • ~/.getmail: va contenir les fichiers de configuration de Getmail (un fichier par compte)
  • ~/backup/gmail: est le répertoire de destination ou la sauvegarde va être faite

En utilisant les commandes suivantes:

mkdir ~/.getmail
mkdir ~/backup/gmail

On passe ensuite à la création du fichier de configuration (~/.getmail/getmail.gmail) pour notre compte Gmail. Ce dernier doit contenir les lignes suivantes:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
username = user@gmail.com
password = password
mailboxes = ("inbox",)
port = 993

[destination]
type = Mboxrd
path = ~/backup/gmail/user.mbox

[options]
received = false
delivered_to = false
read_all = false
verbose = 0

Je vous laisse modifier ce fichier avec vos propres informations.

On s’empresse de protéger ce fichier des regards extérieurs:

chmod 700 ~/.getmail/getmail.gmail

Comme vous pouvez le voir dans cette même configuration, j’ai choisi d’utiliser le format Mboxrd qui est un standard reconnu par la plupart des logiciels. Getmail doit disposer d’une archive vide avec les bons droits avant de le lancer pour la première fois. On utilise donc la commande suivante pour le satisfaire:

touch ~/backup/gmail/user.mbox

Lancement initial de Getmail

Je vous conseille de faire le premier lancement de Getmail depuis une console pour voir les éventuels messages d’erreurs.

getmail -r ~/.getmail/getmail.gmail

Il est possible, notamment si vous lancé Getmail depuis un serveur n’ayant jamais fait de connexions clientes IMAP vers GMail, que Google bloque l’accès et que Getmail retourne un message du style:

IMAP error during logout (command CLOSE illegal in state AUTH, only allowed in states SELECTED)

Pour résoudre se problème il faut se connecter sur votre compte Gmail (à partir de n’impote qu’elle machine) puis de cliquer sur le bandeau rouge en haut de l’écran:

Puis de valider votre connexions:

Vous avez alors 10 minutes pour relancer la première commande de ce paragraphe.

Si il n’y a pas d’erreur, alors le téléchargement des fichiers vers votre archive (fichier unique) devrait commencer. vous pouvez aller prendre un café, ou plusieurs, selon la taille de votre compte GMail. Je vous conseille de prévoir un espace disquelégérement supérieur à l’information donnée par Gmail en bas du WebMail (fichier archive de 4 Go pour 3 Go affiché dans Gmail). En effet, l’archivage implique l’ajout d’un « overhead » assez important.

Note: Même depuis mon serveur OVH connecté à 100 Mbps sur Internet, je ne dépasse pas les 1 Mbps lors de l’archivage, surement une limite des serveurs Google et/ou du protocole IMAP.

Automatiser la sauvegarde

« Sauvegarder, c’est bien, automatiser la sauvegarde c’est mieux. » [Nicolargo]

Une petite ligne ajoutée à votre crontab système va permettre d’automatiser la sauvegarde incrémentale de votre compte Gmail. Personnellement, je la déclenche toutes les nuits à 1h du matin.

# crontab -e

0 1 * * * getmail -r ~/.getmail/getmail.gmail

Vous voilà maintenant plus tranquille avec une archive bien à vous de vos (g)mails !

 

Catégories
Blog Web

Quelques liens glanés pendant l’été

De retour de congés après 3 semaines de sevrage de clavier et de souris. Tel un aventurier solitaire avec mon smathphone comme couteau de commando, voici les liens intéressants que j’ai étoilé pour moi et maintenant pour vous.

  • Pas mal de mouvement du coté des WAF (Web Application Firewall) pour NGinx avec notamment ModSecurity qui débarque. Je pense prochainement faire un billet sur son grand concurrent Français, j’ai nommé Naxsi. Preuve que le secteur est en pleine ébullition, même Korben, notre DDOS Generator propose une configuration statique de Nginx pour se protéger de quelques attaques.
  • YunoHost, une distribution GNU/Linux basée sous Debian propose toutes les briques pour un serveur professionnel administrable par une interface Web. Une démo est disponible en ligne.
  • Textmate 2 passe sous licence GPL v3. Vu les raisons invoqués par le créateur, je ne pense pas que cela face beaucoup avancer les choses pour les logiciels libres…
  • Le partage des configurations du prompt Shell est très à la mode, j’adore celui là: LiquidPrompt.
  • GlusterFS, le système de fichiers nativement distribués est disponible en version 3.3. Encore un prochain sujet de billet.
  • Si vous devez faire un site Web, plutôt qu’une bête feuille CSS de reset, je vous propose d’utiliser Normalize.css.
  • Vous êtes un utilisateur de Syslog-ng ? Alors cet article devrait vous plaire.

De mon coté, quelques activités durant le mois de juillet:

Bonne reprise aux chanceux qui ont pris des vacances !

 

Catégories
Blog Open-source Planet-libre

Hébergements des blogs du Planet Libre

Dans mon dernier billet, j’avais utilisé des scripts pour récupérer automatiquement un certain nombre d’informations sur les blogs Français. J’ai donc adapté ces scripts pour recueillir ces mêmes informations sur les blog du Planet Libre (liste des blogs datées du mois de juillet 2012).

Les informations suivantes sont analysées :

  • le nom de l’hébergeur
  • le type de serveur Web utilisé et si le blog utilise un proxy/cache Varnish

Sur l’hébergement, OVH arrive en tête. Par contre et contrairement aux autres types de blogs, le nombre de serveurs auto-hébergés arrive en troisième position (13%, à égalité avec Online.fr).

Sur les serveurs Web, Apache domine Nginx (pourtant très à la mode) avec plus de 70% des blogs. On peut aussi noter la faible proportion de blogs utilisant Varnish (environ 2%).