La Lanterne Rouge

La Lanterne Rouge

Warning: Geek Inside

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.

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
#!/bin/sh
#
# Plugin to monitor Tenki sensor Temperature
#
# Magic markers (optional - only used by munin-config and some installation scripts):
#%# family=contrib
 
TENKIGET=/usr/local/bin/usbtenkiget
WARN=30
CRIT=38
SENSORID=${0##*/tenkitemp_}
 
if [ "$1" = "autoconf" ]; then
        if [ -x $TENKIGET ]; then
                echo yes
                exit 0
        else
                echo no
                exit 1
        fi
elif [ "$1" = "config" ]; then
        echo "graph_title Tenki Temperature Sensor"
        echo "graph_args --base 1000"
        echo "graph_vlabel Celsius"
        echo "graph_category sensors"
        echo "graph_info This graph shows Temperature data from sensor $SENSORID"
        echo "temp.label temp"
        echo "temp.type GAUGE"
        echo "temp.info Celsius."
        echo "temp.colour 00ff00"
        echo "temp.warning $WARN"
        echo "temp.critical $CRIT"
        exit 0
elif [ "$1" = "suggest" ]; then
        $TENKIGET -l | sed -n 's/.*Channel \([0-9]\{1,\}\):.*/\1/p'
        exit 0
elif [ $SENSORID = "" ]; then
        echo Missing sensor ID. Try "suggest".
        exit 2
fi

temp=$($TENKIGET -i $SENSORID)
echo "temp.value $temp"

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

Publié le par Nanawel
Publié dans : #apache | #https | #svn | #proxy | #linux | #réseau
Reverse proxy HTTPS/SVN avec Apache

Si jamais vous avez un jour besoin de monter un reverse-proxy avec Apache devant un serveur SubVersioN accessible via HTTPS (par Apache/DAV par exemple), voici un petit exemple de configuration fonctionnelle.

Note : j'utiliserai "RP" pour Reverse-Proxy et "SVN" pour... SubVersioN évidemment.

 

Le serveur Apache RP doit au préalable avoir les modules suivants installés et fonctionnels :

  • mod_ssl
  • mod_proxy
  • mod_proxy_http
  • mod_proxy_connect

 

Attention : l'activation du module de proxy peut potentiellement transformer votre Apache en proxy ouvert, accessible et utilisable par tout le monde. Fort heureusement, la directive ProxyRequests est par défaut à Off, mais vérifiez bien qu'aucun fichier de configuration ne l'active sur votre serveur.

Reverse proxy HTTPS/SVN avec Apache

L'URL du serveur SVN sera la suivante : https://svn.domaine.local/projet1/

L'URL du serveur en RP sera la suivante : https://svn.domaine.fr/projet1/

 

Le but ici sera de mapper l'une à l'autre, de manière à ce qu'un utilisateur se connectant depuis Internet à l'adresse (publique) https://svn.domaine.fr/projet1/ accède au dépôt SVN à l'adresse (interne) https://svn.domaine.local/projet1/.

 

Voici le fichier de configuration du VirtualHost à utiliser sur le serveur Apache tournant sur la machine svn.domaine.fr :

<VirtualHost *:443>
        ServerName svn.domaine.fr
        DocumentRoot /srv/http
        ErrorLog /var/log/apache2/svn-proxy.error.log

        SSLEngine on
        SSLCertificateFile /etc/apache2/ssl/server.crt
        SSLCertificateKeyFile /etc/apache2/ssl/server.key

        ProxyPass /projet1/ https://svn.domaine.local/projet1/

        SSLProxyEngine On
        <Proxy *>
                Order allow,deny
                Allow from all
        </Proxy>

        <Location /projet1/ >
                ProxyPassReverse https://svn.domaine.local/projet1/
                <Limit OPTIONS PROPFIND GET REPORT MKACTIVITY PROPPATCH PUT CHECKOUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
                        Order Deny,Allow
                        Allow from all
                        Satisfy Any
                </Limit>
        </Location>
</VirtualHost>

Les points importants ici sont :

  • La nécessité de préciser explicitement dans le bloc <Limit> les méthodes correspondant aux actions SVN autorisées à s'exécuter (je n'ai trouvé aucun document le confirmant mais il semblerait que seules quelques méthodes classiques comme GET, POST, OPTIONS et autres soient autorisées par défaut)
  • Faire parfaitement correspondre les chemins du bloc <Location> et de la directive ProxyPassReverse : le chemin du serveur RP doit être celui du dépôt SVN (ici "/projet1/" très exactement). J'avais initialement placé cette directive après ProxyPass avec le chemin complet (autre syntaxe possible normalement) mais les tentatives de connexion me renvoyaient une erreur 405 "Method not allowed" sur l'action PROPFIND jusqu'à ce que je la déplace. Cette contrainte viendrait d'un problème de réécriture de headers et pourrait être contournée d'une manière plus élégante mais je n'ai pas cherché plus loin. Je ne trouve malheureusement plus l'URL de la page qui m'a donné la solution :(
  • Inutile de préciser mais au cas où, hein, il faut que le RP puisse accéder au dépôt via l'URL interne https://svn.domaine.local/projet1/. Ben oui, c'est un proxy, pas un magicien :)

 

Une fois le vhost enregistré, un petit

# apachectl restart

et - à condition que les DNS soient à jour évidemment - il devrait être désormais possible d'utiliser l'URL https://svn.domaine.fr/projet1/ pour accéder en fait au dépôt situé à l'adresse https://svn.domaine.local/projet1/.

Publié le par Nanawel
Publié dans : #magento | #php | #module | #ecommerce

En ce moment au boulot je n'ai pas le temps que je voudrais pour coder des modules sur la plateforme Magento (qui me permet de consommer de la nourriture et du matos informatique depuis quatre ans). J'ai donc décidé de me mettre "à mon compte" et de développer sur mon temps libre. Qui sait ? cela pourra peut-être intéresser des gens... (et des recruteurs ^^)

[Magento] Réécritures de 404 par regexp

Le petit module dont je viens de terminer la première version tire son idée de besoins récurrents chez les clients de la société dans laquelle je travaille. Il arrive en effet fréquemment de devoir gérer des redirections d'URL en masse, par exemple suite à la restructuration du catalogue, ou suite simplement à la migration d'une boutique en ligne vers Magento.

 

Un exemple simple : la navigation par couches (ou "à facettes") générait sur l'ancienne plateforme d'un client des URL de cette forme :

http://www.boutique.com/categorieA-valeur1-valeur2.html

dont l'équivalence dans Magento après migration aurait pu donner ceci :

http://www.boutique.com/categorieA.html?filtre1=valeur1&filtre2=valeur2

Je simplifie volontairement, car il y avait en réalité une dizaine de valeurs en suffixe (!), toutes toujours présentes même si elles étaient vides (elles avaient alors la valeur "0").

 

Dans un pareil cas, le client ne souhaite pas forcément rediriger chaque URL vers son équivalent exact, mais simplement vers la catégorie correspondante afin de conserver au maximum le référencement. Parfois, une simple redirection permanente vers la (nouvelle) page d'accueil sera même suffisant. Essayer de retrouver toutes les URLs (donc toutes les combinaisons de valeurs !) par crawling ou autre n'est de toute manière clairement pas gérable.

