La Lanterne Rouge

La Lanterne Rouge

Warning: Geek Inside

Publié le par Nanawel
Publié dans : #réseau | #linux | #dns | #serveur | #usul

Sous-titre : "Mais continuez à gérer les DNS locaux via votre box".

 

Si vous avez suivi l'actualité ces derniers mois, vous savez certainement que l'accès Internet par les principaux FAI en France (Orange, Bouygues, Free, SFR) vient d'en prendre un (premier ?) coup au niveau de sa neutralité.

La cause ? Un ordre du TGI de Paris qui leur a demandé d'interdire les accès à plusieurs sites web dont - évidemment - ThePirateBay et ses nombreux miroirs.

En termes techniques, l'application de ces restrictions par les opérateurs a consisté à modifier leurs DNS afin qu'il ne résolvent plus les adresses des domaines concernés. C'est évidemment très idiot - autant sur le plan technique que politique - donc je ne m'attarderai pas sur cet aspect, d'autres le font mieux que moi.

RÉ-PON-SE--IN-VA-LI-DE. DOIT-DÉ-TRUIRE-LE-PI-RA-TA-GE. BIP.

RÉ-PON-SE--IN-VA-LI-DE. DOIT-DÉ-TRUIRE-LE-PI-RA-TA-GE. BIP.

Étant client chez le FAI au carré rouge®™, je subis donc ces restrictions depuis mon accès ADSL. Ce n'est pas que je télécharge des tera-octets de données quotidiennement sur TPB, mais plutôt le principe qui me dérange. Comme je ne suis pas encore prêt à passer par un FAI associatif type FdN, il me reste soit à faire avec, soit à trouver une solution de contournement.

Alors oui, il y a la réponse classique copyright jeuxvideo.com : b1 c simpl, change le DNS 2 ton PC é utiliz cui de Google a la place lol xpdr.

