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.

Je ne fais habituellement pas de publicité pour les sites commerciaux mais celui-là est un peu spécial. Hidden Tavern permet de mettre en relation des gens (non, des geeks en fait) cherchant (d'une part) et vendant (d'autre part) des choses comme des jeux rétro (Game Boy, Mega Drive, master System, PS1, ...), des jeux moins rétro (DS, Wii, Xbox, ...) mais aussi tout ce qui peut toucher de près ou de loin à l'univers aux univers geeks.

Le site est tenu par deux passionnés toulousains qui officient sur le web depuis 2012. Je leur laisse à présent la parole pour faire la présentation :

Pourquoi Hiddentavern.fr ?

Le site est encore un peu jeune mais il n'attend plus que des passionnés y proposent leur articles. Si c'est votre cas, pensez-y avant d'aller sur LeBonCoin ou pire... eBay ! :)

Un petit post pour vous faire découvrir un groupe de power metal / metal symphonique hongrois qui m'a particulièrement plu sur Jamendo récemment : Obsidian Shell.

Une voix féminine excellente, de bon gros riffs de guitare, de la double-pédale à foison et des sonorités électroniques qui rappellent un peu Blackstar Halo et parfois Nightwish, voilà qui rentre très précisément dans la catégorie de metal que j'apprécie tout particulièrement.

Quatre albums au compteur (et on espère d'autres en préparation) et une qualité qui se retrouve assez rarement sur une plateforme comme Jamendo (bon, même si je n'ai pas tout écouté, loin de là) Obsidian Shell est un groupe que vous devez écouter, au moins pour vous faire une idée.

Je vous recommande particulièrement l'album Angelic Asylum qui accompagnera avec merveille vos activités quotidiennes ( ^^ ) avec ses rythmes énergiques, ses sonorités éléctroniques et la voix de la chanteuse, douce et dégageant pourtant une certaine puissance qui décidément équilibre chaque piste avec bonheur. Certaines chansons sont en anglais, d'autres en hongrois (seule Starfall dans cet album) mais chacune apporte son caractère et sa fraîcheur aux titres.

En passant, n'hésitez pas à récupérer le lien RSS disponible dans la colonne de droite pour rester au courant ce qui se passe ici (promis, ça ne polluera pas vos flux, je ne poste qu'une à deux fois par mois ^^)

Si vous avez raté le début :

Usul II : le retour du fils de la vengeance (1ère partie)

Usul II : le retour du fils de la vengeance (2ème partie)