Une fois la migration terminée, et si on n'y prend pas garde, on se retrouve rapidement dans Google Webmaster Tools à devoir gérer des dizaines, des centaines, voire des milliers d'URL en erreur, tout simplement parce qu'on n'a pas (suffisamment) géré la transition. Dans le cas dont je parle, nous avions quand même anticipé la réécriture de plusieurs centaines de milliers d'URL, mais cela n'a pas suffit.

 

J'ai donc pensé qu'une solution élégante pour résoudre ce problème, avant ou après la transition, était de poser un hook au niveau du rendu de la page 404 de Magento, c'est-à-dire au moment où Magento va nous renvoyer la page CMS "Cette page n'existe pas gnagnagna".

À ce moment, et sans trop altérer le workflow de la plateforme, il nous suffit de consulter une table contenant des règles de redirections, et grâce à la fonction REGEXP de MySQL on peut éventuellement renvoyer une notification de redirection permanente au visiteur (et surtout au moteur de recherche !) afin qu'il aille tout seul à la nouvelle URL la prochaine fois pour obtenir la ressource demandée.

 

Dans l'exemple plus haut, il suffit de créer une règle avec le pattern suivant :

^/categorieA-.*\.html

et de définir le chemin cible suivant :

categorieA.html

pour rediriger simplement les visiteurs utilisant les anciennes URL vers la nouvelle catégorie.

On peut aussi à la place utiliser le chemin "système" afin de ne pas être dépendant des url-keys (la catégorie aurait l'ID 10) :

catalog/category/view/id/10

 

Chaque règle est associée à une boutique (store), possède un option de redirection (aucune, temporaire, permanente), et peut-être activée ou non.

 

Bien sûr, il s'agit d'un fonctionnement de fallback, et doit être utilisé comme tel. Il ne remplace pas le système de réécritures d'URL de Magento, ni les fonctionnalités de réécritures offertes par Apache (via .htaccess et vhost). Il vient uniquement en complément, et permet surtout au client de gérer ses redirections lui-même depuis le back-office, d'en ajouter, d'en modifier, et d'en supprimer si besoin.

Il est nécessaire de savoir un peu ce qu'est une expression rationnelle, mais avec une petite documentation et un peu de support, même les plus hermétiques à la technique peuvent s'y mettre :)

[Magento] Réécritures de 404 par regexp

Le GitHub du module est disponible ici :

https://github.com/nanawel/Arrakis_404EverGone

En cas de bug ou problème, un petit ticket et j'y jetterai un oeil :)

 

Quelques captures d'écran de l'interface d'administration disponible dans le back-office ci-dessous.

Note : la traduction française est disponible, et sans fautes, ce qui est quand même à mentionner quand on connaît l'état du pack de traductions FR de Magento...

[Magento] Réécritures de 404 par regexp
[Magento] Réécritures de 404 par regexp[Magento] Réécritures de 404 par regexp
[Magento] Réécritures de 404 par regexp
Publié le par Nanawel
Publié dans : #linux | #nvidia | #intel | #pulseaudio | #systemd | #udev | #multiseat | #xorg

Si jusqu'à présent la plupart de mes articles concernant Linux étaient très orientés "serveur" ou du moins "headless", suite à mon changement de configuration matérielle et mon passage à Archlinux comme OS principal, je vais commencer à élargir un peu et tenter d'aborder certains aspects plus "desktops".

Comme je l'ai expliqué il y a quelques semaines, je suis passé d'un triple-head sous Windows XP à un (potentiel) triple-head sous Archlinux.

Si sous Windows le nombre d'écrans disponibles est presque un détail car le panneau de configuration autorise tous les agencements possibles facilement, sous Linux c'est encore un peu laborieux. Alors quand en plus il s'agit de faire cohabiter deux adaptateurs graphiques de constructeurs différents (j'entends NVidia, AMD ou Intel), il ne faut pas espérer conserver beaucoup de cheveux sur le crâne à la fin de l'opération... si fin il y a !

En parlant de fin, elle arrivera peut-être plus tard car ce que je vais présenter ici n'est pas - et de loin - ce que je qualifierai de "solution parfaite ferme et définitive". Mais je me lance quand même.

Schéma résumant ma précédente configuration sous Windows XP

Schéma résumant ma précédente configuration sous Windows XP

Quoi que c'est-y pour faire ?

