Catégorie : Planet-libre

Catégorie pour flux planet-libre

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 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%).

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Comment sont hébergés les blogs Français ?

On annonce régulièrement que l’avènement du Web 3.0 sonnera comme la fin des blogs, du moins dans la forme dont on les connait actuellement. En attendant cette révolution, les blogs restent, de mon point de vu, la source d’information la plus intéressante sur la World Wide Web. La France n’est pas à la traîne et dispose d’une blogosphère dynamique. Nous allons dans ce billet nous intéresser aux techniques d’hébergements qu’utilisent ces sites.

J’ai compacté les grandes tendances des données obtenues dans le diagramme suivant:

La french blogosphère et son hébérgement en 2012
La french blogosphère et son hébérgement en juillet 2012

 J’ai donc chercher, pour les blogs appartenant au TOP 300 du classement eBuzzing de juillet 2012, les informations suivantes:

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

Pour cela, j’ai écrit des scripts shell (disponible sur le GitHub suivant sous licences LGPL) permettant de récupérer automatiquement la liste des blogs sur le site eBuzzing, de chercher dans la base Whois chez qui le blog est hébergé et enfin d’étudier l’header HTTP renvoyé pour avoir des informations sur le type de serveur Web et l’utilisation éventuelle de Varnish, le proxy/cache à la mode.

Les résultats bruts sont dans ces deux fichiers CSV: hébergeur et type de serveur Web.

Note importante:

Les informations données dans ce graphe sont à prendre avec certaines précautions. En effet, concernant les hébergeurs, l’utilisation de service comme CloudFare (utilisé notamment par Korben.info) masque l’hébergeur. Pour le type de serveur Web, il est tout à fait possible à un administrateur, pour des raisons de sécurité, de masquer ou de transformer les informations renvoyées par l’en-tête HTTP.

Les hébergeurs

OVH, Le leader Français de l’hébergement trône en haut de la plus haute marche du podium avec 21% des blogs parmi le TOP 300 eBuzzing. Il est suivi avec 19% des blogs, par la plate-forme OverBlog qui permet de créer sont blog en quelques clicks. Enfin, dans le même esprit, on retrouve 14% des blogs hébergés par la plate-forme Blogger de Google (a noter que pour ce dernier, l’hébergeur est masqué, mais on voit que ces blogs utilisent le serveur Web GSE, solution spécifique à Google).

Dans les autres hébergeurs, on peut noter la très bonne 6em place du très professionnel hébergeur Typhon avec 3% des blogs.

Les types de serveur Web

Pas de grosses surprises. Apache Web Serveur arrive en tête avec 71% des blogs. Bien qu’il existe des solutions plus légères, surtout pour héberger un simple blog, Apache conserve une solide réputation en terme de fiabilité et de facilité d’administration grâce aux nombreuses sources d’informations que l’on peut trouver sur le Web. Vient ensuite, avec 17% des blogs, Nginx le challenger qui monte. Un solution également très stable mais beaucoup plus légère que j’utilise personnellement depuis quelques années sur ce blog. Enfin, on retrouve, avec 14% des blogs, le serveur GSE de Google, utilisé sur sa plate-forme Blogger (à noter qu’il en existe une implémentation open-source sous licence Apache 2).

Varnish or not Varnish

J’ai été surpris par le nombre assez important (26%)  des blogs utilisant cette superbe solution de proxy/cache qu’est Varnish. En regardant ce chiffre de plus près, il faut noter que la plate-forme OverBlog le met en place par défaut sur l’ensemble de ses serveurs. Vu le gain de performance et l’allègement des ressources CPU qu’il procure sur les blogs à fort trafic, je pense que ce chiffre va fortement évoluer dans les prochains mois.

Et pour les blogs libristes ?

J’ai également exécuté les même scripts de statistiques sur les blogs traitant des logiciels libres en me basant sur le classement Wikio (limité au 60 premiers blogs). Vous pouvez consulter et exploiter les données qui sont disponibles dans les deux fichiers suivants: hébergeurs et type de serveur Web.

