Au petit plombier

Autant Linux fournit un environnement complet pour les adeptes de la publication papier (pensez à LaTeX, Scribus, ou même OpenOffice), autant la création de DVD vidéos tient encore de la semi-voltige.
Un utilitaire en ligne de commande existe, dvdauthor, mais avec des interfaces graphiques assez jeunes pour ceux qui ne sont pas nécessairement attirés par l’écriture de fichiers de configuration en XML.

J’avais commencé par utiliser qdvdauthor. Il marchait assez bien, jusqu’au jour où… il s’est arrêté de marcher, et la laideur de l’interface QT sous Ubuntu Breezy ne m’a pas incité à essayer de le réparer. [C'est pernicieux, comme méthode de prosélytisme, de rendre moches par défaut les librairies graphiques de ses petits camarades pour mieux imposer ses choix.]
J’avais même configuré mon MythTV pour enregistrer une émission sur DVD en trois boutons de télécommande, mais en fait j’ai beaucoup plus tendance à enregistrer des émissions courtes, et je veux donc en mettre plus qu’une par DVD…

Je suis passé à dvdstyler, qui a beaucoup progressé récemment. Et qui offre une interface que je trouve plus intuitive, mais intuitif est une notion des plus subjectives.

Recette rapide, pour archiver sur DVD vidéo des enregistrements MythTV:

1. Installer et configurer nuvexport, pour pouvoir transcoder un .nuv de MythTV en séquence MPEG-2 qui se respecte
1. Configurer son /etc/nuvexportrc pour que les réponses par défaut soient celles qui vont bien. Notamment, la réduction de bruit (noise_reduction) de ffmpeg ne m’a jamais causé que des soucis. Je l’ai enlevé et je ne m’en porte que mieux.
2. Sous l’utilisateur mythtv, transcoder les enregistrements visés en lançant la commande nuvexport. Il est possible et facile de mettre toute une série d’enregistrements en queue.
3. Faire montre de patience pendant que mythtv transcode…
2. Installer et configurer dvdstyler, pour pouvoir créer un menu pour le DVD.
1. dvdstyler est disponible sous Ubuntu Breezy, via un
   deb http://dvdstyler.sourceforge.net/repository/ubuntu/ breezy main
   dans la liste des fichiers sources de apt.
2. Ubuntu Breezy (et Dapper j’imagine) tombe sous le coup de ce problème. Pour s’en rendre compte, il faut jouer avec gdb, l’application n’étant pas très vocale. Comme indiqué sur le lien, ajouter -S 420mpeg2 à la commande ppmto4ym dans les "core settings" de dvdstyler résoud le problème.
3. Les vidéos transcodés auparavant peuvent se rajouter dans la frise temporelle en bas de la fenêtre. Pour les boutons, il vaut mieux indiquer les options de navigation à la main, plutôt que de laisser l’option par défaut (automatique). Les sites web des émissions, ou bien au pire Google Images fournissent de jolis fonds d’écran pour le menu principal.

Mon bon Pocillopora (qui propulse reefs et advancedaquarist) a toujours été une cible privilégiée des spammeurs.

Jusqu’au week-end dernier, les spams étaient combattus pendant le connexion SMTP entrante, à l’aide de MIMEDefang, un très bon milter de Sendmail. À charge de MIMEDefang d’appeler à la volée une clique d’autres logiciels (tout aussi libres que MIMEDefang) :

• Spamassassin (analyse bayésienne, filtrage euristique, tests RBL, analyse des en-têtes et des corps de message)
• Razor (système collaboratif d’identification de spams connus à l’aide d’empruntes numériques)
• Pyzor (cf. razor)
• dcc (cf. pyzor)
• ClamAV (anti-virus libre, qui détecte notamment un grand nombre d’attaques de type phishing)

À partir de cette petite soupe, MIMEDefang calcule une note et rejette le mail avec une erreur 554 si elle est trop élevée. Le record du spam le plus gratiné dans les journaux qui sont encore en ligne sur Pocillopora a une note de 61.553 (les mails qui atteignent 10 sont déjà assez graves):

$ sudo gzip -fdc /var/log/mail.log* | \
grep ",spam," | \
sort -k4 -t "," -n | \
tail -1
Mar 22 11:33:28 pocillopora mimedefang.pl[26796]: MDLOG,k2MBXIYY027790,spam,61.553,60.190.31.22:BAYES_99:DCC_CHECK:DIGEST_MULTIPLE:
DNS_FROM_RFC_WHOIS:FORGED_MUA_OUTLOOK:FORGED_OUTLOOK_HTML:FORGED_YAHOO_RCVD:
FRONTPAGE:HEAD_ILLEGAL_CHARS:HTML_80_90:HTML_CHARSET_FARAWAY:HTML_FONT_BIG:
HTML_IMAGE_ONLY_12:HTML_IMAGE_RATIO_02:HTML_MESSAGE:MIME_BOUND_DD_DIGITS:
MIME_HTML_ONLY:MIME_HTML_ONLY_MULTI:MIME_QP_LONG_LINE:MISSING_MIMEOLE:
MPART_ALT_DIFF:MSGID_SPAM_CAPS:PYZOR_CHECK:RAZOR2_CF_RANGE_51_100:RAZOR2_CHECK:
RCVD_BY_IP:RCVD_DOUBLE_IP_SPAM:RCVD_HELO_IP_MISMATCH:RCVD_ILLEGAL_IP:
RCVD_IN_BL_SPAMCOP_NET:RCVD_IN_DSBL:RCVD_IN_NJABL_PROXY:RCVD_IN_XBL:
RCVD_NUMERIC_HELO:SUBJ_ILLEGAL_CHARS:URIBL_OB_SURBL:URIBL_WS_SURBL,
<npcukrymxxgicd@yahoo.com>,[...]

Coût ? Un fils MIMEDefang prend dans les 30-40 MB. Un peu usine à gaz, mais jusqu’à récemment, cette solution marchait bien.

L’année 2006 a été celle d’un tournant malencontreux, celui où le débit en spams (en rouge dans le graphique qui suit) s’est mis à excéder de manière constante le débit en mails légitimes (en vert). Sachant que la courbe verte contient une majorité écrasante de mails générés par le serveur (typiquement par le système de notification des forums), donc de toute évidence légitimes – au moins du  point de vue de Pocillopora.

Résultat, les spams ont commencé à traverser les filtres, et surtout à destination des comptes systèmes (votre serviteur en sait quelque chose). Rien de bien méchant, mais une tendance qu’on veut définitivement arrêter rapidement.

C’est ici qu’intervient milter-greylist. Comme son nom l’indique, c’est un milter de Sendmail qui met en oeuvre des "listes grises". Milter-greylist est programmé par Emmanuel Dreyfus (administrateur de PC, raison suffisante pour jeter un coup d’oeil).
Le concept d’une liste grise est de forcer les serveurs de mail distants douteux à mettre en queue les mails qu’ils voudraient vous envoyer. Un peu comparable à une technique assez répandue contre le démarchage téléphonique. "Rappelez ce soir quand mon mari sera rentré, c’est lui qui s’occupe de ca.".
Mais en plus efficace – pour l’instant.
Si le serveur distant respecte le cadre de SPF, le mail est accepté directement – on milite comme on peut pour SPF, hein.

Après 3 jours d’opérations, voici les statistiques de délai sur Pocillopora :

$ sudo cat /var/log/mail.log /var/log/mail.log.0 | \
awk ‘ (/Greylisting in action, please come back in /) { delayed+=1 }
(/autowhitelisted/) { autowhitelisted+=1 }
(/Greylisting in action, please come back in / &&
 !/Greylisting in action, please come back in 00:30:00/) { redelayed+=1 }
END { print "Premiere tentative : \t"delayed"\nTentatives suivantes : \t\
"redelayed"\nFinalement accepte : \t"autowhitelisted }’
Premiere tentative :    4173
Tentatives suivantes :  458
Finalement accepte :    322

Sur les 4173 premières tentatives d’envoi (refusées temporairement via une erreur 451) , 458 ont été suivies d’autres tentatives aussi refusées temporairement (parce que le responsable n’était pas encore rentré), et au final 322 mails ont été acceptés. Enfin, jugés aptes à passer à la moulinette MIMEDefang.

Impact sur le nombre total de spams à examiner ? "Ca se voit sur le graphique", milter-greylist ayant été deployé samedi :

grey_in, c’est le nombre de mails qui se sont fait acceptés après avoir du être retransmis.
grey_delayed, c’est à chaque fois qu’un mail se fait acceuillir par un "repassez plus tard" (chaque mail peut compter plusieurs fois).
mail_in, c’est tous les mails qui sont relayés correctement.

Beaucoup moins de spams ont l’occasion d’affronter MIMEDefang, et le flot de mails légitimes n’a pas l’air de tarir.
Voilà qui s’annonce bien !

J’ai fini par trouver une solution à mes problèmes d’accents dans mes commentaires sur ce blog…
Ils venaient d’une mauvaise gestion de l’UTF-8 (ce système de codage des caractères qui prend en compte pratiquement toutes les langues écrites de la planète), quelque part entre Wordpress, le client mysql et le serveur mysql (4.0).

Après avoir passé un peu de temps sur google, j’ai eu confirmation qu’il semblait y avoir beaucoup de problèmes et autant de solutions, quelques-unes virant légèrement au vaudou.
Mon problème (qui est resté non-identifié) s’est fait résoudre par une mise à jour de mysql 4.0 vers mysql 4.1 – première version de mysql à supporter UTF-8 décemment, avais-je lu 10 secondes avant de tenter la mise à jour.

apt-get install mysql-server-4.1

Ah, et si vous avez jamais à changer l’encodage d’un fichier latin1 en UTF-8 (ou vice-versa): iconv, qui vient directement de la libc.

Valérie est bien contente de son Tréo 600, gnome-pilot faisant merveille pour synchroniser son emploi du temps, ses contacts et garder des sauvegardes. Seul hic, pas moyen a priori de récupérer les "photos" des entrailles de cet appareil magique.
Jusqu’à ce que vous tombiez sur ce petit utilitaire, treo-grab-img (fichier source).

Vous seriez bien avisé d’éditer le monsieur à la main pour arriver à
#define PORT "/dev/pilot"
en ligne 47.
Il faut installer le paquet libgnome-pilot2-dev, puis un petit
gcc -Wall -g treo-grab-imgs.c -o treo-grab-imgs -lpisock
plus tard, vous vous retrouvez avec un binaire qui s’appelle treo-grab-imgs.

Ensuite, commencez par mettre le démon gpilotd en pause, pressez sur la touche de synchronisation du Tréo (ce qui va créer le périphérique /dev/pilot) puis lancez treo-grab-imgs dans une console.
Devant vos yeux ébahis, le répertoire courant se fait peupler de toutes les photos qui étaient désespérément coincées dans le Tréo…
Un exemple ?
Home depot, un week-end assez récent :

Euh, je viens de me relire. C’est quand même dingue les contorsions qu’on arrive à s’imposer parfois, pour obtenir des choses assez simples d’un pingouin…

Ubuntu permet à l’utilisateur de s’affranchir du montage "manuel" des périphériques amovibles (clefs USB, carte mémoire flash, disques durs externes, iAudio X5…
Ubuntu 5.10 (Breezy) / hal / pmount le fait automatiquement, ce qui marche relativement bien quand un seul utilisateur est présent sur un seul serveur graphique de la machine. Relativement, parce que j’ai déjà vu des cas de démontage sauvage (malgré le clic droit, démonter).

En revanche, la situation s’aggrave en environnement multi-utilisateur. Le bout de Gnome chargé d’attribuer le périphérique nouvellement monté a tendance à le faire au petit bonheur la chance. Et comme chez moi, sont connectés en permanence votre serviteur, sa tendre épouse et Monsieur MythTV, vous imaginez le bazar.
J’exagère un tantinet, je n’ai pas mis mythtv dans le group plugdev, il ne rentre donc en fait pas dans l’équation.

Il existe un paquet Ubuntu censé géré ce genre de cas, multiseat, mais de toute évidence il va falloir attendre Daper pour qu’il soit utilisable. Si j’avais trouvé de la documentation pour son fichier de configuration (/etc/multiseat.conf il semble), je ne m’en serais que mieux porté.

Solution (bancale) que j’ai mise en oeuvre, en acceptant que les périphériques amovibles soient accessibles par n’importe que utilisateur connecté :

J’ai commencé par mettre les deux utilisateurs en question dans le même group Unix. Il fallait ensuite changer le masque de montage du périphérique pour que le group ait contrôle dessus, ce qui est malheureusement codé en dur dans pmount.
Il est cependant possible de forcer le montage de la manière qu’on veut – la lecture de la page de manuel de pmount aide bien à le comprendre, pour peu qu’il y ait la bonne entrée ™ dans /etc/fstab.

Pour savoir quoi mettre dans mon fstab, j’ai branché l’un des périphériques en question, noté ses options de montage via la commande mount, et je les ai reproduites dans /etc/fstab. J’ai ensuite changé le masque de montage (par défaut, umask=077 que j’ai changé pour umask=007). Je n’ai pas eu à changer le groupe de montage (gid), parce que mes deux utilisateurs sont dans le même groupe primaire – autrement, il m’aurait fallu configurer gid pour un groupe auquel les deux utilisateurs appartiennent.
J’ai aussi rajouté l’option user, car sinon les montage via /etc/fstab ne sont opérables que par root.

Chez moi, cela ressemble pour ma carte d’appareil photo à (sur une seule ligne) :

/dev/sdb1 /media/CANON_DC vfat   user,rw,noexec,nosuid,nodev,quiet,shortname=winnt,uid=1000,gid=1003,umask=007,iocharset=utf8    0       0

[ Mettre un iocharset à utf8 est un peu provocateur pour un système FAT, comme il rend le système de fichier sensible à la casse. Je prend cela comme une démarche volontariste pour établir UTF-8 en standard de facto. ]

On peut assez facilement étendre cette méthode aux périphériques qui ne doivent être montés que par un des utilisateurs, en adaptant le groupe (gid) et le masque de montage (umask).

Inconvénient de cette méthode à base de fstab, il faut répéter cette opération pour tous les périphériques qui doivent être accessibles par les deux utilisateurs.
Avantage, migrer de cette "solution" à quelque chose de plus permanent (chez Daper espérons-nous) devrait être aussi simple que supprimer ces entrées dans /etc/fstab.

Lu chez Veuve Tarquine, un excellent jeu de maux – pour l’instant, il vaut mieux essayer d’en sourire avant que cela ne dégénère. Curieux de savoir combien de temps il va falloir à cette saleté pour traverser l’atlantique…

Depuis que j’étais passé à Ubuntu sur le serveur de la maison, j’avais cette erreur ennuyante quand je tentais de réduire et recompresser des photos en rafale via la commande :

jhead -cmd "convert -quality 90 -geometry 600×600 &i &o" *.jpg

Le jhead était là pour remettre les informations Exif en place, une fois que convert (qui fait partie de imagemagick) les a supprimées au cours de ses manipulations de l’image.

En fait, cette version récente de convert n’efface plus les informations Exif pendant ses transformations. jhead se trouvait alors tout perdu, à vouloir écrire des informations Exif dans une image qui en avait déjà…

Ma petite conversion s’écrit donc maintenant :

for file in *.jpg
do
convert -quality 90 -geometry 600x600 $file $file
done

Paradoxe du progrès, ce qui se faisait en une ligne se fait maintenant en 4.
jhead conserve cependant toute ma confiance, et sert bien pour redresser les photos verticales prises par exemple par les appareils photo Canon récents (cf. drapeau "-autorot").

Même si ce message d’erreur n’est pas foncièrement anodin, il n’est pas effrayant de prime abord.
Il devrait l’être.

En bref, après avoir superbement ignoré ce message, je me suis retrouvé avec une sauvegarde sous forme d’un fichier tar de 20 Go… inutilisable. D’autant moins plaisant que toutes les photos depuis la naissance d’Arthur et Clément étaient dans cette archive – un peu plus de 4300 photos.

J’ai commencé par m’égarer du côté du gzip Recovery Toolkit. Très interessant, mais pas quand la corruption vient directement de tar. Quelques recherches plus tard, j’avais la confirmation que ma corruption à moi venait bien de tar (cf. titre).

Je me suis bien lancé dans du découpage d’archives en 4 à grands coups de dd, mais le gros des fichiers interessants restait bien caché. Et manipuler à l’aveugle un fichier de 20 Go a tendance à rapidement prendre du temps !

J’ai fini par échouer sur ATR, Advanced Tar Repair. Dur, dur, quand le logiciel le plus prometteur pour réparer un fichier tar – Unix s’il en est – tourne sous Windows. Leur modèle de vente est par ailleurs assez intéressant : ils commencent par vous fournir une version gratuite de leur logiciel, qui ne fait que lister les fichiers de l’archive qu’ils pensent pouvoir récuperer. Une dizaine d’heures de calculs sur un Pentium 3 pour arriver à la liste finale. Ensuite, vous sortez votre carte de crédit, et $50 plus tard vous avez la version complète du logiciel. Enfin, ils vous remboursent si la liste de fichiers récupérés n’est pas atteinte. Ce qui n’a pas été mon cas.

En résumé, beaucoup de contrariétés, mais des dégats assez bien contenus…

La morale de cette histoire: tar -tf, c’est bien pour avoir une idée visuelle de la sanité d’une archive, mais pas quand le nombre de fichiers de l’archive devient trop important…

Ce blog a beaucoup tardé, essentiellement pour des raisons techniques.
Il aurait du commencer le 8 septembre 2001, avec l’atterrissage à l’aéroport de Houston dans des décors à la Starsky & Hutch.
Entre la date, l’endroit et l’absence complète de repères, il y avait déjà de quoi faire.
Mais non, l’envie n’y était pas.
Pas encore.
On y arrive.
Silence, on tape.