Oui, mais non, pour les raisons suivantes.

  • Tout d'abord, ce n'est pas un problème de "mon PC", mais de "mon cheptel". Car oui, derrière ma box se cachent une dizaine de machines, plus ou moins actives à un moment donné. Si je pouvais centraliser la gestion du DNS comme le fait ma box actuellement, ça serait quand même mieux (cache DNS, etc.).
  • Ensuite, si contourner une restriction de son opérateur qui se torche allègrement avec la neutralité du Net signifie se jeter dans les bras de Google (si chauds et confortables qu'ils soient), alors la morale de l'histoire a des relents de poisson pourri. Donc non, si je dois utiliser un autre serveur DNS, ça sera en priorité celui d'une organisation un peu plus regardante niveau respect de la vie privée (tiens, celui de FdN par exemple).
  • Pour finir, et c'est la raison principale de cet article, je dépends étroitement des "DNS personnalisables" de ma box pour y inscrire les noms des machines de mon cheptel, afin que ceux-ci soient connus de toutes sur mon LAN. Ces noms sont évidemment privés, et peuvent être qualifiés de domain-less (car ce sont de simples noms de machines, sans domaine associé). Cette situation a des raisons historiques, et en tant que telle, tout changement pourrait faire sortir la Terre de son axe (voire pire). Or, utiliser un DNS public à la place de la box me fera perdre ces correspondances et m'obligera à les ajouter dans les fichier /etc/hosts de chacune des machines. Galère !

Une petite liste de DNS internes sur ma box...

Une petite liste de DNS internes sur ma box...

Je me suis donc dit qu'il serait plus pratique de confier la gestion des DNS à une autre machine centrale de mon réseau, toujours disponible, et qui utiliserait comme résolveur final un serveur DNS public qui ne serait pas celui de mon FAI.

Mais !

Uniquement pour les noms avec domaines évidemment ! Car je souhaite continuer à utiliser ma box pour gérer les (nombreux) noms de machines depuis cet endroit. Elle doit également continuer à gérer le DHCP - ce qui impliquera de devoir préciser le serveur DNS manuellement sur les machines, mais uniquement lui. Ces contraintes sont liées à différents facteurs, dont une factrice (j'me comprends ^^).

Le principe étant d'altérer le moins possible l'infrastructure du réseau, et de ne surtout pas toucher à ce qui marche.

 

La machine centrale qui gèrera ce relai DNS est toute trouvée : Usul,  mon serveur sous Debian dispo 24/7/365 et qui ne craint pas d'héberger un petit serveur DNS ou tout autre logiciel nécessaire.

En résumé, mon plan est donc celui-ci (en vue logique "trafic DNS") :

Le but ici sera simplement de ne plus avoir ces requêtes qui partent vers le DNS du FAI

Le but ici sera simplement de ne plus avoir ces requêtes qui partent vers le DNS du FAI

Installation du serveur

Quid à présent de la mise en place de ce relai DNS ?

Vu que je ne connais pas grand chose dans le domaine, j'ai fait quelques recherches et je suis initialement parti avec BIND9, référence dans le domaine et présent sur toutes les distros GNU/Linux...

Ô l'erreur. Totalement hors de portée pour moi, surtout vu l'usage que je comptais en faire, d'autant que je me suis rendu compte après-coup que ce n'était d'ailleurs même pas possible ! (faire du relai DNS si, bien sûr, mais pas de manière sélective avec mes noms domain-less)

J'ai galéré un moment avant de me tourner vers... dnsmasq. Un serveur DNS justement spécialisé dans le relai, et beaucoup plus simple à mettre en place.

Avec celui-ci, il est possible de définir des serveurs DNS finaux par domaine, et également de définir un serveur DNS pour les noms simples, donc domain-less. Dans mon cas, les requêtes concernant des FQDN seraient donc routées vers le serveur DNS public neutre, et les requêtes vers des noms de machines seraient résolues - comme c'est le cas actuellement - par la box.

Pour l'installation sur une Debian (ou Ubuntu, ne soyons pas raciste), c'est très simple :

# apt-get install dnsmasq

Le daemon devrait être lancé à la fin de l'installation. Personnellement ce package était déjà présent sur mon installation, même si je n'avais pas le souvenir de l'avoir installé manuellement.

Il faut ensuite s'assurer que le daemon est bien configuré pour être lancé au boot. Pour cela, éditez le fichier /etc/default/dnsmasq et passez la variable ENABLE à 1.

On passe ensuite à la configuration du serveur proprement dite. Par conventionn, on ne touchera pas au fichier /etc/dnsmasq.conf. On créera à la place un fichier /etc/dnsmasq.d/custom-lan.conf (le nom importe peu) qui viendra surcharger proprement les directives du premier fichier.

 

Je me suis basé sur les la présentation disponible ici et évidemment sur le manuel .

Quelques explications sur chacune des directives :

bogus-priv

Empêche les requêtes inversées (IP vers nom) d'être retransmises vers le serveur DNS distant pour tous les réseaux privés (ex : 192.168.x.x) si aucune correspondance n'est trouvée dans /etc/hosts.

cache-size=512

Je précise une taille de cache de 512 entrées pour les résolutions DNS effectuées. Toute entrée présente dans le cache et encore valide (TTL) sera renvoyée directement au lieu d'interroger le serveur DNS distant. C'est donc un point important pour mutualiser les résolutions, comme le faisait la box jusque-là.

no-resolv
no-hosts

Ici c'est particulier, car on va rendre dnsmasq autonome, "coupé" du système qui l'héberge : mon serveur Usul.

La première ligne lui interdit de se servir du fichier /etc/resolv.conf pour connaître les serveurs DNS à interroger, ceci car les serveurs en questions seront définis plus loin.

La seconde lui interdit également de se servir du fichier /etc/hosts. En effet, ce fichier est réservé aux surcharges (ou aux définitions plus généralement) des DNS pour la machine elle-même. Je ne souhaite pas que ces définitions soient renvoyées aux requêtes envoyées par les autres machines de mon LAN. C'est un choix personnel, à adapter au besoin.

log-queries
log-dhcp
log-facility=/var/log/dnsmasq.log

Ces lignes-ci sont plus optionnelles : elles activent simplement le log des requêtes traitées dans le fichier spécifié (et aussi des demandes DHCP, mais ici je ne l'utilise pas - encore). C'est en consultant ce fichier que j'ai découvert la technique spéciale mais un peu étrange de Chrome/Chromium pour détecter les DNS menteurs.

#Neufbox
server=//192.168.1.1
#FDN
server=80.67.169.12
# Google
#server=8.8.8.8

C'est (enfin) la partie importante. Ici sont définis les serveurs DNS à utiliser pour résoudre les deux types de noms que nous aurons à gérer : les domain-less, et les autres.

La syntaxe complète de la directive server est la suivante :

[/[<domain>]/[domain/]][<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]

Elle permet de définir pour un ou plusieurs domaines (précisés entre les slashes), un serveur à interroger.

On pourrait donc avoir :

server=/gouv.fr/8.8.8.8

pour interroger le serveur DNS 8.8.8.8 pour tout domaine situé sur gouv.fr.

Et si les deux slashes sont vides ? Eh oui, on définit un serveur à interroger pour les noms domain-less. Ici c'est donc l'adresse IP de la box qui est précisée pour ces requêtes.

Pour toutes les autres, c'est le serveur DNS de FdN qui sera utilisé. Celui de Google est présent mais commenté, si jamais j'en ai besoin, je n'aurai qu'à le décommenter.

Pour donner des chiffres, le serveur de FdN me répond généralement entre 47 et 55ms, quand celui de Google oscille entre 45 et 100ms. La proximité géographique du premier doit y être pour quelque chose j'imagine.

 

Ne reste plus à présent qu'à appliquer les changements, ce qui se résume à un classique

# /etc/init.d/dnsmasq restart

À partir de cet instant, dnsmasq écoute les requêtes entrantes sur le port standard UDP/53.

Configuration des clients

La partie "serveur" étant terminée, il faut à présent modifier les clients (donc les autres machines du LAN) afin qu'ils utilisent désormais notre dnsmasq et plus celui fournit via DHCP par la box.

Avec NetworkManager

On retrouve cette configuration généralement sur toute machine disposant d'un environnement graphique (mais pas exclusivement). Des applets permettent ensuite depuis le bureau de configurer le réseau.

C'est donc très facile, il suffit d'ouvrir le gestionnaire de connexion, puis de modifier le profil pour utiliser l'attribution de l'adresse via DHCP avec un DNS manuel. Sur mon exemple l'adresse IP de la machine hébergeant dnsmasq est 192.168.1.254.

Dans mon cas, c'est ma machine de bureau "Leto" sous Archlinux qui doit être configurée ainsi.

Contournez le proxy menteur de votre FAI

Avec /etc/network/interfaces

Ici tout se fait via les fichiers de configuration.

Pour configurer une interface réseau en DHCP on pourra lire la doc de Debian ici.

Et pour configurer le serveur DNS, toujours sur la même page un peu plus loin ici.

Afin qu'Usul bénéficie lui aussi du nouveau DNS, j'ai d'ailleurs dû le configurer lui aussi grâce à cette méthode pour que les requêtes DNS passent par localhost (donc par dnsmasq) au lieu du DNS fourni par la box. Mon fichier /etc/resolv.conf contient donc à présent la ligne

nameserver 127.0.0.1

(et non plus 192.168.1.1).

Résumé

À ce jour, la box conserve son rôle central sur le LAN dont :

  • l'attribution des adresses IP via DHCP
  • la gestion des DNS pour les machines du LAN

Toute machine qui se connecte au réseau en mode "full-DHCP" utilisera donc la box comme serveur DNS, qui relaye - si nécessaire - vers celui du FAI, avec les restrictions associées. Pas de changement à ce niveau, on conserve donc le fonctionnement existant.

Si par contre on souhaite, disons "un peu plus de liberté" dans sa résolution de noms, il est possible de configurer son poste en DHCP tout en précisant manuellement le serveur DNS hébergé sur Usul (daemon dnsmasq). Celui-ci est configuré de telle sorte que les requêtes portant sur des noms de domaines pleinement qualifiés seront relayées vers le serveur DNS externe (neutre), alors que les requêtes portant sur des noms de machine seront relayées vers la box, qui saura les résoudre directement.

La seule contrainte de la seconde méthode est de devoir configurer manuellement sur chaque poste le serveur DNS à utiliser, plutôt que celui fourni par DHCP. Cette technique présente cependant l'avantage de ne pas modifier le fonctionnement du LAN, et d'apporter simplement une "alternative".

 

Il est important de préciser que ce qui est fait ici sur un PC "normal" utilisé comme serveur (x86 avec carte mère mini-ITX), peut être également et aussi facilement mis en place sur une plateforme beaucoup plus réduite, type Raspberry Pi par exemple. La méthodologie sera exactement la même en utilisant alors Raspbian. Il est donc extrêmement simple et abordable d'utiliser un serveur DNS alternatif à celui fourni par son FAI, tout en continuant à centraliser la gestion des DNS internes sur la box ainsi que le DHCP.

Publié le par Nanawel
Publié dans : #metal | #musique

Les finlandais ont remis ça en début d'année, et même s'ils n'inventent rien et persistent dans leur style de heavy-metal bien teinté "années 80" avec leurs nappes de synthés, leur dernier album se laisse bien écouter.

Battle Beast : Unholy Savior

La dernière piste (vidéo non-officielle ci-dessous) ne fait que confirmer que le groupe assume totalement son style un poil anachronique. Mais comme les années 80 reviennent à la mode, ils sont finalement peut être plus à la page que d'autres !

Publié le par Nanawel
Publié dans : #metal | #musique | #japan-is-superior

Pardon, mais c'est la faute de Deezer qui me propose des trucs aussi.

Publié le par Nanawel
Publié dans : #linux | #bash | #gist

J'ai récemment eu un besoin assez simple mais qui n'a pas pu trouver de moyen clé-en-main pour le satisfaire : surveiller le contenu d'un dossier local et m'afficher régulièrement une notification sur le bureau avec son contenu (notamment afin que je procède à son tri !).

J'ai fini par le coder moi-même avec Bash et en utilisant Zenity.

Pour le lancer en tâche de fond, il suffit de l'ajouter à la liste des programmes lancés avec la session. Sur XFCE en ce qui me concerne, il faut aller dans :

Paramètres > Session et démarrage > Démarrage automatique d'application

puis ajouter un nouvel élément avec les paramètres suivants (à adapter) :

Surveillance de dossier avec notifications via zenity

Ceci évidemment en supposant que le script est présent dans le dossier /usr/local/bin.

 

Si cela peut vous être utile, n'hésitez pas à l'utiliser (et si vous voulez l'améliorer, forkez-le !)

Publié le par Nanawel
Publié dans : #hardware | #intel | #bug | #linux | #cpu | #gpu | #kernel

Comme narré dans mon précédent article, je dispose à présent dans le salon d'un petit Brix de Gigabyte (un équivalent du NUC d'Intel) qui me sert principalement de HTPC. Il est relié à un moniteur Full-HD de 22" situé à deux mètre du canapé, donc parfaitement adapté en taille à son usage.

Si les choses n'ont pas été simples au début à cause des problèmes liés au EHCI/xHCI dans le BIOS, ce problème a finalement été résolu.

Restait un second problème très énervant et finalement bien plus grave au vu de l'utilisation de la machine : les freezes aléatoires - mais très réguliers - lors de la lecture de vidéos (crashes complets du système avec image figée sur l'écran).

Sans parler desdits freezes qui obligeaient à rebooter méchamment "au bouton", la lecture était soumise à de régulières coupures du son, saccades du flux des images, ou, la plupart du temps, les deux simultanément. Niveau confort pour une machine dédiée à la vidéo, on a déjà fait mieux.

Crashes lors de la lecture de vidéos avec Atom Bay Trail (i915)

J'ai tenté une analyse approfondie, en utilisant à peu près les mêmes techniques que pour le problème précédent :

  • test de plusieurs lecteurs vidéo  : VLC, SMPlayer, Totem, etc., mais même la lecture de vidéos Flash depuis Chromium pouvait planter le PC,
  • inspection des logs à la recherche de fautes matérielles : pas la moindre trace de signes avant-coureurs,
  • monitoring des capteurs de température : tous dans la normale, à peine une légère élévation des valeurs lors de la lecture de flux HD (normal jusque-là),
  • suppression de tous les services d'arrière-plan/daemons inutiles,
  • mise à jour vers le kernel du dépôt "testing" d'Arch (pour passer au kernel 4.0 à ce moment-là),
  • invocations mystiques sur la ligne de commande du kernel (intel_pstate=disable et ses déclinaisons),
  • mise à jour du BIOS,
  • j'en passe sûrement...

Rien, absolument rien, n'a donné de résultats satisfaisants. Ce qui est évidemment pernicieux, c'est que les plantages sont aléatoires, donc parfois après un changement, tout semble mieux fonctionner pendant quelques heures... mais c'est juste pour que le retour à la réalité soit plus dur.

Crashes lors de la lecture de vidéos avec Atom Bay Trail (i915)

Heureusement là encore, après avoir expliqué mon problème sur le forum d'Arch, un membre m'a indiqué un fil de discussion sur FreeDesktop qui parlait justement de problèmes similaires avec un processeur Bay Trail (l'architecture de ce modèle), le driver i915 et un kernel récent. En lisant les échanges, il semblerait effectivement qu'un bug soit apparu dans le noyau à partir de la version 3.17 (octobre 2014) concernant la gestion de l'alimentation du GPU intégré.

Les CPU récents utilisent en effet des systèmes de mise en veille très complexes afin de minimiser leur consommation (et par conséquent, leur dégagement thermique). Ils alternent en permanence entre plusieurs états (les C-states) selon leur activité courante. Un CPU très sollicité va être alimenté en permanence (état C0). En idle à l'inverse, il passera la plupart de son temps sous-alimenté (ex : états C3, C4 et suivants) et ne se "réveillera" que pour accomplir une tâche, avant de se remettre en veille, dès que possible.

Les SoC de la famille Bay Trail disposent apparemment comme leurs cousins desktop depuis Sandy Bridge et Haswell des états C6 et C7 qui correspondent à des veilles très profondes où le CPU est presque entièrement désactivé. Afin que l'alimentation soit gérée de la manière la plus fine possible, le noyau doit savoir utiliser ces états. C'est notamment le rôle des pilotes qui sont inclus au fur et à mesure dans les différentes versions de Linux. Ceci explique notamment pourquoi une mise à jour du noyau peut apporter une augmentation notable de l'autonomie sur des PC portables (ou au contraire, une baisse, ce qui est moins cool). Une mauvaise gestion des C-states, que ce soit par la partie logicielle ou même matérielle peut conduire à des instabilités ou des plantages assez désagréables.

Les C-States sur la présentation de l'architecture Silvermont d'Intel (Bay Trail)

Les C-States sur la présentation de l'architecture Silvermont d'Intel (Bay Trail)

C'est donc en fait ce qui m'arrivait lors de la lecture de mes fameuses vidéos. En l'occurrence il s'agirait d'un problème lié à la fois au mode Turbo et au C-state C6, à cause d'une réduction excessive de l'horloge du CPU. L'utilisation intensive du GPU ne serait en fait qu'une manière "aisée" de produire le bug. J'ai effectivement pu observer des crashes sur ma machine sans lire de vidéos, mais c'était assez rare. Comme sur un SoC le CPU et le GPU sont étroitement liés, il n'est pas trop étonnant d'avoir des effets de bord de l'un affectant l'autre.

Un patch a été soumis sur la branche de développement du driver graphique Intel et devrait logiquement être intégré à la prochaine version du noyau (4.1 à l'heure où j'écris). En attendant, la manière que j'ai choisie pour éviter les plantages, c'est d'utiliser le noyau LTS (Long Terme Support) proposé par Archlinux, soit la version 3.14. Et là, tout marche sans problème depuis plusieurs jours.

Pour faire de même, sous Arch c'est très simple :

# pacman -Sy linux-lts
# grub-mkconfig -o /boot/grub/grub.cfg

Le noyau le plus récent est conservé mais devrait être positionné en deuxième option par GRUB. Il reste donc possible de tester régulièrement si le problème a été corrigé :)

Publié le par Nanawel
Publié dans : #hardware | #linux | #ordinateur | #archlinux | #xhci

J'ai récemment décidé de remplacer mon magnifique multi-seat à trois écrans (que j'avais mis quelques semaines à mettre en place hein, rien que ça) par un dual-screen pour le bureau, et un mini-PC dédié pour la "TV". Je passe les détails, déménagement, tout ça, c'est pas geek donc on s'en tamponne le coquillard.

Aucun problème à signaler sur Leto (le PC du bureau donc) et son dual-screen, tout fonctionne parfaitement avec le driver Nvidia proprio. Avec nouveau, ça plante un peu trop.

Pour le mini-PC du canapé - car c'est le sujet de ce post - j'ai longuement hésité sur le type de machine que je voulais prendre (inutile de préciser : il tournerait sous Nunux évidemment).

À ce jour, il y a en effet pas mal de possibilités :

La machine de récupération

Avantages :

  • Pas chère à l'acquisition, puisque même gratuite.
  • Du matériel relativement ancien donc généralement bien supporté par GNU/Linux.
  • Customisation facile (ajout et changement de composants, etc.).
  • Bonne versatilité, il sera possible de l'utiliser également pour surfer ou jouer, mais de manière plus ou moins modeste selon la configuration.

Inconvénients :

  • Prend de la place, car il s'agit souvent d'un moyen-tour qu'il faut donc arriver à caser de manière esthétique dans un salon... ce qui n'est pas gagné. Malus d'âge : les carcasses grises (voire jaunâtres !).
  • Consomme sûrement beaucoup trop par rapport à l'usage qui en sera fait. On atteindra facilement la centaine de watts. Ici aussi l'âge représente un bon malus (vive les configs de 2005 qui pompent 150W en idle). Et qui dit consommation importante dit forcément dégagement thermique proportionnel - y'a pas d'miracle ma bonne dame - donc sympa l'été.
  • Les performances dépendront de la configuration. Selon le CPU et la carte graphique, lire certaines vidéos en HD ou même utiliser le player Flash sur un site web peuvent se révéler impraticables. À ce sujet, les CPU mono-cores seront fortement déconseillés.
  • Connectique vidéo et audio à vérifier, surtout si vous envisagiez d'utiliser du HDMI sur un PC de plus de 6 ans.
Par Ruben de Rijcke [CC BY-SA 3.0], via Wikimedia Commons

Par Ruben de Rijcke [CC BY-SA 3.0], via Wikimedia Commons

Le mini-ordinateur (ARM, type Raspberry Pi)

Avantages :

  • Coût d'achat faible. Pour un RPi il faut compter une soixantaine d'euros, avec l'alimentation, le boitier et la carte (micro-)SD.
  • Totalement silencieux, et très peu encombrant.
  • Une consommation très faible (moins de 4W en pic, 3W en moyenne), donc fraîcheur garantie et sourire sur la facture d'électricité.

Inconvénients :

  • Des performances CPU très limitées, particulièrement sur le RPi 1 (le 2 devrait être largement plus véloce cependant). La navigation dans Kodi/XBMC se révèlera assez pénible quand la médiathèque est assez volumineuse.
  • Une utilisation exclusive en mediacenter. Naviguer sur le Web confortablement étant exclu avec les performances offertes.
  • Une évolutivité quasi-inexistante. En effet, impossible ici d'ajouter de la RAM ou d'opter pour un GPU plus véloce. Seul le moyen de stockage pourra être remplacé en utilisant une carte SD de plus grande capacité.
  • Un chipset audio très léger qui obligera les audiophiles à utiliser un DAC externe pour produire un son de qualité.
Par cowjuice [CC BY-SA 3.0], via Wikimedia Commons

Par cowjuice [CC BY-SA 3.0], via Wikimedia Commons

Le mini-PC d'assemblage

Avantages :

  • Une formule sur-mesure qui vous assure de monter la configuration qui correspond exactement à l'usage et au rapport coût/performances recherchés, du moins en théorie.
  • Une excellente versatilité. Avec la distribution adaptée vous pouvez combiner en une seule machine : le mediacenter, le serveur, le NAS, et la console de jeu.
  • Une évolutivité limitée mais non-nulle. Il restera possible d'ajouter de la RAM, de changer/ajouter facilement disques durs ou SSD, et éventuellement d'ajouter une carte d'extension.

Inconvénients :

  • Une offre de composants inégale, privilégiant notamment l'imposant mini-ITX quand une taille plus acceptable serait plus à chercher dans le nano-ITX (AMHA). La difficulté est souvent aussi de trouver une carte mère proposant les bons ports : VGA, HDMI, Ethernet Gb, SPDIF, ...
  • Un manque criant d'alimentations adaptées aux puissances nécessaires : un PC de ce type consommant grand maximum 60W (plutôt 30 à 40W avec un petit CPU), alors que les premières alimentations de qualité commencent à 300 W. Le rendement en prend alors un coup.
  • Un coût forcément plus élevé, le prix des composants étant généralement inversement proportionnel à leur taille (ok j'exagère un peu). Compter 250€ minimum pour un boitier bien rempli.

 

Un boîtier vide, plus qu'à le remplir !

Un boîtier vide, plus qu'à le remplir !

By VIA Gallery from Hsintien, Taiwan [CC BY 2.0], via Wikimedia Commons

By VIA Gallery from Hsintien, Taiwan [CC BY 2.0], via Wikimedia Commons

Le Mini-PC prémonté (type NUC ou Shuttle)

Avantages :

  • Un encombrement réduit et un refroidissement adapté, donc un silence garanti (ici aussi, en théorie).
  • Versatilité : idem précédente, hormis le fait que le nombre d'emplacements pour les disques durs nécessite rarement l'utilisation du pluriel.
  • Presque tous les NUC possèdent un système de montage VESA, bien pratique donc pour cacher (et protéger !) la bête derrière un moniteur ou une TV.

Inconvénients :

  • Pour les PC Shuttle, malgré leurs avantages apparents en terme de compacité, j'ai personnellement été déçu des modèles proposés : j'avais besoin d'un port VGA et aucune machine abordable n'en disposait. Sur les modèles plus volumineux (donc plus encombrants), c'est la nécessité d'utiliser une alimentation de format propriétaire qui me dérange (j'en avais déjà parlé).
  • Pour les NUC comme pour les Shuttle, c'est l'évolutivité qui pêche. Hors changement de la RAM et du disque dur/SSD, point de salut.

Note concernant le premier point : j'ai découvert cet article bien après : l'adaptateur série/VGA pour Shuttle... ouin.

Nouveau venu : le PC du salon

Le décodeur de la box

Avantages :

  • Vous l'avez sûrement déjà, soit dans son carton, soit sur le lecteur DVD dans le salon. S'il n'est pas branché, n'ayez crainte, c'est pas trop difficile.

Inconvénients :

  • Ça n'est pas un ordinateur, juste un décodeur, même s'il est très avancé et qu'il fait plein de choses (plus ou moins bien). C'est pour un geek l'équivalent d'un appareil photo d'iPhone pour un photographe.
  • Aucune évolutivité.
  • Les vidéos, leurs pistes audio et leurs sous-titres sont plus ou moins bien lus selon le modèle de décodeur, le FAI, la position de la Lune et l'âge du capitaine.
  • Suite à une mauvaise manipulation de la télécommande, on peut tomber sur TF1 ou M6 et perdre instantanément 20 points de QI (30 pour NRJ12).
On sait de suite qu'on a affaire à du matos de geek de qualitay parce qu'il y a marqué "1337" sur l'horloge (après enquête, ce phénomène ne se produirait en fait qu'une fois par jour)

On sait de suite qu'on a affaire à du matos de geek de qualitay parce qu'il y a marqué "1337" sur l'horloge (après enquête, ce phénomène ne se produirait en fait qu'une fois par jour)

C'est mon choix ®

Après avoir longuement consulté le catalogue d'un e-commerçant dans l'objectif de plutôt monter un PC de zéro, j'ai dû me rendre à l'évidence que cette option n'était ni la plus aisée (pour trouver les pièces), ni la plus économique.

Malgré la sortie récente du Raspberry Pi 2 - et même si j'ai pris cette décision avant -, cette plateforme ne me semblait pas non plus adaptée, car l'utilisation visée n'était pas du pur mediacenter, mais plutôt une machine polyvalente bien que légère pour du surf, de la musique, des jeux, et éventuellement ce qui a remplacé les soirées diapos de nos aïeux : le diaporama de photos de vacances (ou d'autres choses). Le tout devant être absolument discret, autant sur le plan esthétique que sonore ou thermique.