Et vous lecteurs/blogueurs, vous êtes chez quel hébergeur ? Quel serveur Web ? Varnish ?

Partager tout cela avec nous dans les commentaires !

Catégories
Blog Open-source Planet-libre Web Webdesign

Modèles de présentations HTML5 pour remplacer PowerPoint

Suite à mon track sur la supervision lors de la première journée de SophiaConf 2012, j’ai eu pas mal de question par mail sur le logiciel utilisé pour concevoir mon support. J’ai en fait utilisé une présentation 100% HTML5 basée sur l’outil Impress.js, lui même inspiré de Prezi. Je ne trouve que des avantages à ce type de présentation. En effet, en mettant de coté le dynamisme et l’aspect « fun », on manipule un format standard, lisible sur n’importe quel navigateur digne de ce nom (je dois avouer que Impress.js, fonctionne beoucoup plus fluidement sur Chromium que sur Firefox).

Nous allons dans ce billet découvrir un panel de solutions équivalentes permettant, moyennant une bonne connaissance du langage HTML et de CSS, de concevoir des présentations originales sans avoir à installer aucun logiciel sur votre machine mis à part un éditeur de texte et un navigateur Web. Bref une solution 100% libre, basée sur des standards !

Les commentaires sont bien sûr là pour compléter cette liste et nous faire partager vos expériences sur le sujet !

Impress.js

Démonstration

GitHub

C’est par cet outil que j’ai découvert les alternative possible à la grande maladie des entreprises du 21em siècle: PowerPoint.

L’exemple fourni sur le GitHub permet de bâtir simplement un jeu de slide. Pour être un peu plus original, il faudra aller éditer le fichier CSS. Impress.js s’occupe de tout le reste: transition entre les slides, vu d’ensemble des slides, animations. C’est un projet perpétuellement en évolution, à surveiller sur GitHub.

Personnellement, j’ai « forké » le projet sur mon espace GitHub, puis je génère une branche par présentation. Cela me permet d’avoir toujours les présentations sous le coude. A noter GitHTML, l’excellente extension à Chrome/Chromium , qui vous permet de visualiser directement vos fichiers HTML  et donc votre présentation à partir de GitHub.

Deck.js

Démonstration

GitHub

Projet débuté en mars 2011, il propose une alternative sérieuse à Impress.js. Moins « fun », les présentations générés sont cependant claires et je trouve le code HTML plus propre.

Html5Rocks

Démonstration

Distribué sous licence Apache 2.0, ce jeu de slides est initialement conçu pour présenter les nouveautés du langage HTML5. Sa structure peut permettre de bâtir simplement votre propre présentation avec en prime des exemples de fonctions HTML5 déjà toutes faites.

Html5Slides par Google

Démonstration

Google Code

Difficile de faire un billet sur un tel sujet sans parler de Google qui y va de son modèle de présentation compatible HTML5. Pas de surprise ici. C’est simple et sobre avec un code HTML facilement compréhensible, même pour un béotien. A noter que le modèle est sous licence Apache 2.0.

Reveal.js

 

Démonstration

GitHub

Bien que présenté comme un modèle CSS de présentation 3D, Reveal.js est plus un modèle HTML permettant de faire des présentations sous la forme de matrice en deux dimensions. On peut, si on le souhaite et si la présentation a été faite pour, se déplacer en haut, en bas, à gauche et à droite pour passer d’un slide à l’autre. Ce mode de navigation, un peu perturbant n’est pas forcement adapté pour un track mais plutôt pour un présentation « à tiroirs ».

Shower

Démonstration

GitHub

Ce modèle de présentation permet de faire rapidement une présentation au format HTML5. On peut noter la possibilité de voir les miniatures des slides avant de commencer la présentation. Les transitions sont simples et rapides. On dispose également de fonctions intéressantes pour, par exemple adapter les images automatiquement à la taille de l’écran ce qui peut être sympa pour une présentation basée sur des photos.