J'ai la chance d'avoir mon PC sur mon bureau (enfin, sous, mais passons) à trois mètres à peine de mon canapé, ce qui me permet facilement de passer de l'un à l'autre au gré de mes envies. Cela fait quelques années que j'utilise un dual-head et je m'arrangeais jusque-là pour toujours avoir un des moniteurs visible depuis le "coin à glandouille", à savoir maintenant le canapé (mais avant c'était une chaise; mais ça c'était avant que je ne devienne milliardaire et que je n'exige que du mobilier suédois sur-mesure). C'était bien. Mais déménagements et réorganisations ont finalement eu raison de cette option. Et quand j'ai acquis la première version d'Usul j'ai également obtenu mon fameux moniteur HD "gratuit", un petit 22" en 16/9 mais qui me satisfait pleinement.

Au départ relié à mon PC via un adaptateur USB-VGA, j'ai finalement craqué pour une carte graphique secondaire en PCI-Express 1x (seul port disponible restant), une petite GeForce 210 qui fait autant de bruit qu'un Concorde à l'écrasement, je veux dire, à l'atterrissage.

Depuis, je disposais d'un bureau Windows de 5760x1080 réparti sur trois moniteurs. Bon, en fait la GeForce 210 peinait un peu à gérer la résolution HD pour tous les films et toutes les vidéos Flash, donc j'ai été obligé de réduire la définition de son affichage à 1440x900, ce qui en plus avait l'avantage de rendre les textes plus gros, donc plus lisibles (mouais, vite fait alors). J'avais donc réellement du 5280x1080 dont une bande supérieure était inutilisable sur le troisième moniteur.

Pour contrôler tout ça, il y avait tout d'abord le clavier et la souris filaires sur le bureau, et au départ un clavier et souris sans-fil pour le canapé. J'ai ensuite remplacé avantageusement ces derniers par un clavier K400r de Logitech avec touchpad plus compact, plus léger, donc plus maniable. J'y ai juste perdu le pavé numérique. Tout ce beau monde est évidemment en USB (cela aura une certaine importance pour la suite).

J'insiste donc maintenant sur le fait que tout était alors partagé : session, programmes, et évidemment : claviers et souris. Pendant que j'étais affairé à mon bureau, un petit malin pouvait depuis le canapé taper des bêtises sur la fenêtre ayant le focus sur n'importe quel moniteur (c'est-à-dire la plupart du temps celle sur laquelle j'opérais). Idem pour remuer le pointeur et m'empêcher de cliquer sur le bouton que je visais. Heureusement, la plupart du temps, la menace de retrait de bière et son remplacement par de l'eau plate suffisait à calmer le malin en question.

Cette configuration fonctionnait pour les raisons suivantes :

  • Windows retient plutôt bien les emplacement et tailles des fenêtres pour chacune des applications et les restaure à leur redémarrage. Il affiche cependant presque toujours les boîtes de dialogue sur le moniteur "courant" (celui contenant le pointeur), ce qui est un comportement "logique".
  • Media Player Classic HC - mon lecteur vidéo favori sous Windows - s'ouvre automatiquement sur le moniteur sur lequel se trouve le pointeur de la souris, il suffit donc de positionner un raccourci sur le moniteur du canapé pour que le lecteur apparaisse sur celui-ci quand on le lance.
  • Grâce au point 1 il suffit d'installer Firefox Portable et d'ajouter un raccourci sur le moniteur du canapé pour que celui-ci conserve son emplacement à chaque ouverture une fois positionné sans interférer avec le Firefox "fixe" dont la fenêtre s'affiche sur un des moniteurs du bureau.

Et sous Linux ?

Une fois mon Archlinux installé et grossièrement fonctionnel avec XFCE, j'ai évidemment (et "bêtement") souhaité reproduire le même schéma sous cet environnement. Mais il n'a pas fallu trop de recherches ni de tests pour me rendre compte que les trois points qui en faisaient une solution viable sous Windows étaient impossible à conjuguer sous Linux (en tout cas sous XFCE ou Gnome) : l'emplacement des fenêtres à leur ouverture dépend du bon vouloir de l'application :

  • VLC et Firefox s'ouvrent sur le moniteur courant (qui affiche le pointeur à ce moment-là)
  • Chromium conserve son emplacement précédent
  • SMPlayer s'ouvre toujours sur le moniteur principal (dans mon cas, celui du milieu)
  • De nombreuses autres applications ont leurs fenêtres qui s'affichent aux coordonnées (0,0), donc en haut du moniteur gauche du bureau

Je suis par contre régulièrement tombé sur des gens parlant de "multiseat", sans savoir au départ que c'était une solution possible et même préférable pour mon cas.

Après renseignement, j'ai décidé de tenter le coup.

 

Le multiseat, c'est - dixit Wikipédia - "une configuration par laquelle un ordinateur unique permet à plusieurs utilisateurs locaux indépendants (les "seats") de travailler en parallèle". Pour simplifier, il s'agit d'avoir une UC unique, et N couples moniteur-clavier-souris, N dépendant évidemment de la configuration matérielle de l'UC et des ports de chaque type dont elle dispose.

Multiseat 4 postes, By Tiago Vignatti / Rattus [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons

Multiseat 4 postes, By Tiago Vignatti / Rattus [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons

Je dois avouer que la mise en place d'une telle configuration nécessite une obstination (un acharnement même) et une implication de compétition. La tâche est - je pense - rendue encore plus ardue par l'utilisation de composants récents dont les pilotes ne sont évidemment ni complètement stables ni complets.

Je vais donc détailler à qui serait intéressé par le montage d'un système similaire les principales étapes indispensables.

Attention : il ne s'agit pas d'une tutorial générique mais de mon expérience, avec mes composants, et ma configuration. Des adaptations plus ou moins importantes peuvent être nécessaires en changeant de distribution Linux, de matériel, ou d'environnement de bureau.

Précision importante et potentiellement décevante : j'utilise le pilote libre Nouveau et non le pilote propriétaire NVidia. Cela permet d'obtenir des performances similaires en 2D mais la 3D est fortement dégradée ce qui interdit tout jeu un peu gourmand (même L4D2 ne tourne pas à plus de 15 FPS). La raison de ce choix est que cela n'en est pas un : en effet je ne suis pas arrivé à obtenir une configuration stable avec le pilote NVidia pour le moment. Cela reste néanmoins dans ma TODO-list car je sais que cela reste possible.

Présentation générale

Mon objectif ici a été de mettre en place un système de double session sur mon PC : un premier utilisateur pour le dual-head du bureau, pour les tâches usuelles (surf, dev, administration, lecture de musique et de vidéos) et un second utilisateur pour le canapé (principalement pour de la lecture de vidéos mais également du surf léger et de la lecture de musique). Le bureau aura son couple clavier-souris filaires, et le canapé son clavier sans-fil avec touchpad, chacun ne contrôlant que sa propre session évidemment.

Pourquoi deux utilisateurs ? Tout simplement car nous allons devoir lancer deux instances du serveur X, et qu'il n'est pas possible facilement et surtout pas conseillé de faire cela avec le même utilisateur. Ensuite cela permet de séparer clairement les configurations des environnements (XFCE et applications) qui, du reste, n'auront pas le même contexte (matériel), ainsi que d'appliquer des permissions plus fines à l'utilisateur du canapé et empêche le petit malin du paragraphe au-dessus de jouer avec les fichiers de l'utilisateur principal.

J'ai repris le diagramme du montage sous Windows que j'ai adapté aux nouveaux objectifs :

Une configuration multiseat sous GNU/Linux

Avertissement : si vous vous décidez de vous lancer ce genre de procédure, assurez-vous d'avoir mis en place au préalable un serveur SSH sur la machine et d'avoir un client SSH connecté au même réseau (filaire de préférence !) pour pouvoir relancer le gestionnaire d'affichage ou rebooter si nécessaire. Les bidouilles suivantes touchent en effet au clavier et à la souris, périphériques qui sont vos seuls moyens de communication avec le système !

Configuration de Xorg

Un gros morceaux !

Tout d'abord il faut savoir que Xorg depuis déjà quelques années fonctionne parfaitement en Plug-and-Play sans fichier de configuration sur la majorité des installations. Il saura trouver tout seul les périphériques, les cartes graphiques et les écrans et adapter la définition de l'affichage à chacun. Cependant il s'agit d'une configuration "par défaut" qui ne conviendra pas toujours à l'utilisateur, surtout s'il est un peu geek et qu'il a des lubies bizarres. Dans ce cas, la configuration manuelle (ou semi-manuelle) est inévitable. (attention, on perd dans ce cas cette "adaptabilité" automatique proposée par X)

L'objectif de cette section sera donc de définir les "seats" et leurs périphériques associés.

Pour générer un template de configuration j'ai utilisé Xorg -configure afin d'avoir déjà de nombreuses valeurs pré-remplies. J'ai ensuite largement modifié certaines directives et les ai réparties dans des fichiers séparés pour améliorer la lisibilité et la maintenance.

 

Avant de commencer, il est indispensable de connaître un minimum la structure des fichiers de configuration de Xorg (voir ici et ici). Je dois dire que j'ai beaucoup appris de cette expérience car jusqu'ici je n'avais eu qu'à modifier quelques lignes bien précises (remplacer un driver par un autre, ajouter des options au clavier, etc.).

Un schéma qui résume par ailleurs très bien les sections de configuration est disponible dans la doc de Fedora :

Une configuration multiseat sous GNU/Linux

Je ne vais pas paraphraser la page de documentation (qui est très bien faite d'ailleurs) mais sachez juste que j'ai dû créer un ServerLayout par seat.

J'ai regroupé les directives définissant chaque seat dans un fichier dédié. Je parlerai désormais de seat principal ("Main", bureau) et secondaire ("Aux", canapé).

ServerLayout "Main"

Les directives suivantes ont été placées dans le fichier /etc/X11/xorg.conf.d/50-serverlayout-main.conf

Section "ServerLayout"
    Identifier     "Layout-Main"
    Screen         "Screen-Main" 0 0
    InputDevice    "Logitech-Illuminated" "CoreKeyboard"
    InputDevice    "Logitech-G100S" "CorePointer"
    Option         "AllowEmptyInput"  "true"
EndSection

Section "InputDevice"
    Identifier     "Logitech-G100S"
    Driver         "evdev"
    
    Option         "Protocol" "auto"
    Option         "Device" "/dev/input/by-id/usb-Logitech_G100s_Optical_Gaming_Mouse-event-mouse"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
    Option         "GrabDevice" "on"
EndSection

Section "InputDevice"
    Identifier     "Logitech-Illuminated"
    Driver         "evdev"
    
    Option         "XkbLayout" "fr"
    Option         "XkbModel" "pc104"
    Option         "Device" "/dev/input/by-id/usb-Logitech_Logitech_Illuminated_Keyboard-event-kbd"
    Option         "GrabDevice" "on"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Samsung"
    ModelName      "Samsung SyncMaster 2433"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 60.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Samsung"
    ModelName      "Samsung SyncMaster 2333sw"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 60.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "NVIDIA-GTX760"
    Driver         "nouveau"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 760"
EndSection

Section "Screen"
    Identifier     "Screen-Main"
    Device         "NVIDIA-GTX760"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Il y a donc une section par composant matériel (InputDevice, Monitor, Device), puis un couple carte graphique/moniteur pour former un écran (Screen) et enfin un agencement d'affichage qui utilise les briques précédentes (ScreenLayout). Le diagramme ci-dessous résume cette configuration de manière un peu plus graphique :

Une configuration multiseat sous GNU/Linux

Les points à noter :

  • section Screen : seul un moniteur est déclaré ("Monitor0"). En fait j'ai réalisé de nombreux tests infructueux avant d'opter pour cette configuration. La configuration en dual-screen sera appliquée une fois la session du DE lancée via xrandr (voir paragraphe plus loin). Sur l'écran de login, les deux moniteurs afficheront donc la même image en mode "clone".
  • section ServerLayout : la directive AllowEmptyInput a été ajoutée au départ, car si les périphériques utilisés par le seat ne sont pas disponibles/initialisés quand le serveur X se lance, le démarrage échoue. Nous verrons plus loin qu'après la mise en place des dépendances via udev/systemd ce cas ne peut normalement plus se produire, mais j'ai malgré tout conservé cette ligne.
  • sections InputDevice : par rapport à une configuration automatique j'ai renseigné précisément les périphériques à utiliser, et pour cela j'ai utilisé leurs alias disponibles dans le pseudo-système de fichiers /dev/input/by-id/*. Comme ces périphériques apparaissent souvent sous la forme de plusieurs entrées, il faut les essayer une par une si les noms seuls ne permettent pas de déterminer laquelle utiliser.


Exemple sur ma machine :

$ ls -l /dev/input/by-id/
lrwxrwxrwx 1 root root 10 29 juin 21:13 usb-Logitech_G100s_Optical_Gaming_Mouse-event-mouse -> ../event21
lrwxrwxrwx 1 root root 9 29 juin 21:13 usb-Logitech_G100s_Optical_Gaming_Mouse-mouse -> ../mouse0
lrwxrwxrwx 1 root root 10 29 juin 21:13 usb-Logitech_Logitech_Illuminated_Keyboard-event-if01 -> ../event20
lrwxrwxrwx 1 root root 10 29 juin 21:13 usb-Logitech_Logitech_Illuminated_Keyboard-event-kbd -> ../event19
lrwxrwxrwx 1 root root 10 30 juin 19:42 usb-Logitech_USB_Receiver-if02-event-mouse -> ../event22
lrwxrwxrwx 1 root root 9 30 juin 19:42 usb-Logitech_USB_Receiver-if02-mouse -> ../mouse1
  • À cela j'ai dû ajouter la directive "GrabDevice" qui, comme l'indique le commentaire, empêche les événements émis par le périphérique concerné d'être interceptés par les autres ServerLayout en empêchant un autre pilote d'initialiser le périphérique et d'envoyer les événements aux fichiers périphériques /dev/mice et /dev/kbd. Je présume que cette ligne est nécessaire pour "contrer" le fonctionnement Plug-and-Play de Xorg/evdev (un même périphérique pouvant être contrôlé par deux pilotes différents - ou deux instances du même pilote - pour deux utilisations complémentaires).
     

ServerLayout "Aux"

Pour le second ServerLayout, on reprend le même principe avec des composants matériels différents.

Les directives suivantes ont été placées dans le fichier /etc/X11/xorg.conf.d/51-serverlayout-aux.conf

Section "ServerLayout"
    Identifier     "Layout-Aux"
    Screen         "Screen-Aux" 0 0
    InputDevice    "K400r-keyboard" "CoreKeyboard"
    InputDevice    "K400r-keyboard-multimedia" "SendCoreEvents"
    InputDevice    "K400r-mouse" "CorePointer"
    Option         "AllowEmptyInput"  "true"
EndSection

Section "InputDevice"
    Identifier     "K400r-mouse"
    Driver         "evdev"
    
    Option         "Protocol" "auto"
    Option         "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-if02-mouse"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
    Option         "GrabDevice" "on"
EndSection

Section "InputDevice"
    Identifier     "K400r-keyboard"
    Driver         "evdev"
    
    Option         "XkbLayout" "fr"
    Option         "XkbModel" "pc104"
    Option         "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse"
    Option         "GrabDevice" "on"
EndSection

Section "InputDevice"
    Identifier     "K400r-keyboard-multimedia"
    Driver         "evdev"
    
    Option         "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse"
    Option         "XkbModel" "evdev"
    Option         "GrabDevice" "on"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Compaq"
    ModelName      "Compaq Q2159"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 60.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Intel-I915"
    Driver         "intel"
    VendorName     "Intel"
    BoardName      "Intel IGP"
    BusID          "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier     "Screen-Aux"
    Device         "Intel-I915"
    Monitor        "Monitor1"
    DefaultDepth    24
EndSection
Une configuration multiseat sous GNU/Linux

La configuration ressemble énormément à la précédente (on retrouve notamment la directive "GrabDevice") sauf sur un point :

  • une section InputDevice supplémentaire permet de déclarer le périphérique système à utiliser pour gérer les touches multimédia du clavier (grâce à l'option "Xkbmodel evdev"). Celle-ci est nécessaire car autrement rien ne détectait cette capacité et le volume n'était pas ajustable depuis le canapé (un comble !). Ici le nom défini par udev n'est pas explicite et il faut y aller à tâton pour trouver la correspondance de chaque fichier présent dans /dev/input et son utilité.

Le fichier /etc/X11/xorg.conf.d/10-evdev.conf fourni avec la distrib est conservé et n'a pas été touché. Au départ je l'avais commenté mais il semblerait que ce soit lui qui permette d'utiliser les touches multimédias du clavier du seat Main (donc très important !).

Configuration du gestionnaire de bureau

 

 


EDIT 14/10/2014

Attention : cette méthode ne fonctionne plus depuis très récemment sous Archlinux car la définition des seats se fait désormais avec logind. Je laisse le paragraphe ci-dessous car il restera probablement d'actualité pendant encore quelques mois pour de nombreuses autres distributions moins "cutting-edge".

Je n'ai pas encore la procédure pour configurer le multiseat avec logind, malheureusement...


 

Xorg étant configuré, ce n'est pas pour cela que tout va fonctionner tout seul (oh non, loin de là...). Il faut à présent configurer le gestionnaire de session pour qu'il instancie les 2 seats au démarrage. J'ai choisi d'utiliser Lightdm qui est particulièrement bien adapté au multiseat (GDM était également compatible avant, puis - comme le reste de Gnome... - il y a eu quelques régressions qui font qu'il est préférable de l'éviter pour cette utilisation pour le moment).

On éditera donc le fichier /etc/lightdm/lightdm.conf :

[LightDM]
minimum-vt=1
run-directory=/run/lightdm

[SeatDefaults]
greeter-session=lightdm-gtk-greeter
greeter-show-manual-login=true
session-wrapper=/etc/lightdm/Xsession
pam-service=lightdm-autologin

[Seat:0]
xserver-command=/usr/bin/X :0 -sharevts
xserver-layout=Layout-Main

[Seat:1]
xserver-command=/usr/bin/X :1 -sharevts -novtswitch
xserver-layout=Layout-Aux

Je n'ai conservé ici que les lignes non-commentées (mais je vous conseille de tout conserver dans votre fichier au cas où !).

Les points clés ici sont évidemment les deux sections [Seat:0] et [Seat:1] respectivement pour la configuration des seats Main et Aux.

En ce qui concerne les options -sharevts et -novtswitch je ne me hasarderai pas à donner des explications que je ne pourrais justifier. Je me suis longuement documenté à leur sujet et la seule configuration fonctionnelle que j'ai trouvée (celle ci-dessus donc) est justement celle qui est marquée à plusieurs reprises comme à éviter dans les notes du wiki d'Archlinux et sur la plupart des sites que j'ai consultés (Gentoo, Ubuntu, etc.).

Normalement à partir de ce moment, si je relance Lightdm je vois apparaître les deux écrans de sessions sur les trois moniteurs. Et si je manipule la souris du seat Main, le curseur reste immobile sur le seat Aux, et vice-versa. Je peux me logger sur l'une des sessions sans toucher à l'autre et... ah non je ne peux pas me logger avec le même utilisateur sur l'autre. Comme je l'ai dit au début, il faut créer un utilisateur dédié. On pourra ensuite se logger avec sans problème. Mon seat Aux étant prévu pour paresser depuis le canapé, je l'ai appelé couchy. Je ne détaillerai pas ici comment ajouter un utilisateur, il existe des interfaces graphiques ou des petites lignes de commande pour ça.

 

Une fois la session démarrée, tout n'est pas encore parfait : sur mon dual-head, les moniteurs sont par exemple inversés. Or, je tiens à conserver mon moniteur de droite comme écran primaire (simplement parce qu'il est en face de moi en réalité), et celui de gauche comme écran secondaire. Pour cela c'est très simple, il suffit de lancer la bonne commande utilisant xrandr à l'ouverture de la session.

Pour savoir qu'elle est cette commande et si "man xrandr" est un peu indigeste, on peut utiliser arandr, une application graphique similaire au gestionnaire d'affichage de Gnome ou de Windows, permettant de placer à la souris les écrans l'un par rapport à l'autre. Il est ensuite possible d'enregistrer l'agencement directement sous forme de script shell dans son dossier personnel (par exemple), puis d'ajouter l'entrée correspondante dans les programmes lancés au démarrage. Sur XFCE, c'est dans "Session et démarrage".

L'application de configuration d'affichage arandr

L'application de configuration d'affichage arandr

Dans mon cas, le contenu du script shell ressemble à ceci :

xrandr --output DVI-D-0 --mode 1920x1080 --pos 0x0 --rotate normal --output HDMI-0 --off --output DVI-I-1 --mode 1920x1080 --pos 1920x0 --rotate normal --output DVI-I-0 --off --output DP-1 --off --output DP-0 --off

(remarque : c'est une unique commande, donc sur une seule ligne)

Ça c'est pour ma session Main, avec le dual-head. Mais il y a aussi quelques ajustements à faire côté canapé avec la session Aux. Le principal est surtout d'adapter le zoom, enfin, plutôt la taille des polices d'affichage et des éléments d'interface. En effet, avec mon petit 22", à deux mètres de distance les textes ne sont plus lisibles. L'avantage d'avoir un utilisateur dédié est de pouvoir gérer ce type de préférences sans risquer de provoquer des effets de bord sur l'utilisateur principal. Chacun gère son affichage et ses préférence de bureau à sa sauce. SUr XFCE, cela se configure notamment dans Paramètres > Apparence.

Une configuration multiseat sous GNU/Linux

Configuration de Pulseaudio

La partie affichage étant réglée, on va tester si la lecture de vidéos passe bien sur le seat Main.

Pas de problème ? Parfait.

La même chose côté Aux à présent.

Ah la vidéo s'affiche bien mais aucun son ne sort ? Eh oui, c'est bien le problème.

 

Les systèmes Linux utilisent depuis déjà pas mal de temps maintenant un (nouvel) intermédiaire logiciel pour la gestion du son qui, comme systemd, a subit les foudres de nombreux libristes au début de son adoption par les différentes distributions (tiens, d'ailleurs c'est le même auteur ^^).

Je passe rapidement car ce n'est pas le propos ici mais ALSA (et OSS avant lui) s'impose comme intermédiaire de la carte son (d'UNE carte son à la fois). Tout programme souhaitant l'utiliser doit donc collaborer avec ALSA qui va assurer le mixage matériel ou logiciel, permettant à plusieurs applications de lire par exemple chacune du son en parallèle.

Cependant, ALSA n'est disponible que sous Linux, ce qui peut être limitant lorsqu'on essaye de créer des applications multimédia multi-plateformes. Il ne bénéficie pas non plus de capacités avancées de mixage, de flux de sortie (réseau par exemple) et de contrôle de volume par application, bref des choses qui s'il y a quelques années seraient apparues comme des fonctionnalités de niches, sont aujourd'hui beaucoup plus abordables (et abordées) grâce à la multiplication des matériels existants (que ce soit les appareils mobiles ou les équipements home-cinema).

Pour tout cela il y a donc Pulseaudio, qui vient grossièrement s'intercaler entre ALSA et les applications, afin d'y ajouter les fonctionnalités avancées dont ALSA manque cruellement. C'est bien une chance pour moi car c'est exactement ce dont j'ai besoin pour ma configuration multi-seat (en tout cas cela permet une gestion assez fine de celle-ci).

Pour plus d'infos (en anglais) et sûrement moins de bêtises que je n'en dis : http://tuxradar.com/content/how-it-works-linux-audio-explained

 

Mais pour le moment, Pulseaudio dans sa configuration par défaut m'empêche purement d'atteindre mon objectif, à savoir pouvoir utiliser la même carte son depuis mes deux seats. Pulseaudio est en effet lancé lors de l'ouverture de la session (ici XFCE) et accapare la carte son de manière à être sûr qu'ALSA (et donc les applications) passe par lui. Une carte son virtuelle est ensuite mise à disposition d'ALSA qui peut faire son travail. Le problème est qu'ici Pulseaudio est lancé avec l'utilisateur de la session, sur lequel l'autre utilisateur n'a pas la main. La première session ouverte sur la machine verrouille donc la carte son et l'autre ne peut tout simplement pas l'utiliser.

Avant d'aller plus loin je précise qu'il est possible d'utiliser la fonctionnalité de "carte son distante" offerte par Pulseaudio pour mettre le serveur de son à disposition de l'autre utilisateur par le réseau. Cela fonctionne, mais pour que la configuration soit stable il faut forcément que l'utilisateur configuré pour gérer la carte son soit toujours préalablement loggé. Enfin bref, c'est un merdier pas possible, je vous demande pas de retenir ce genre de détail (mais je tiens à signaler que je m'y suis essayé et cassé les dents, à bon entendeur).

Diagramme de l'architecture de Pulseaudio, By Pulseaudio-diagram.svg / Pulseaudio-diagram.png: Manuel Amador Briz derivative work: Tsaitgaist (talk) (SVG Version) derivative work: Emeric Grange (French version) (Pulseaudio-diagram.svg) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Diagramme de l'architecture de Pulseaudio, By Pulseaudio-diagram.svg / Pulseaudio-diagram.png: Manuel Amador Briz derivative work: Tsaitgaist (talk) (SVG Version) derivative work: Emeric Grange (French version) (Pulseaudio-diagram.svg) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Non ce qu'il faudrait, c'est un daemon système et non de session.

Un serveur Pulseaudio qui serait lancé au boot avec des droits adaptés et auxquel les applications de différentes sessions se connecteraient pour utiliser la carte son chacune de leur côté avec les mêmes droits. C'est le principe de Pulseaudio en mode système, une configuration qui présente des limitations et des risques pour la sécurité mais qui est ici tout indiquée, et pour laquelle il n'y a encore aucune alternative (à ma connaissance).

Sur Archlinux, le plus simple est d'installer le package AUR permettant d'activer le mode système pour PA. Celui-ci  installe notamment un fichier de configuration pour systemd et crée  l'utilisateur dédié que Pulseaudio utilisera (on va quand même pas le  faire tourner en root !). Lors de mes bidouillages je ne l'ai découvert qu'après et ai donc perdu beaucoup de temps, bien que cela m'ait servi à comprendre un peu le fonctionnement de l'ensemble...

Pour l'installer facilement :

$ yaourt pulseaudio-systemd

On a ensuite un utilisateur pour le daemon système de PA :

$ tail -1 /etc/passwd
pulse:x:619:618:PulseAudio:/var/run/pulse:/bin/false

Ainsi qu'un groupe correspondant pour cet utilisateur, et un groupe supplémentaire dans lequel nous placerons les utilisateurs autorisés à accéder au daemon, c'est-à-dire ceux souhaitant émettre du son : pulse-access.

$ tail -2 /etc/group
pulse:x:618:
pulse-access:x:617:
# usermod -a -G pulse-access nanawel
# usermod -a -G pulse-access couchy

Si on veut que le dameon soit lancé au boot, il vaut mieux le dire :

# systemctl enable pulseaudio.service

 

À ce stade il vaut mieux rebooter pour repartir sur une base saine, ou au moins déconnecter les sessions courantes ayant lancé PA et lancer le nouveau daemon manuellement :

# systemctl start pulseaudio.service

Si tout va bien - et grâce à ce package AUR qui fait une bonne partie du travail pour nous - il suffit d'ouvrir à nouveau une session avec les deux utilisateurs précédents pour pouvoir lire simultanément deux fichiers audio sur chacune des sessions.

L'utilisation de Pavucontrol depuis l'une ou l'autre permet ensuite de régler finement le volume de chacune des applications (et là, merci Pulseaudio).

Si après un reboot il n'y a plus du tout de son, alors cela signifie peut-être que vous en avez une grosse comme moi (de configuration matérielle - merci le Core i7 et le SSD) et que le boot orchestré par systemd est trop rapide pour laisser le temps à la carte son de s'initialiser. Lisez alors le paragraphe "Configuration de udev/systemd" plus bas.

Pour les raccourcis clavier à présent, c'est un peu plus la galère, mais pas partout. Sous Gnome normalement aucun problème, les touches sont déjà mappées correctement et fonctionnent bien avec PA (je n'ai pas testé, donc à prendre avec des pincettes). Sous XFCE je n'ai pas réussi à les faire fonctionner en utilisant le package xfce4-volumed-pulse pourtant prévu pour ça.

Le wiki d'Archlinux mentionne les commandes à assigner aux touches pour régles le volume, soit directement celui d'ALSA (bof) soit plutôt celui de Pulseaudio. Mais dans les deux cas, chez moi ça fait que quand je baisse un peu trop le volume, celui-ci se coupe et il me faut passer par Pavucontrol pour le rétablir (aucune touche ne peut plus le débloquer).

Configuration de udev/systemd

Carte(s) son

Après avoir mis en place PA en mode système, il m'a fallu résoudre un autre problème qui m'a paru loin d'être évident au début. J'ai pu constater qu'après chaque reboot je n'avais plus de son. Mais il me suffisait cependant de relancer le daemon de Pulseaudio pour le retrouver.

C'était dû au fait que le temps entre GRUB et l'écran de login était extrêmement court (environ 1 à 2 seconde, ça fait rêver les Windowsiens ^^), grâce notamment à systemd. Mais "grâce" à systemd, ce qui auparavant était séquentiel ne l'est plus. Et l'initialisation des périphériques peut donc également être terminée après... disons par exemple le lancement du gestionnaire de session.

Dans mon cas, le problème était que la carte son était initialisée après le daemon Pulseaudio. Je pensais que c'était une limitation de PA de ne pas pouvoir détecter de périphériques après son lancement, mais en fait je pense qu'il s'agit plus d'une conséquence de la désactivation du chargement de modules à chaud, précaution de sécurité inhérente au mode "système" et présente dans le package pulseaudio-systemd (voir fichier pulseaudio.service).

 

Toujours est-il qu'il est nécessaire de contourner cette limitation. La solution qui m'a été tout simplement proposée par un Archer sur le forum est de définir une dépendance entre la carte son et le daemon PA, et cela au moyen de udev. Le principe est de forcer le daemon a attendre que la carte son soit initialisée avant de se lancer.

Pour cela il faut s'intéresser au fonctionnement des règles udev, un formidable outil que je n'avais jusque-là jamais eu à toucher, bien que j'en ai souvent entendu parler. Ce qui est notamment bien - surtout pour moi ici - c'est qu'il est possible de tagger des éléments du système de manière à pouvoir les identifier dans les unités de systemd.

Je ne vais pas m'étendre sur la syntaxe et les possibilités offertes par le système de règles proposé par udev, il faudrait au moins un article aussi long. Je vais simplement présenter ce que j'ai effectué, et les effets que cela a.

Tout d'abord j'ai créé un fichier de règles /etc/udev/rules.d/99-soundcard-tagging.rules dans lequel j'ai mis la simple ligne :

ACTION=="add", KERNEL=="card*", SUBSYSTEM=="sound", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/sound/devices/$attr{id}"

(toujours une seule ligne, ma colonne n'est pas assez large)

Celle-ci permet, à l'initialisation des périphériques de type carte (card) son (sound) de créer un périphérique virtuel (un alias) au chemin (virtuel)

/sys/subsystem/sound/devices/$attr{id}

$attr{id} est évidemment une variable qui sera évaluée à l'exécution. Pour connaître sa valeur pour ma carte par exemple, il me suffit d'exécuter la commande suivante :

$ cat /sys/class/sound/card0/id
DGX
$ cat /sys/class/sound/card1/id
NVidia

On peut voir ici qu'il y a en fait deux cartes son : une "vraie" (la DGX) et une "fausse" (la sortie HDMI de la carte graphique).

Le chemin virtuel généré par la règle udev sera donc pour la "vraie" carte son :

/sys/subsystem/sound/devices/DGX

Ce qui, selon les règles de de correspondance de nommage de udev/systemd, correspond à l'unité suivante :

sys-subsystem-sound-devices-DGX.device

 

J'ai à présent un moyen sûr d'identifier de manière précise ma carte son comme unité systemd. Il suffit donc à présent d'ajouter la dépendance avec le daemon Pulseaudio.

# mkdir /etc/systemd/system/pulseaudio.service.d
# nano /etc/systemd/system/pulseaudio.service.d/10-wait-for-soundcards.conf
[Unit]
Wants=sys-subsystem-sound-devices-DGX.device
After=sys-subsystem-sound-devices-DGX.device
# systemctl daemon-reload

Et un reboot plus tard : tadaa ! Le boot prend bien deux à trois secondes de plus, mais au moins Pulseaudio détecte bien la carte son !

Lennart Poettering, By ramkrsna (http://www.flickr.com/photos/ramkrsna/2106127348/) [CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Lennart Poettering, By ramkrsna (http://www.flickr.com/photos/ramkrsna/2106127348/) [CC-BY-SA-2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons

Périphériques de saisie

Un autre inconvénient dû à la configuration choisie pour Xorg est qu'il n'est plus possible de se reposer sur l'auto-détection des claviers/souris par le serveur d'affichage. En ayant manuellement assigné (dans les fichiers de configuration pour chaque seat vus plus haut) les claviers et souris à chacun des ServerLayouts, je me suis retrouvé dans la situation où là encore Lightdm/Xorg se lançait avant que les périphériques ne soient initialisés.

Ce qui était frustrant était le côté aléatoire du fonctionnement : parfois après le reboot tout fonctionnait (rarement), souvent il fallait relancer Lightdm depuis une connexion SSH (toujours pas de terminal virtuel je rappelle). Après cela, tout fonctionnait bien jusqu'au prochain reboot.

 

Une fois la source du problème comprise, j'ai simplement réutilisé la même méthode que pour la carte son : j'ai ajouté une règle udev pour tagger les périphériques (une fois ceux-ci identifiés, ce qui n'a pas été sans mal), puis j'ai ajouté une dépendance entre les unités systemd correspondantes et le daemon Lightdm.

La règle udev dans le fichier /etc/udev/rules.d/99-input-tagging.rules :

ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/subsystem/input/devices/$env{ID_SERIAL}"

Ce qui m'a donné les nouvelles unités systemd suivantes, dont les noms sont parfaitement évocateurs :

sys-subsystem-input-devices-Logitech_G100s_Optical_Gaming_Mouse.device
sys-subsystem-input-devices-Logitech_Logitech_Illuminated_Keyboard.device
sys-subsystem-input-devices-Logitech_USB_Receiver.device

Je peux ensuite utiliser ces unités dans le fichier /etc/systemd/system/display-manager.service.d/10-wait-for-input-devices.conf

[Unit]
Wants=sys-subsystem-input-devices-Logitech_Logitech_Illuminated_Keyboard.device sys-subsystem-input-devices-Logitech_G100s_Optical_Gaming_Mouse.device sys-subsystem-input-devices-Logitech_USB_Receiver.device
After=sys-subsystem-input-devices-Logitech_Logitech_Illuminated_Keyboard.device sys-subsystem-input-devices-Logitech_G100s_Optical_Gaming_Mouse.device sys-subsystem-input-devices-Logitech_USB_Receiver.device

J'ai également ajouté une dépendance entre Pulseaudio et Lightdm dans le fichier /etc/systemd/system/display-manager.service.d/10-wait-for-pulseaudio.conf. De cette manière je suis sûr que quand un utilisateur se logge tout est fonctionnel.

[Unit]
Wants=pulseaudio.service
After=pulseaudio.service

Enfin, une dépendance également entre Dbus et Pulseaudio (dans une configuration classique, Dbus est lancé bien avant Pulseaudio, mais ici nous sommes au même "niveau" : celui des daemons systèmes) :

$ ls -l /etc/systemd/system/pulseaudio.service.wants
lrwxrwxrwx 1 root root 36 25 avril 14:13 dbus.service -> /usr/lib/systemd/system/dbus.service

Là normalement, on est paré !

C'est quand on essaye de mettre en place ce genre de configuration qui sort un peu des sentiers battus, qu'on comprend le travail qui a été fait depuis dix ans en termes de "plug-and-playability" sur les environnements GNU/Linux, car avant on pouvait se retrouver à tâtonner autant pour mettre en place un environnement single-seat/single-head tout ce qu'il y a de plus basique...

Résumé

J'ai à présent un système comprenant une UC unique, disposant de deux cartes graphiques : l'une externe (NVidia GeForce 760 sur port PCI-Express), l'autre intégrée au CPU (IGP Intel).

Sur la première j'ai deux moniteurs HD branchés en DVI, sur lesquels j'affiche un bureau étendu pour toutes les tâches usuelles (bureautique, dev, jeu, video, moulage divers) utilisant XFCE.

Sur la seconde, j'ai un unique moniteur HD branché en VGA et accessible depuis le canapé, avec un utilisateur (Linux) dédié, donc un bureau spécifique (mais toujours XFCE). Chaque seat possède son couple clavier/souris propre, ce qui permet d'utiliser chacun d'eux indépendamment (le crash d'un environnement n'entraînant pas l'autre, oui ça arrive...).

 

D'autre part, la carte son de l'UC est partagée entre les deux sessions ce qui me permet de contrôler le son depuis l'un ou l'autre seat de la même manière. C'est un point de la configuration qui peut être facilement adapté dans le cas où chaque seat possède ses propres enceintes/écouteurs.

D'ailleurs, en réalité j'ai volontairement simplifié mes explications car j'ai moi-même deux cartes son : celle intégrée à la carte mère et la carte Asus Xonar DGX (mentionnée dans mon l'article où je présentais ma nouvelle configuration matérielle), mais je n'en utilise qu'une seule 99% du temps. Il est néanmoins très facile grâce à Pulseaudio de rediriger le flux audio d'une application vers l'une ou l'autre carte.

Ma configuration (fonctionnelle !) actuelle

Ma configuration (fonctionnelle !) actuelle

Les bugs et limitations

Oui malheureusement, même après plusieurs jours de batailles et de frustration le résultat est encore loin de la perfection, mais il s'agit d'une bonne base tout à fait utilisable

 Afin d'être tout à fait honnête voici les bugs et les limitations de la configuration présentée. Certains points ne sont néanmoins pas directement liés au multi-seat mais simplement à l'état de l'art sous GNU/Linux...

  • Obligation d'utiliser le pilote Nouveau, ce qui interdit tout jeu 3D gourmand (mais laisse la possibilité d'utiliser Steam avec des jeux plus légers). Aucun problème par contre avec les vidéos HD (y compris 4K).
  • Directement lié au point précédent, le pilote Nouveau plante régulièrement, même si je dois avouer que c'est nettement plus rare depuis quelques semaines (en même temps il est en perpétuelle évolution). Un crash se traduit par un retour à l'écran de login de Lightdm, fermant brutalement les applications de la session en cours, mais sans affecter le second Seat (utilisant lui le GPU Intel). Au départ j'observais en moyenne un à deux crashs par jour, mais il s'agit à présent plutôt d'un à deux crashs par semaine maximum.
  • Malgré les règles udev mentionnées plus haut, il arrive parfois qu'un ou plusieurs périphériques de saisie ne soient pas détectés après le boot, et donc ne soient pas utilisables, mais c'est très rare (une fois tous les 10-20 reboots peut-être, et encore cela ne m'est plus arrivé depuis un moment).
  • Le combo clavier-touchpad Logitech du canapé a la fâcheuse tendance à devenir inactif, parfois, au bout de plusieurs heures ou jours, ce qui oblige au reboot pour pouvoir l'utiliser à nouveau. Là également c'est très rare et ne m'est pas arrivé depuis plusieurs semaines, mais je préfère le signaler (après, savoir d'où ça vient : noyau, pilotes, connexion sans-fil, USB, etc... aucune idée).
  • La lecture de vidéos sur le moniteur branché sur le GPU Intel affichait jusqu'à très récemment une ligne de tearing très désagréable à 2/3 de la hauteur de l'écran, mais il semblerait que la dernière mise à jour du noyau et des pilotes Intel ait corrigé ce problème. Un bon point s'il persiste !
  • Sous XFCE, le contrôle du volume avec les touches multimédia "coince" le son en sourdine si on abaisse trop le volume. Il n'est ensuite plus possible de le rétablir sans passer par une interface telle que Pavucontrol. C'est un bug qui touche Pulseaudio de manière générale et qui est présent dans de très nombreuses discussions sur le Net...
  • Sur le seat Main, les applications Wine ne sont utilisables que sur l'écran de gauche (alors que les applications de configuration de Wine fonctionnent sur les deux) mais présentent de nombreux artefacts : de gros rectangles noirs apparaissent notamment aux endroits masqués par une fenêtre recouvrante. Le placement de la fenêtre sur l'écran de droite rend les boutons et autres menus totalement insensibles aux clics ou aux touches du clavier. Utilisant un dual-screen sur le PC du boulot avec Archlinux, Mate et les pilotes NVidia, je pense qu'il s'agit d'un problème lié à Nouveau car je n'ai jamais rencontré ce comportement sur cette configuration, mais sans certitude aucune.
Un des glitches des applications Wine...

Un des glitches des applications Wine...

Ceci fait, j'espère que cet article aura pu intéresser les geeks ayant des lubies bizarres et souhaitant s'amuser avec leur matériel flambant neuf (mais hormis le challenge technique, c'est super pratique, faut le relever).

Moi en tout cas  - et rétrospectivement, maintenant que tout fonctionne au poil ! - je dois dire que j'apprécie le résultat. Et lancer un petit XBMC sur le moniteur du canapé reste un plaisir bien sympathique (même si j'utilise plus volontier VLC et SMPlayer depuis Thunar ^^).

 

 

Ah, et pour info, les schémas de cet article (ainsi que du précédent sur les honeypots) ont été créés avec draw.io.

Publié le par Nanawel
Publié dans : #neufbox | #php | #monitoring

Il semblerait que SFR soit en train de déployer une nouvelle version des firmwares des Neufbox 4 vers la version NB4-MAIN-R3.3.10. La procédure est progressive et ne touche pas encore tout le monde, ma box a par exemple été mise à jour mais pas encore celle reliée à mon serveur Sihaya.

Cela a néanmoins suffit à rendre inopérant mon script chargé du monitoring et de la sauvegarde régulière de ma box. En cause : la procédure de login a légèrement changé.

J'ai corrigé mon script en conséquence et la version 1.1 est désormais disponible sur Github. N'hésitez pas à la télécharger dès que le firmware de votre NB4 aura été mis à jour.

Publié le par Nanawel
Publié dans : #linux | #upnp | #réseau

Je suis en train de monter une machine de récupération (Rabban pour ne pas la nommer) qui sera bientôt installée loin du reste de mon cheptel, mais à laquelle je vais devoir accéder à distance plus ou moins régulièrement notamment pour de la maintenance.

J'ai donc installé une bonne Debian Wheezy 7.5 avec SSH, Webmin et Lighttpd+PHP (car l'utilité première sera pour une application PHP). Ce serveur sera derrière une box dont je n'ai pas le contrôle direct, mais qui a par contre - comme c'est le cas par défaut - le service UPnP activé.

Une fois tous les services en place et testés en local, j'ai réfléchi au moyen de les rendre accessibles quand ils seront sur le LAN distant. Pour la problématique de l'adresse/nom de domaine, il existe de nombreux services de DNS dynamiques. Il suffit de faire son choix puis d'installer l'utilitaire de mise à jour automatique associé. Pour le problème de NAT/PAT par contre c'est une autre histoire. Et étant donné que cette box - comme les autres - ne possède pas d'API de contrôle, et que mon API maison est faite pour une Neufbox 4, j'ai pensé que le moyen le plus simple était d'utiliser UPnP.

Commandez l'UPnP avec miniupnpc

J'ai trouvé pour cela MiniUPnP, un petit utilitaire disponible sous Linux, qui plus est dans les dépôts Debian, et dont l'utilisation est archi-simple.

Pour l'installer :

# apt-get install miniupnpc

Puis pour l'utiliser on peut :

  • soit renseigner très précisément les ports externes à ouvrir et la machine de destination (qui peuvent être différents de ceux du serveur),
  • soit utiliser une syntaxe simplifiée permettant d'ouvrir plusieurs ports à la fois en les faisant correspondre obligatoirement avec les ports du serveur.

Exemple pour le premier cas, ouvrir le port TCP 8080 externe vers le port 80 de la machine à l'adresse 192.168.1.200 :

$ upnpc -a 192.168.1.200 80 8080 tcp

Simple non ?

Et il n'y a rien à configurer de plus. La demande est faite automatiquement à la passerelle configurée, soit manuellement, soit par DHCP.

Pour ajouter plusieurs règles de NAT/PAT en une seule fois :

$ upnpc -r 80 tcp 443 tcp 22 tcp

Ici on redirige les ports TCP 80 (HTTP), 443 (HTTPs) et 22 (SSH) vers la machine depuis laquelle la commande a été exécutée.

 

Enfin, pour être sûr que les ports restent ouverts même après une coupure électrique (attention au Restore on A/C Power Loss) ou un reboot de la box, on peut évidemment ajouter un job CRON qui exécutera cette commande régulièrement.

 

Tellement simple mais tellement pratique !