Christophe Nowicki

June 16, 2014

Déploiement “en masse” de noyau Linux personnalisé et durci à l’aide de Puppet

200px-Pax_tux

Comme tout barbu qui se respecte, j’aime avoir un noyau Linux, dont la configuration correspond parfaitement au matériel et à l’utilisation d’une machine.

Pour cela j’ai développé un module Puppet qui permet de déployer des noyaux Linux personnalisés et durcis.

Problématique

Compiler et personnaliser la configuration du noyau d’une seule machine est une tâche qui nécessite :

  • une bonne connaissance des options du noyau ;
  • connaissance du matériel et des drivers correspondants ;
  • du temps ;

Il y a de cela une dizaines d’année il était fréquent de compiler une version personnalisée du noyau Linux, mais aujourd’hui le noyau fourni par une distribution GNU/Linux, contient une grande quantité de pilotes et couvre la plupart des besoins.

Il n’y a pas de différence de performance entre un pilote de périphériques compiler en “dur” dans le noyau et charger en modules.

Les seules raisons de compiler un noyau personnalisé sont :

  • la vitesse de démarrage ;
  • et la sécurité.

C’est ce dernier point qui m’a poussé à mettre en place un système de compilation de noyau Linux automatisé.

Module Puppet

Le module Puppet dispose des fonctionnalités suivantes :

  • installation et décompression des sources du noyau dans /usr/src ;
  • application du patch grsecurity ;
  • écriture d’un fichier de configuration personnalisé ;
  • re-compilation du noyau et création d’un paquet pour la distribution Debian GNU/Linux ;
  • compilation en cas de changement de la configuration ;
  • TODO : installation du paquet et reboot sur le nouveau noyau à l’aide de kexec ;

Gestion de la configuration du noyau

D’après le LKDDb (Linux Kernel Driver DataBase), il y a plus de 19 000 options différentes dans un noyau Linux.

L’approche classique pour la gestion d’un tel nombre d’options est l’utilisation d’un tableur Excel ;-)

Mais la plupart des utilisateurs conservent les fichiers de configuration directement sur le système de fichier ou dans un logiciel de gestion de version.

Mais cette approche ne me satisfait pas, j’ai donc opté pour l’utilisation d’une base de données hiérarchique : Hiera

Structure hiérarchique

La structure adoptée est la suivante :

# /etc/puppet/hiera.yaml
---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hiera/
:logger: puppet
:hierarchy:
  - "fqdn/%{::fqdn}"
  - "boardproductname/%{::boardproductname}"
  - "hardwaremodel/%{::hardwaremodel}"
  - common

common.yaml

Contient la configuration commune à toutes les machines et la “négation” des options, ce qui évite à make-kdpkg de choisir une option par défaut :

# /etc/puppet/hiera/common.yaml
---
linux-grsec::kernel::config:
    CONFIG_CGROUP_DEBUG: n
    CONFIG_CGROUP_FREEZER: n
    CONFIG_CGROUP_DEVICE: n
    CONFIG_CPUSETS: n
    CONFIG_PROC_PID_CPUSET: n
    CONFIG_CGROUP_CPUACCT: n
    CONFIG_RESOURCE_COUNTERS: n
    CONFIG_MEMCG: n
    CONFIG_CGROUP_HUGETLB: n
    CONFIG_CGROUP_PERF: n
    CONFIG_CGROUP_SCHED: n
    CONFIG_FAIR_GROUP_SCHED: n
    CONFIG_CFS_BANDWIDTH: n
    CONFIG_RT_GROUP_SCHED: n
    CONFIG_BLK_CGROUP: n
    CONFIG_CHECKPOINT_RESTORE: n    
    CONFIG_GRKERNSEC: y
    CONFIG_GRKERNSEC_CONFIG_AUTO: n
    CONFIG_GRKERNSEC_CONFIG_CUSTOM: y
    CONFIG_PAX: y
...

Répertoires hardwaremodel et boardproductname

Le répertoire hardwaremodel contiens la définition d’un architecture :

/etc/puppet/hiera/hardwaremodel/
├── i586.yaml
├── i686.yaml
└── x86_64.yaml

Comme par exemple l’architecture x86_64:

# /etc/puppet/hiera/hardwaremodel/x86_64.yaml
---
linux-grsec::kernel::config: 
    CONFIG_64BIT: y
    CONFIG_X86_64: y
    CONFIG_OUTPUT_FORMAT: '"elf64-x86-64"'
    CONFIG_ARCH_DEFCONFIG: '"arch/x86/configs/x86_64_defconfig"'

Le répertoire boardproductname contient la définition des pilote de périphériques pour une machine :

/etc/puppet/hiera/boardproductname/
├── beagleboneblack.yaml
├── C7Q67.yaml
├── D33217GKE.yaml
├── DN2800MT.yaml
├── net5501.yaml
├── net6501.yaml
├── raspberrypi.yaml
├── wandboard.yaml
├── X7SPA-HF.yaml
├── X9SCL.yaml
└── Z68MA-D2H-B3.yaml

Par exemple, pour un net5501 de Soekris Inc. :

# /etc/puppet/hiera/boardproductname/net5501.yaml
---
linux-grsec::kernel::config:
    CONFIG_SMP: n
    CONFIG_X86_64_SMP: n
    CONFIG_X86_32_SMP: n
    CONFIG_RCU_FANOUT: 32
    CONFIG_MGEODE_LX: y
    CONFIG_X86_GENERIC: n
    CONFIG_GENERIC_CPU: n
    CONFIG_NET_VENDOR_VIA: y
    CONFIG_VIA_RHINE: y
    CONFIG_VIA_RHINE_MMIO: y
    CONFIG_HW_RANDOM_GEODE: y
    CONFIG_FB_GEODE: y
    CONFIG_CRYPTO_DEV_GEODE: y
    CONFIG_CRC_T10DIF: y
    CONFIG_ATA_GENERIC: y
    CONFIG_PATA_CS5536: y
    CONFIG_CS5535_MFGPT: y
    CONFIG_SENSORS_PC87360: y
    CONFIG_I2C: y
    CONFIG_SCx200_ACB: y
    CONFIG_LEDS_NET5501: y

Répertoire fqdn

Le répertoire fqdn contient les options spécifique à une machine et à ses fonctionnalités (ici une gateway VPN avec StrongSwan et l’IPS Suricata ) :

# /etc/puppet/hiera/fqdn/foo.bar.yaml
---
linux-grsec::kernel::config:
# StrongSwan
    CONFIG_XFRM_USER: y
    CONFIG_NET_KEY: y
    CONFIG_NET_KEY_MIGRATE: n
    CONFIG_IP_ADVANCED_ROUTER: y
    CONFIG_IP_MULTIPLE_TABLES: y
    CONFIG_INET_AH: y
    CONFIG_INET_ESP: y
    CONFIG_INET_IPCOMP: y
    CONFIG_INET_XFRM_MODE_TRANSPORT: y
    CONFIG_INET_XFRM_MODE_TUNNEL: y
    CONFIG_INET_XFRM_MODE_BEET: y
    CONFIG_NET_IPVTI: n
    CONFIG_IPV6: y
    CONFIG_INET6_AH: y
    CONFIG_INET6_ESP: y
    CONFIG_INET6_IPCOMP: y
    CONFIG_INET6_XFRM_MODE_TRANSPORT: y
    CONFIG_INET6_XFRM_MODE_TUNNEL: y
    CONFIG_INET6_XFRM_MODE_BEET: y
    CONFIG_IPV6_MULTIPLE_TABLES: y
    CONFIG_IPV6_SUBTREES: n
    CONFIG_NETFILTER: y
    CONFIG_NETFILTER_XTABLES: y
    CONFIG_NETFILTER_XT_MATCH_POLICY: y
# Suricata
    CONFIG_NETFILTER_ADVANCED: y
    CONFIG_BRIDGE_NETFILTER: n
    CONFIG_NETFILTER_NETLINK_QUEUE: y
    CONFIG_NETFILTER_NETLINK_ACCT: y
    CONFIG_NETFILTER_XT_TARGET_NFQUEUE: y
...

Configuration finale

$ hiera -h  linux-grsec::kernel::config ::hardwaremodel i586 ::boardproductname net5501 ::fqdn foo.bar
{"CONFIG_NETFILTER_XT_MATCH_STATISTIC"=>"n",
 "CONFIG_BLK_DEV_RSXX"=>"n",
 "CONFIG_USB_CATC"=>"n",
 "CONFIG_MMU"=>"y",
 "CONFIG_GPIO_BCM_KONA"=>"n",
 "CONFIG_CHELSIO_T4VF"=>"n",
 "CONFIG_SERIAL_CORE"=>"y",
 "CONFIG_DM_MIRROR"=>"y",
 "CONFIG_IO_DELAY_TYPE_NONE"=>3,
 "CONFIG_MMC_TEST"=>"n",
...

Exemple d’utilisation

# puppet agent -t
...
info: Applying configuration version '1402952642'
notice: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]/ensure: created
info: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4.tar.xz]/ensure: defined content as '{md5}c7c565d14833550faa39ef8279272182'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch]/ensure: defined content as '{md5}e88a81b0c222d14e228dc29dd76a875a'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch.sig]/ensure: defined content as '{md5}737b22b6e8cae0d4398ba3f68acaf1e1'
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]/returns: executed successfully
info: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4]/returns: executed successfully
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4/.config]/ensure: created
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: exec make kpkg_version=12.036+nmu3 -f /usr/share/kernel-package/ruleset/minimal.mk debian APPEND_TO_VERSION=-foo  INITRD=YES 
...
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: cp -pf debian/control.dist          debian/control
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[2]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[1]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]: Triggered 'refresh' from 2 events
notice: Finished catalog run in 179.65 seconds
..
# dpkg -i linux-*.deb