RoboDeck

Démonstration

GitHub

Le principal intérêt de ce modèle de présentation est que si la présentation est disponible en ligne alors il est possible de synchroniser les visiteurs sur le slide en cours. Pour cela, le serveur sur lequel les slides sont hebergés va envoyer (via Web Socket) les informations NEXT et PREV. Je trouve par contre les présentations pas très sexy… A suivre quand même pour des présentations massivement en ligne.

Slides par Brian Cavalier

Démonstration

GitHub

Sur ce modèle, les transitions se font par un très agréable fondu enchaîné. J’aime beoucoup le CSS par défaut qui est sobre et clair. A réserver à des présentations sérieuses.

Slides par Brian Cavalier

Démonstration

GitHub

Comme le précédent modèle, les transitions se font par un très agréable fondu enchaîné, mais la comparaison s’arrête là. Ici on est dans un style de présentation plus « fun » et très bien adapté aux développeurs (avec notamment le syntax highlight). A bookmarker !

Pour conclure

De nos jours et en mettant à part les présentations qui doivent passer entre les mains de personnes sachant uniquement utiliser PowerPoint, je ne comprends pas que l’on utilise pas plus se genre de modèle de présentation. En effet, elles n’ont que des avantages: simple à éditer (avec un éditeur de texte), facilement transportable sur une clés USB ou l’on peut ajouter une version Chromium ou Firefox portable et avec nativement une mise en ligne optimisée (c’est du HTML 🙂 !). Alors ciao PPT et bonjour HTML.

Et vous chers lecteurs vous en êtes ou avec la cure de désintoxication de PowerPoint ?

D’autres modèles à nous conseiller ?

Catégories
Open-source Planet-libre Reseau

Simuler un réseau WAN entre deux réseaux LAN

A partir de sa version 2.6, le noyau Linux dispose d’une fonction permettant de simuler certaines caractéristiques comme un délais de transit, une perte de paquets ou même un débit maximal sur une simple interface réseau locale. J’avais déjà parlé de ce sujet il y a quelques temps pour simuler une liaison WAN entre une machine et son réseau. Suite à une question d’un lecteur, voici un billet dans lequel nous allons mettre en place un simulateur de liaison WAN entre deux réseaux LAN. Cette infrastructure pourra être utile à toutes personnes devant valider sur table une architecture inter-site.

De quoi avons nous besoin ?

Pour bâtir cette infrastructure, nous avons besoins de deux réseaux LAN (mais deux PC peuvent suffirent) et d’une machine GNU/Linux disposant de deux interfaces réseaux permettant de faire un pont entre ces deux LAN. Le choix d’une architecture en pont (bridgé) permet d’insérer facilement le simulateur dans une architecture réseau existante.

 

Configuration du bridge

Personnellement, j’ai utilisé une distribution GNU/Linux Debian Squeeze pour mettre en place le simulateur. Mais toutes les distributions GNU/Linux avec une version de Kernel >= 2.6 peuvent faire l’affaire.

Après une installation standard du système d’exploitation Debian, il faut ajouter le paquet bridge-utils pour permettre à ce dernier de créer le pont entre les deux interfaces réseaux:

sudo aptitude install bridge-utils

Il faut ensuite éditer le fichier de configuration /etc/network/interfaces de la manière suivante:

auto lo

iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto br0

iface br0 inet dhcp

bridge_ports eth0 eth1

Puis on fait prendre en compte cette configuration par le système:

sudo /etc/init.d/networking restart

Note: il faut attendre une trentaine de seconde lors de l’initialisation.

On vient donc de créer une nouvelle interface virtuelle (br0) qui fait un pont entre les deux interfaces physiques (eth0 et eth1).

Si vous connectez en l’état le simulateur entre vos deux LAN, tout le trafic transitera de manière transparente à la vitesse maximale de vos interfaces eth0 et eth1.

Configuration du simulateur