C'est donc finalement vers un NUC que je me suis tourné, enfin plus exactement vers un BRIX de Gigabyte, doté d'un processeur Celeron J1900 à 2GHz / 4 coeurs : GB-BXBT-1900 de son petit nom. Il s'agit d'un modèle très abordable disposant de manière très classique pour ce format d'un emplacement SODIMM pour de la RAM DDR3 (1,35V attention) et d'un emplacement pour disque dur ou SSD 2,5".

Niveau connectique, il propose donc un port VGA (indispensable pour le moment puisque je n'ai qu'un moniteur faisant office de TV) mais également un port HDMI. On trouve ensuite trois ports USB3, un port Ethernet Gigabit et un jack audio 3,5mm. Le strict minimum, mais tout y est. Ah si, un chipset wifi b/g/n est intégré évidemment.

Le système de montage VESA est fourni avec, il s'agit d'une plaque à visser dans les emplacements prévus au dos d'un moniteur ou d'une TV, pour ensuite venir y emboiter le PC via deux encoches. Cela permet de retirer le PC très rapidement, sans tournevis, notamment pour aller le debugger dans une autre pièce... mais nous y viendrons.

Pour ce qui est du moniteur HD et du clavier/souris, je réutilise ceux existants, un moniteur Compaq de 21" et le clavier/touchpad K400r de Logitech.