Conclusion

Ce système me permet de déployer des noyaux GRSec sur la petite dizaine de machines de mon réseau local.

Cette méthode ne convient pas au domaine de l’embarqué, (rasberrypi, beaglebone black, wandboard, etc… ) car l’espace disque et la puissance de calcul nécessaire ne sont pas disponible sur ce type de machine.

Références

Filed under: Debian — Tags:, , , , , , , — cscm @ 22:33

January 13, 2011

Suivi de la consommation d’eau et du bon fonctionnement la climatisation

Voici un exemple d’installation permettant de suivre sa consommation d’eau et recevoir des notifications lors d’un problème avec le circuit de climatisation.

Problématique

Lorsque le système de climatisation d’une salle serveur s’arrête alors la température monte dangereusement, et après avoir perdu quelques routeurs coûtants plusieurs milliers d’euros ;-), nous avons décidé d’agir et mettre en place un système de surveillance.

N’ayant pas trouvé de système / solution comparable dans le commerce.
Nous avons donc décidé de suivre les conseils de mon cousin Piotr Adamski. ;-)

Solution

Nous avons donc mis en place la solution suivante :

Composants

Les composants matériels suivants sont nécessaire :

L’ensemble des composants sont disponibles en France, chez Planet Domotique et sont produits par Embedded DATA Systems.

Pour la partie logiciel vous avez plusieurs choix possibles pour :

  • Faire des graphiques de la consommation d’eau à l’aide du protocole SNMP avec Munin ou Cacti ;
  • Surveiller l’écoulement de l’eau à l’aide de Nagios ou Monit ;

Budget

  • 40 euros TTC pour le compteur d’eau ;
  • 56 euros TTC pour le compteur d’impulsion ;
  • 130 euros TTC pour le serveur Ethernet / 1-wire ;
  • 100-200 euros TTC pour l’installation du compteur par un plombier ;

Total : de 326 à 426 euros TTC

Photos du montage

Voici quelques photos du montage en action :

Surveillance avec Monit

Le script de surveillance pour Monit est disponible sur github :

Simple water watchdog script for OW-SERVER / DS2423 and Monit

Il se lance via monit de la manière suivante :

check process water_watchdog with pidfile water_watchdog.pid
    	start program  = water_watchdog

check file water_watchdog.status with path water_watchdog.status
	ignore match OK
	if match ^KO then alert

Il faut ajouter le chemin absolut aux noms de fichiers.

Le script de surveillance fonctionne sur le principe suivant :

Un lanceur de deamon water_watchdog, lance le script water_watchdog.pl et le surveille en permanence.

Celui-ci interroge toutes les 60 secondes la compteur d’eau et vérifie que la quantité d’eau consommée a bien augmentée dans l’intervalle.

Écrit le résultat dans le fichier water_watchdog.status qui est surveillé par monit.

En cas de coupure d’eau, le nombre de litres d’eau consommée n’évolue pas et une alerte monit est lancée.

Le système est très fiable, mais il est nécessaire de le paramétrer en fonction du débit de votre installation.
Voici ma configuration pour 10 000 l/j :

  • FLOW_ALERT_LOWER_LIMIT = 1
  • RATE = 60

Conclusion

Le script fonctionne en production depuis plusieurs semaines. Il permet d’intervenir très rapidement en cas de coupure et donc de sauver la vie de quelques serveurs ;-)

Références

Filed under: Hardware,Home automation — Tags:, , , , — cscm @ 10:38

November 7, 2010

Lancement du projet HOMESENSE à Paris

HomeSense Logo

EDF R&D, Tinker London et l’ Université de Lancaster ont lancer le projet HomeSense.

L’objectif de celui-ci, est de mettre à disposition de plusieurs maisons réparties en Europe un kit de développement électronique basé sur la carte Arduino et un expert référent.

L’idée de projet est d’accompagner des personnes sans compétences particulières dans le domaine de l’électronique et la domotique dans une démarche de maison intelligente.

La démarche m’a beaucoup plus et j’ai donc décidé de participer au projet pour les raisons suivantes :

  • Je m’intéresse un peu à la domotique ;
  • Le matériel libre me passionne ;
  • J’aime beaucoup le rapprochement interdisciplinaire créé par la communauté Arduino, en effet, ce n’est pas simplement encore une carte de prototypage électronique rapide créée par l’industrie, mais bel et bien un rapprochement entre les “gens” du hardware, du software et du design ;
  • Cela me fait une excuse officielle pour bidouiller ;-)

Le Kit

L’Université de Lancaster a mis au point un Kit électronique basé sur la carte Arduino, il s’agit d’un kit sans soudure, un peu comme dans une boite de LEGO, l’ensemble des connections se font très simplement.
Le kit est très semblable à l’Electronic Brick de SeeedStudio

Le kit contient les briques suivantes :

  • carte Arduino ;
  • alimentation ;
  • “sensor shield” ;
  • un émulateur de clavier ;
  • des câbles ;
  • des boutons poussoirs ;
  • des capteurs de pression ;
  • des potentiomètres ;
  • des LEDs ;
  • servomoteur ;
  • un écran LCD.

Le kit est fourni avec des nombreux exemples pour exploiter ces composants.

Les Projets

Durant les trois mois du projet, nous nous sommes mis d’accord avec Maëlle pour réaliser des projets suivants :

  • La gestion des différentes radios de l’appartement pour “Écoutez la différence” ;-)
  • Le système d’illumination de l’appartement.

Nous documenterons notre démarche et l’avancement des travaux sur les différents blogs.

Références

Voici quelques références intéressantes :

July 29, 2010

Domotique et économie d’énergie

Dans ce billet, je vais essayer d’expliquer le rôle que pourrait jouer les technologies domotique dans l’économie d’énergie.

Je vais décrire mes expérimentations et quelques ressources intéressantes sur le sujet.

Le suivi de la consommation en temps réel

C’est l’étape la plus simple à mettre en oeuvre, elle consiste à mettre en place un système de suivi de la consommation qui affiche l’information en temps réel.

Il existe de nombreuses techniques pour mesurer :

Le rôle de la mesure

J’ai tout d’abord été très septique sur l’utilité de ces techniques et à part faire de jolis graphiques et des calculs sur ces données, cela ne me semblait pas être vraiment utile.

Pourtant, le fait d’afficher la consommation en temps réel aux utilisateurs permet d’influencer son comportement.

En effet, le fait qu’un appareil consomme de l’énergie n’est pas perceptible par un humain et il est donc nécessaire de mettre en place des outils de mesure.

L’affichage en temps réel permet de notifier les utilisateurs sur la quantité d’énergie consommée et le coût de celle-ci;
ce qui influence directement leur comportement et permet de réaliser des économies tangibles et chiffrables.

D’après une étude de l’université d’Oxford , l’affichage en temps réel de la consommation permet de la faire baisser de 7 à 15%. Pour un investissement de départ faible. ( voir la liste des solutions de Mesure de consommation électrique )

Pour ma part, le Current cost m’a permis de réduire ma facture d’électricité de 10% sur un an.

Optimisations possibles

Dans un second temps, il faut s’attaquer aux pertes d’énergie et optimiser au maximum son usage.

Électricité

Dans une maison, comme chez vous, il y a de nombreux appareils inutiles qui consomment de l’énergie électrique sans être utilisés : les veilles, les transformateurs, etc…

La plupart des veilles sans trompeuses.En effet, certains appareils électriques mal concus consomment presque autant d’énergie en veille qu’en fonctionnement normal.
Comme par exemple, les “Box Internet”.

Il est donc nécessaire d’éteindre complètement ces appareils lorsque vous ne les utilisez pas.

Pour ce faire, les moyens les plus simple sont les multiprises de type maître-esclave qui fonctionnent à l’aide du port USB, d’un système de seuil de consommation ou bien à l’aide d’un interrupteur.

Pour les autres appareils, il est aussi possible d’utiliser des relais (X10, Plugwise, PLCBUS, EasyDAQ, 1-wire, etc… ) pour couper à distance un appareil, durant les périodes ou ils ne doivent pas être utilisés.

L’idée est de coupler ces systèmes avec un ordonnanceur de tâches (tel que Job scheduler, fcron, cron… ) pour prendre en charge l’effacement des différents appareils de manière cohérente.

Vous pouvez ensuite optimiser votre consommation en fonction de facteurs extérieurs tels que :

  • le type d’abonnement du fournisseur d’énergie (EDF Tempo, Heure Creuses, etc… ) ;
  • le nombre de personnes présent dans habitat (RFID is your friend) ;
  • les demandes de votre fournisseur d’énergie ( SmartGrid : Peak curtailment/levelling ) ;
  • les prévisions météo ;
  • votre propre production d’énergie ;

Eau et Gaz

Pour les liquides, il existe des solutions de vannes équipées de Servomoteur, permettant de couper l’eau ou le gaz en cas de fuite.

Domotique = Informatique

Comme la domotique consiste à utiliser l’informatique au sein de habitat, il est donc nécessaire de mettre en place des services qui fonctionnent en permanence sans trop consommer d’énergie.

Les choix les plus importants dans ce domaine sont la plate-forme matériel et logiciel.
Pour ceux qui ont opté pour une solution basée sur GNU/Linux, il existe de très nombreuses solutions embarquées qui allient puissance de calcul et faible consommation.

Pour les autres, le serveur Microsoft Windows, peut toujours servir de radiateur ;-)
Et le Mac de lampe de chevet ;-)

Futur

Comme vous pouvez le constater, il existe de nombreuses solutions pour réduire sa consommation d’énergie à l’aide de la domotique.