On passe maintenant à la partie intéressante de ce billet: comment simuler un lien WAN à partir de notre simulateur.

Vous allez voir que c’est relativement simple. Nous allons utiliser un script de configuration automatique qui va activer / désactiver le simulateur à la demande. Les caractéristiques du WAN à simuler seront codées en dur dans la section configuration du script. A vous de l’adapter à vos besoins.

Voici le script en question (également disponible sur mon GitHub):

#!/bin/bash
#
# simulwan-bridge.sh
# Nicolargo - 2012
#

##############################################################################

# Nom des interfaces ou l'on doit faire les simulations
# eth0 cote LAN local 
# eth1 cote LAN distant
IF=eth1

# Liaison sortante (UPLOAD) a appliquer sur IF
# Debit sortant
BWU=8mbit
# Délai de transit sortant
DELAYU=15ms
# % de paquets perdus sortant
LOSSU=0.0001%

# Liaison entrante (DOWNLOAD) a appliquer sur IF
# Debit entrant
BWD=1mbit
# Délai de transit entrant
DELAYD=15ms
# % de paquets perdus entrant
LOSSD=0.00001%

##############################################################################

start() {
    modprobe ifb
    ip link set dev ifb0 up

    tc qdisc add dev $IF ingress

    tc filter add dev $IF parent ffff: \
    protocol ip u32 match u32 0 0 flowid 1:1 \
    action mirred egress redirect dev ifb0

    # Liaison entrante
    tc qdisc add dev ifb0 root handle 1:0 \
    netem delay $DELAYD 10ms distribution normal \
    loss $LOSSD 25%

    tc qdisc add dev ifb0 parent 1:1 handle 10: \
    tbf rate $BWD buffer 3200 limit 6000

    # Liaison sortante
    tc qdisc add dev $IF root handle 2:0 \
    netem delay $DELAYU 10ms distribution normal \
    loss $LOSSU 25%

    tc qdisc add dev $IF parent 2:1 handle 10: \
    tbf rate $BWU buffer 3200 limit 6000
}

stop() {
    tc qdisc del dev ifb0 root
    tc qdisc del dev $IF root
    # ip link set dev ifb0 down
}

restart() {
    stop
    sleep 1
    start
}

show() {
    echo "Liaison entrante"
    tc -s qdisc ls dev ifb0
    echo "Liaison sortante"
    tc -s qdisc ls dev $IF
}

case "$1" in
    start)
        echo -n "Starting WAN simul: "
        start
        echo "done"
        ;;
    stop)
        echo -n "Stopping WAN simul: "
        stop
        echo "done"
        ;;
    restart)
        echo -n "Restarting WAN simul: "
        restart
        echo "done"
        ;;
    show)
        echo "WAN simul status for $IF:"
        show
        echo ""
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|show}"
        ;;
esac

exit 0

Par défaut, le script simule une liaison WAN de type ADSL (8 Mbps en download et 1 Mbps en upload avec un délais de transit de 30ms en aller/retour et un taux de perte de 10^-4).

Pour l’installer, il suffit de saisir les commandes suivantes:

sudo wget -O /etc/init.d/simulwan.sh https://raw.github.com/nicolargo/simulwan/master/simulwan-bridge.sh
sudo chmod a+x /etc/init.d/simulwan.sh

Pour lancer le simulateur WAN:

sudo /etc/init.d/simulwan.sh start

Pour arrêter le simulateur WAN:

sudo /etc/init.d/simulwan.sh stop

Pour avoir un état des interfaces:

sudo /etc/init.d/simulwan.sh show

Conclusion

Vous venez donc à moindre coût de mettre en place une architecture permettant de simuler des liaisons WAN. Le PC sur lequel se base votre simulateur n’a pas besoin d’être une bête de course et vous pouvez donc facilement récupérer du vieux matériel pour mettre en place ce système.

 

 

 

Catégories
Open-source Planet-libre Reseau

Suivi graphique des attaques DDOS avec Munin

