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

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

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 :)

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.

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.

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 :

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.

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

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 ^^)

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 :)

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

Télécharger l'archive du dépôt :

https://github.com/nanawel/Arrakis_404EverGone/archive/master.zip

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.

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.

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 :

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 :

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

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

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

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.

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

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 !

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.

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.

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.

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.

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.

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 !

Un serveur des fois, c'est comme un gosse. Et quand vous lui demandez le soir comment s'est passée la journée, il se peut qu'il vous dise qu'une petite brute a essayé de lui voler son goûter à la récré. Mais la différence majeure c'est que sur un serveur vous le verrez dans les logs, et vous aurez même l'adresse de la petite brute. Pourquoi ne pas alors essayer de l'empêcher de recommencer ?

(bon, comparaison à deux sous en guise d'intro : check)

En lisant les rapports logwatch générés quotidienne depuis mon aggrégateur RSS auto-hébergé, cela fait déjà plusieurs mois que j'ai pu constater que mon port 22 était régulièrement approché par des IP peu recommandables, qui tentaient évidemment d'en profiter pour s'introduire dans le système.

Mais j'y songe, comment lis-je mes rapports logwatch depuis mon aggrégateur RSS vous demanderez-vous peut-être ?

logwatch-rss

J'ai réalisé il y a quelques temps que je consultais plus facilement mon aggrégateur que ma boîte mail, surtout celle du serveur (qui n'est qu'une boîte "système", je n'ai pas encore franchi le pas de l'email auto-hébergé). Je me suis logiquement dit qu'il serait donc plus pratique de "recevoir" via un flux RSS le rapport système généré par logwatch que je consulte tous les jours.

Le principe serait de modifier le job CRON qui exécute la génération afin qu'il écrive le résultat dans un fichier texte dans un dossier dédié en plus de le renvoyer sur la sortie standard (de manière à conserver la réception par mail en parallèle). Un petit script PHP dans le dossier "logwatch-rss" situé dans la racine de mon serveur web va ensuite construire un flux Atom à partir des fichiers texte, permettant leur lecture depuis n'importe quel aggrégateur.

Pour moi qui place les fichiers rapports dans le dossier /var/logwatch-archives, le job CRON devient donc ceci :

20 2 * * * root /usr/sbin/logwatch | tee /var/logwatch-archives/logwatch_$(date +%Y-%m-%d).txt

Le script PHP correspondant est disponible sur mon GitHub. La configuration demandée est minimale : il suffit de préciser le chemin vers le dossier contenant les fichiers textes. Le reste est automatique. Dans mon cas, je peux ensuite vérifier le flux en accédant à la page http://usul/logwatch-rss/. C'est aussi cette adresse que j'ai renseignée dans mon aggrégateur.

Le résultat est le suivant dans mon rsslounge :

(ici on peut voir "localhost" dans l'adresse du flux car évidemment le serveur interrogé est la machine elle-même)

Désormais, lous les matins en consultant mes flux, il me suffit d'ouvrir celui provenant de logwatch-rss pour lire tranquillement le rapport généré.

Ceci fait, revenons au sujet principal.

Le retour de la petite brute

La méthodologie expliquée ici s'inspire fortement de l'article de daemonkeeper.net.

Mon serveur, étant accessible depuis le grand Nain Ternet est - comme toutes les machines dans ce cas - la cible de bots tentant de pénétrer les systèmes un peu trop ouverts dans le but d'en dérober des données ou plus souvent d'en faire des membres forcés d'un botnet. En ce qui me concerne je ne crains pas vraiment les attaques en brute-force car mes mots de passes sont suffisamment complexes, et surtout sont couplés à une politique d'exclusion assez sévère : au bout de 3 essais échoués, l'IP est placée en liste noire pour une heure. Je ne dis pas que ce serait suffisant pour résister à une attaque d'envergure provenant d'IP multiples, mais ici ma modeste machine ne représente un challenge intéressant pour aucun pirate sain d'esprit (à raison), je suis donc plutôt tranquille.

Il reste cependant toujours frustrant de constater ces attaques sans pouvoir rien faire. D'autant que grâce à logwatch et au reverse DNS, j'ai remarqué qu'une majorité d'IP provenait de Chine, d'Europe de  l'Est/Russie et des États-Unis, trois régions du globe dont je n'attends aucune connexion légitime.

Serait-il possible via des règles iptables adaptées d'exclure des plages IP ? Et si oui, où trouver les plages IP correspondant aux pays que je souhaite bloquer ?

Après une rapide recherche, je réalise que je ne suis évidemment pas le seul à m'être posé cette question.

Problème : il n'y a pas une plage d'IP par pays mais de (très) nombreuses, et s'il faut les ajouter sous forme de règles individuelles dans iptables on n'est pas sorti de l'auberge. D'autant que j'apprends qu'iptables n'est pas du tout adapté à ce genre d'utilisation et un nombre important de règles entraîne de forts ralentissement dans le traitement des paquets. L'utilisation d'ipset est suggérée et recommandée. Je me suis donc renseigné sur son utilisation.

Sur Debian Wheezy, il suffit d'installer le paquet éponyme : 

# apt-get install ipset

Le module noyau correspondant est déjà présent, il n'y a rien à faire. Pour Squeeze (et Ubuntu 10.04 chez moi avec Sihaya) il est possible de le compiler et de l'installer séparément, ce qui prend 5 minutes avec module-assistant (les deux commandes permettant de ce faire sont disponibles ici). Attention cependant dans la suite de cet article, vous devrez adapter la syntaxe des commandes ipset car elle a changé entre la version fournie avec Squeeze et Wheezy (man ipset is your friend).

IPDeny : au pays des listes

Tout d'abord il faut récupérer les plages IP des pays que l'on souhaite ajouter aux règles. IPDeny fournit des archives de fichiers "zone" au format texte répondant exactement à ces critères (attention, l'archive all-zones.tar.gz proposée est en fait vide). Après réflexion, plutôt que de constituer une liste noire, j'ai préféré créer une liste blanche de pays autorisés en incluant dans un premier temps tous les pays d'Europe de l'Ouest (où je pourrais potentiellement voyager à moyen terme, il ne s'agirait pas que je me bloque moi-même !).

J'ai téléchargé l'intégralité des fichiers zones disponibles ainsi que le très pratique script aggregate-cidr-addresses.pl (apt-get install perl pour pouvoir l'exécuter évidemment). Une fois tous les fichiers dans un dossier, il permet en effet de fusionner en un fichier unique toutes les lignes de plusieurs zones, tout en fusionnant aussi les plages IP qu'ils contiennent !

Dans mon cas, j'ai copié les fichiers des pays d'Europe de l'Ouest dans un dossier "ipset_whitelist" avec le script.

# ls -1
ad.zone
aggregate-cidr-addresses.pl
be.zone
ca.zone
ch.zone
de.zone
dk.zone
es.zone
fi.zone
fr.zone
gb.zone
gf.zone
gr.zone
ie.zone
is.zone
it.zone
local.zone
mc.zone
nl.zone
no.zone
pf.zone
se.zone

Puis j'ai lancé la fusion :

$ chmod +x aggregate-cidr-addresses.pl
$ ./aggregate-cidr-addresses.pl *.zone > whitelist.zone

Le fichier local.zone (qui n'est pas fourni par IPDeny) contient seulement la zone "locale" et les adresses privées qui font évidemment partie de la liste blanche :

$ cat local.zone
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

J'obtiens un fichier whitelist.zone de 260 ko environ (contre 480 ko pour la somme des poids des fichiers d'origine).

Création de la collection avec ipset

Avant d'ajouter ces plages à ipset, il faut initialiser la collection correspondante et lui donner un nom (j'ai choisi "geowhitelist") :

# ipset create geowhitelist hash:net

On peut vérifier à présent qu'elle existe et qu'elle est vide :

# ipset list geowhitelist
Name: test
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536 
Size in memory: 16760
References: 0
Members:

À présent, pour traiter l'ajout des plages dans ipset et dans le cas où j'aurai cette action à refaire plus tard, j'ai créé un petit script qui prend deux paramètres en entrée : l'identifiant de la collection ipset (IPSET_SET_NAME), et le fichier zone source contenant les plages d'IP (INPUT_FILE). Le script exécute ensuite cette commande pour chaque ligne du fichier : ipset add $IPSET_SET_NAME <plage IP>.

# ./create_ipset_rule.sh geowhitelist whitelist.zone
Updating set "geowhitelist" using "whitelist.zone"
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... [...]
Done.
Set updated successfully (now approx. 16825 lines).

Voici le code source du script en question :

#!/bin/bash
if [ $(whoami) != "root" ]; then
    echo Must be run as root.
    exit 1
fi
if [ -z $1 ]; then
    echo Missing set name
    exit 1
fi
IPSET_SET_NAME=$1
if [ -z $2 ]; then
    echo Missing filename
    exit 1
fi
INPUT_FILE=$2
echo Updating set "$IPSET_SET_NAME" using "$INPUT_FILE"
for cidr in $(cat $INPUT_FILE); do
    ipset add $IPSET_SET_NAME $cidr
    return=$?
    if [ $return != 0 ]; then
        echo
        echo ipset returned $return
        exit 2
    fi
    echo -n .
done
echo
echo Done.
linesCount=$(ipset list $IPSET_SET_NAME | wc -l)
echo "Set updated successfully (now approx. $linesCount lines)."

Le problème avec ipset est que ces collections sont éphémères et ne sont pas restaurées après un reboot. Dans mon cas ce n'est pas critique, mais autant faire les choses bien. Je dumpe donc la collection dans un fichier, lui-même dans un dossier que je crée préalablement :

# mkdir /etc/ipset
# ipset save geowhitelist > /etc/ipset/geowhitelist.set

Puis j'installe le script suivant dans /etc/network/if-pre-up.d/restore-ipset (source originale disponible ici)

#!/bin/sh
# Nanawel 2014-06-02 - Restores ipset rules when eth0 interface comes up
# http://blog.laimbock.com/2013/09/22/how-to-block-countries-with-ipdeny-ip-country-blocks-ipset-and-iptables-on-el6/
set -e
if [ "$IFACE" != "eth0" ]; then
        exit 0
fi
# Only run from ifup.
if [ "$MODE" != "start" ]; then
        exit 0
fi
# load ipset sets from /etc/ipset
# ipset set naming syntax is <setname>.set
find /etc/ipset -maxdepth 1 -type f -iname "*.set" | while read SET; do
    /usr/sbin/ipset restore -! < $SET
    if [ $? -eq 0 ]; then
        logger -t ipset "success: restore of $SET"
    else
        logger -t ipset "fail   : restore of $SET"
    fi
done
exit 0

Note : n'oubliez pas d'adapter le nom de l'interface réseau à votre cas (chez moi c'est eth2 mais j'ai préféré mettre le plus classique eth0 ci-dessus).

Un petit

# chmod +x /etc/network/if-pre-up.d/restore-ipset

pour rendre le script exécutable, et on est bon ! À partir de maintenant, toute collection ipset précédemment enregistrée dans le dossier /etc/ipset avec l'extension ".set" sera chargée lors de l'activation de l'interface réseau eth0.

Configuration de iptables

Nous avons donc une règle ipset qui est capable de distinguer les IP provenant de certains pays. Mais ipset seul ne fait rien, il faut le coupler avec iptables pour pouvoir manipuler le trafic correspondant.

Ma règle sera simple : je vais simplement demander à iptables d'ignorer (drop) toutes les connexions TCP à destination des ports 22, 80 et 443 (soit respectivement SSH, HTTP et HTTPS) dont l'adresse IP source n'appartient pas à la collection "geowhitelist". Pour cela je me place dans la table "filter" et dans la chaîne "INPUT". J'avais déjà utilisé iptables il y a 3 ans pour mettre en place des adresses IP "virtuelles" grâce à NETMAP, mais c'est beaucoup plus simple ici.

# iptables -t filter -A INPUT -p tcp -m tcp -m multiport -m set -j DROP --dports 22,80,443  ! --match-set geowhitelist src

Je détaille pour les deux du fond qui dorment :

Pretty straightforward, isn't it Watson?

Pour vérifier, nous pouvons à présent lister les règles courantes de la table "filter" :

# iptables -t filter -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere            tcp multiport dports ssh,http,https ! match-set geowhitelist src 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

iptables nous remplace en plus gentiment les numéros des ports par leur équivalent en termes de services, plus lisible (voir /etc/services).

Ce résultat est à interpréter selon les règles déjà en place évidemment. Dans le cas où vous avez des règles de filtrage par port, il est nécessaire d'ajouter la règle AVANT celles pouvant exclure ou accepter les paquets correspondants. On utilisera alors à la place la commande d'insertion proposée par iptables ("iptables -I" au lieu de "iptables -A").

Ça y est, la règle est en place, les paquets correspondant aux critères que nous venons de définir sont désormais ignorés par Netfilter. Afin de tester l'efficacité du système, essayez de vous connecter à SSH depuis le réseau local, ou au pire de la machine elle-même : normalement vous n'aurez aucun problème puisque vous êtes dans la "geowhitelist" (rappelez-vous, en plus des pays nous avons aussi ajouté les plages d'adresses privées non-routables sur Internet).

Pour tester à présent que les connexions de la "zone noire" sont bien filtrées, et si vous n'avez pas de machine à disposition depuis un de ces pays, vous pouvez utiliser l'utilitaire nmap en ligne fourni par pentest-tools.com, dont l'adresse IP est apparemment localisée en Roumanie, donc hors de notre "geowhitelist".

Les ports sont bien marqués comme filtrés, preuve que la machine qui a scanné les ports n'a pas trouvé le service tournant réellement derrière.

(Note : ici le port 22 est marqué "open" mais nous verrons cela dans la suite, considérez qu'il est "filtered" lui-aussi)

Mise en place de Kippo avec la geowhitelist

Après la mise en place du filtrage précédent, j'ai pu constater l'efficacité de la technique : les tentatives d'accès frauduleux sur mon serveur ont en effet diminué d'au moins 90%.

C'était bien.

Mais après réflexion, je me suis demandé s'il n'était pas possible de se servir de cette capacité à discerner "le bon grain de l'ivraie" pour s'amuser un peu et observer ce que les attaquants tentent de faire une fois qu'un serveur leur ouvre leurs portes.

Fidèle (petit) lecteur de MISC depuis quelque années et m'étant déjà renseigné sur le sujet, je savais qu'il existait des applications adaptées pour tromper de manière sécurisée les attaquants du réseau : les honeypots, ou "pots de miel" dans la langue de Shakespeare (s'il était né dans le Royaume de France au lieu de cette île froide et humide au nord de l'Europe).

Le terme définit bien sa fonction : attirer les nuisibles en leur offrant un met de choix, de manière à ce qu'ils ne s'intéressent pas à ce qui est vraiment important. Le maître du honeypot a également tout loisir d'observer en toute sécurité les actions de ces nuisibles sans que ceux-ci ne s'en doutent ou ne puissent l'en empêcher. Cela permet de mieux comprendre les techniques d'attaque et de mieux s'en prémunir sur les infrastructures réelles.

L'art du honeypot se décline en plusieurs pratiques. Certaines consistent à monter des machines (virtuelles le plus souvent) possédant une faille de sécurité connue dans un environnement réseau contrôlé. Il peut s'agir d'une faille du noyau, d'un applicatif réseau (Apache, PHP, Tomcat, etc.) ou d'une application web (injection SQL, XSS). Il peut également s'agir de laisser une configuration par défaut un peu trop permissive. Les actions effectuées peuvent alors être générée à partir de captures réseau (Wireshark) et des logs de la machine elle-même, à laquelle on aura ajouté éventuellement des outils adaptés en ce sens.

D'autres pratiques consistent à utiliser un logiciel qui va imiter le fonctionnement d'un applicatif réseau qui va lui-même enregistrer les actions des attaquants. Cet applicatif ressemblera pour l'attaquant au logiciel réel qu'il imite, mais sans la possibilité pour celui-ci de le détourner réellement. Le but est de faire tomber l'attaquant dans le miel, pas de le laisser repartir avec le pot !

Ce qui est le plus divertissant et le plus facile à monter est un honeypot SSH. Divertissant, car il est possible de visionner - en direct ou en différé - les sessions des utilisateurs, c'est-à-dire les commandes tapées et leur retours tel que les voit ceux-ci. Facile, car il existe plusieurs logiciels "prêts à l'emploi" dont il suffit d'extraire l'archive et de lancer le binaire pour qu'il soient opérationnels. Les plus connus sont Kippo et Kojoney. J'ai opté pour Kippo pour la simplicité et le nombre de retours disponibles sur la Toile.

La version "officielle" est disponible sur GitHub mais après un test de quelques jours j'ai décidé d'utiliser à la place celle issue du fork par Michel Oosterhof car celle-ci ajoute notamment le "support" du protocole SFTP. En effet, la plupart des intrusions ne laissaient aucune trace après le login car l'attaquant tentait d'utiliser le SFTP, qui échouait. Il abandonnait donc immédiatement la connexion.

N'oubliez pas d'installer les dépendances requises avant de poursuivre.

Préparons le terrain et installons notre honeypot. Il nous faudra un utilisateur dédié et sans privilèges (disons que c'est quand même préférable !).

# useradd -d /home/kippo -m -s /bin/false kippo
# su -l kippo -s /bin/bash
$ cd
$ git clone https://github.com/micheloosterhof/kippo.git
$ cd kippo

Puis il faut initialiser la configuration à partir du modèle fourni :

$ cp kippo.cfg.dist kippo.cfg

Il est ensuite possible de modifier cette configuration, notamment le port utilisé (par défaut 2222) et le faux nom de la machine.

Dans la version de Michel Oosterhof, un utilisateur "root" est configuré avec le mot de passe "*" qui demande à Kippo d'accepter tous les mots de passe fournis. Cela étant, afin de conserver un comportement "réaliste" et éviter de trop éveiller les soupçons, il est préférable de n'en choisir qu'un parmi la liste des plus basiques (root, 123456, admin, etc.).

Puis pour lancer le service en tâche de fond :

$ ./start.sh

On peut ensuite se déconnecter et le honeypot continuera de tourner, attendant patiemment les connexions sur le port choisi. Attention toutefois, rien ne le redémarre automatiquement en cas de reboot. Vous pouvez alors soit créer un script de démarrage (init.d / rc.d / systemd) ou ajouter un job CRON appelant le script start.sh avec l'utilisateur kippo (@reboot).

Il faut à présent ajouter la règle iptables qui va rediriger les requêtes provenant de pays blacklistés vers le honeypot, tout en laissant évidemment les autres accéder au vrai service OpenSSH qui tourne sur le port 22.

Voici ce que ça donne (ma machine a l'adresse IP 192.168.1.100 sur mon LAN) :

# iptables -t nat -A PREROUTING -p tcp -m tcp -m set -d 192.168.1.100 --dport 22 -j DNAT --to-destination 192.168.1.100:2222  ! --match-set geowhitelist src

Toujours pour les deux du fond :

Comme la chaîne PREROUTING  - de la table "nat" - est exécutée avant la chaîne INPUT - de la table "filter" (voir ci-dessous) - on n'a même pas à modifier la règle ajoutée dans la section précédente. Il n'y aura simplement plus de paquets qui arriveront dans INPUT à destination du port 22 à partir d'adresses IP en dehors de notre geowhitelist (par contre il restera toujours les paquets destinés aux ports 80 et 443 que l'on veut continuer de filtrer).

Le résultat est visible en listant les règles en place sur la table "nat".

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             usul                 tcp dpt:ssh ! match-set geowhitelist src to:192.168.1.100:65022
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

C'est fini ! Il ne reste plus qu'à patienter et consulter régulièrement les logs pour repérer les tentatives d'accès.

L'analyse des logs de Kippo

On trouve tout d'abord les traces complètes dans le fichier log/kippo.log : connexions, commandes envoyées, informations de débogage.

Ensuite, pour chaque accès réussi, un fichier log horodaté est également créé dans log/tty. Celui-ci conserve la trace complète de l'interaction dans un format qu'il est possible de "réexécuter" afin de le visionner. Pour cela on utilisera le script utils/playlog.py comme suivant (depuis le répertoire racine de Kippo) :

$ util/playlog.py log/tty/20140610-125839-2844.log

Le terminal déroulera alors le scénario de la session telle qu'elle a été enregistrée par le honeypot directement dans le terminal. Il s'agit évidemment d'un visionnage qui n'interagit aucunement avec le terminal courant ni la machine réelle, simplement une série de lignes de texte , un peu comme celles qu'on peut trouver sur asciinema.

Les fichiers téléchargés par les attaquants sont quant à eux placés dans le dossier dl/ en racine de Kippo pour une inspection ultérieure. Pour avoir moi-même procédé à une analyse de quelques-uns avec VirusTotal, il s'agit évidemment la plupart du temps de binaires de backdoors pour Linux, en 32 ou 64 bit. Pour la sécurité, Kippo change automatiquement leurs droits en 600, ce qui évite de les exécuter par erreur ! Attention : ClamAV ne les détecte que rarement à ce jour, l'analyse régulière du dossier avec cet antivirus ne remontera donc que rarement une alerte.

Il est possible aisément d'adapter ou compléter votre honeypot en modifiant les fichiers dans le dossier textcmds/ ou en modifiant les fichiers du faux système de fichiers en recréant son image (fs.pickle). Les informations sont disponibles sur le GitHub du projet et un peu partout sur la Toile.

Une dernier conseil : si comme moi vous vous retrouvez avec plusieurs dizaines de tentatives d'accès réussies chaque jour, il est préférable de mettre en place un logrotate sur le fichier log/kippo.log, et de supprimer automatiquement les fichiers téléchargés dans dl/ régulièrement. Il serait dommage que votre honeypot soit à l'origine d'un crash de votre machine réelle à cause du manque d'espace ! Vous pouvez aussi mettre en place un quota pour cet utilisateur, ou monter son dossier home sur un RAMdisk de taille fixe... le choix est large.

Amusez-vous bien :)

Après une courte pause (hem), je reprends le fil du blog et vais tenter d'y poster quelques mises à jour. La raison de cette pause ? Il y en a plusieurs. Mais la principale est résumée ci-après...
 

Après 5 ans de bons et loyaux services, il était temps que mon PC principal (fixe) soit l'objet d'une upgrade conséquente. Sa configuration, achetée principalement au printemps 2009, était la suivante :

• CPU : Intel Core 2 Quad Q8200
• RAM : 4 Go DDR2 Corsair
• Carte mère : Asus P5QL-E
• Cartes graphiques :
  • Asus ENGTX260 (GeForce GTX 260 - 896 Mo RAM)
  • Club 3D GeForce 210
• Carte son : Creative Audigy SE
• Disque système : WD Velociraptor 150Go
• Boîtier : Antec 300
• Alimentation : Cooler Master Silent Pro 700W
• OS : Windows XP 32bit

J'ai retardé autant que possible cette étape car il s'agit évidemment d'un élément clé de mon "cheptel" - comme je l'appelle - et que la réinstallation d'un système et sa configuration aux petits oignons prend souvent plusieurs semaines. Ces dernières années j'ai donc préféré multiplier les machines (de configurations modestes) et y répartir les services plutôt qu'améliorer/remplacer celles existantes. De nombreux articles sur ce blog témoignent d'ailleurs de ces acquisitions et de ces mises en place.

En mars de cette année, j'ai décidé qu'il était temps d'investir, en argent mais surtout en temps, et de remplacer ma machine principale. Je ne me doutais pas encore que pour le second aspect - le temps - je n'allais pas être déçu.

Ce qui m'a poussé à cette décision ?

Facile : en 2014, 2,75 Go de RAM c'est vraiment trop peu. Eh oui car "deux cartes graphiques" signifie "deux fois plus d'adresses réservées aux périphériques", et comme je suis en 32 bit cela se ressent immédiatement sur la quantité de RAM allouable. Avec une carte graphique j'étais déjà limité à 3,25 Go de RAM. En ajoutant la seconde, je perds encore 512 Mo. J'ai cherché longtemps s'il n'était pas possible de limiter cette occupation (inutile en plus), mais je n'ai rien trouvé de probant. Le 32 bit, c'est juste dépassé.

Voici la configuration qui a finalement eu la chance de faire un bon trou dans mon budget annuel :

• CPU : Intel i7 4771
• RAM : 16Go DDR3 Kingston
• Carte mère : Gigabyte GA-Z87-D3HP
• Carte graphique : MSI GeForce 760 (2 Go RAM)
• Carte son : Asus Xonar DGX
• "Disque" système : SSD Intel 530 Series 240Go (et Velociraptor recyclé pour Windows)
• Boîtier : Fractal Design Define R4
• Alimentation : LDLC QS-550+ (80+ Gold)

Les lecteurs de Canard PC Hardware retrouveront des références plébiscitées par ce magazine, et pour cause, je l'ai longuement consulté avant de faire mes choix.

Pour le CPU, je souhaitais quelque chose de costaud, quad-core obligatoirement, et peu m'importait qu'il soit "OC-ready" (le fameux "K" en suffixe) puisque je n'overclocke jamais mon matériel, la stabilité étant largement plus importante pour moi que les performances brutes (et puis à mon avis cela fait longtemps que l'overclocking a perdu de son intérêt). S'il y a 10 ans j'étais un inconditionnel d'AMD - même quand certains modèles étaient inférieurs à Intel - j'ai retourné complètement ma veste depuis la sortie des Core iX d'Intel.

Pour la RAM, je sais que 8 Go sont souvent suffisants pour la plupart des tâches, mais mon PC au boulot (tournant sous Archlinux) étant lui aussi équipé de 16 Go, j'ai souvent pu apprécier une quantité aussi importante pour du multitâche lourd couplé à l'utilisation de machines virtuelles. Alors j'ai dit "Banco !".

Pour la carte mère, le point important a été le nombre, le format et la disposition des ports PCI-Express et PCI. Étant plutôt un habitué d'Asus, j'ai cependant décidé de passer à Gigabyte sur l'influence de mes lectures magazinesques. Je ne sais pas aujourd'hui encore si je dois le regretter, mais j'y reviendrai.

Pour la carte graphique, je voulais quelque chose de puissant, mais au tarif "raisonnable". La GeForce 760 est le compromis proposé par Canard PC et pour lequel j'ai opté. Il fallait simplement qu'il y ait 2 Go de RAM embarqués, car j'ai vu avec ma précédente carte qu'ils étaient réellement utiles, contrairement à ce que l'on peut penser de prime abord (non ce n'est pas QUE du marketing). Pour le fondeur, et contrairement à Intel/AMD, ma position n'a pas bougé d'un pouce par rapport à il y a 10 ans : entre NVidia et ATI AMD, et tant que leurs pilotes Windows ET Linux ne seront pas meilleurs, je ne prendrai pas d'AMD (bien que cela soit en train de changer depuis quelques mois).

Même si les chipsets "son" intégrés aux cartes mères se sont largement améliorés depuis 10 ans, je continue à utiliser une carte son séparée, qui offrira souvent un meilleur rendu et un son plus propre (souvent avec moins de bruit de fond). En 2009, Creative était la seule marque à proposer une référence au rapport qualité/prix correct dans l'entrée de gamme. Aujourd'hui la donne a un peu changé et c'est Asus qui concurrence désormais fortement la marque historique (ah, la Sound Blaster 64...), autant en entrée de gamme que sur du matériel destiné à un public audiophile (que je ne suis pas).

Pour le disque système, si en 2009 le monde des SSD en était à ses balbutiements, tant au niveau des performances, du prix au Go que de la fiabilité (ce qui m'a incité à opter à la place pour un disque dur en 10 000 tpm), il est impensable aujourd'hui de penser monter une configuration sans utiliser la fameuse mémoire Flash au moins pour la partition système. Malgré ses prix un peu supérieurs à la concurrence, Intel fait figure de référence en termes de fiabilité (merci CPC). C'est donc avec un modèle relativement généreux de cette marque que j'ai décidé de me lancer.

L'alimentation devait ensuite être choisie en connaissance de cause. En 2009 - alors que la rédaction de Canard PC préparait le premier numéro de leur série "Hardware" - je m'étais bêtement fait avoir par les tests trouvés ça et là sur le Net, et j'avais opté pour une Cooler Master de 700W. Quand j'ai lu le test de cette même alimentation plus tard dans le magazine, j'ai un peu déchanté. Déjà, 700W sont parfaitement inutiles car la configuration ne dépassait pas les 400W (j'ai pu le vérifier moi-même avec mon Conserve Insight), mais en plus la belle réputation de Cooler Master n'est clairement pas justifiée sur tous les modèles, et celui-là peinait à légitimer son tarif (test de la version 500W sur x86-secrets). J'ai donc pris le meilleur rapport qualité-prix du moment conseillé par CPCH (conception Seasonic inside).

Enfin, pour enrober toute cette électronique, et sachant que j'allais conserver l'ancienne configuration quasi-intacte en parallèle (au moins au début), j'ai également choisi un boîter plus "actuel" (comprenant notamment des emplacements adaptés pour les SSD ou disques 2,5"), plus vaste également, et surtout mieux conçu. J'ai donc répondu à l'appel de l'acier suédois avec le Define R4 de Fractal Design, une grosse bête de plusieurs kilos à vide, solide, sobre et au cable management sans faille... mais au tarif raisonnable ! (Pour info, seule la conception est suédoise évidemment, ça reste du "Made in China"...)

C'est un détail mais j'ai également acheté un graveur Blu-ray et un lecteur multi-cartes USB 3, même si je ne pressens pas les utiliser tous les jours... Enfin bon, ça peut servir.

Après commande chez un e-commerçant à quatre lettres et particule, j'ai réceptionné deux énormes (et lourds) cartons contenant les précieuses pièces du puzzle que j'envisageais de monter.

Et pour cela j'ai pris mon temps. Le montage a été facilité par la conception du boîtier, largement meilleure que celle de mon Antec 300 de 2009 (elle-même à des années lumière de celle de mon "Phoenix" avec alimentation Heden intégrée du début des années 2000...). Ce Define R4 est imposant et difficile à manipuler, mais il faut avouer que question lisibilité et accessiblité de l'ensemble quand on le remplit de cartes, de lecteurs et de disques, l'espace interne qu'il nous offre est bien appréciable. J'anticipe un peu, mais le silence qu'il procure est également un must (oui là je l'avais pas encore allumé hein...).

Une fois la machine complétée, est venu le temps de la mise en marche. Hormis la LED de façade que j'avais branchée à l'envers (évidemment) et la nécessité d'accuser le coup de l'absence volontaire de LED d'activité des disques sur ce modèle (une honte), tout semblait bien fonctionner et j'ai pu découvrir le fameux UEFI dont les journaux parlent tant.

Oui, le seul UEFI que j'ai pu manipuler est celui du PC de mon boulot, car aucune des machines chez moi ne possédait ce... "progrès". Je sais, le BIOS est un héritage d'une époque révolue et il faisait depuis longtemps plus de mal que de bien. Mais bon, chacun a droit à son côté "vieux con" hein :)

Hormis le fait que beaucoup de réglages sont accessibles à plusieurs endroits du setup ce qui donne un faux sentiment de "configurabilité", et que la souris est évidemment utilisable ce qui rend probablement l'interface plus accessible au quidam moyen (alors que personnellement je trouve que la sensibilité et le délai de réaction épouvantables de celle-ci interdisent simplement une utilisation confortable), on se retrouve bêtement devant un BIOS à l'affichage un peu plus fin que dans les années 90. J'ai d'ailleurs eu tôt fait d'activer l'option "Mode BIOS" pour retrouver une navigabilité familière (et fluide) au clavier.

Mais je n'ai pas encore abordé un point important... Quel OS allait se retrouver sur cette bête de combat ?

Après avoir longtemps, très longtemps utilisé Windows sur ma machine principale (et désormais, plus seulement que sur celle-ci d'ailleurs), je tenais à passer le dernier (premier ?) élément de mon cheptel sur l'OS au manchot. Néanmoins, je sais d'expérience que le pilote NVidia n'est pas exempt de bugs qui interdisent certaines utilisations un peu poussées. Je sais également que le pilote "Nouveau", s'il évolue rapidement, n'est malheureusement pas encore suffisant pour exploiter à 100% les ressources des derniers GPU. Je reste enfin un joueur occasionnel qui apprécie les graphismes tape-à-l'oeil et les shaders chatoyants proposés uniquement sur des jeux nécessitant Windows. Il me faudrait donc l'OS à la fenêtre, mais en dual-boot bien sûr car je ne l'utiliserai que comme OS "de console".

J'ai donc installé Windows 7. En premier évidemment, car puisque lui se considère comme le seul OS de la machine et qu'il n'hésite pas à écraser les colocataires s'il y en a, je ne tenais pas à devoir refaire plusieurs fois les installations (et ça économise les puces du SSD ! ^^). Ah oui, j'ai choisi pour cette machine (puisque c'est un choix à présent) d'utiliser le mode "Le futur c'est maintenant", c'est à dire UEFI+GPT.

Tout allait bien jusqu'à l'installation des pilotes graphiques (240 Mo le fichier du pilote, ça reste hallucinant quand on a connu les années 1990). À partir du premier redémarrage, j'ai profité enfin d'une résolution HD. Mais pas longtemps. l'affichage était instable, constamment entrecoupé de noirs, puis il m'a été difficile de me logger sur ma session. Une fois le bureau apparu j'ai rapidement vu s'afficher en boucle la bulle "Le pilote d'affichage ne répondait plus et a été récupéré". AÏeeeuuhhh.

J'avais l'impression de revenir en 2000 en train d'essayer de faire fonctionner ma GeForce 256 (Guillemot) avec ma Sound Blaster Live! 1024 de Creative. De mémoire de geek c'est la seule fois que j'ai pu voir de mes yeux une réelle et méchante incompatibilité matérielle. Jamais pu les faire fonctionner ensemble, et pourtant j'en ai passé du temps. Enfin bon, c'était une autre époque, Windows 98 tout ça...

Et puis la machine a freezé. Simplement.

C'était pas bon signe, mais bon, je ne connaissais pas encore le matériel, et je savais qu'avant de désespérer il y avait encore le grand Google pour m'aider. J'ai fait quelques recherches, j'ai exploré le setup du BIOS/UEFI afin de vérifier que tout était configuré en "stabilité maximale", mais après plusieurs reboot j'avais toujours ces problèmes qui revenaient.

Oh et puis Windows, va brûler en Enfer, je vais installer une bonne Archlinux et tout va rouler, je résoudrai ce problème plus tard.

Pour Linux, j'ai suivi scrupuleusement le wiki (toujours aussi appréciable) en m'aidant parfois du forum pour quelques détails. J'avoue ne pas être encore à l'aise avec UEFI+GPT que j'ai du mal à voir encore autrement que comme des technologies "jeunes", avec tout ce que ça a de péjoratif (faut dire aussi que BIOS+MBR sont là depuis 30 ans aussi...). Point important : le fait d'avoir choisi de séparer physiquement le disque Windows du disque - enfin, du SSD - Linux s'est révélé sécurisant, j'ai eu moins peur dans la suite des opérations d'altérer l'un avec l'autre.

Le processus d'installation depuis la session live n'a présenté aucune instabilité particulière, ce qui m'a bien rassuré. J'ai eu juste un comportement bizarre où le noyau n'a pas voulu me détecter le chipset Ethernet, même après avoir ajouté le module ad hoc. Finalement, après plusieurs manipulations j'ai enfin pu avoir une adresse attribuée par DHCP pour installer le système de base.

J'ai ensuite toujours suivi les instructions pour installer le bootloader (ici GRUB2), et une fois redémarré, j'ai pu constater que j'avais bien le menu qui s'affichait. Par contre il manquait l'entrée correspondant à Windows. En cherchant un peu, j'ai trouvé comment la rajouter simplement, en ajoutant dans le fichier /etc/grub.d/40_custom un bloc "menuentry" de manière à obtenir le contenu suivant :

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.


menuentry "Windows 7" {
        insmod part_gpt
        insmod chain
        set root='(hd6,gpt1)'
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Il m'a juste fallu déterminer le numéro du disque : ici hd6. C'est en fait le port SATA sur lequel celui-ci est branché sur la carte mère.

Une regénération du menu de GRUB2 plus tard

# grub-mkconfig -o /boot/grub/grub.cfg

et tout était rentré dans l'ordre.

Un terminal c'est bien, mais cela manque de couleurs... entre autres choses. Il me fallait maintenant ajouter un gestionnaire de bureau.

J'apprécie Gnome-Shell pour une utilisation ludique, j'avoue avoir du mal à le considérer comme un environnement productif, surtout quand les extensions cassent et les applications changent d'apparence à chaque mise à jour.

J'utilise Mate au boulot (le fork de Gnome 2) et reste assez fan de ses interfaces sobres et efficaces. Mais j'avais testé récemment une Xubuntu et plus récemment encore une Manjaro (fork d'Archlinux pas très apprécié des "vrais" Archers) et j'avoue que les dernières versions de XFCE sont vraiment très agréables à utiliser et en plus très esthétiques dès qu'on y installe un thème et des plugins adaptés (merci Whisker). Je dis banco pour XFCE. J'installerai de toute manière Gnome 3 et Mate, après tout il ne s'agit que d'un choix au moment du login.

Meta-packages aidant, le tout est installé en 30 minutes : environnement de bureau (XFCE donc), gestionnaire de login (GDM) et pilotes graphiques (pilotes proprios NVidia, pour commencer). Un reboot plus tard et j'obtiens l'écran de login - gris et moche - de GDM. Et là, je sens de suite qu'il y a quelque chose de pas normal non plus. Des artefacts apparaissent à l'écran, le curseur tressaute, les animations sont saccadées.
 

Je parviens malgré tout à me logger mais le bureau n'est - cette fois sous Linux - toujours pas stable et ne met pas longtemps à freezer. Normalement un crash sous Linux n'est pas fatal, il suffit la plupart du temps de passer sur un autre terminal virtuel (Ctrl+Alt+F2 par exemple) pour redémarrer le gestionnaire de login. On aura seulement perdu les modifications non enregistrées, mais la machine ne nécessitera pas de reboot.

Sauf que. Sauf que pilote NVidia et UEFI ne font pas bon ménage. La raison est encore floue pour moi mais il semblerait que l'utilisation de terminaux virtuels avec celui-ci soit encore impossible avec les dernières versions. Cela sera peut-être résolu... un jour. Conséquence directe : le Ctrl+Alt+F2 affiche un écran noir d'où il est impossible de revenir, et quand l'affichage est crashé, impossible de le récupérer sans intervenir "de l'extérieur". Heureusement il s'avère par hasard que j'ai... allez disons une petite dizaine de machines sur le même LAN, toutes équipées de clients SSH. Évidemment, un des daemons que j'avais installé en premier après le système de base, c'est bien sûr Openssh, un réflexe que j'ai pris il y a déjà un moment.

J'ai donc tenté de redémarrer GDM mais la commande semblait se "bloquer", le prompt ne me rendait pas la main. En fait il a bien fallu 60 secondes avant que l'affichage ne soit finalement réinitialisé. Mais après reconnexion, et à mon grand désespoir, les symptômes ont repris.

Je vais ici faire une ellipse, mais genre maousse costaude l'ellipse.

Non parce que j'ai quand même passé au moins 7 à 10 jours à comprendre pourquoi la machine était instable et d'où cela provenait. Évidemment, tout fonctionnait parfaitement avec la sortie vidéo du chipset intégré... mais bon les perfs étaient différentes ! J'ai flashé le BIOS/UEFI avec la dernière version disponible sur le site du constructeur, j'ai retiré la carte son (je pressentais la rebelote d'avec ma GeForce 256) et je n'ai pas eu de problème pendant plusieurs reboots. J'ai alors lancé une demande de retour en garantie pour celle-ci, mais finalement les bugs sont revenus. J'ai tenté d'intervertir ma nouvelle et mon ancienne carte graphique. Cela a semblé marché, j'ai alors demandé à ajouter dans le retour garantie la carte graphique mais il était déjà trop tard. Puis finalement les problèmes sont quand même revenus avec l'ancienne carte, mais c'était un peu aléatoire. J'ai surtout perdu un temps précieux en recherche Google infructueuses. C'était déprimant.

Et puis...

Et puis, en revenant une énième fois dans le setup du BIOS/UEFI, j'ai remarqué un réglage (évidemment à un endroit très évident : "Misc settings") qui m'avait semblé relever du point de détail quand j'étais tombé dessus par hasard lors de la configuration initiale :

Et là, un souvenir me frappe. Je me souviens avoir lu dans un Canard PC Hardware (pour changer) qu'il était souvent nécessaire de forcer le mode "Gen 2" car le 3 était encore très mal supporté. Quelques semaines plus tard, j'ai retrouvé le numéro en question, ils y testaient alors les différences entre les versions/révisions/générations 2 et 3 de plusieurs protocoles (USB, SATA, et PCI-Express justement). C'était pourtant un numéro qui avait presque 2 ans, mais le conseil était encore valable ! Merci les constructeurs !

Je force donc le mode "Gen 2" dans le setup, et reboote pour la 2658^ème fois mon PC. À ce moment précis, j'étais partagé entre le "C'est ça, c'est sûr, ça ne peut être que ça" et le "Je sens que c'est pas ça, c'est trop simple, ça ne peut pas être ça", voyez l'ambiance entre les deux hémisphères.

Et puis... la machine a tourné. J'ai tenté Windows d'abord, puisque suite à mes nombreux tests c'était là que les bugs étaient les plus rapidement visibles, et je n'ai rien constaté. Tout fonctionnait "normalement" (même si je n'avais pas vraiment encore eu l'expérience de cette "normalité"), je n'ai eu aucun crash du pilote graphique. J'ai essayé sous Arch, et pareil tout fonctionnait bien.

WTFdenomdedieudebourdeldemerde.

Je n'ai malgré tout pas été tranquille les premiers jours, m'attendant d'une minute à l'autre à subir un nouveau crash. Puis petit à petit, j'ai accordé ma confiance à ce tas d'électronique, et j'ai commencé à lui demander un peu plus (benchmarks 3D, charge importante), mais rien n'a jamais bronché jusqu'à maintenant. Et finalement, Leto, puisque c'est son nom, fait désormais partie de la famille.

J'ai subi depuis lors bien des déconvenues et des déceptions, principalement sous Linux je dois bien l'avouer, mais je laisse cela à un prochain article plus technique qui présentera comment j'ai mis en place du "multiseat" en jouant avec Xorg, Lightdm, systemd et udev. Rassurez-vous, je me bornerai à expliquer "comment faire pour que ça marche immédiatement" plutôt qu'à raconter ma vie :)

Une dernière note : n'achetez JAMAIS un boîtier ne disposant pas de LED signalant l'activité des disques. C'est juste indispensable.