La plupart sont faciles à mettre en place et nécessite un faible investissement.

Il est clair que les solutions de compteurs intelligents vont se démocratiser et ouvrir la voix au réseau électrique intelligent.

Ces réseaux doivent normalement rester à la porte de votre appartement, car ils présentent un risque important pour la vie privé.

En effet, le marché du suivi de l’énergie intéresse beaucoup de monde car la simple observation de votre consommation permet de déterminer vos habitudes et la marque de votre frigidaire.

Références

Filed under: Home automation — Tags:, , , , , — cscm @ 20:18

March 29, 2010

Migration d’un réseau Debian GNU/Linux vers IPv6 et au-delà …

Migration IPv6

C’était une tâche sur ma TODO liste depuis quelques années…
J’ai enfin franchi le pas et migré mon réseau vers IPv6.

Cette migration n’est pas encore évidente et j’ai rencontré quelques problèmes dont je voulais vous faire part dans ce billet.

L’objectif inavouable de cette migration était de rendre mon réfrigérateur directement accessible depuis le travail ;-)

Amis manchots, suivez- moi ;-)

Présentation d’IPv6

IPv6 c’est le futur ©, l’avenir du monde libre, c’est le monde de demain … puisqu’on vous le dit depuis 10ans^W^W!

Bref, je ne vais pas vous faire un long discours sur le sujet mais
plus simplement vous expliquer ce qui a réellement motivé ma migration.

Comme vous le savez sûrement, je m’intéresse un peu à la domotique et à la culture D.I.Y., ce qui m’a permis de découvrir quelques concepts sympathiques et connexe au domaine tels que :

  • Physical computing : l’intéraction entre un processeur et le monde physique ;
  • Ambient intelligence : L’Intelligence ambiante, la fonte de l’informatique dans nos objets de tous les jours ;
  • Internet of Things : L’Internet des objets, l’extension de l’Internet au monde réel.

Pour émerger, ces concepts ont tous besoin de la même chose : un nouveau protocole Internet permettant :

  • d’augmenter sensiblement le nombre d’adresses disponibles ;
  • des mécanismes de configuration automatique ;
  • la sécurité et de la mobilité.

Avec IPv6, il est possible de connecter :

Bref, cela permet d’ouvrir de nombreuses possibilités ;-)

Tunnel

Si votre fournisseur d’accès Internet ne met pas à votre disposition une collectivité IPv6 native, alors vous aurez besoin de mettre en place un tunnel 6to4.
Visiblement seuls Nerim et FDN offrent en France un collectivités IPv6 native.

IPv6 Tunnel Brocker

Pour obtenir un tunnel, il suffit d’ouvrir un compte chez Hurricane Electric (HE), vous devez suivre la procédure décrite avec des copies d’écran sur howto forge.

Fonctionnalités

HE vous fournit les services suivants :

  • Tunnel 6to4 ;
  • Deux sous-réseau IPv6 : /64 et /48 ;
  • Serveur DNS accessible en IPv4 et IPv6 ;
  • Résolution inverse DNS sur vos deux sous réseaux ;
  • Une certification de vos compétences IPv6 et du bon fonctionnement de votre reseau.

Un des gros avantage de HE est de vous fournir un sous-réseau /48 qu’il est possible de découper en plusieurs sous-réseau /64 en fonction de vos besoins : LAN, DMZ, Réseau de capteurs, etc…

Configuration du pare-feu Shorewall

DMZ avec un s

Comme la plupart des réseaux, j’utilise le principe de DMZ pour les services accessibles publiquement en IPv4.

Comme IPv6 me fournit beaucoup plus d’adresses publiques, il est possible de découper la route /48 fourni par HE en plusieurs DMZ.

Installation de Shorewall6

Pour la gestion du pare-feu, j’utilise les scriptes fournis par le projet Shorewall, qui facilite grandement l’écriture et l’organisation des règles.
Pour la gestion de l’IPv6, il est nécessaire d’utiliser une version spécifique : shorewall6.
Celle-ci est disponible dans les versions squeeze et sid de Debian, il est donc nécessaire de backporter le paquet.
Il suffit donc de backporter la version 4.4 de shorewall dans lenny :

# cd /usr/src
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4-2.dsc
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4.orig.tar.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4-2.diff.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5-1.dsc
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5.orig.tar.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5-1.diff.gz
# dpkg-source -x shorewall6_4.4.7-2.dsc
# dpkg-source -x shorewall_4.4.7-1.dsc
# cd shorewall-4.4.7
# dpkg-buildpackage -b
...
# dpkg -i ../shorewall-common*
# dpkg -i ../shorewall-all*
# dpkg -i ../shorewall-shell*
# cd ../shorewall6-4.4.7
# dpkg-buildpackage -b
# dpkg -i ../shorewall6*.deb

Configuration du tunnel

Pour le tunnel 6to4, il est nécessaire de modifier le fichier /etc/shorewall/tunnels de Shorewall (IPv4) :
###############################################################################
#TYPE ZONE GATEWAY GATEWAY
6to4 net IP
#

Migration de la configuration

Vous devez ensuite migrer votre configuration de Shorewall IPv4 vers IPv6.
Pour cela vous pouvez vous aider avec les exemples fournis dans le /usr/share/doc/shorewall6/examples

La stratégie de filtrage est identique à celle en IPv4 : c’est à dire bloquer tous les services et ajouter des règles spécifiques pour autoriser des services. Il faut juste faire attention à l’ICMPv6 qui à un plus grand rôle dans le cas de IPv6.

Pour la configuration des fonctionnalités spécifiques à IPv6 dans Shorewall6, vous pouvez vous reporter directement à la documentation : Shorewall IPv6 Support

Configuration du DNS

Pour la configuration de mon serveur DNS, BIND prend en charge l’IPv6. J’ai donc créé une sous-zone v6.csquad.org pour les services uniquement accèssibles en IPv6 et attribués des addresses aux services publics existants :

$ grep AAAA /etc/bind/wan/db.csquad.org
        		AAAA    2001:470:c830::6
ns			AAAA	2001:470:c830::3
smtp			AAAA	2001:470:c830::10
www                      AAAA    2001:470:c830::6

Une sous-zone v6.csquad.org pour les services uniquement accessibles en IPv6:

$TTL    3600 ; 8 heures
@       IN      SOA ns.v6.csquad.org. hostmaster.csquad.org. (
                        2010031801      ; Serial
                                1D      ; Refresh
                                2H      ; Retry
                                6W      ; Expire
                         3600 ) ; Negative Cache TTL

                        NS      ns.v6.csquad.org.
                        A       82.247.220.114

ns              IN A 82.247.220.114

host             IN      AAAA    2042:42:42:42:42:42:42:42

La partie la plus difficile est la Zone inverse IPv6, car le contenu du fichier est très verbeux, et il est nécessaire de manipuler des adresses complexes à la main :

$TTL    3600 ; 8 heures
@       IN      SOA ns.v6.csquad.org. hostmaster.csquad.org. (
                        2010031602      ; Serial
                                1D      ; Refresh
                                2H      ; Retry
                                6W      ; Expire
                         3600 ) ; Negative Cache TTL

                        NS      ns.v6.csquad.org.

$ORIGIN 0.0.2.4.0.0.2.4.0.0.2.4.0.2.ip6.arpa.

2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4 IN PTR host.v6.csquad.org.

Pour vous aider, vous pouvez utiliser le programme ipv6calc :

$ ipv6calc --in ipv6addr --out revnibbles.arpa 2042:42:42:42:42:42:42:42
2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.2.ip6.arpa.

Vous pouvez tester le bon fonctionnement du DNS IPv6 à l’aide de la commande dig :
$ dig +short -t aaaa host.v6.csquad.org
2042:42:42:42:42:42:42:42

Le reverse :
$ dig +short -x 2042:42:42:42:42:42:42:42
host.v6.csquad.org.

Google et ses amis

De nombreux services Internet ne sont pas IPv6 ready out of the box et utilisent des sous-zones DNS pour leur services accèssibles en IPv6. Par example Google :
$ dig +short -t aaaa www.google.com
$ dig +short -t aaaa ipv6.google.com
ipv6.l.google.com.
2a00:1450:8001::63
2a00:1450:8001::67
2a00:1450:8001::68
2a00:1450:8001::69
2a00:1450:8001::6a
2a00:1450:8001::93

La commande ne retourne pas d’adresse IPv6, car google réserve cette réponse aux ISP/services qui disposent d’une connectivité IPv6 :
$ dig +short -t aaaa @212.27.32.176 google.com
$ dig +short -t aaaa @4.2.2.2 google.com

Pas de réponse via le DNS de Free et le DNS Public de Google.
Par contre, si j’interroge le DNS de Hurricane Electric (HE) :
$ dig +short -t aaaa @74.82.42.42 google.com
2a00:1450:8001::68
2a00:1450:8001::93
2a00:1450:8001::6a
2a00:1450:8001::67
2a00:1450:8001::69
2a00:1450:8001::63

Il faut donc modifier le fichier /etc/bind/named.conf.local pour forwarder la résolution de certains noms de domaine via le DNS de HE :

zone "google.com" {
        type forward;
        forwarders {
                  2001:470:20::2;
        };
};

D’habitude, je fais du Google bashing, mais je dois avouer que cette fois-ci Google est le seul à résoudre en IPv6.
Les autres “Grands Noms de l’Internet” , ne disposent pas d’une connectivité IPv6, parmi ceux-ci :

  • wikipedia ;
  • facebook ;
  • twitter ;
  • flickr ;
  • yahoo ;
  • slashdot ;
  • linuxfr.org ;

Bref, seul google est IPv6 friendly, les autres acteurs de l’internet sont à la traine.