Les attaques DDOS sont une véritable plaie pour les sites Internet. Même pour des sites à forte audience et donc dimensionnés au niveau architecture système et réseau pour absorber ces aléas, il est important de surveiller de prêt ces attaques. Nous avions déjà abordé ce sujet ensemble en mettant en place une alerte Nagios sur attaque DDOS. Nous allons ici compléter cette supervision en apportant un suivi graphique de ces attaques en utilisant un plugin spécifique pour Munin.

Installation de Munin

Il suffit de vous reporter au billet que j’avais écrit sur le sujet il y a quelques mois. Le plugin qui va se charger de la détection des attaques DDOS doit être installé sur chacun des noeuds (« Munin node ») à surveiller.

Principe du Plugin ddos_

Ce plugin se base sur le même principe que le plugin Nagios. Il va lire le nombre de connexions de type SYN_RECV ouvertes et les renvoyer au noeud Munin maître pour que ce dernier stocke l’information dans une base RRD et l’affiche à la demande dans un page Web.

Le plugin est disponible sur mon GitHub (il est donc possible de l’améliorer et d’en faire profiter la communauté).

Si vous êtes intéressé par l’écriture de vos propres plugins pour Munin, le plus simple est de commencer par la lecture de la documentation officielle.

Revenons à notre plugin ddos_.

Pour l’installer sur un noeud, la procédure à suivre est la suivante:

cd /tmp
wget https://raw.github.com/nicolargo/muninplugins/master/ddos_
sudo munin-node-configure --shell
sudo cp ddos_ /usr/share/munin/plugins/
sudo chmod a+x /usr/share/munin/plugins/ddos_
sudo munin-node-configure --shell
sudo ln -s /usr/share/munin/plugins/ddos_ /etc/munin/plugins/ddos_
sudo service munin-node restart

On peut vérifier que le plugin est bien actif en saisissant la commande:

sudo munin-node-configure | grep ddos
ddos_                      | yes  |

Il faut ensuite attendre quelques heures pour voir apparaître le graphe au niveau de votre serveur Munin.

Par défaut, le plugin est configuré pour afficher les valeurs en WARNING quand le nombre de SYN_RECV dépasse le seuil des 50 et en CRITICAL au dessus de 70 (vous pouvez bien sûr changer ces valeurs dans le munin.conf).

C’est pas beau Munin 🙂 ?

Catégories
Open-source Planet-libre Web

Partager simplement des fichiers sur le Web avec DropCenter

Suite à mon billet sur les solutions auto-hébergées de partage de fichiers par interface Web, quelques lecteurs et followers m’ont conseillés de regarder du coté de DropCenter. Une solution libre (licence CC BY-NC-ND 2.0), légère (sans base de données) et que l’on peut auto-héberger.

Cerise sur le gâteau, le projet est développé par deux jeunes Français (aka IdleMan et Fox). Il ne m’en fallait pas plus pour me plonger dans le test de DroCenter. C’est partie pour la visite guidée.

Installation de DropCenter

Nous allons commencer par détailler l’installation de DropCenter sur une machine Debian 6 (mais la procédure peut être suivie pour n’importe quelle distribution GNU/Linux ou BSD).

Les pré-requis sont réduits au strict minimum car il suffit de disposer d’un serveur Web compatible avec le langage PHP (j’utilise personnellement le stack NGinx + PHP FPM).

cd /tmp
wget http://dropcenter.fr/wp-content/Versions/1.4Beta/dropCenter1.4Beta.zip
unzip ./dropCenter1.4Beta.zip
sudo mv dropCenter /var/www/dropcenter
sudo chown -R www-data:www-data /var/www/dropcenter

Note: les commandes précédentes vont installer la version 1.4b de DropCenter dans le répertoire Web /var/www/dropcenter.