Coût total :

146 € (BRIX) 

+ 40 € (RAM)

+ 44 € (SSD)

= 230 € environ.

Montage, tontage, sontage

Cette phase est d'une complexité sans nom. Il faut retirer 4 fins morceaux de métal noir cylindriques et filletés situés au quatre coins du boîtier - nous les appellerons des "vis" - au moyen d'un instrument allongé doté d'une poignée et d'un embout formant une sorte de croix, laquelle s'insère étrangement bien dans les encoches présentes au bout des éléments précitées. Après plusieurs tours réalisés à l'aide d'une main ferme sur la poignée, les "vis" s'extraient finalement doucement des cavités dans lesquelles elles étaient précédemment logées. Une fois la dernière retirée, l'arrière du boîtier peut être ôté à son tour en le retournant sur une surface plane.

 

Je crois que c'est la description la plus alambiquées qu'il m'ait été donnée d'écrire sur le dévissage d'un boitier.

 

Donc on ouvre le boitier, on ajoute la barrette de RAM, on dévisse la plaque de support du disque dur de la face arrière, on y visse le disque... - non le SSD, de 60 Go parce que bon c'est pas ce qu'on va y mettre, mais il faut que ça booste - et on replace le tout.

Pour le montage VESA, tout est expliqué sur la petite fiche technique fournie, il y a quatre vis pour fixer la plaque sur le moniteur, et deux vis à encoche à fixer sur le boitier. Elle coulissent ensuite dans la plaque pour le maintenir en place tout en assurant un retrait simple.