Vous pouvez tester tous ses noms de domaines via cette page : IPv6 websites accesibility.

Configuration des machines

Autoconfiguration

Pour l’auto-configuration des machines, vous devez installer le paquet radvd :
# apt-get install radvd
Et modifier le fichier de configuration /etc/radvd.conf pour prendre en charge votre interface LAN avec votre prefix IPv6, comme cela :

interface eth1
{
        AdvSendAdvert on;
        MaxRtrAdvInterval 30;
        prefix 2042:42:42:42::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
                AdvValidLifetime 300;
                AdvPreferredLifetime 120;
        };
};

Ensuite vous devez relancer le daemon :
# /etc/init.d/radvd restart

Ensuite vous pouvez relancer l’interface réseau d’une machine et vérifier qu’elle à bien pris une adresse IPv6 :

# ip -f inet6 addr   | grep -B 1 global
4: eth0: <BROADCAST ,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000
    inet6 2042:42:42:42:42:42:42:2/64 scope global dynamic

Cette adresse IPv6 est produite à l’aide du prefix v6 et l’adresse MAC de votre carte réseau.

IP statique

Vous pouvez aussi attribuer une adresse IPv6 statique à l’aide du fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
        address 192.168.0.11
        netmask 255.255.255.0
        gateway 192.168.0.100

iface eth0 inet6 static
        address 2042:42:42:42::1
        netmask 64
        gateway 2042:42:42:42::100

Linux-VServer

La version de Linux VServer disponible dans Debian “lenny” dispose du support IPv6.

Il suffit d’ajouter l’adresse ip à l’interface et relancer le serveur :

# cd /etc/vservers/NOM_MACHINE/interfaces
# mkdir 1
# echo "eth0" > dev
# echo "2042:42:42:42:42:42:42:42/64" > ip
# echo "NOM_MACHINE" > name
# vserver NOM_MACHINE restart

Migration des services

Apache

Pour la configuration d’Apache, il suffit d’ajouter dans le fichier /etc/apache2/ports.conf, l’adresse de votre service :

Listen [2042:42:42:42:42:42:42:42]:80
Listen [2042:42:42:42:42:42:42:42]:443

Puis d’utiliser cette adrese dans un VirtualHost :

<VirtualHost  [2042:42:42:42:42:42:42:42]:80>
        ServerName host.v6.csquad.org
...

Messagerie

La configuration de Postfix en IPv6, ne pose aucun problème particulier. Il suffit d’ajouter des enregistrements DNS AAAA à votre serveur de messagerie :

                        MX      10 smtp
smtp                    AAAA    2001:470:c830::10

Et de modifier le fichier /etc/postfix/main.cf :

mynetworks = 127.0.0.0/8 [::1]/128 [2001:470:c830::]/48 [2001:470:1f13:299::]/64
inet_interfaces = [2001:470:c830::10]
inet_protocols = ipv4, ipv6

Ensuite, vous pourrez recevoir des mails de la part de [2001:41b8:202:deb:…] ;-)

CUPS

La configuration est identique à celle d’apache. Il suffit de modifier la directive Listen du fichier /etc/cups/cupsd.conf.

Samba

Je n’ai pas testé, mais visiblement depuis 2008, Samba dispose d’un support d’IPv6 qui est parfaitement inter-opérable avec les versions recentes de Microsoft Windows : Archive for the ‘Samba’ Category sur le blog de Erion Services.

Squid

Pour faire fonctionner le proxy mandataire Squid avec IPv6, il est nécessaire de mettre à jours la version disponible dans Debian “lenny”, vers la version 3.1.
La procédure de mise à jours est décrite dans ce billet : Squid 3.1 on Debian Lenny

Jabber

Pour mon serveur Jabber, j’utilise ejabberd. La migration consiste simplement à ajouter votre interface IPv6 dans le fichier /etc/ejabberd/ejabberd.cfg, comme cela :


{listen,
[
{5222, ejabberd_c2s, [
inet6,
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536},
starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
]},
...

Le plus dur est de trouver un serveur jabber compatible IPv6 poour faire du s2s.

Téléphonie

Il existe une version spécifique d’Asterisk pour IPv6.,mais elle n’a pas été intégrée dans la branche principale du projet et elle n’a pas l’air d’être maintenue activement.
Je vais donc me configurer OpenSER (alias Kamailio) pour faire office de proxy SIP IPv4/IPv6. (en cours ;-) )

Télévision

Je diffuse la télévision sur mon résau local avec MuMuDVB (j’ai décrit ma configuration dans ce billet : Diffuser des flux TV sur réseau local avec MuMuDVB). Celui-ci ne supporte pas IPv6.

Par contre VLC supporte très bien IPv6. Il est donc possible de transposer un flux IPv4 multicast vers un flux IPv6 multicast.

Les équipements

Le point noir dans cette migration vient des équipements embarqués qui disposent d’une connectivité IPv4 :

  • Switch manageable : aucun firmware disponible avec le support d’IPv6 ;
  • Télephones SIP : le SPA941 et le PAP2, ne disposent pas d’un firmware compatible IPv6 ;
  • Amplificateur Home-Cinema : idem ;
  • Imprimante : idem ;
  • RFXCOM : idem ;

Pas de surprises, l’ensemble des équipements IP ne disposent pas d’une connectivité IPv6, il faut chercher dans du matèriel très haut de gamme pour obtenir cette fonctionnalité.

Une solution possible est de rendre ses services accessibles en IPv6 à l’aide d’un reverse proxy 6to4 via Apache :

<VirtualHost [2042:42:42:22:42:42:42:42]:80>
   ServerName host.v6.domaine
   DocumentRoot /var/www
   ProxyPass / http://host.domaine/
   ProxyPassReverse / http://host.domaine/
</VirtualHost>

Mais cela ne fonctionne que pour les inferfaces HTTP de configuration et non pour tous les services fournir par ces équipements.

La seule bonne nouvelle pour les équipements et que la plupart disposent de la possiblité de mise à jours de leur firmware et donc ils seront un jour compatible ;-)

Sécurité

Kerberos Comme vos machines sont directement accessibles via Internet, il est nécessaire d’augmenter le niveau de sécurité du réseau. Pour ma part, j’ai déployé les éléments suivants :

  • Chiffrement TLS/SSL de TOUS les services, c’est le minimum syndical ;
  • Règles de Firewall strictes ;
  • Désactiver des services réseaux inutiles ;
  • Maintien à jours de l’ensemble des paquets ;

Et si vous êtes un peu paranoïaque, (comme moi ;-) ) vous pouvez encore ajouter quelques éléments de sécurité en plus :

  • Renforcer la sécurité du noyau et des services à l’aide de patches spécifiques ( grsecurity, Suhosin, etc…) ;
  • Mettre en place un NIDS comme Prelude ;
  • Mettre en place un HIDS comme SAMHAIN.

Bref, Comme les machines peuvent être directement accessibles et vous n’avez plus la “protection” du NAT. Il est nécessaire d’accorder plus d’importance à la sécurisation des vos serveurs.
Si non vous avez de fortes chances de vous retrouver dans ce cas : The brave new world of IPv6. (on me signale qu’il existe une très bonne protection ;-) )

Références

Conclusion

J’ai appris beaucoup de choses lors de cette migration.

Mon réseau dispose d’une connectivité IPv6 et je vais pouvoir m’amuser avec les nouvelles possiblités offertes ;-)

January 31, 2010

Gestion de la lumière d’ambiance avec le protocole DMX sous Debian GNU/Linux

La technologie des lumières à LEDs offre la possibilité de placer une source de lumière n’importe où (aquarium, meubles, faux plafonds, derrière un écran, etc…).

Par contre, les LEDs disposent de plus de fonctionnalités que les ampoules classiques.
En effet, en plus d’un bouton d’allumage, vous avez la possibilité de changer la couleur de la lumière, la faire varier dans le temps, modifier son intensité, jouer une séquence, etc…

Avec un nombre de possibilités plus grand, les interfaces de contrôle classique (X10, PLCBUS, etc…) ne suffisent pas.

Il est donc nécessaire de placer un peu plus d’intelligence dans le réseau d’illumination à l’aide du protocole DMX.

Ce protocole est utilisé dans le monde des concerts, des plateaux de télévision et des spectacles.
Néanmoins, il est tout à fait possible de le détourner pour un usage domotique.

Dans ce billet, je vais décrire l’utilisation d’un contrôleur LED RGB DMX et de l’interface OpenDMX de chez ENTTEC, à l’aide du projet OLA sous Debian GNU/Linux.

Principe de fonctionnement

Voici le schéma du montage:
dmx_led_overview

  • le PC communique à l’aide du port USB avec un contrôleur DMX ;
  • les contrôleurs LEDs mis en série convertissent les ordres en instructions RGB ;

Et voici ce que cela donne :

OpenDMX RGB LED

Matériel

Voici le matériel nécessaire pour un bandeau à LED, le tout fonctionne bien sûr sous Debian GNU/Linux est FOSS Friendly ;-)

Produit Prix
OPEN DMX USB Hardware Interface $52.00 – $60.00
RGB LED DMX Controller 2 $48.00 – $76.80
RJ45 Connetor to XLR Female Connector $11.20 – $14.25
RJ45 to XLR Male DMX Cable Adapter 3ft $10.99 – $14.00
DMX/XLR converter connector $10.50 – $12.00
LED Controller Power Supply, USA/EU $23.10 – $36.96
DMX 512 Terminator, 3 Pole Male Connector $7.94
Mini Bandeau Rigide RGB 12 Led 20cm 150° 12v DC 6 € – 12,95 €
Raccord intermédiaire pour Bandeau lumineux à Led Longueur 5cm 1.5 €