Note 2: Par défaut, votre configuration PHP limite la taille maximale des fichiers à uploader à 16 Mo. Pour augmenter cette valeur, il faut modifier les paramètres post_max_size et upload_max_filesize dans votre fichier de configuration php.ini. Attention, sur un système 32 bits, la limite doit être de 2147483647 octets (2 Go – 1). 

Il ne reste plus qu’à pointer un navigateur vers l’URL: http://votreserveur.com/dropcenter pour accéder à la page de configuration du compte administrateur.

Il suffit de saisir les informations suivantes pour créer le compte administrateur initial:

  1. le login de l’administrateur
  2. le mot de passe associé (il serait bien de disposer dans le formulaire d’un champ de confirmation pour ressaisir une seconde fois le mot de passe…)
  3. l’adresse mail de l’administrateur (idem)
  4. l’URL racine de votre installation de DropCenter
  5. de vérifier que les pré-requis de votre serveur Web sont bons

« That’s all folks ! ».

L’installation est terminé, vous pouvez commencer à utiliser votre service DropCenter !

Utilisation de DropCenter

Il suffit de d’aller sur l’URL http://votreserveur.com/dropcenter pour accéder à votre DropCenter.

L’interface utilisateur est simple:

Il suffit de copier/glisser le fichier à uploader (si votre navigateur est compatible, en bref si vous n’utilisez pas IE :)) ou de cliquer sur cette même zone.

Après sélection, les fichiers vont automatiquement être « uploadés » dans le sous-répertoire /var/www/dropcenter/uploads/.

Il est alors simple d’obtenir le lien (URL) vers le fichier en question (une fonction de type raccourcissement d’URL serait la bienvenue !).

Les fichiers uploadés sont seulement visibles des personnes disposant d’un compte sur votre DropCenter. La création de nouveaux comptes utilisateurs est limité aux administrateurs. Par contre ils sont téléchargeables par n’importe qui disposant du lien vers le fichier.

Autre fonction que je trouve intéressante est la possibilité de s’abonner à un flux RSS permettant de suivre tout ce qui se passe sur votre DropCenter (ajout d’utilisateur, upload de fichiers…). Le lien est disponible en bas de l’interface Web. Les auteurs proposent même un deuxième logiciel nommé DropNews (disponible sous Linux et Windows) qui exploite ce flux RSS pour afficher directement les évènements sur le bureau de votre ordinateur.

Note pour les utilisateurs utilisant PHP-FPM

Je suis tombé sur l’erreur suivante qui m’empêchait de  voir la liste des fichiers disponibles sur mon DropCenter:

2012/06/02 16:05:07 [error] 30975#0: *181 FastCGI sent in stderr: « PHP message: PHP Warning: date(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Europe/Berlin’ for ‘CEST/2.0/DST’ instead in /var/www/dropCenter/php/function.php on line 49

Pour résoudre ce petit problème, j’ai ajouter la ligne suivante à mon fichier /etc/php5/fpm/php.ini:

date.timezone = Europe/Paris

Puis j’ai relancé PHP-FPM:

sudo service php-fpm restart

Alors ?

Je dois dire que j’ai été bluffé par la rapidité d’installation de DropCenter par rapport aux autres solutions du même style.

L’utilisation est du même acabit: simple et efficace. Le logiciel fait ce qu’on lui demande et il le fait bien !

Pour revenir à mon billet précédant, je pense que DropCenter est de loin la meilleure solution légère comme alternative aux services en ligne propriétaire.

Le futur de DropCenter

Ce projet prometteur est actuellement en version 1.4 bêta. La version stable devrait bientôt sortir et être suivie d’une version 2 qui apportera, entre autres, les fonctionnalités suivantes:

  • classement des fichiers par taille, date, tags, auteur
  • upload vers Dropbox
  • édition avancée des fichiers
  • version pour mobile et tablettes
  • restrictions sur le Hotlinking

Les auteurs recherchent des contributeurs matures et motivés ayant des compétences en PHP/Javascript/CSS/HTML (pour la partie web), C++/QT (pour la partie client lourd) et WebDesign (pour la partir UI).