La migration matérielle était à présent terminée et le rodage se passait bien. Si bien que la machine a retrouvé deux jours plus tard son coin du placard (non sans un petit coup d'aspirateur au préalable). J'ai continué néanmoins à corriger ou adapter petit à petit la configuration logicielle suite à la montée en version de Debian.

Suite et fin de la série sur Usul II...

Ajustements et corrections : autofs à la rescousse

Le point qui me chagrinait le plus est qu'à chaque reboot depuis le passage à Wheezy, les montages réseaux (CIFS) définis jusque-là dans /etc/fstab bloquaient la séquence de boot car, apparemment, le réseau n'était pas encore disponible à ce moment-là. La seule manière de poursuivre le chargement était de presser S pour sauter le montage, puis une fois arrivé au shell, remonter les partages concernés avec un

# mount -a

Après une bonne phase de recherche sur le web, j'ai réalisé que ce que je faisais jusque-là fonctionnait plus par erreur qu'autre chose !

En effet, il est plutôt :

1. optimiste de penser que les partages réseaux définis dans /etc/fstab seront toujours accessibles au boot de la machine (si le NAS est éteint par exemple),

2. téméraire de les monter au boot sachant que si une erreur se produit (car, par exemple au hasard, le réseau n'est pas encore actif) c'est la séquence de boot entière qui sera suspendue jusqu'à l'action de l'utilisateur.

Les pistes que j'ai trouvées pour ce genre de cas m'ont dirigé vers autofs.

Autofs est un daemon qui va surveiller certains dossiers préalablement configurés et qui, à la première tentative d'accès, va monter de manière transparente la partition ou le partage réseau associé. Pour l'application à l'origine de ce premier accès, elle verra donc immédiatement le contenu de la cible du montage, même si celui-ci était démonté l'instant d'avant. Cela peut bien sûr occasionner un petit délai lors de l'accès déclenchant le montage, mais sans influer sur le déroulement de l'application.

Il ne s'agissait pas de la seule option possible pour ce cas de figure mais cela me semblait être la plus proche de ce que j'avais jusque-là, sachant que je ne tenais pas à dépendre d'un système basé sur FUSE par exemple.

Pour information, sur les distributions plus récentes utilisant de base systemd comme Archlinux (que j'utilise aussi quotidiennement), il est possible d'utiliser directement /etc/fstab en ajoutant simplement l'option "x-systemd.automount" pour arriver au même résultat. Si Systemd suscite encore aujourd'hui beaucoup de critiques négatives (de la part de passéistes intégristes barbus diront les mauvaises langues), j'avoue que certaines fonctionnalités intégrées sont parfois fort pratiques !

Mais revenons à Debian et son antique sysvinit. Un package éponyme est évidemment disponible pour autofs, on l'installera par la commande

# apt-get install autofs

Ceci installe évidemment le script de démarrage /etc/init.d/autofs qu'il ne faudra pas hésiter à utiliser pour appliquer les changements de configuration ultérieurs.

Le fichier principal est situé au chemin /etc/auto.master dans lequel toutes les lignes sont initialement commentées.

Je rajoute la ligne suivante pour mon cas :

/media/autofs/feydakin          /etc/autofs.d/feydakin.smb      --ghost

puis je crée le fichier /etc/autofs.d/feydakin.smb dans lequel je rajoute une ligne par montage souhaité selon le format suivant :

<nom_partage> <options_montage> :<cible>

Par exemple pour ma mp3thèque je saisirai :

music -fstype=cifs,credentials=/root/.samba/feydakin.cred,file_mode=0660,dir_mode=0770,uid=0,gid=1006 ://192.168.1.200/music

NOTE : il n'y a pas de retours à la ligne dans cette section, mais ma colonne n'est pas assez large pour l'afficher en entier)

Qu'est-ce que cela signifie en clair ? Je vais détailler.

Dans le premier fichier "maître" tout d'abord :

1. Je souhaite monter tous les partages définis dans le fichier /etc/autofs.d/feydakin.smb dans le dossier /media/autofs/feydakin (créé préalablement).

2. Feydakin est le nom de mon NAS, je regroupe ainsi tous les partages le concernant dans un fichier dédié afin de faciliter la maintenance que je nomme "feydakin.smb" par pur choix personnel. Le nom du fichier est le nom de la machine distante, l'extension m'indique le protocole utilisé pour ces montages. J'aurais pu lui donner le nom "coincoin.pouet" cela aurait fonctionné de la même manière, tout simplement car ce n'est pas ici que nous définissons les caractérisques de montage, seulement le dossier parent qui va accueillir les points de montage.

3. L'option "--ghost" en fin de ligne force autofs à créer un dossier correspondant à tous les points de montage même si ceux-ci ne sont pas encore montés. Par exemple au boot de la machine le dossier /media/autofs/feydakin/music sera automatiqement créé, mais sera vide. C'est assez pratique pour ne pas avoir de chemins invalides tant que les montages ne sont pas en place ce qui évite les erreurs potentielles.

Dans le second fichier à présent :

1. Je défini un montage nommé "music" qui donnera son nom au dossier créé à la racine commune pour les montages de ce fichier : /media/autofs/feydakin (défini dans le premier fichier)

2. Je spécifie les options de montage, c'est-à-dire essentiellement un copier-coller des options qui étaient jusque là dans /etc/fstab, en préfixant simplement par "-fstype=cifs," qui remplace le "smbfs" de fstab. Je ne détaille pas plus les options suivantes, un petit

$ man mount.cifs

vous en dira plus.

3. Enfin, j'indique où se trouve la cible du montage que je viens de définir. La notation est spécifique au protocole. Pour du SMBFS/CIFS j'aurai donc //192.168.1.200/music pour accéder au partage "music" situé sur la machine à l'adresse "192.168.1.200". Il faut cependant penser à préfixer ce chemin par deux-points ":".

4. Si j'ai d'autres partages, je n'ai qu'à les ajouter sur une nouvelle ligne en utilisant toujours le même format en 3 "colonnes". Et ainsi de suite.

That's all folks!

Je n'oublie pas de commenter les lignes correspondantes dans le fichier /etc/fstab, puis je reboote.

Et cette fois je n'ai plus aucune erreur ! Je tente immédiatement un :

$ ls /media/autofs/feydakin/music

et après une courte attente (liée au montage automatique par autofs en arrière-plan), le contenu du partage "music" du NAS s'affiche bien avec les bonnes permissions, exactement comme il s'affichait auparavant quand il était monté via fstab.

Dovecot-cot-socket

Petit souci supplémentaire dont je ne me suis pas aperçu immédiatement après la montée en version : Postfix semblait ne plus pouvoir envoyer de mails. En fait le problème n'était pas tant au niveau du MTA que du MDA, en l'occurrence Dovecot, dont la configuration avait largement évolué entre la version fournie avec Squeeze (1.2.x) et celle avec Wheezy (2.1.x). Mes fichiers de configuration ne correspondaient plus et les directives qu'ils contenaient ne s'appliquaient plus.

Il faut savoir que l'évolution entre ces versions ne touche pas seulement au format de certaines directives, mais également à leur répartition dans les fichiers de configuration. Auparavant par défaut rassemblées dans un unique fichier de 3Km de haut au chemin /etc/dovecot/dovecot.conf, elles sont maintenant éclatées, réparties par fonctionnalités dans des fichiers aux noms explicites situés dans le dossier /etc/dovecot/conf.d (comme c'est de plus en plus l'usage sur Debian).

Ce qu'il m'a fallu principalement reporter ce sont les directives de mise à disposition de l'authentification par socket, permettant à Postfix de déléguer l'authentification à Dovecot.

Mon fichier /etc/dovecot/dovecont.conf en version 1.x avait la section suivante aux alentours de la ligne 1140 (rien que ça...) :

...
socket listen {
        # Client for postfix SASL 
        client { 
            path = /var/spool/postfix/private/dovecot-auth 
            mode = 0660 
            user = postfix 
            group = postfix 
        }
    }
...

J'ai reporté cette section dans le fichier de configuration correspondant dans la version 2.x, c'est à dire /etc/dovecot/conf.d/10-master.conf :

service auth {
  [...]
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/dovecot-auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  [...]
}

La section générale "service auth" était déjà présente. J'ai simplement ajouté/décommenté la sous-section "unix_listener" que j'ai adaptée. Les "[...]" signalent que d'autres sous-sections sont présentes et sont à laisser telles quelles.

Un petit

# /etc/init.d/dovecot restart
# /etc/init.d/postfix restart

suivi d'un :

# ls -l /var/spool/postfix/private/dovecot-auth
srw-rw---- 1 postfix postfix 0 janv.  8 13:59 /var/spool/postfix/private/dovecot-auth

pour vérifier que le socket a bien été créé. Et c'est bon, on peut à nouveau envoyer des zimèles depuis l'extérieur de la machine !

Watchdog

Tout allait pour le mieux (et cette section ne serait pas là si j'avais moins tardé à publier ce post) quand soudain, courant décembre, mon serveur chéri s'est subitement mis à ne plus répondre.

Plus d'accès SSH, plus aucune réponse d'Apache ni de Webmin, rien de rien. J'ai alors branché un moniteur et un clavier sur la tour pour tenter d'en savoir plus sur l'état de la machine, mais le moniteur est resté désespérément en veille malgré mes appuis sur différentes touches.

J'ai dû me résoudre au fait que je faisais face à un crash (du genre plutôt méchant).

J'ai rebooté puis j'ai immédiatement consulté les logs et graphes de charge : chou blanc. Aucun indice ne permettait de comprendre ce qu'il s'était passé. S'il y a bien une chose pire qu'un crash complet de Linux, c'est être incapable d'en déceler l'origine.

J'ai espéré que ce cas resterait exceptionnel et considéré que cela pouvait arriver aux meilleurs (on se rassure comme on peut). Mais je ne tenais pas à ce que, s'il devait se reproduire, je sois obligé d'intervenir manuellement sur la machine, tout simplement car d'après la loi de Murphy, au moment où cela se produira je serai loin, et j'aurai un besoin urgent de la machine et ses services.

La solution ici était de confier la vie de la machine à un watchdog.

Je résume rapidement le principe du watchdog (ou "chien de garde" en françois du sud) : un composant matériel (bien) ou logiciel (moins bien) décrémente régulièrement un compteur initialement à N jusqu'à 0. Lorsque 0 est atteint, la machine est rebootée, de manière "soft" ou de manière "hard".

Afin d'éviter le reboot lorsque 0 est atteint, un processus du système est chargé de réinitialiser régulièrement le compteur à N. Tant que ce processus arrive à réinitialiser le compteur, c'est que - a priori - le système n'est pas planté (au moins le noyau donne régulièrement la main à ce processus qui peut faire son travail, ce qui est une bonne évaluation de "pas planté").

Si le système plante (ou est considéré planté^(*)) le processus ne réinitialisera plus le compteur. Le watchdog décrémentera lui toujours le compteur et arrivé à 0, il rebootera la machine.

Ça, c'est la version avec un watchdog matériel, mais ni tous les PC ni tous les CPU ne disposent nécessairement d'un watchdog matériel, c'est à dire indépendant des processus exécutés par le CPU. Je ne détaillerai pas ce cas ici mais il existe donc une "émulation" du watchdog sous Linux appelée "softdog" qui, au lieu de rebooter brusquement (mais efficacement) la machine, ordonne au noyau d'effectuer un reboot. Mais vous l'aurez compris : si le noyau lui-même est planté, cela ne sera d'aucun secours...

La première chose à faire dans ce cas de figure est de vérifier si la machine ou le CPU dispose d'un watchdog matériel. Pour cela, on peut utiliser la commande simple suivante :

$ ls -l /dev/watchdog
crw------- 1 root root 10, 130 déc.  21 13:18 /dev/watchdog

Le fichier spécial existe, ce qui signifie très probablement qu'un watchdog est présent et reconnu par le noyau. Pour s'en assurer on peut utiliser la deuxième commande suivante :

$ dmesg | grep -iE "(wdt|watchdog)
[    5.434643] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07
[    5.434926] iTCO_wdt: Found a NM10 TCO device (Version=2, TCOBASE=0x0460)
[    5.435133] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Là on en est sûr : un watchdog existe (ici c'est celui inclus dans le chipset NM10 d'Intel, Atom oblige) et est utilisable. On apprend aussi que son "timeout" est de 30 secondes (troisième ligne), c'est au bout de ce temps qu'il reboote la machine si rien n'a réinitialisé le compteur. On apprend aussi que c'est le pilote noyau "iTCO_wdt" qui est chargé de sa gestion (voir la liste complète des pilotes et de leur options ici).

Il ne reste plus qu'à activer et configurer le daemon watchdog de Linux. Pour cela, rien de plus simple :

# nano /etc/watchdog.conf

et décommenter la ligne :

watchdog-device = /dev/watchdog

Puis pour activer le daemon au boot :

# nano /etc/default/watchdog

et décommenter/passer la valeur à 1 :

run_watchdog=1

On peut aussi en profiter pour vérifier que le pilote trouvé un précédemment est bien celui noté sur la ligne :

watchdog_module="iTCO_wdt"

On lance enfin le daemon :

# /etc/init.d/watchdog start

Pour tester : on va simuler un crash en empêchant le daemon de réinitialiser le compteur. Si on arrête "proprement" le dameon, le watchdog ne rebootera pas la machine car actuellement celui-ci est configuré en "nowayout=0" (c.f. résultat de la deuxième commande), c'est-à-dire qu'il reste possible de fermer le fichier /dev/watchdog de manière à ce que le watchodg comprenne qu'il doive arrêter son travail, et donc ne pas rebooter la machine. C'est ce qui se passe si on arrête le daemon en utilisant le script dans /etc/init.d.

Une manière de procéder est comme suivant (source) :

# touch /forcefsck
# sync
# pkill -9 watchdog
# for n in $(seq 1 60); do echo $n; sleep 1; sync; done

J'ajouterai personnellement que j'ai préféré aussi stopper proprement les principaux daemons (notamment Subsonic, MPD, Samba, ...) avant de les jouer.

L'effet est très simple : on force une vérification des disques au prochain reboot (parce que l'arrêt aura été brutal), on force l'écriture sur disque des données en attente, puis on tue le processus du daemon watchdog (donc pas de fermeture propre du fichier). On attend ensuite le reboot automatique pendant 60 secondes en forçant l'écriture des données sur disque toutes les secondes afin d'éviter au maximum les corruptions.

Et au bout de 30 secondes (chez moi) : boum ! Le PC reboote automatiquement, signalant le succès de l'opération. Je peux à présent ressortir de chez moi sans craindre de ne plus accéder à mon serveur à cause d'un crash (qui ne s'est pas encore reproduit par ailleurs).

(*) Mon utilisation ici est la plus simple qui soit, mais il est possible de configurer le daemon pour qu'il considère la machine comme "plantée" selon différents critères : ping d'une machine, charge moyenne, mémoire libre, température, etc. Consulter le fichier /etc/watchdog.conf pour en savoir plus.

Comme beaucoup de personnes ayant connu les années 90 (voire 80), j'ai encore des traces de ce qui représentait alors le summum de la technologie grand public de l'époque : j'ai nommé le caméscope-analogique-aux-couleurs-qui-bavent. Ces traces sont présentes chez moi sous la forme de cassettes VHS. Malgré la faiblesse de ce support, ce qu'elles renferment tient pourtant de l'inestimable : des souvenirs de vacances, d'anniversaires, de Noëls en famille, ...

C'est pourquoi j'ai pris la décision on m'a fortement incité à prendre la décision de numériser toutes ces bandes avant qu'elle ne disparaissent irrémédiablement, elles ou leur lecteur associé (appelé "magnétoscope", j'en avais parlé là de manière pas du tout ironique).

Cela faisait déjà pas mal d'années que je ne m'étais plus tenu au courant de ce qui se faisait en terme de capture vidéo sur PC, j'avais seulement des souvenirs assez flous du début des années 2000 où le matériel était clairement limitant : cartes dédiées hors de prix, pilotes et logiciels associés partiellement instables, débits d'écriture liliputiens, espace de stockage ultra-limité (les disques aux prix accessibles ne dépassaient pas les 40 Go), puissance CPU imposant de lancer les tâches de transcodage la nuit...

Tout ça pour finalement se rendre compte que les paramètres définis n'étaient finalement pas bons et qu'il fallait attendre la nuit suivante pour relancer le processus ! (dans un autre cas, le PC avait simplement planté lamentablement sous la charge)

C'est donc avec une légère crainte provenant du fond des âges que j'ai commencé mes recherches concernant l'acquisition du matériel adéquat pour numériser la poignée de cassettes qui se tenaient sur mon bureau. Même si les données que je devais extraire n'avaient pas de prix, j'avais placé une limite haute de budget à 80€, en espérant plutôt trouver un compromis à 50€ car il s'agirait certainement d'une opération unique que je n'aurais ensuite plus à refaire (ça et la période de Noël qui dit aussi grosses dépenses à côté).

Après une séance de lèche-vitrine sur les principales boutiques en ligne et la lecture de quelques comparatifs, mon choix s'est porté sur l'adapteur "USB-Live 2" d'Hauppauge, que j'ai trouvé à 40€ sur LDLC.

Comme son nom l'indique, il s'agit d'une "carte" externe, compatible USB 2.0 - point important : cela peut être clairement limitant si on traite de la vidéo HD, mais n'est pas mon cas - disposant de 3 connecteurs RCA (dits "cinch") et d'un connecteur S-Video. Je n'avais aucune assurance concernant sa compatibilité avec Linux mais son prix était clairement intéressant, donc même si mon objectif était de réaliser les captures sous Linux, j'étais prêt à y renoncer en dernier recours.

Les premiers tests

N'étant pas chez moi pour les fêtes, j'ai tout d'abord testé l'appareil sur un PC équipé de Windows XP. Après l'installation de la partie analogique (un magnétoscope Schneider 65DV20, pour information), les éternelles installations de pilotes suivies par les non moins éternels redémarrages, j'ai pu faire l'amère constatation que... je n'avais pas les bon câbles.

En effet, même si j'avais prévu l'adaptateur Péritel/RCA et les câbles Composite, aucun signal ne semblait arriver à la carte. En cherchant un peu, j'ai réalisé qu'il me fallait un adaptateur d'un type différent : celui que j'avais ne fonctionnait que dans le sens Composite -> Péritel et non l'inverse. Or ici la Péritel était branchée en sortie du magnétoscope, et le signal sortait par les prises RCA. (je n'ai pas poussé plus loin mes investigations, donc si quelqu'un tient à me corriger, qu'il n'hésite pas)

En faisant quelques courses le lendemain, j'ai évidemment fait un tour du côté HIFI d'un Géant Casino afin de voir si par hasard je pouvais éviter la commande en ligne. Bien m'en a pris car j'ai trouvé un adaptateur Philips correspondant avec un câble de 1,5m pour à peine 8€. Si tout allait bien, je restais encore dans mon budget ! :)

Pour information, je n'ai pas la référence exacte mais il s'agit d'un câble équipé 3 prises RCA d'un côté (2 audio + 1 vidéo) et d'une Péritel de l'autre. Un bouton sur la Péritel permet de choisir le sens du flux : IN ou OUT. Ici c'est OUT qui m'intéresse.

Sous Windows...

De retour sous Windows, les tests ont été plus concluants. "Plus" oui, mais pas totalement. J'arrivais enfin à obtenir le signal sur le logiciel WinTV fourni avec la carte, mais celui-ci était brouillé, un peu comme... s'il n'était pas décodé en SECAM. Ah, le bonheur de ces formats antiques ! Grr...

J'ai dû chercher une bonne paire d'heures avant de me rendre compte que ce que je prenais pour la fenêtre de modification du format de lecture (NTSC, PAL, SECAM, etc.) n'était en fait que la fenêtre de configuration générale du dispositif de capture, et que la liste permettait seulement de consulter les formats supportés (je résume, mais c'est à peu près aussi bête). Pour changer le standard de codage à la volée au cours de la capture, il suffisait de... changer de chaîne.

La carte est en effet vue comme un tuner, et changer de chaîne permet de passer d'un standard à un autre, ce qui, lorsqu'on a trouvé le bon, donne immédiatement une image claire (enfin, pour autant qu'on puisse considérer ce type d'image analogique comme "clair", mais c'est une autre histoire).

J'ai immédiatement tenté la capture de la première cassette.

Trois heures plus tard (la durée de la cassette...), le logiciel WinTV avait généré un fichier TS de 8 Go environ contenant deux flux : un flux vidéo encodé en MPEG-2 et un flux audio encodé en MPGA (appelé "MP2"), ce qui est je crois le format des DVD. Le tout était évidemment désentrelacé, et la synchronisation vidéo/audio parfaite d'un bout à l'autre.

Un très bon point.

Puis sous Linux...

Maintenant que je m'étais assuré que le montage fonctionnait sous Windows, je pouvais faire le test sous Linux. Ayant sur moi mon vaillant PC portable de 2009 tournant sous Archlinux, j'ai branché la carte USB et commencé mes recherches sur le grand Nain Ternet. Les premiers résultats étaient moyennement encourageant : le wiki de LinuxTV indiquait qu'un noyau récent supportait "probablement" cette carte, mais un autre paragraphe était moins enthousiaste.

Pour tester cela semblait simple : brancher la carte et lancer xawtv.

# pacman -Sy xawtv
$ xawtv

Et effectivement, j'ai branché la carte sur un port USB libre, installé et lancé xawtv, et miracle : l'image apparut correctement dans le petit cadre !

Bon, impossible de l'agrandir sous peine de perdre la moitié de l'affichage - remplacé par une bande verte - mais qu'à cela ne tienne ce n'était pas pour du visionnage en plein écran que je souhaitais utiliser la carte mais pour de la capture vers un fichier. J'étais sur la bonne piste.

Première étape : la capture

De retour dans mon atelier chez moi, sur mon fidèle Freeseed bi-core équipé lui aussi d'Archlinux, j'ai cherché comment enregistrer le flux de la manière la plus brute possible, même si cela devait signifier de créer des fichiers de 10 à 20 Go par heure. Mon objectif était dans un premier temps de créer des enregistrements simples que je pourrais retravailler et transcoder après coup.

J'ai tout d'abord regardé du côté de VLC, véritable boîte à outil vidéo multi-plateforme.

Seulement, à mon grand désespoir, si j'arrivais bien à obtenir l'image en utilisant la configuration prédéfinie "TV (analogique)", le son lui manquait, et l'erreur suivante apparaissait :

Évidemment qu'il n'y a aucun fichier à cet emplacement, mais ce n'est pas ce que je te demande, banane !

Après une rapide recherche infructueuse pour déterminer d'où pouvait bien provenir le fait que VLC essaye d'ouvrir le périphérique audio comme un fichier dans le dossier courant, je me suis finalement tourné vers mplayer et son acolyte mencoder. J'ai trouvé des exemples de commandes permettant a priori de faire ce que je voulais, alors je les ai essayées.

L'enregistrement serait fait dans un conteneur AVI, en utilisant le codec vidéo MJPEG et le codec audio PCM (ce qui est connu comme le format "wave" sous Windows). Il s'agit d'un des fomats les plus simples et les plus "bruts" : la vidéo est mise sous forme d'images JPG indépendantes (il y a donc une compression mais sur chacune des images, pas sur le flux), et le son est conservé sous forme d'onde échantillonnée, donc sans aucune compression.

Puis j'ai testé.

Longuement.

Laborieusement.

Le premier test m'a donné une vidéo en accéléré alors que le son était au rythme normal. J'ai alors ajouté les paramètres "-noskip" et "-mc 0" pour conserver les frames. Le résultat semblait bon, alors j'ai lancé la capture d'une seconde cassette de trois heures.

Lors d'un visionnage attentif de la vidéo générée, j'ai réalisé qu'après une heure environ le son était en retard par rapport à l'image, et que ce retard se creusait progressivement pour atteindre les 4 à 5 secondes en fin de fichier. Inacceptable.

(2 jours plus tard...)

Après moult essais à base de combinaisons de paramètres obscurs, filtres vidéo ("harddup", "softskip" et autres), incantations magiques et tentatives d'envoûtement (en dernier recours) qui n'ont jamais corrigé ce rogntudju de décalage entre le son et l'image, j'ai décidé de me reconcentrer sur VLC. Mes recherches montraient clairement que lorsqu'un problème n'était pas résoluble par mencoder, il fallait tenter VLC (et réciproquement).

Le problème du périphérique de son évoqué plus haut a été "simplement" résolu en préfixant la valeur proposée dans la liste "hw:2,0" par "alsa://". Les joies du son sous Linux où OSS, Alsa, Pulse et les autres s'ébattent joyeusement dans une mare de caca.

Voici finalement la boîte de dialogue avec la configuration fonctionnelle, celle affichant, dès l'appui sur le bouton "Lire" l'image provenant de la carte d'acquisition et le son associé :

Ce qui est intéressant c'est que si je souhaitais, disons par exemple, créer un petit script pour enregistrer le flux via VLC, je n'ai qu'à prendre les options de lecture qui apparaissent en cochant "Afficher plus d'options".

La commande pour simplement lancer la lecture dans VLC va donc se traduire par :

$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300

Ça, c'est pour lire. Moi je veux enregistrer. La commande complète serait donc celle-ci :

$ cvlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300 \
:sout=#transcode{vcodec=mjpg,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}

Ce qui signifie :

• Utiliser la version "console" de VLC (pas d'interface graphique, donc pas de suivi de la vidéo. Utiliser "vlc" à la place de "clvc" pour retouver l'interface)
• Lire la vidéo sur le périphérique V4L /dev/video0
• Lire le son sur le périphérique ALSA hw:2,0 (à adapter selon la configuration matérielle, etc.)
• Utiliser le standard de codage SECAM L/C (ce que xawtv me sélectionnait automatiquement plutôt que "SECAM L", je n'ai pas trouvé ce qui différenciait les deux)
• Transcoder la vidéo en utilisant le codec MJPEG (pareil qu'avec mencoder) avec un bitrate de 1024k
• Transcoder le son en utlisant le codec MPGA (MP2) avec un bitrate de 160k
• Écrire le tout dans un fichier "out.mpg", qui, d'après l'extension, sera un conteneur MPEG-PS (sinon on peut forcer le muxer en utilisant le paramètre "mux=...").

Pour connaître les codecs et muxers utilisables, voir cette page :

https://wiki.videolan.org/Codec

MAIS.

J'obtenais encore une fois un décalage entre le son et l'image : cette fois-ci le son était en avance. Grr de grr.

Il a fallu que je change le codec vidéo et passer par du MPEG-1 (toujours avec du MP2 en audio) pour enfin obtenir une vidéo synchronisée de bout en bout !

Ma commande "finale" est donc :

$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300 \
:sout=#transcode{vcodec=mp1v,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}

J'ai pu ainsi numériser tranquillement toutes les cassettes restantes, et créer des fichiers MPG propres que je pouvais ensuite transcoder et compresser à loisir dans un second temps. Pour information, à la fin de cette première phase on obtient des fichiers pesant 6 à 7 Go par heure, ce qui est très acceptable AMHA.

Afin de conserver la trace de ces commandes et pouvoir les adapter et les réutiliser au besoin, j'ai créé un script Bash auto-explicatif très simple disponible ici :

http://pastebin.com/kXCw2qUN

Pour l'utiliser :

$ record_vlc.sh [<duree>]

Où <duree> est la durée de l'enregistrement à créer, en secondes (optionnelle).

Ne pas oublier de configurer correctement les variables VIDEO_DEV et SOUND_DEV en début de script.

Deuxième étape : redécoupage et transcodage

Là je vais résumer par flemme, mais ce fut encore perte de temps et compagnie, car en plus de vouloir transcoder les films bruts dans un format un peu plus économe en terme d'occupation sur le disque, je souhaitais recouper le film : supprimer les quelques secondes initiales, et souvent les nombreuses minutes à la fin (ayant lancé la commande pour numériser la totalité de la cassette, même si parfois seule une partie était réellement utilisée).

J'ai réessayé mencoder, qui normalement est fait pour cela. Mais j'obtenais de nouvelles désynchronisations dans les vidéos résultantes, ou (selon le codec testé) des corruptions dans le son. OK je passe au suivant.

VLC m'a donné peu ou prou la même chose, avec au final un résultat décevant. Impossible notamment de bien recouper le film à partir d'un point jusqu'à un autre.

Puis je suis passé à ffmpeg. Et enfin, ce fut le bon ! Je pouvais redécouper correctement les morceaux qui m'intéressaient et encoder la vidéo dans un format un peu plus efficace : MPEG-4 (avec le son en MP3), le tout enrobé dans du bon MKV.

Voici donc la commande utilisée pour ce faire :

$ ffmpeg -i in.mpg \
-c:v mpeg4 -b:v 6000k -c:a mp3 -b:a 160k \
out.mkv

J'ai également créé un script Bash auto-explicatif permettant de configurer le transcodage. Il est disponible ici :

http://pastebin.com/BTJdyTbN

Pour l'utiliser :

$ transcode_ffmpeg.sh <fichier> [<debut> <fin>]

Où <debut> est la position à partir de laquelle commencer la conversion du film d'origine et <fin> la position de fin. Les deux paramètres peuvent être spécifiés en secondes ou au format **hh:mm:ss[.xxx]** (grâce à ffmpeg qui accepte les deux).

J'obtiens ainsi des fichiers dont la taille a été divisée par un peu plus de 2 (exemple : 9,7Go après conversion par ffmpeg pour 21,8Go après l'enregistrement "brut" par VLC). La différence de qualité est, elle, imperceptible (pour moi).

Voilà c'est tout. J'espère encore une fois ne pas avoir dit trop de c... bêtises, et que le récit de mes péripéties pourra être utile à quelqu'un souhaitant aussi mettre en lieu sûr ses précieux souvenirs analogiques des années 80 et 90. Si j'en juge par le peu d'informations utilisables (et à jour) que j'ai pu dénicher sur la Toile, je pense que oui.

Je délaisse un moment les octets, CPU, Watts, codes sources, NAS, adresses IP et autres scripts chers à tout geek qui se respecte, pour tenter de vous faire découvrir quelques perles musicales qui me tiennent à coeur ces derniers temps.

Voici la troisième édition des Sons en Vrac, avec au menu de la soul, du jazz, du rock, du trip-hop et bien sûr du métal. Bonne écoute !

Beth Hart

Découverte il y a plus d'un an avec un enregistrement live sur Oüi FM (ci-dessous), j'ai été subjugué et emporté par la puissance et le timbre de sa voix.

Beth Hart est une chanteuse américaine de rock/blues/soul qui officie depuis la fin des années 90 et sort depuis régulièrement de nouveaux albums. Son style, sans être d'une originalité extrême, est reconnaissable principalement à sa voix, encore une fois.

Les quatre albums que j'écoute régulièrement sont les suivants :

• Screamin' For My Supper (1997)
• Leave The Light On (2003)
• 37 Days (2007)
• My California (2010)

De la bonne musique américaine, où l'on perçoit les différentes influences culturelles qui s'entremêlent et qui personnellement projette dans mes yeux de petit Européen des images de grands espaces et d'american way of life comme on n'en fait plus.

Seth MacFarlane

On reste aux USA mais on change totalement de registre avec un monsieur que beaucoup connaissent pour être l'auteur de ces séries héritières des Simpsons des premiers jours, politiquement incorrectes et délirantes, j'ai nommé Family Guy, American Dad et maintenant The Cleveland Show (dans une moindre mesure cependant).

Qui n'a jamais réécouté deux fois ces scènes dignes de comédies musicales des années 50 ? Moi je n'ai pas résisté en tout cas. Et quand on sait que c'est Mr MacFarlane lui-même qui fait la voix des principaux personnages et lui qui chante toutes les chansons, on ne peut que lui reconnaître un indéniable talent et pardonner à ses séries certains gags pipi-caca (il paraît que ça gêne des gens, moi j'adore).

Seth nous offre dans son album Music Is Better Than Words une reprise de titres de swing et jazz des années 40 à 60 dans le pur style Sinatra-esque accompagné d'une orchestration sans faille qui nous replonge instantanément dans un univers de chaleur en noir et blanc.

Heifervescent

Découvert sur Jamendo il y a un peu plus d'un an, c'est encore aujourd'hui avec bonheur que j'écoute ce petit groupe indé britannique qui nous offre dans ses cinq albums une pop-rock rafraîchissante et énergique, aux sonorités originales et acidulées.

Les trois albums sont disponibles en intégralité sur Jamendo et en téléchargement gratuit :

• Pondlife Fiasco (2009)
• The Glue Factory (2010)
• Further Adventures in Monkeyland (2011)

Pour les plus récents par contre :

• Little Egg (2012)
• Wake Up Sheepyhead (2013)

certaines pistes ont été otées et ne sont disponibles que par des voies bassement commerciales (les auteurs réclamant paraît-il de pouvoir vivre de leur travail).

Je ne peux que vous conseiller une petite écoute rapide sur Jamendo, et si le son vous plaît, de télécharger (pour les gratuits) et d'acheter leur discographie.

Tab & Anitek - Sights & Sounds

Toujours sur Jamendo, une petit "album" de trip-hop/ambient qui s'écoute aussi facilement pour se détendre, pour bosser toute la journée ou pour accompagner une soirée (arrosée ou non).

Je n'ai pas encore écouté le reste de la discographie d'Anitek mais si le reste est du même acabit j'adhère à 200%.

Paradise Lost

Là j'attaque du lourd, du groupe de metal britannique qui vient de fêter ses 25 ans - rien que ça - avec sa horde de fans poilus (j'imagine hein) et qui a débuté dans le registre sombre du doom/death, pour créer ce qui deviendra le gothic, et prendre ensuite un "virage" vers ce que Wikipédia n'hésite pas à appeler de la cold wave et redescendre à nouveau vers du gothic-metal plus "léger" et carrément excellent, avant de finalement revenir dans les derniers albums vers ses origines plus "dark".

Listons d'abord les (nombreux !) albums :

• Lost Paradise (1990)
• Gothic (1991)
• Shades of God (1992)
• Icon (1993)
• Draconian Times (1995)
• One Second (1997)
• Host (1999)
• Believe In Nothing (2001)
• Symbol Of Life (2002)
• Paradise Lost (2005)
• In Requiem (2007)
• Faith Divides Us Death Unites Us (2009)
• Tragic Idol (2012)

Je l'avoue de suite : je ne suis pas fan des premiers albums jusqu'à One Second. Trop death pour moi.

J'ai en fait d'abord découvert l'album de pop (!) Host qui m'a franchement plu avec ses mélodies accrocheuses et ses sonorités électro à la Depeche Mode (mais sans l'impression désagréable de déjà-entendu). Les métalleux purs et durs renient j'en suis sûr volontiers cet opus trop radio-like.

Mais ce n'était qu'une entrée en bouche, et One Second est arrivé. Et là, la claque. Des teintes d'électro, mais moins que sur Host, une base metal indéniable mais des arrangements complexes, pour un tout finalement agréablement abordable et surtout carrément pêchu !

J'ai poursuivi sur la lancée avec Believe In Nothing et Symbol Of Life, les deux autres membres du trio qui constitue mes références actuelles pour ce groupe. Puis je suis passé aux suivants que j'apprécie finalement à chaque écoute un peu plus. Une fois mon oreille éduquée, j'ai même tenté une réécoute des premiers albums, mais il n'y a guère que Draconian Times qui peut pour le moment flatter mon tympan.

Tout ça pour en arriver à me demander comment le metal fait pour passer sous le radar des média traditionnels pour que des perles dans ce genre me soient restées cachées aussi longtemps. Mais pinaise la découverte en vaut le coup !

Blackstar Halo

Découvert fin 2011 (déjà !) en regardant la vidéo du Winland Tour de MaSu (séquence), j'ai immédiatement accroché au son de ce groupe de metal finlandais. Seul un album (Illuminated) est pour le moment disponible mais le groupe nous assure qu'un second est en préparation.

Quoi dire de plus ? C'est du metal progressif tendance mélodique, qui rappelle parfois un peu MaSu... sans le SID-side évidemment !

Si vous accrochez, je vous conseille également d'écouter l'album My Last Prayer de Downfall qui n'est autre... que le même groupe avant que celui-ci ne change de nom ! Un peu moins travaillé, on voit sans peine que le groupe a progressé depuis 2002, que ce soit au niveau chant que dans les arrangements.

Battle Beast

Voici venu le temps... non pas des rires et des chants, mais du metal kitsch ! Oui dit comme ça évidemment ça ne donne pas trop envie. Imaginez seulement qu'un groupe de heavy metal des années 80 atterrisse par quelque hasard à notre époque en ayant sauté toutes les évolutions que le genre a connu en plus de 20 ans... et essaye tant bien que mal de les rattraper !

Résultat : bam, Battle Beast.

Un groupe venu de Finlande (comme c'est étonnant), formé en 2008, que j'ai découvert sur Tracks l'an dernier et qui, passé la première impression "Whouah c'que c'est kitsch !", m'a sérieusement donnée envie d'écouter l'album entier pour m'en faire une idée plus... complète.

Et c'est kitsch. Si si faut l'avouer. Mais c'est du kitsch travaillé, énergique, avec son côté heavy metal de papa et ses paroles qui nous dévoilent un monde dur, froid et robotique et... ouais ok et ça va pas très loin. On n'est pas chez un Nightwish, mais l'ensemble est assez flatteur, avec des gros riffs de guitares bien francs et des synthés en choeurs derrière. Ce qui tranche peut-être un peu, c'est la voix. Car c'est une métalleuse aux commandes, pour le premier comme pour le second album (même si c'est pas la même).

Si la chanteuse du premier album me convainquait niveau puissance mais moins niveau timbre, celle du deuxième m'emballe carrément plus quand elle montre l'étendu de ses capacités vocales (voir un bon exemple dans la vidéo ci-dessous). Oui j'ai bien dit capacités vocales, arrêtez de mater.

C'est tout pour cette fois, mais une quatrième édition n'est pas exclue !