Pour le câblage, entre le bandeau lumineux et le contrôleur à LED, Il faut couper une extrémité du cable de raccord et la dénuder pour brancher sur le bornier à quatre vis de sortie RGB.

Installation du matériel

Une fois que vous avez branché l’OpenDMX au PC, vous devez voir un convertisseur USB-Serial (UART) à l’aide de lsusb :

$ lsusb
Bus 002 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Pour faire fonctionner l’OpenDMX, vous avez besoin du module noyau dmx-usb et d’un environnement de compilation pour les modules. (paquet linux-headers*, etc…).

# cd /usr/src
# git-clone http://www.erwinrol.com/git/dmx_usb_module/
# cd dmx_usb_module
# make
# cp ./dmx_usb.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial
# depmod -a

Comme, l’OpenDMX est un convertisseur USB-Serial, le noyau par défaut le présente comme une interface /dev/ttyUSB.
Il est donc nécessaire de blacklister les modules usbserial dans le fichier /etc/modprobe.d/blacklist, en ajoutant les lignes suivantes :

blacklist usbserial
blacklist usb-serial
blacklist ftdi_sio

Ensuite, ajouter le module dmx_usb dans le fichier /etc/modules et rebooter la machine.
Au reboot, vous devez avoir une interface /dev/dmx0, qu’il faut rendre accessible pour tous les utilisateurs :

# ls -l /dev/dmx0
crw-rw---- 1 root root 180, 192 2010-01-30 00:37 /dev/dmx0
# chmod a+rw /dev/dmx0

Installation du logiciel pour la gestion de la lumière : Open Lighting Architecture (OLA)

Comme, il n’y a pas de paquets Debian disponibles pour ce programme, je vais décrire une procédure d’installation à partir des sources. Ces instructions ont été valider à l’aide de la version 0.7.3 de OLA :

Dépendances

Vous allez avoir besoin des dépendances suivantes pour la compilation :

# apt-get install build-essential uuid-dev libcppunit-dev libgcrypt-dev uuid-dev

Compilation de Protocol Buffers de Google

Vous avez besoin de protobuf, pour la gestion de l’échange de données :

# cd /usr/src
# wget http://protobuf.googlecode.com/files/protobuf-2.3.0.tar.bz2
# tar xjf protobuf-2.3.0.tar.bz2
# cd protobuf-2.3.0
# ./configure ; make ; make install

Compilation de google-ctemplate

Vous avez besoin du système ctemplate :

# cd /usr/src
# wget http://google-ctemplate.googlecode.com/files/ctemplate-0.96.tar.gz
# tar xzf ctemplate-0.96.tar.gz
# cd ctemplate-0.96
# ./configure; make ; make install

Compilation de microhttpd (optionnel)

Vous avez besoin de la libmicrohttpd version > à 0.4 (non disponible dans Debian) pour l’interface web de gestion :

# cd /usr/src
# wget ftp://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.4.5.tar.gz
# tar xzf libmicrohttpd-0.4.5.tar.gz
# cd libmicrohttpd-0.4.5
# ./configure; make ; make install

Compilation de OLA

Le projet OLA se découpe en deux parties : un serveur et des clients, dont voici la procédure de compilation. Vous devez remplacer x.y.z, par la version stable la plus récente du programme. (0.7.3 dans mon cas)
Pour le serveur :

# cd /usr/src
# wget http://linux-lighting.googlecode.com/files/ola-x.y.z.tar.gz
# tar xzf ola-x.y.z.tar.gz
# cd ola-x.y.z
# ./configure; make ; make install

Pour le client en C++ :

# cd /usr/src
# wget http://linux-lighting.googlecode.com/files/ola-examples-x.y.x.tar.gz
# tar xzf ola-examples-x.y.z.tar.gz
# cd ola-examples-x.y.z
# ./configure; make ; make install

Lancement d’OLAd

Vous pouvez lancer olad, avec un utilisateur qui dispose des droits de lecture / écriture du /dev/dmx0 :

$ olad -l 3
...

Vous pouvez ensuite vérifier si l’OpenDMX a bien été détecté par le serveur à l’aide du client ola_dev_info :

$ ola_dev_info
...
Device 3: OpenDmx USB Device
port 0, OUT Open Dmx at /dev/dmx0
...

Et si vouz avez compilé libmicrohttpd, vous devez pouvoir accèder à l’interface web du daemon, sur le port 9090 :

DMX OLA web console

Test et validation du bon fonctionnement

Avant de pouvoir manipuler les LEDs, il est nécessaire d’attribuer ununivers au contrôleur OpenDMX à l’aide de la commande ola_patch :

$ ola_patch -d 3 -p 0 -u 0

Ensuite vous pouvez lancer dans deux terminaux les commandes ola_dmxmonitor et ola_dmxconsole.
La première permet de suivre le statut des diffèrents composants et la seconde permet de les controler à l’aide d’un interface graphique en curses.

L’identifiant du contrôleur LED RGB sur le réseau DMX, est fonction de la valeur prise par le petit switch qui se situe sur celui-ci.
Et se découpe de la manière suivante :

  • Rouge = valeur du switch ;
  • Vert = valeur du switch + 1 ;
  • Bleu = valeur du switch + 2.

Vous pouvez faire varier les trois valeurs pour obtenir les diffèrentes couleurs possibles.

Allez plus loin avec l’Open Lighting Architecture (OLA)

OLA supporte de nombreux contrôleurs USB et Ethernet.
Il dispose d’une API Client C++ et Python, ce qui rend son intégration possible et facile dans d’autres projets et offre de nombreuses possiblités.

La diffusion d’informations à l’aide de la lumière d’ambiance et ses possiblités

L’idée de pouvoir contrôler l’intensité et la couleur d’un bandeau à LED qui se situe dans n’importe quel endroit de la maison, offre des possiblités interessantes en matière de diffusion d’informations.

En effet, la lumière permet de diffuser l’information de manière non intrusive.
Voici quelques exemples des possibilités offertes :

  • comme la lampe DAL de Violet, se connecter à l’Internet pour exploiter des ressources ;
  • Pour ceux qui disposent de l’option Tempo d’EDF, il est possible de diffuser la couleur du jour ;
  • Modifier l’Intensité lumineuse en fonction de nombreux paramètres : tempèrature, l’ensoleillement, nombre de personnes présentes dans la pièces, activation d’une alarme, réveil du bébé, etc…

Ce sont quelques exemples des possiblités offertes. Pour le reste vous pouvez faire marcher votre imagination pour créer des nouvelles manières d’inter-agir avec les machines et cette Intelligence ambiante.

Réferences

Voici mes réferences :

Conclusion

Le protocole DMX est ancien et souffre de nombreux défaults, mais il présente encore de nombreux avantages tels que :

Il faut noter qu’il existe une alternative plus récente au protocole DMX : Digital Addressable Lighting Interface (DALI).

Il est aussi possible de remplacer le contôleur OpenDMX par une carte Arduino, comme décrit ici.

Filed under: Debian,Home automation — Tags:, , , , , — cscm @ 11:39

January 11, 2010

Faire son propre moteur de recherche avec Nutch

Allez aujourd’hui, je lâche mon troll, qui n’a pas manger depuis plusieurs semaines :

S’il y a quelque chose que vous faites et que personne ne doit savoir, peut-être qu’il faudrait commencer par ne pas le faire

Source : Google CEO Eric Schmidt Dismisses the Importance of Privacy

Il a raison le bon docteur Schmidt, il aurait du faire plus attention Liu Xiaobo avant de chercher droits de l’homme sur un moteur de recherche censuré

Bref vous m’avez compris ce genre de parole dans la bouche de l’homme le plus puissant de la plante ne m’inspire pas confiance et je continue à penser que le slogan de Google Don’t be evil est une véritable plaisanterie.

Alors au lieu de vous conseiller de passer à Bling, je vais vous expliquer comment faire votre propre moteur de recherche.

Ce billet décrit la mise en place d’un moteur de recherche sous Debian GNU/Linux basé sur Nutch.

Pré-requis

140px-Google’s_First_Production_Server

Pour faire votre propre moteur de recherche vous avez besoin de :

  • 450 000 serveurs répartis sur toute la planète ;
  • 80Go d’espace disque par machine ;
  • 4Go de mémoire par machine ;
  • Une connexion fibre optique entre vos “data centers” ;

Bref, si vous n’avez pas cette infrastructure à votre disposition ce n’est pas la peine d’aller plus loin ;-)
Bon d’accord, vous voulez simplement un moteur de recherche personnel?

Un seul serveur avec les caractéristiques suivantes :

  • Un bon processeur ;
  • Beaucoup de mémoire (4Go, ba oui, c’est du Java ma petite dame ;-) ) ;
  • Un gros disque dur très rapide de plus de 500Go (des Raptor par exemple ) ;
  • Une bonne bande passante, avec plus de 2Mb en download;
  • Une distribution Debian GNU/Linux ;
  • Des compétences en administration d’Apache, Tomcat et ligne de commande ;
  • Un peu de temps pour configurer le système et le paramétrer aux petits oignons.

C’est bien plus abordable ? ;-)

Fonctionnalités

En mettant en place mon propre moteur de recherche, je voulais obtenir les fonctionnalités suivantes :

  • Indexation des documents locaux (ex: un Intranet) ;
  • Indexation plus poussé de mes centres d’intérêts ;
  • Indépendance par rapport à un moteur de recherche ;

Néanmoins, je dois faire une croix sur :

  • la publicité ciblée ;
  • la recherche d’images, de vidéos et temps réel ;
  • la correction orthographique.

Les limitations