Le BRIX fixé sur son support VESA

Le BRIX fixé sur son support VESA

Petit tour à la pompe

Tradition oblige, toute nouvelle acquisition passe par mon Conserve Insight qui me donne des valeurs indicatives de sa consommation dans ses différents états.

Pas trop de surprises ici, il s'agit bien d'une machine légère à la consommation fortement limitée. On obtient donc les chiffres suivants :

État Consommation instantanée (W)
Éteint < 1
Idle 6,8
Activité 13,5 (pic)
Veille 1,6

 

J'en déduis un coût annuel de l'ordre de 4 à 5 €. Tout à fait raisonnable.

Installation de l'OS

J'avais commencé bien avant à réfléchir à ce que j'allais installer comme OS pour profiter de cette petite machine, mais j'ai rapidement réalisé que j'étais trop habitué à l'utilisation que j'en avais du temps du multi-seat pour en faire un simple HTPC. Il me fallait forcément un environnement de bureau avec un navigateur, un gestionnaire de fichiers, un lecteur vidéo, audio, et plus encore. Utiliser un OS de mediacenter pur type OpenELEC était donc exclu. Ce serait donc une distribution "classique".

Du côté de Debian - à moins d'utiliser Jessie, et encore - les applications sont un peu trop obsolètes, et je risque d'avoir demain un besoin qui nécessitera une version indisponible sur cette distro.

Côté Ubuntu et dérivé... pfff comment dire ? J'accroche pas. Si j'ai adoré Ubuntu 5.04 jusqu'à 7.04 pour m'avoir aidé à découvrir un peu plus facilement Linux qu'avec une Debian (et Mandrake, dont j'ai un amer souvenir), là non je ne peux plus.