On pourrait dire que Nutch est un moteur de recherche de l’époque “web 1.0”. En effet, il ne contient pas d’algorithme d’Intelligence Bolchevique^Wcollective comme la plupart des moteurs de recherche. Cela signifie que seul le Page rank est utilisé et que les votes des utilisateurs ne sont pas pris en compte. Il est aussi plus sensible au Spamdexing.

Présentation des composants

L’architecture d’un moteur de recherche est assez simple, vous avez besoin :

  • d’un Web crawler, un logiciel qui explore automatiquement le Web à la recherche de ressources.
  • un système d’indexation, dans le cas de Nutch c’est Apache Lucene ;
  • des interfaces de recherche ;

Installation

Voici les étapes nécessaires pour faire fonctionner la version 1.0 Nuch sur une machine Debian GNU/Linux version “lenny”.

Dépendances

Vous avez besoin des composants suivants :
# apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps sun-java6-jre

Configurer le JRE par default :
# update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java

Nutch

C’est une application en Java, que je place dans le repertoire opt :

# cd /opt
# wget http://mirror.mkhelif.fr/apache/lucene/nutch/nutch-1.0.tar.gz
# tar xzf nutch-1.0.tar.gz
# ln -s nutch-1.0 nutch
# mkdir nutch/urls
# mkdir nutch/crawl
# chown tomcat55: nutch-1.0

Configuration

La configuration du moteur de recherche se trouve dans le fichier conf/nutch-default.xml, vous disposez de votre fichier conf/nutch-site.xml, spécifique à votre instance. Les variables intéressantes sont :

  • http.agent.* : la politesse, pour décrire votre robot ou bien prendre l’identité d’un autre ;
  • db.fetch.interval.(default|max) : ces variables définissent le nombre de jours entre chaque passage du robot, comme vous ne pourrez pas faire le tour du web en moins de 30 jours ;-), une bonne idée est d’augmenter ces valeurs ;
  • plugin.includes : la définition des plugins pris en charge, ici vous pouvez ajouter la gestion des documents pdf, microsoft word et du protocole https.

Bootstrapping du moteur de recherche

Votre moteur de recherche doit avaler une quantité de donnée importante avant de pouvoir faire une recherche pertinente.
Voici quelques sources pour l’initialiser.

A l’aide d’un annuaire

Il existe de très bons annuaires complets comme le projet Open Directory Project.
Dont l’ensemble des données sont disponibles au format RDF et téléchargeables librement : http://rdf.dmoz.org/rdf/.
Par contre, attention ce fichier référence 4 446 480 sites web et vous allez avoir besoin de beaucoup de place pour les référencer tout ce contenu.

Voici la procédure pour utiliser l’annuaire DMOZ avec Nutch :

$ cd /opt/nutch
$ mkdir urls
$ wget http://rdf.dmoz.org/rdf/content.rdf.u8.gz -O urls/content.rdf.u8.gz
$ gunzip urls/content.rdf.u8.gz
$ bin/nutch org.apache.nutch.tools.DmozParser urls/content.rdf.u8 > urls/dmoz
$ bin/nutch inject crawl/crawldb urls/dmoz
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/dmoz
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done

A l’aide d’un Marque-page

Une autre source pour initialiser le moteur de recherche est d’utiliser les adresses contenues dans votre marque-page. Le principal avantage de cette technique est la faible quantité de données à analyser et une pertinence de recherche accrue.
Pour ce faire, vous devez exporter votre marque-page au format HTML (pour Mozilla Firefox) et en extraire les adresses de la manière suivante :


$ cd /opt/nutch
$ grep "A HREF=\"http" bookmarks.html | cut -d '"' -f 2 > urls/bookmarks
$ bin/nutch inject crawl/crawldb urls/bookmarks
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/bookmarks
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done

A l’aide de Wikipedia

Wikipedia fourni des dumps de sa base de données au format XML. Il est donc possible d’utiliser les URLs des articles de wikipedia comme source.
Voici la procédure pour la version française de Wikipedia, celle-ci contient 897 974 urls.

$ cd /opt/nutch/
$ mkdir urls
$ wget http://download.wikimedia.org/frwiki/latest/frwiki-latest-abstract.xml -O urls/frwiki-latest-abstract.xml
$ grep "<url>" urls/frwiki-latest-abstract.xml | cut -d '>' -f 2 | cut -d '< ' -f 1 > urls/wikipedia-fr
$ bin/nutch inject crawl/crawldb urls/wikipedia-fr
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/wikipedia-fr
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done

What you’re waitin’ for ? Christmas ?

Come get some!

Une fois que vous avez chargé la base de données avec vos urls, il faut les parcourir afin de les indexer. Cela se fait à l’aide de plusieurs commandes :

  • generate : sélections des adresses à parcourir ;
  • fetch : parcourt des urls ;
  • updatedb : mise à jours de la base des adresses ;
  • invertlinks : mise à jours de l’index des adresses inversées ;
  • index : indexation des données ;

Une séquence classique ressemble donc à cela :

bin/nutch generate crawl/crawldb crawl/segments -topN 1000
s1=`ls -d crawl/segments/2* | tail -1`
bin/nutch fetch $s1
bin/nutch updatedb crawl/crawldb $s1
bin/nutch invertlinks crawl/linkdb $s1
bin/nutch index crawl/indexes crawl/crawldb crawl/linkdb $s1

Cette suite de commandes vous permet de parcourir et d´indexer 1000 adresses issues de votre base.
C’est un très bon 1er test pour voir si cela fonctionne.

Shake it, baby!

Une autre commande intéressante est readdb avec l’option stats, qui permet d’obtenir des informations sur le contenu de votre base :

$ bin/nutch readdb crawl/crawldb/ -stats
CrawlDb statistics start: crawl/crawldb/
Statistics for CrawlDb: crawl/crawldb/
TOTAL urls: 3377315
...
min score: 0.0
avg score: 0.13178158
max score: 401.402
status 1 (db_unfetched): 2966337
status 2 (db_fetched): 300008
status 3 (db_gone): 46659
status 4 (db_redir_temp): 27857
status 5 (db_redir_perm): 36454

Une bonne idées serait de mettre en place un système de monitoring sur ces informations pour suivre le déroulement. Par contre, il faut faire attention car la commande prend plusieurs minutes à s’exécuter. (donc hors de question de la placer dans un plugin munin, un mail tous les soirs serait une meilleur méthode).

Damn… I’m looking good!

Vous pouvez tester en ligne de commande le fonctionnement du moteur de recherche :
$ bin/nutch org.apache.nutch.searcher.NutchBean apache
Total hits: 6413
0 20100104001440/http://xmlgraphics.apache.org/fop/
... be part of Apache's XML Graphics project . Demonstration ... goals of the Apache FOP project are to ...
1 20100103201220/http://velocity.apache.org/
... Library Site building Site tools Apache Reference Apache Website How the ASF ... way in its field. Apache
...

Voilà cela fonctionne en ligne de commande, nous pouvons passer à l’interface end user (enfin un moteur de recherche en ligne de commande c’est très pratique aussi ;-) )

Configuration de l’interface web

Nutch fournir un application pour Tomcat / Jboss. Il suffit de la déployer et de lui indiquer l’emplacement de votre index de la manière suivante :

# cd /opt/nutch
# cp nutch-1.0.war /var/lib/tomcat5.5/webapps
... attendre
# vim /var/lib/tomcat5.5/webapps/nutch-1.0/WEB-INF/classes/nutch-default.xml
... remplacer la value de searcher.dir par /opt/nutch/crawl

Mais aussi modifier la sécurité de tomcat, via le fichier /etc/default/tomcat5.5 en mettant la variable TOMCAT5_SECURITY à no.
Ou bien en créant un fichier policy donnant l’accès au répertoire /opt/nutch/crawl. (c’est plus propre ;-) )

Vous pouvez ensuite redémarrer tomcat et accèder au moteur de recherche via votre navigateur sur le port 8180.

Problèmes rencontrés

Voici quelques problèmes que j’ai rencontré lors de mes tests de la version 1.0 de Nutch :

La directive merge ne fonctionne pas

Impossible de fusionner deux index, il est nécessaire de re-creer l’ensemble de l’index à chaque fois.

La directive fetch flanche

Lorsque trop nombreux sites sont choisis dans la liste des sites à parcourir par le robot d’indexation à l’aide de l’option topN, le programme produit une erreur et le segement produit est corrompu. (c’est pour cette raison que je limite le nombre de site dans un segment à 5000)

Maintenance de l’index

Une fois le moteur de recherche mise en place, il faut maintenir l’index à jours. Pour cela, j’ai mis en place un simple script de crawl avec cron qui se lance tous les soirs :

#!/bin/sh
bin/nutch generate crawl/crawldb crawl/segments -topN 5000
s1=`ls -d crawl/segments/2* | tail -1`
bin/nutch fetch $s1
bin/nutch updatedb crawl/crawldb $s1
bin/nutch invertlinks crawl/linkdb $s1

et un autre qui re-créer l’index :