Bon ben, il ne reste qu'Arch on dirait. Comme c'est bête. Allez on s'y met :)

 

Installation comme à l'accoutumée, en suivant le wiki et en aggrémentant de ma propre expérience. J'ai choisi une combinaison BIOS+GPT, soit : un boot BIOS classique, mais des partitions GPT, un peu plus actuelles que le vieillisant format DOS et son MBR.

Pour l'environnement de bureau, j'ai choisi à nouveau Xfce car je savais que je recopierai de toute façon le HOME de l'utilisateur "Couchy" qui servait à l'origine sur mon multi-seat. Cela m'a permis de retrouver en quelques minutes un environnement pré-paramétré, avec les favoris de Firefox, Chromium, la taille des polices (grosse), le thème, les raccourcis, etc.

En quelques heures la machine était prête et ronronnait silencieusement (oui je place des oxymores si je veux d'abord).

Mais...

... là, c'est le drame. ®

Si lors de l'installation je n'ai pas fait état des quelques blocages du PC lors de plusieurs reboots, ce point commençait à être un peu gênant.

D'autant plus que si les premières mises en veille ont fonctionné parfaitement, j'avais de plus en plus souvent des plantages lors de celles-ci : l'affichage se figeait, la machine ne répondait plus (même en SSH), et il fallait que je l'arrête via le bouton d'alimentation.

Pour les reboots (ou arrêts), Xorg se fermait bien, systemd arrêtait bien tous les daemons, démontait les partitions, puis affichait "Reached target shutdown", qui est normalement la dernière étape avant la coupure d'alimentation. Mais là, rien. L'écran restait également figé. Et vas-y que je suis encore obligé d'utiliser le bouton.

Puis c'est devenu quasi-systématique. Pour résumer, le reboot/arrêt ou la mise en veille ne fontionnait plus qu'une fois sur 10, voire une fois sur 20.

Je me suis donc mis à chercher la cause de ce problème. Ci-dessous les différentes pistes que j'ai suivies, sans succès.

  • Débugger le shutdown de systemd via un log dédié : pas plus d'information que ce qui s'affichait à l'écran.
  • Utiliser les kernels LTS d'Arch.
  • Désactiver Xorg, supprimer les drivers Intel.
  • Supprimer tous les daemons "inutiles" (disons les moins utiles).
  • Jouer avec les options des P-States dans les paramètres du kernel au boot.
  • Flasher le BIOS (mais aucune mise à jour n'était disponible).
  • Désactiver les chipsets audio et réseau depuis le BIOS.
  • Modifier les paramètres liés aux C-States dans le BIOS.
  • Utiliser une version de systemd plus ancienne.
  • Réinstaller Arch en UEFI+GPT.
  • Réinstaller Arch en BIOS+MBR.
  • Réinstaller Arch en x86.
  • Réinstaller Arch en ne laissant que le système de base, mais j'ai réalisé que même le LiveCD n'arrivait pas à rebooter la machine lui non-plus !
  • Utiliser un disque dur classique à la place du SSD (c'est d'ailleurs lui que j'ai utilisé pour les réinstallation précédentes, afin de ne pas user inutilement le SSD).

 

Finalement, j'ai craqué et j'ai installé une autre distribution. Enfin, plusieurs autres, afin de voir lesquelles posaient problèmes et celles qui fonctionnaient.

Fedora a fonctionné. Aucun problème pour rebooter.

Ubuntu. Idem.

Debian Wheezy. Idem.

Manjaro par contre a le même problème qu'Arch. En même temps elle se base sur Arch...

P'tain !! Mais c'est vraiment lié à Arch alors !

 

On y croit encore. On n'y croit plus.

On y croit encore. On n'y croit plus.

Désespéré, j'ai hurlé mon désespoir sur le forum d'Arch, et après deux semaines, une piste que j'avais ignorée m'a été donnée : désactiver l'EHCI ou activer/forcer l'xHCI depuis le BIOS. Des termes barbares qui me rappellent vaguement un lien avec l'USB3, mais dont mes connaissances frôlent le zéro.

En consultant l'option correspondante dans le BIOS, je remarque que la valeur sélectionnée est "Smart Auto", soit "Voiture intelligente" qui ne veut absolument rien dire évidemment. Hein ? Ah non pardon, ça signifie "Moi constructeur, toi utilisateur con, moi savoir ce que toi vouloir donc moi inventer option qui choisit à place à toi".

Les autres options disponibles étant "Auto" (gné ?) et "Enabled".

Par acquis de conscience, je teste d'abord "Auto". Mais ça marche pas.

Je passe donc sur "Enabled", comme conseillé par un Archer sur le forum.

Ô miracle bonne mère ! J'arrive à rebooter pour la première fois depuis trois jours ! Hem, point de hâte et de joie prématurée. Ne vendons pas la peau de l'ours avant qu'il ne soit mort de manière naturelle dans une réserve de l'ONF après s'être reproduit et que sa progéniture ait été recensée et baguée (cette mise à jour de proverbe vous est offerte par la WWF).

Je reboote une seconde fois. Ça marche aussi. Je contiens ma joie, mais un rictus se forme lentement sur la commissure droite de mes lèvres.

Je reboote une troisième fois. Ça marche toujours. Le rictus contamine à présent le côté gauche.

Je tente le tout pour le tout : une mise en veille suivie d'un réveil et d'un arrêt. Ça marche aussi. Avant même que le rictus ne se soit transformé en rire gras, ce sont les pleurs qui le remplacent et me brouillent la vue.

Voilà, tout ça pour ça. Deux semaines à chercher, à perdre du temps, à essayer des choses totalement inutiles, pour finalement réaliser qu'il y avait une dernière option dans le BIOS que je n'avais pas essayé de modifier.

 

Et le pire dans tout ça, c'est qu'il s'agit déjà de la deuxième blague crasse que me fait Gigabyte sur une de ses cartes mères. Car oui, mon problème de stabilité sur Leto dont j'ai parlé ici venait lui aussi d'une p****n d'option "Auto" dans le BIOS.

Cette marque a beau être plébiscitée par Canard PC pour sa qualité matérielle, je vais sérieusement réfléchir à lui confier mes économies lors de mon prochain achat de matos.

 

Ah oui, et son petit nom, c'est Ghanima, et sa fiche est là (ça manquait de noms féminins depuis un moment donc je vais essayer de rétablir la parité).

Publié le par Nanawel
Publié dans : #nerd | #humour

Nerdistic Behaviour Disorder Test

You scored 16.4 on the Nerdistic Behaviour Disorder index.

You have answered this test in such a way to suggest that you are definitely a nerd. Seek help immediately.

For the OSSA (Open Source Software Addiction) index, you scored 10.2. You appear to have extreme open source software tendencies. Seek help immediately.

 

Mouhahaha :)

Faites vous aussi le test : http://stopnerds.org/nerd-test/

Publié le par Nanawel
Publié dans : #mpd | #linux | #serveur | #audio | #samba

Un très courte et simple astuce aujourd'hui mais qui peut sauver des nerfs.

J'ai déjà mentionné de nombreuses fois ma home web-radio utilisant MPD en place sur mon serveur Usul, et le fait qu'elle lisait les fichiers situés sur mon NAS via un montage Samba. Il y a quelques mois je me suis mis à retagger en masse mes fichiers car les informations étaient très souvent hétérogènes (voire inexistantes).

En plus du retaggage, j'en ai profité pour renommer en masse les fichiers (une fonctionnalité souvent proposée en parallèle). C'est ainsi que certains fichiers ou dossiers n'ont pas changé d'orthographe mais on changé de casse.

Un exemple :

"Draconian times" (de Paradise Lost) est devenu "Draconian Times".

 

Peu de temps après j'ai réalisé que MPD stoppait inexplicablement sa lecture sur certains fichiers (avec une erreur du genre "Impossible de décoder le fichier ...", soit un message qui n'est pas aussi explicite que "Fichier introuvable").

Au départ je n'ai pas fait le rapprochement, et en comparant à l'oeil nu les chemins je n'ai pas trouvé de différence, d'autant qu'en copiant-collant le chemin depuis le message d'erreur, le fichier était bien trouvé dans le terminal ! (eh oui, Samba est case-insensitive comme Windows)

J'ai bien essayé de rescanner mes dossiers, plusieurs fois, mais rien n'y faisait, au bout d'un moment il y avait ces erreurs qui arrêtaient la lecture sur des fichiers qui pourtant, semblaient exister.

Et puis j'ai compris. Mais par contre cela ne m'a pas expliqué pourquoi MPD ne mettait pas ces chemins à jour dans sa base. Il semblerait qu'il adopte une gestion "deux poids deux mesures" :

  • le scan des fichiers (l'ajout initial en base) est case-sensitive, jusque-là c'est normal,
  • la vérification de l'existence lors de la mise à jour de la base dépend du support, donc si c'est sur un montage Samba, elle sera case-insensitive,
  • et la lecture des fichiers est forcément case-sensitive, ça je ne l'explique pas.

Une mise à jour de la base ne suffit donc pas à mettre réellement à jour les chemins des fichiers. Il faut la détruire.

Et pour cela, rien de plus simple :

# /etc/init.d/mpd stop
# rm /var/lib/mpd/tag_cache
# /etc/init.d/mpd start

On peut ensuite relancer un scan complet de ses dossiers de musique, et là les chemins seront évidemment mis à jour (mais le scan sera plus long qu'une simple mise à jour).

Publié le par Nanawel
Publié dans : #machinae supremacy | #metal | #musique | #album | #sid-metal

Évidemment, je me devais de faire un petit billet pour signaler la sortie du dernier album de Machinae Supremacy : Phantom Shadow, un petit bijou que je suis en train de découvrir en ce moment même.

Nouvel album de MaSu : Phantom Shadow

J'ai reçu mon exemplaire physique aujourd'hui, après deux mois d'attente depuis sa précommande (mais après surtout deux ans d'attente depuis leur dernier opus !) et je dois dire que ce son coule toujours dans mes oreilles comme du miel, même si j'y reprocherai - comme c'est de tradition depuis Overworld - une finition un peu trop lisse à mon goût.

 

Côté nouveautés, MaSu s'entoure à cette occasion de deux éléments qui font mouche.

Tout d'abord des voix féminines qui alternent avec la voix si spéciale de Gazz sur Europa et qu'on retrouve également dans les pistes de transition.

Viennent ensuite le piano et les instruments à cordes qui composent ou enrobent ces pistes instrumentales, et que l'on retrouve également dans Europa (encore elle !).

Malgré cela il ne faut pas s'y tromper : il s'agit du son brut de MaSu, encore renouvelé. Un power metal léché, puissant et maîtrisé, qui sonnera forcément familier aux (retro-)gamers aux travers de bips et des bops de la SIDStation.

 

Bon et puis il faut avouer, ça fait quand même son petit effet de voir son nom dans la liste des remerciements sur la couverture quand on est un gros fan :)

Publié le par Nanawel
Publié dans : #munin | #capteur | #usb | #linux | #thermometre | #monitoring

Le contexte

Je surveille étroitement la température des différents capteurs présents sur les machines de mon cheptel, et l'été est toujours une période à risque car la température monte chez moi parfois au-dessus des 30°C là où se trouvent mon serveur et mon NAS. J'utilise pour cela les rapport fournis par Monitorix et Munin qui produisent chacun de jolies courbes d'historisation.

Si les températures relevées via ces capteurs sont globalement proportionnelles à celles régnant dans la pièce (ou le placard !) dans laquelle les machines se trouvent, il s'agit néanmoins de la température des composants. Je souhaitais en plus pouvoir consulter et historiser facilement la température de la pièce elle-même.

Pour la consultation en temps-réel et sur place, le problème n'en est pas pas un : il suffit d'acheter un thermomètre !

Pour la consultation en temps-réel mais à distance, on pourrait imaginer de filmer le même thermomètre avec une webcam. D'accord ça commence à être tordu.

Pour la consultation différée sur place ou à distance, il n'y a pas vraiment de solution sans automatisation.

Je me suis donc mis à la recherche d'un thermomètre USB. Je me doutais qu'un gadget de ce type devait se trouver facilement à 10€ sur Amazon.

En réalité, oui et non. Il existe en effet des sondes de température que l'on peut brancher sur le port USB, sur Amazon et eBay, mais aucune n'est à 10€ et celles qui s'approchent le plus de ce tarif ont des commentaires bien souvent assassins. En cause : la qualité de fabrication principalement, entraînant des mesures très peu précises.

 

Surveillez la température de votre placard

J'ai cherché longtemps d'autres modèles de meilleure qualité, mais je tombais finalement toujours sur des sites d'équipements professionnels, dont les prix étaient tout sauf accessibles. Il manquait un juste milieu.

Puis, suite à la lecture d'un commentaire sur un forum je crois, j'ai découvert la boutique de Dracal Technologies, une (apparemment) petite société canadienne qui produit des capteurs en tout genre, à des tarifs plus raisonnables. Le thermomètre USB simple "USBTenki" est au prix de $29.99. Une fois la conversion effectuée et les frais de livraison ajoutés, on tombe à environ 29,00€. J'ai failli craquer pour le modèle relevant température, humidité et pression atmosphérique mais je me suis ravisé :)

Un point amusant et intéressant au passage, la plupart de ces appareils sont basés sur des montages dont les plans sont librement accessibles :

http://www.raphnet.net/electronique/usbtenki/index_en.php

Le matériel

Le capteur reçu est en tout point conforme à la description et aux photos sur la fiche produit. On sent clairement qu'il s'agit de petits circuits imprimés et petits composants cachés sous des gaines de plastique, mais l'ensemble est très propre et ne semble pas particulièrement fragile.

Il y a d'ailleurs deux portions de gaines rigides différentes : une au milieu du câble, d'une dizaine de centimètres - contenant j'imagine l'électronique de conversion - et une en bout, contenant le capteur même. Le reste du câble (mesurant environ 1m au total) est flexible et peut donc être facilement manipulé de manière à placer précisément la sonde.

Surveillez la température de votre placard

Une fois le capteur branché, j'ai pu constater qu'il était bien détecté :

# lsusb
[...]
Bus 006 Device 003: ID 1781:0a98 Multiple Vendors

L'ID 1781:0a98 correspond bien au capteur  : 1781 est l'identifiant du constructeur (ou "Vendor ID", ici c'est un ID générique : "Multiple Vendors"), et 0a98 celui du modèle ("Product ID").

 

Le logiciel

Cette sonde - ainsi qu'apparemment toutes celles vendues par Dracal - peut être contrôlée depuis Windows, Mac et Linux. Un excellent point car chez moi c'est à Usul - tournant sous Debian Wheezy - qu'elle va être branchée. Une petite page est même dédiée au manchot et détaille les opérations nécessaires pour compiler les binaires qui vont lire les valeurs des capteurs. Il suffit de se placer dans le dossier client après avoir décompressé l'archive, un petit make et voilà les binaires compilés (quand on a installé les packages build-essential et libusb-dev évidemment).

Deux binaires sont générés : usbtenkiget et usbtenkisetup. Le second permet apparemment de calibrer la sonde, mais je ne l'ai pas utilisé.

Si le capteur est branché, il doit être possible de lire la valeur directement. Il faut par contre le faire en tant que root ou que l'utilisateur courant fasse partie du groupe plugdev, autrement le message "No device found" s'affiche.

# ./usbtenkiget
24.19

Concis et efficace !

La précision de la valeur retournée est à la deuxième décimale, mais d'après la fiche produit la précision réelle est estimée à ±0,5°C à 25°C. D'après mes tests, je pense que celle-ci est légèrement meilleure que celle annoncée.

Il est évidemment possible d'utiliser des options pour lister les différents capteurs disponibles, changer l'unité (F° ou K°), le format de sortie et bien d'autres choses.

# ./usbtenkiget -p -T Kelvin -i 0
Temperature: 297.09 °K

Le paramètre -i permet de sélectionner le capteur à interroger. Pratique si on en a plusieurs, ici il est facultatif, ce qui renvoie par défaut la valeur du capteur 0.

Pour lister les capteurs disponibles avec leurs ID, utiliser le flag -l :

# usbtenkiget -l
Found: 'USBTenki', Serial: '??????', Version 2.0, Channels: 9
    Channel 0: MCP980x I2C Temperature sensor [Temperature]

 

Afin de pouvoir appeler cette commande depuis n'importe quel dossier, j'ai évidemment copié le binaire dans le dossier /usr/local/bin.

Plugin Munin

Pouvoir récupérer la température sur demande c'est bien, mais automatiser cette lecture et l'historiser, c'est mieux. Pour cela j'ai créé un petit plugin très simple pour Munin.

Sauf que si je tente d'interroger le capteur en tant que munin, le résultat n'est pas ce qu'on pourrait appeler un flottant crédible :

# su -l munin -s /bin/bash -c usbtenkiget
No device found

La commande munin-node - exécutée toutes les 5 minutes et chargée de récolter les valeurs des différents plugins actifs - tourne en effet avec les droits de l'utilisateur munin, qui sont très restreints. On pourrait ajouter cet utilisateur au groupe plugdev, ou... utiliser un peu de la magie des permissions UNIX pour autoriser l'utilisation du binaire usbtenkiget par tout utilisateur.

Je vais pour ma part utiliser la seconde option car j'aurai besoin dans un second temps qu'une application Web (donc  l'utilisateur www-data) puisse elle aussi aller lire la valeur du capteur. Si munin pourrait à la rigueur être membre du groupe plugdev, il est par contre hors de question que www-data le soit. Faut pas déconner.

 

EDIT 20/08/2014 : Il est aussi possible concernant le plugin Munin de préciser l'utilisateur et/ou le groupe à utiliser lors de son exécution.

 

Pour cela nul besoin de baguette magique, juste d'un petit terminal. Il suffit de changer le groupe du fichier et de positionner le bit SGID :

# chgrp plugdev /usr/local/bin/usbtenkiget
# chmod g+s /usr/local/bin/usbtenkiget
# ls -l /usr/local/bin/usbtenkiget
-rwxr-sr-x 1 root plugdev 129704 juil. 10 22:16 /usr/local/bin/usbtenkiget

Et pour vérifier que munin peut à présent bien relever la température :

# su -l munin -s /bin/sh -c usbtenkiget
21.31

(NdA : tiens, il fait plus frais que quand j'ai écrit le paragraphe précédent ^^)

On peut à présent installer le plugin ci-dessous dans le dossier /usr/share/munin/plugins. Je l'ai appelé tenkitemp_ et me suis basé sur un plugin utilisé à la base pour monitorer la température de mon Raspberry Pi, auquel j'ai ajouté la possibilité de préciser l'ID du capteur. On crée ensuite un lien dans le dossier /etc/munin/plugins qu'on nomme tenkitemp_0 (car on va relever la valeur du capteur à l'ID 0).

# ln -s /usr/share/munin/plugins/tenkitemp_ /etc/munin/plugins/tenkitemp_0

Les valeurs WARN et CRIT sont purement arbitraires. Comme je l'ai dit plus haut, chez moi 30°C est une température facilement atteignable en été, mais qui est clairement élevée. Par contre à 38°C on peut se demander si je n'ai pas oublié un chiffon imbibé d'essence dans le four allumé...

Une fois le plugin installé, n'oubliez pas de recharger la configuration du daemon munin-node :

# /etc/init.d/munin-node restart

 

Après quelques jours, on peut observer de jolies courbes dans la catégorie "sensors" de Munin :

Non ce n'est pas une erreur, la température varie *vraiment* autant...

Non ce n'est pas une erreur, la température varie *vraiment* autant...