#!/bin/sh
rm -rf crawl/indexes/
bin/nutch index crawl/indexes/ crawl/crawldb/ crawl/linkdb/ crawl/segments/*

Optimisation du robot d’indexation

La principale difficulté de ce projet est l’indexation d’une énorme quantité de données avec des moyens techniques très limité.
Voici donc quelques idées pour optimiser l’indexation de votre moteur de recherche.

Utiliser le serveur mandataire de votre fournisseur d’accès à Internet

Vous pouvez ajouter l’adresse du serveur mandataire de votre FAI dans le fichier conf/nutch-site.xml :

<property>
<name>http.proxy.host</name>
<value>proxy.free.fr</value>
</property>
<property>
<name>http.proxy.port</name>
<value>3128</value>
</property>

Note : On me signale dans l’oreillette, que mon FAI à fermer son proxy à cause d’une sombre histoire de Haute Autorité De l’Ouverture Postale Inopinée.

Mise en place d’un serveur DNS locale

Vous avez besoin de mettre en place un serveur cache DNS locale qui prend en charge les requêtes du robot. Vous pouvez faire cela avec ISC BIND ou bien pdnsd.

Augmentation du nombre de Threads

Vous pouvez aussi augmenter le nombre de processus utiliser par le robot d’indexation en modifiant les variables du fichier de configuration :

  • fetcher.threads.fetch : nombre de threads au total (42) ;

Pour plus d’informations, vous pouvez voir sur le wiki du projet : OptimizingCrawls.

Imposer^WIntégrer Nutch

Voici quelques astuces pour intégrer Nutch à votre architecture.

Mozilla Firefox

Pour Mozilla Firefox, le système de plugin permet d’inclure votre propre moteur de recherche.
Pour faire cela, il faut placer le fichier nutch.xml dans votre profile Firefox : ~/.mozilla/firefox/*.default/searchplugins (en remplacant par l’addresse de votre instance ) .

DNS Menteur

Vous pouvez modifier la configuration de votre DNS pour résoudre le domaine google avec l’adresse de votre moteur de recherche. (Ouais, je sais Net Neutrality, toussa ;-) ). En modifiant la feuille de style de l’interface web certains utilisateurs ne verront surement pas la diffèrence.

Est-ce bien raisonnable ?

Vous allez me dire. Héberger son propre moteur de recherche chez soit, quelle drôle d’idée ;-)
Je pousse, le concept d’Auto-hébergement au maximum, mais il est clair que j’ai fait cette article “Just for fun”, car même si je ne peut indexer que 5000 sites par jours (le script fonctionne durant les heures creuses) , soit 1 825 000 en un an, je vais avoir beaucoup de mal à indexer les 4 446 480 urls de DMOZ.

Références

Voici quelques références intéressantes sur le sujet :

Conclusion

Vous avez maintenant à votre disposition un moteur de recherche personnel.
Et vous êtes libre de rechercher des choses sans que personne ne puisse le savoir ;-)
L’étape la plus dure est de se passer de l’utilisation google ;-)
Si vous voulez aller plus loin dans le monde des moteurs de recherche libre vous pouvez intégrer Nutch avec Solr, comme décrit dans cette article : Using Nutch with Solr.
Afin d’obtenir un moteur de recherche professionnel pour une entreprise. (principalement pour éviter la fuite d’information).
Ou bien si vous si êtes intéressé par un produit similaire aux Solutions d’entreprise de Google.

Pour finir, la petite cerise sur la gâteau, comme Nutch utilise Hadoop, il scale comme un troupeau éléphants ;-)

Filed under: Debian,Network — Tags:, , , , — cscm @ 23:22

December 19, 2009

Présentation du standard Zigbee

ZigBee_Network_Design

Je reviens des mercredis de la RFID organisé par filrfid, le sujet de la présentation était le protocole ZigBee.

Lors de la présentation faite par Véranith Ly de la société oRFIDée, j’ai appris beaucoup de choses sur ce protocole.

J’aimerai donc vous en faire profiter et parler des domaines qui m’intéressent à savoir la domotique, la robotique et la topologie des réseaux maillés.

Description rapide du standard

ZigBee, est un standard de communication sans-fils comme le Wifi ou le Bluetooth.
Les principaux avantages du standard sont :

  • Autonomie de l’émetteur, il est possible de le faire fonctionner durant plusieurs années à l’aide d’une batterie ;
  • La possibilité de mettre en place une topologie de réseaux maillés ;
  • 65535 nœuds sont addressable sur le réseau ;
  • le standard définie : les méthodes de communication sur le réseau, mais aussi les fonctionnement des applications ;
  • l’ensemble des produits sont certifiés par l’Alliance ZigBee et soutenus par de nombreuses entreprises industriels ;

Ce qui est intéressant, c’est que le standard définit un ensemble de caractéristiques pour un équipement.
Regroupé sous forme de famille :

Domaines d’application du protocole

Les domaines d’applications du protocole sont les suivants :

La promesse du standard

Les équipements qui respectent le standard et sont certifiés par l’Alliance ZigBee sont théoriquement interchangeable et peuvent communiquer ensemble.

Cela signifie, qu’il est possible d’allumer à l’aide d’une télécommande de marque A, une douille d’ampoule de marque B et un lecteur de DVD de marque C.

Cela parait trivial dit comme cela, mais dans l’état actuel de développement de la domotique, cela releve du miracle

Même, s’il existe des protocoles propriétaires pour faire cela, il est nécessaire de vendre son âme à un constructeur (Vendor lock-in garantie sur facture ;-) ) ou bien mettre en place des protocoles de Middleware comme xPL et une belle galaxie de protocoles hétérogènes. (cf. le schéma de ma petite installation perso ;-) ).

La gestion des binding

La couche applicatif du standard ZigBee, inclut une possibilité très intéressante pour la domotique : le binding.

L’idée est de relier deux équipements du réseau de manière automatique et transparente pour l’utilisateur.

L’un des meilleur exemple pour comprendre est celui d’une ampoule et un d’un interrupteur.

Lorsque l’utilisateur active physiquement le binding, à l’aide d’un bouton par exemple.

Les deux devices se mettent en relation avec le coordinateur du réseau, qui détermine si oui ou non les profils applicatifs sont compatibles et de les lier.

Ce qui permet aux équipements d’être liés automatiquement et il n’est pas nécessaire de configurer les adresses des équipements, etc…

L’état actuel de la certification

Pour l’instant, il y a peu d’équipements qui sont certifiés par l’Alliance :

Mais on trouve pas mal de vendeurs d’autres produits que ne sont pas forcement entièrement certifiés mais qui respectent la partie communication du standard.

Problématique du sans-fils

Comme toutes technologies sans-fils, elle présente quelques problématiques particulières :

La source d’énergie

Bien que le module ZigBee nécessite très peu d’énergie pour fonctionner (20mA pour émettre une trame sur le réseau), se pose la question de la source d’énergie.

Lorsque celle-ci est fournie par une pile cela pose de problématique de :

  • fiabilité / qualité de la source d’énergie ;
  • la nécessité de remplacer régulièrement la source d’énergie ;
  • la nécessité de mettre en place un dispositif pour notifier l’utilisateur du statut de la pile.

La sécurité

La sécurité du standard ZigBee repose tout d’abord, sur la sécurité du protocole de communication IEEE 802.15.4. Pour mieux comprendre les méthodes de sécurisation mises en place par le protocole, vous pouvez lire cet article de vulgarisation : Security in 802.15.4 and ZigBee networks ; ou bien cet excellent papier Security Considerations for IEEE 802.15.4 Networks. Mais dans ce domaine, rien de nouveau, ce sont toujours les mêmes principes qui s’appliquent, à savoir :

  • Plus la puce dispose de puissance et plus le niveau de chiffrement est fort (au maximum AES128 pour ZigBee) ;
  • La qualité des composants et du générateur de nombre aléatoire ( merci de ne pas utiliser le PID du programme ;-) ) ;
  • La qualité de l’implémentation du code de chiffrement.

Bref, vous vous doutez bien que les modules ZigBee qui seront vendus au grand publique ne seront pas d’un niveau de sécurité militaire et n’embarqueront sûrement pas pas un compteur Geiger comme source d’entropie ;-)

D’autant plus que le standard n’impose pas forcement un niveau de chiffrement fort à tous les profils applicatifs.

Robotique

Pour la robotique, il n’existe pas de profil dans le standard, mais la plupart des amateurs dans le domaine ont déjà compris les nombreux intérêts de ZigBee et on voit de plus en plus d’interfaces apparaître (Bioloid, WowWee, etc… )

Logiciels libres

Du coté des logiciels libres, nous avons :

  • Un projet mort : ZigBuzz ;
  • Le projet IEEE802.15.4/ZigBee Stack for Linux, dont l’objectif est l’intégration de la pile ZigBee dans le noyau Linux, commiter dans la version 2.6.30-rc7 ;
  • Le projet FreakZ, dont l’objectif est l’implémentation du pile ZigBee libre pour l’embarque ;

Malheureusement, il y a une incompatibilité entre la licence des spécifications du standard ZigBee et la licence GPL. en effet celle-ci ne prend pas en compte un usage non commercial.

Pour plus de détails sur ce point : Zigbee, Linux, and the GPL.

Néanmoins, le code du protocole IEEE 802.15.4 est déjà le noyau et bénéficie d’un niveau de protection ;-)

Matériel

Le matériel ZigBee disponible se découpe en plusieurs familles de la plus simple à la plus complexe :

Émetteur-récepteur

Les principaux constructeurs d’émetteur-récepteur sont Texas instruments et Freescale.

Puce

Les puces prennent en charge la norme IEEE 802.15.4, elles sont produites par : Ember, Jennic, Texas instruments et Freescale.

Modules

Les modules prennent en charge le standard ZigBee et sont produites par : Digi, One-RF, Telegesis, Meshnetrics, Radiocrafts

Produit fini

  • Tritech : dongles USB et routeurs Ethernet/Zigbee ;
  • Digi : passerelles RS232/485, USB, Ethernet, GPIO, routeurs autonomes
  • Telegesis : dongles USB et CF, routeurs autonomes et Ethernet
  • Alektrona : gateway ethernet / zigbee;
  • Libelium : capteurs et routeurs multi-protocoles Wifi, Bluetooth, GPRS et GPS ;
  • Des shields pour la carte Arduino et ses dérivées.

Offre packagée

Pour les produits packagés, il existe les solutions suivantes :

  • Control4 : gamme de produits domotiques ;
  • AlerteMe : système de suivi de la consommation électrique et alarme.

Déploiements importants de ces technologies

Il y a pas mal de déploiements de ces technologies aux USA dans le cadre des réseau de distribution d’électricité « intelligent » en Californie et au Texas principalement.

En Europe, le ville de Gothenburg en Suède a déployé un réseau de 90 000 compteurs intelligents.

En France, le déploiement est encore à l’état de recherche avec le projet SensLab, le projet de localisation fait par Orfidée pour la Marine Nationale.

Et d’autres projets couverts par des accords de non divulgation ;-)

Références

Voici quelques références pour approfondir le sujet :

Conclusion

Voilà, ceci est une petite présentation standard ZigBee, que j’ai voulu la plus succincte possible. Le sujet étant très vaste et passionnant. J’ai forcement fait des erreurs et oublié des références. Merci de m’en faire part par mail ou via les commentaires.

Filed under: Home automation,Network,Robotics,Work — Tags: — cscm @ 14:00

December 9, 2009

Notifications Nagios par Téléphone

J’ai configuré mon instance de Nagios pour recevoir une notification par téléphone en cas d’incident. (déclenchement d’une alarme ou d’un détecteur d’eau / fumée dans mon installation domotique).

Ce billet décrit comment mettre en place un système de la notification par téléphone avec Nagios.

Pré-requis

Vous avez besoin des composants suivants :

  • Une distribution Debian GNU/Linux ;
  • Une installation fonctionnelle de Nagios ;
  • Une PABX IP avec le support du protocole SIP, comme Asterisk ;
  • Un système de Synthèse vocale fonctionnelle, comme eSpeak + MBROLA ;
  • Un client SIP en ligne de commande comme PJSUA.

Installation

Le client SIP en ligne de commande PJSUA n’est pas disponible dans les paquets du projet Debian.
Il est donc nécessaire de l’installer manuellement à l’aide du classique : configure, make, make install.
La procédure est décrite dans ce billet : Un client SIP en ligne de commande.

Pour l’installation du système de synthèse vocale, vous pouvez vous référer à mon précèdent billet sur le sujet : Text-to-Speech avec eSpeak, MBROLA et Speech Dispatcher.

Configuration

Vous devez créer un compte SIP pour Nagios sur votre PABX et tester que l’enregistrement est fonctionnel.

Pour cela vous avez besoin d’un fichier de configuration spécifique à Nagios pour PJSUA, dans /etc/nagios/sip.cfg par exemple :

--id sip:nagios@pabx.csquad.lan
--registrar sip:pabx.csquad.lan
--realm *
--username nagios
--password secret

Vous pouvez ensuite tester l’enregistrement en ligne de commande :
$ pjsua --config-file /etc/nagios/sip.cfg
...
11:17:05.376 pjsua_acc.c sip:nagios@pabx.csquad.lan: registration success, status=200 (OK), will re-register in 300 seconds

Un appel de test :
$ pjsua --config-file /etc/nagios/sip.cfg --null-audio sip:secretariat@pabx.csquad.lan

Ensuite un appel de test audio avec un message :
$ espeak -v mb/mb-fr1 "E.T. téléphone maison" | /usr/local/bin/mbrola /usr/share/mbrola/fr1/fr1 - test.wav
$ pjsua --config-file /etc/nagios/sip.cfg --play-file=test.wav --auto-play --null-audio sip:secretariat@pabx.csquad.lan
$ rm -f test.wav

On met le tout dans un petit script expect pour prendre en charge la déconnections de manière polie :

#!/usr/bin/expect --
set timeout 45
set addr [lindex $argv 0]
set text [lindex $argv 1]
exec /usr/bin/espeak -v mb/mb-fr1 $text | /usr/local/bin/mbrola /usr/share/mbrola/fr1/fr1 - /tmp/phone-call.wav;
spawn /usr/local/bin/pjsua --app-log-level=3 --config-file /etc/nagios/sip.cfg --play-file /tmp/phone-call.wav --auto-play --null-audio --max-calls 1 sip:$addr
expect {
"DISCONNCTD" {
exit
}
timeout {
send "h\n"
exit
}
eof {
exit
}
}

Et voilà ;-)

Il ne nous reste plus qu’à configurer ce type de notification dans Nagios.
Pour cela, il faut modifier le fichier contacts.cfg :
# 'nagios-phone' contact definition
define contact{
contact_name nagios-phone
alias Nagios Admin via Phone
service_notification_period 24x7 ; mouahahahahahaha
host_notification_period 24x7 ; moiahahahahahahah
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-phone
host_notification_commands host-notify-by-phone
email sip:secretariat@pabx.csquad.lan
}

Puis le fichier misccommands.cfg :
# 'notify-by-phone' personnal command definition
define command{
command_name notify-by-phone
command_line /usr/local/bin/phone-call.sh $CONTACTEMAIL$ "$NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$"
}
# 'host-notify-by-phone' personnal command definition
define command{
command_name host-notify-by-phone
command_line /usr/local/bin/phone-call.sh $CONTACTEMAIL$ "Host $HOSTSTATE$ alert for $HOSTNAME$!"
}

Ensuite, vous pouvez définir nagios-phone comme un contact pour des services ou hosts.

Il faut aussi modifier la valeur de la variable notification_timeout dans le fichier de configuration nagios.cfg, pour avoir le temps de décrocher le téléphone et d’en tendre le message.

Conclusion

Vous n’avez plus aucune excuse pour ne pas brancher vos esclaves^Wéquipe d’administrateurs systèmes directement sur le système de surveillance de vos serveurs ;-)

Plus sérieusement, la notification par téléphone est une méthode très intrusive. Il est nécessaire de décrocher le téléphone. Il faut donc l’utiliser avec parcimonie.

Filed under: Debian,Network — Tags:, , , — cscm @ 20:39

December 8, 2009

Capteur de dioxyde de carbone pour réseau 1-wire

Après la lecture de plusieurs livres de Jean-Marc Jancovici (merci Nicolas ;-) ),
je me suis intéressé à la concentration de dioxyde de carbone dans l’air.
En effet, cette concentration afflue directement sur le climat de la planète.
Je me suis donc mis à la recherche d’un capteur de CO2 abordable pour ma station météo.

La recherche du capteur

co2 sensor Mes critères pour le capteur de dioxyde de carbone de ma station météo étaient les suivants :

  • communicant avec le pc à l’aide d’un protocole standard ;
  • fonctionnant sous Debian GNU/Linux ;
  • petit budget, moins de 150 euros.

Après plusieurs jours recherche, je me suis retrouvé le bec dans l’eau.

En effet, ce genre de capteur est visiblement réservé aux équipements scientifiques et la plupart des devis que j’ai réussi à obtenir sont bien au dessus de mon budget.
Mais dernièrement, j’ai trouvé un revendeur de matériel 1-wire en Suède : m.nu.
Celui-ci propose un capteur de CO2 abordable : CO2-meter.
Ce capteur est basé sur le capteur K30 de chez SenseAir et un DS2450.
Ce capteur peut être utilisé en intérieur ou bien à l’extérieur.
Par contre dans le cas d’une utilisation extérieur, il faut le protéger des précipitations.

Matériel

Pour faire fonctionner le capteur vous avez besoin des composants suivants :

Produit Prix
CO2-meter 139,93€
5V Power injectors 19,96€
Alimentation 5V 14,95€

Exploitation du capteur

Avec OWFS

Une fois le capteur branché sur le réseau 1-wire, il est vu par owfs :

$ tree /mnt/owfs/20.C17E0D000000
/mnt/owfs/20.C17E0D000000
|-- PIO.A
|-- PIO.ALL
|-- PIO.B
|-- PIO.C
|-- PIO.D
|-- address
...
|-- type
|-- volt.A
|-- volt.ALL
|-- volt.B
|-- volt.C
|-- volt.D
|-- volt2.A
|-- volt2.ALL
|-- volt2.B
|-- volt2.C
`-- volt2.D
3 directories, 74 files
$ cat /mnt/owfs/20.C17E0D000000/type
DS2450%

Les informations intéressantes se trouvent dans les fichiers :

  • volt.A : sortie du capteur de CO^2, donne la concentration de CO2 en ppm. Il faut multiplier la valeur par 1000. Ex: 0.772277 * 1000 = 772 ppm ;
  • volt.B : statut du capteur de CO^2, le voltage doit être au alentour de 3.2V ;
  • volt.D : voltage du DS2450S, doit être aux alentours de 5V ;

Avec Munin

Pour faire un graphique de la concentration de dioxyde de carbone, j’utilise munin et un petit plugin fait maison :

$ svn co http://svn.csquad.org/owcarbondioxide
A owcarbondioxide/owcarbondioxide
...
$ chmod a+x owcarbondioxide/owcarbondioxide
# mv owcarbondioxide/owcarbondioxide /usr/share/munin/plugins/
# ln -s /usr/share/munin/plugins/owcarbondioxide /etc/munin/plugins/owcarbondioxide
$ /etc/munin/plugins/owcarbondioxide config
graph_title Carbon dioxide 1-wire sensor
graph_args --base 1000 --lower-limit 0 --upper-limit 5000
graph_vlabel Carbon dioxide in ppm
graph_category sensors
graph_info This graph shows the Carbon dioxide on the one-wire network.
Chambre.label Chambre
$ /etc/munin/plugins/owcarbondioxide get
Chambre.value 786.184

Vous devriez obtenir ce type de graphique :
meuh.csquad.lan-owcarbondioxide-day

Références

Voici quelques références intéressantes sur le sujet :

Filed under: Home automation — Tags:, , , — cscm @ 20:09
Next Page »

Powered by WordPress