Lunixité

Les IA cas, faux con

jdn06 — Wed, 13 Aug 2025 15:02:00 +0200

Comme beaucoup, j’imagine, je suis déjà passé par plusieurs phases dans mes jugements péremptoires sur ce qu’est devenu l’IA depuis l’apparition des grands modèles de langage (LLM). Essayons donc de décrire mon évolution à ce sujet, en espérant que je pourrai relire cet article dans quelques années sans avoir trop à en rougir.

C’est formidable

Ma première réaction fut assez enthousiaste : ne suivant pas les développements technologiques dans ce domaine, je ne m’attendais pas à ce qu’il soit possible de sitôt de converser ainsi librement avec une machine, en obtenant des réponses crédibles. Pourtant, en y réfléchissant aujourd’hui, je me dis que les progrès remarquables de la traduction automatique dans les années qui précédaient, annonçaient clairement une révolution à venir dans la production de textes. Je commençai par passer un peu de temps à jouer avec et à en parler autour de moi, assez surpris de ne trouver souvent qu’une indifférence polie, voire parfois une hostilité immédiate : le développement d’une IA textuelle semblait d’emblée menaçante pour certains — qui n’avaient pas forcément tort en prévoyant des impacts sociaux très rapides et pas forcément désirables.

C’est nul

Vint ensuite une phase de déception relative et de critique. D’une part, en tant qu’enseignant de lettres, toute utilisation professionnelle de l’IA pour me faire gagner du temps (rédaction de cours ou d’exercices de grammaire) était limitée par la pauvreté du rendu et les nombreuses erreurs et absurdités engendrées. Je me souviens par exemple que ChatGPT ne se trompait jamais sur l’orthographe d’un accord, mais était capable de citer une règle impliquant un accord qui contredisait son choix orthographique. Il pouvait par exemple écrire « ils se sont dit » tout en expliquant que dans cet exemple avec l’auxiliaire être il fallait accorder le participe passé avec le sujet du verbe. Comme toujours dans ces cas-là, il s’excusait quand on lui en faisait la remarque, tout en recommençant de plus belle.

Sur un plan plus créatif, il était aussi très facile aussi de le prendre en faute. Si on essayait de lui faire écrire un sonnet, le sens était à peu près correct, mais il lui était impossible de ne pas faire d’erreur concernant les rimes ; quant à leur disposition et au mètre… Si on essayait de lui faire résumer un livre, on se retrouvait avec quelque chose d’à la fois vague, très partiel et faux : des personnages inventés, le récit limité au début du livre etc. Bref, c’était épatant pour quelqu’un qui ne maîtrisait pas le sujet, moins pour les autres.

Pour ce que j’en comprenais par ailleurs, il était difficile pour ceux qui mettaient en place ces technologies de comprendre pourquoi le modèle ne fonctionnait pas correctement. Les réponses étant fondées sur l’utilisation statistique d’un corpus d’une taille inhumaine, difficile de comprendre comment se fabriquaient les hallucinations.

Les impacts négatifs de cette technologie furent aussi assez immédiats concernant l’attitude des élèves face au travail à la maison. Certains rendaient des exercices d’application d’un cours, sans mention de ce cours, mais en produisant des réponses aussi longues que vagues et creuses. Évidemment, interrogés à ce sujet, ils étaient incapables d’expliquer le sens de ce qu’ils avaient écrit. Les exposés étaient aussi parfois très baroques, avec des développements sans rapport avec le sujet et des élèves incapables d’expliquer ce que cette partie faisait là.

Quand enfin, je voulais résoudre un problème de programmation en Python ou en LaTeX, l’amateur que je suis ne trouvait pas grand chose d’intéressant dans les réponses de ChatGPT. Il proposait en gros de faire les choses entièrement différemment, et non de corriger le problème de mon code, qu’il était en général bien incapable d’expliquer.

Quand on mettait ceci en parallèle avec les investissements entrepris et l’impact environnemental de ces technologies, on ne pouvait que rester dubitatif et sceptique. Étais-je donc le seul à considérer que cela ne marchait pas vraiment ?

Par ailleurs, certains ingénieurs, comme Luc Julia, expliquaient qu’il était à craindre que la qualité des productions des IA ne fasse qu’empirer quand le corpus qu’elles utiliseront sera en partie composé de textes déjà produits par IA, du fait de la présence de plus en plus marquée de textes produits par IA sur le web. En se nourrissant de ses propres productions, elle s’éloignera encore davantage du modèle humain souhaité.

C’est quand même bien utile

Puis arrive le mois de juillet 2025. J’ai quelques problèmes informatiques à régler, qui m’ennuient parfois depuis longtemps : routage IPv6 de mon modem-routeur, connectivité parfois défaillante au redémarrage d’un de mes serveurs, utilisation de rspamd pour gérer DKIM, erreur de compilation LaTeX de certains tableaux depuis une mise à jour du paquet tabularray. Comme on m’a conseillé d’essayer Perplexity, et que je profite des vacances pour essayer de régler ces problèmes, j’interroge Perplexity quand je ne trouve pas de solution sur le web. Et là, le résultat est parfois un peu humiliant ! Alors que je viens de passer deux heures à lire de la documentation et des blogs pour mettre en place le DKIM dans rspamd, une simple question à Perplexity m’apporte la solution instantanément. Du coup, je me mets à l’interroger concernant les autres problèmes à régler et le bilan est très largement positif. Utilisé comme un moteur de recherche amélioré, l’outil est particulièrement performant : il permet de compiler et de résumer l’ensemble des informations disponibles sur le web et fait gagner beaucoup de temps. De plus, il permet aussi de gagner en assurance : on a moins tendance à se dire qu’on a pu négliger une partie du problème qu’on ne connaît pas ou à laquelle on n’a pas pensé. Les procédures de vérification permettent de faire le tour des problèmes connus, avec une certaine certitude : par exemple, si le modem est bien configuré de telle et telle manière, que le serveur a bien tel ou tel port ouvert et que nous pouvons vérifier qu’aucun paquet n’arrive jusqu’au serveur grâce à telle procédure, alors le problème ne vient probablement pas de chez moi. Le fait qu’il cite tous les sites consultés pour préparer sa réponse permet d’aller plus loin et de mieux comprendre la situation.

Dans la vie quotidienne, son utilisation peut aussi permettre de gagner du temps. J’arrivais cette semaine dans un petit village de la Meuse où je me mets au vert chaque mois d’août. Or cette année, les routes sont défoncées par de larges tranchées et les maisons couvertes de poussière. Interrogé, Perplexity m’explique aussitôt qu’il s’agit de travaux de collecte des eaux usées, liés à la construction d’une station d’épuration et que les travaux vont encore durer quelques semaines. Il cite les différents documents officiels qui annoncent ces travaux. J’aurais certainement pu trouver une réponse grâce à un moteur de recherche, mais la démarche aurait été beaucoup plus laborieuse, car les liens renvoyés par le moteur n’auraient pas tous été pertinents, loin de là.

Je reste en revanche très perplexe devant les erreurs grossières du logiciel :

l’outil peut tout à fait demander d’utiliser une option qui n’existe pas pour la commande utilisée, sous prétexte qu’elle existe pour une autre commande sous une autre plateforme ;
il m’a demandé d’installer et de configurer unbound sur FreeBSD puis a donné des instructions pour lancer local_unbound; j’ai imaginé qu’il s’agissait d’un des lanceurs possibles de l’application, alors qu’en fait c’est un programme disponible par défaut (donc qui ne s’installe pas) et dont les fichiers de configuration sont situés ailleurs. Beaucoup de temps perdu, puisque mes modifications de la configuration n’avaient aucun impact sur le programme lancé — et pour cause…
il peut se tromper en inversant une adresse IPv6 pour le reverse DNS : le début et la fin sont corrects, mais les chiffres du milieu sont trop nombreux, et inversés par deux. Comme je n’avais pas vérifié en détails, cette erreur m’a fait perdre une bonne heure !

Bref, un outil qui fait gagner du temps dans certains cas, si on est assez vigilant pour ne pas en perdre…

Compiler Unison dans Termux

jdn06 — Thu, 08 Aug 2024 09:51:00 +0200

Unison est un programme au centre de ma gestion de la synchronisation de mes données d'un poste à l'autre. Ce programme est très fiable, précis et permet de repérer et de réparer très facilement les conflits de version. Contrairement à Nextcloud ou à Syncthing, il n'agit que lorsqu'on le lui demande et liste les actions qu'il va effectuer avant de faire quoi que ce soit. Contrairement à Git, il est assez bien adapté aux fichiers binaires et ne conserve pas l'ensemble des modifications apportées, ce qui tiendrait beaucoup de place avec de gros fichiers binaires, comme des images, de l'audio ou de la vidéo.

Bref, j'en ai besoin, partout où je travaille ou prends des notes. Or, sur un téléphone Android, il n'est pas disponible dans les magasins d'applications comme Google Play Store ou F-Droid. Il n'est pas non plus disponible dans Termux. Pour l'utiliser, le plus simple est d'utiliser depuis Termux PRoot Distro et d'installer par exemple Alpine Linux, qui contient un paquet Unison. Malheureusement, cela ne fonctionne pas sur mon vieux Fairphone 2, probablement à cause de son vieux processeur 32 bits.

J'ai donc pris mon courage à deux mains et tenté de compiler OCaml, le langage dans lequel est écrit Unison, puis Unison dans Termux. Comme la chose n'est pas très évidente, je décris le processus ici, afin de faire gagner peut-être un peu de temps à ceux qui voudraient faire la même chose.

pkg install build-essential libandroid-shmem (Il est possible qu'il faille ajouter d'autres dépendances, car je ne suis pas parti d'un Termux fraîchement installé et ne me souviens plus bien de ce que j'ai pu bidouiller avant…)
mkdir $HOME/tmp && export TMPDIR=$HOME/tmp
Télécharger et décompresser ocaml-5.2
À l'intérieur de la structure décompressée, lancer ./configure --prefix=$PREFIX --disable-warn-error --without-afl LDFLAGS="-landroid-shmem"
Puis le classique make suivi de make install
En cas d'erreur de type : call to undeclared function 'issetugid'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 418 | if (!issetugid ()), ajouter -Wno-implicit-function-declaration dans la variable CFLAGS du Makefile.config et recommencer le make.
Dans un autre emplacement, télécharger et décompresser unison-2.53.5
À l'intérieur de la structure décompressée, lancer make NATIVE=false, puis make NATIVE=false install

Voilà pour la partie compilation et installation. Reste un problème à l'utilisation d'Unison ainsi compilé. L'utilisation avec ssh est bloquée par le message :

Fatal error: Warning: the archives are locked. If no other instance of unison is running, the locks should be removed.

Mais les fichiers mentionnés dans le message n'existent pas et ne peuvent donc être supprimés pour débloquer la situation. J'ai d'abord pensé que les deux machines étaient perçues comme étant la même appelée localhost car Android ne gère pas le hostname. J'ai donc utilisé la commande export UNISONLOCALHOSTNAME=montelephone. Cela a modifié légèrement le message d'erreur (le nom du fichier d'archive verrouillé n'était plus le même), mais n'a pas suffi à régler le problème. En recherchant en ligne, on trouve quelques informations expliquant que ce problème d'archives verrouillées serait probablement lié au SELINUX déployé sur Android. Comme il faut rooter le téléphone pour agir sur le comportement de SELINUX et que la maîtrise de SELINUX n'est pas tout à fait à ma portée, ne l'utilisant pas, j'ai plutôt essayé de contourner le problème. En lançant la synchronisation avec l'option -ignorelocks le problème disparaît.

Évidemment, ce n'est pas idéal, et il faut faire alors très attention de ne pas lancer plusieurs synchronisations en même temps. Mais étant le seul utilisateur, je devrais pouvoir y parvenir en me montrant un peu rigoureux. Voilà en tout cas le principal verrou à mon utilisation d'un téléphone Android disparu.

L'Inutile Beauté du Pinephone

jdn06 — Thu, 01 Aug 2024 11:03:00 +0200

La liberté, c'est comme la beauté, ça ne se mange pas en salade. S'il est très satisfaisant de pouvoir utiliser depuis 2020 des téléphones conçus pour fonctionner sous Linux, sans la moindre trace d'Android, il est fâcheux qu'après quatre ans de développement, les progrès réalisés n'aient pas réellement amélioré leur utilisation comme téléphone. Certes, il est formidable de pouvoir accomplir tout un tas de choses avec les mêmes outils que sur son poste de travail Linux. Synchroniser ses prises de notes avec Unison ou Git et les compléter avec Emacs Org-mode est par exemple une chose triviale, plutôt compliquée à reproduire sur la plupart des autres téléphones.

Reste qu'un téléphone a pour fonction première de joindre les autres par la voix et que la chose stagne, voire régresse avec le Pinephone. Listons ici quelques-unes de mes déconvenues :

Même lorsque les conditions de réception sont parfaites, mes interlocuteurs au téléphone doivent toujours tendre l'oreille, tant le son est faible et étouffé. Le pilote libre du modem ne règle pas vraiment le problème, malheureusement.
Le pilote du modem (celui du constructeur comme le libre) plante assez régulièrement, obligeant à redémarrer le téléphone plusieurs fois par jour, ce qui n'améliore pas l'autonomie de l'engin.
L'autonomie très faible rend justement l'utilisation quotidienne assez aléatoire ; il m'est arrivé plusieurs fois de ne pas pouvoir passer un appel important parce que le téléphone s'était déchargé — y compris parce qu'il s'était allumé tout seul sans que je le remarque et avait vidé sa batterie sur la page de demande de clé de chiffrement. Il est possible d'avoir toujours sur soi une petite batterie externe, mais le problème est trop fréquent pour que cela soit vraiment pratique.
En voiture, la connexion par Bluetooth pour utiliser le kit mains libres ne fonctionne toujours pas. Le téléphone se connecte, mais un sifflement aigu est la seule chose qui sort alors des haut-parleurs.
La raréfaction du réseau 3G au profit de la 4G complique aussi la donne depuis quelque temps. En effet, mon Pinephone est supposé pouvoir utiliser le VoLTE, mais cela ne fonctionne pas pour une raison que je n'ai pas réussi à comprendre, malgré un certain investissement en temps à traquer les logs du modem. Il faut repasser manuellement de la 4G à la 3G pour passer les appels. Et je me retrouve de plus en plus souvent dans une situation où je quitte un bon réseau 4G pour rien puisqu'il ne parvient pas toujours à se connecter à une 3G devenue rare. Je ne peux pas alors passer mon appel. Ce problème va certainement s'étendre dans les années qui viennent.

J'ai donc décidé de renoncer en partie à l'Inutile Beauté du libre et à utiliser un téléphone qui permette vraiment de téléphoner. J'ai remis en service mon Fairphone 2 de 2016. J'attendais depuis bien longtemps un passage d'UBPorts à Focal et voyant que cela n'arriverait pas, j'avais décidé d'essayer un Android déGooglisé dessus pour voir ce que cela donnait. J'ai donc testé /e/OS. Et pour quelqu'un qui vient de passer 3 ans sous Pinephone, ce Fairphone de 2016 reste très spectaculaire. Si je ne comptais au départ m'en servir que pour passer des appels et partager ma connexion pour mon Pinephone, il m'apparut assez vite qu'il pouvait avantageusement remplacer le Pinephone. La vitesse de démarrage, la fluidité et l'autonomie sont par exemple sans rapport avec le Pinephone, mais aussi avec ce même Fairphone sous UBPorts 16.04. Certaines choses vont rester compliquées, même si Termux permet d'étendre un peu les possibilités d'un téléphone Android. J'ai par exemple essayé d'y compiler Ocaml pour pouvoir compiler Unison, mais cela ne fonctionne pas. L'installation d'Unison par proot-distro bute sur une erreur de mémoire et je pense que le vieux processeur 32 bits du téléphone n'y est pas pour rien. Les installations de LazyVim et de Doom Emacs en console ont en revanche été faciles. Je vais essayer d'installer Doom Emacs en graphique, ce qui paraît plus compliqué.

Le constat reste cependant un peu amer. Si même un libriste convaincu (d'aucuns diront doctrinaire) avec des besoins smartphoniques personnels et professionnels très limités ne peut se satisfaire au quotidien de ce qu'offrent actuellement les téléphones sous Linux, j'ai bien peur que la base d'utilisateurs n'aille pas en s'élargissant.

Le Raspberry à la rescousse du Pinephone

jdn06 — Sat, 06 Aug 2022 17:12:00 +0200

Très satisfait de mon Pinephone sous Mobian, j'ai voulu profiter que les stocks de Pine64 n'étaient pas épuisés pour acheter la version la plus récente du Pinephone, la Beta Edition, avec ses 3 Go de RAM et ses 32 Go de disque SSD, alors que le UBPorts CE que je possédais se contentait de 2 et 16 Go. Ainsi je transformerai le plus ancien en téléphone de secours immédiatement disponible en cas de pépin.

Le téléphone arrive avec Manjaro Plasma Mobile préinstallé. Passée l'euphorie des premiers instants, avec quelques points forts assez marqués par rapport à Mobian Phosh (la fluidité de l'interface, le clavier virtuel bien pensé, les copier-coller, le navigateur Angelfish, le terminal plus utilisable, KWeather etc.) je me retrouve assez vite coincé par les bugs concernant l'accès internet par la 4G, plutôt rédhibitoires, et l'intégration très limitée de Nextcloud. Je lutte un peu puis renonce et décide d'installer Mobian Phosh.

Malheureusement, les images récentes de l'installateur Mobian ne fonctionnant pas, j'ai jeté l'éponge après quatre ou cinq essais et ai donné sa chance à Manjaro Phosh. Et si je regrette de renoncer au chiffrement total du téléphone, le reste me donne entière satisfaction : l'interface de la dernière version de Phosh est beaucoup plus réussie, l'interface est plus fluide (peut-être du fait du meilleur matériel), les logiciels plus à jour et plus variés. Et puis, j'ai Archlinux sur tous mes ordinateurs et je maîtrise mieux ce système que Debian. Si les finitions sont peut-être moins soignées que Mobian, Manjaro Phosh reste agréable à utiliser. D'autant que les développeurs ont pris le parti de mettre à jour la distribution stable avec parcimonie, ce qui limite un peu les risques de casse, là où Mobian conseille d'utiliser Bookworm et de suivre son rythme effréné de mise à jour.

Vint donc il y a quelques jours ma première mise à jour de Manjaro Phosh. Et là, je vis que la simplicité de l'empaquetage d'Archlinux, qui fait que tout utilisateur peut facilement empaqueter ou modifier des paquets, n'avait pas que des avantages. La complexité des mises à jour de Debian sert un but essentiel : ne jamais casser le système en cas de mise à jour partielle. Ce n'est pas le cas d'Archlinux. Or, pour une raison qui m'échappe, mon téléphone a connu quelque chose comme un kernel panic durant la mise à jour. Après lui avoir laissé une bonne heure dans l'espoir qu'il terminerait la mise à jour, même si l'interface ne répondait plus, je finis pour forcer le redémarrage, et là : catastrophe ! Le noyau démarre (c'est déjà pas mal) mais l'interface graphique ne se lance pas et je me retrouve avec un login de console sans possibilité d'utiliser un clavier pour la saisie.

En cherchant un peu sur le web, je trouve surtout des commentaires invitant à réinstaller, ce que je préférerais vraiment éviter : il y a pas mal de boulot après pour tout réinstaller et configurer !

J'utilise donc la technique que j'emploie avec Archlinux lorsque le noyau ne permet plus le démarrage : un démarrage sur une autre machine, un montage du disque, puis un chroot pour tout réparer. L'installation que j'ai effectuée de Tow Boot aide bien puisque je peux ainsi démarrer mon téléphone pour qu'il se monte sur l'ordinateur auquel il est branché comme une simple clé USB.

Un problème cependant auquel je n'avais pas pensé : lorsque je lance mon arch-chroot j'ai droit à une erreur car je ne peux lancer des exécutables compilés pour AARCH64 depuis mon noyau pour AMD64. Le chroot échoue donc.

C'est alors que je pense au petit Raspberry 400 que je me suis offert l'an dernier. Je l'avais acheté pour bidouiller, mais aurais eu bien du mal à justifier cet achat en m'appuyant sur son utilité, car je n'en faisais rien de vraiment essentiel. Or, je l'ai justement réinstallé il y a peu, afin qu'il fonctionne sous la nouvelle version 64 bits de l'OS maison. Il utilise donc à présent la même architecture que mon Pinephone. Comble de bonheur, cette distribution issue de Debian comprend un paquet arch-install-scripts qui contient arch-chroot, ce qui simplifie les choses.

Reste la partie pas drôle : le système du Pinephone est partiellement cassé. De nombreux paquets ne peuvent être réinstallés sans intervention, car ils se plaignent de fichiers déjà installés qui n'ont pas été enregristrés comme leur appartenant. Après avoir longuement nettoyé tout cela à grands coups de rm et de pacman -S --overwrite, je finis par lancer une réinstallation générale de tous les paquets afin d'avoir un système propre, avec la commande pacman -Qqn | pacman -S -

Lorsqu'enfin je redémarre, tout est rentré dans l'ordre. Et je sais maintenant à quoi peut me servir mon petit Raspberry 400 !

Partage de connexion sous Mobian

jdn06 — Thu, 21 Jul 2022 10:50:00 +0200

Depuis presque neuf mois que je suis passé au Pinephone et à Mobian, venant d'UBPorts, je suis plutôt content de mon téléphone. Néanmoins, une fonctionnalité que j'utilise beaucoup lorsque je voyage, le partage de connexion, m'a joué quelques tours, s'obstinant à ne fonctionner que lorsque je la testais et n'en avais pas vraiment besoin. Dans le courant du mois de juin, la situation s'est même dégradée, car le partage ne fonctionnait plus du tout. Le téléphone amorçait la connexion mais ne terminait jamais l'opération et renonçait après une minute. L'opération en ligne de commande, avec quelque chose comme sudo nmcli device wifi hotspot ifname wlan0 con-name Hotspot ssid Pinephone password HotspotPassword, ne réussissait pas mieux. En regardant les logs, je m'aperçus que la seule erreur visible était un timeout de wpa_supplicant. Malheureusement, mes recherches sur le web au sujet de cette erreur sur un Pinephone ne donnèrent rien du tout. À croire que j'étais le seul à avoir ce problème.

À force de tourner le problème dans tous les sens, un peu inquiet de ne pouvoir utiliser ma connexion durant les vacances d'été, j'eus l'idée d'une solution radicale : puisque le problème semblait venir de WPA_supplicant, il fallait utiliser autre chose. Et justement, j'avais lu ici ou là quelques articles sur IWD, même si je ne l'avais jamais utilisé.

Pour remplacer WPA_supplicant par IWD dans mon téléphone Mobian, j'ai utilisé le wiki Debian consacré à ce sujet. Après avoir installé le paquet iwd j'ai édité /etc/NetworkManager/NetworkManager.conf et ajouté :

[device]
wifi.backend=iwd

Puis j'ai lancé les trois commandes pour relancer NetworkManager avec la nouvelle configuration :

sudo systemctl stop NetworkManager
sudo systemctl disable --now wpa_supplicant
sudo systemctl restart NetworkManager

Et cela a fonctionné ! Le partage de connexion s'est enclenché sans problème. Cerise sur le gâteau : IWD étant conçu pour optimiser le matériel, il est possible que cette modification améliore un peu l'autonomie de mon Pinephone, point faible de ce téléphone.

Pinephone sous Mobian

jdn06 — Sun, 30 Jan 2022 10:27:00 +0100

Après les difficultés que j'ai eues pour trouver un remplaçant sous UBPorts à mon BQ lorsque j'ai cassé son écran, j'ai voulu prendre les devants et m'offrir un téléphone d'avance lorsque l'occasion s'est présentée. Aussi ai-je fait l'acquisition d'un Pinephone UBPorts Edition il y a maintenant plus de deux ans. Si je savais en l'achetant que l'OS était encore loin de ce qu'il pouvait être sous Fairphone 2, j'espérais qu'il progresserait assez rapidement pour atteindre un niveau comparable. Il s'avéra malheureusement que, quel que soit le canal choisi, le développement se mit à stagner.

Pendant ce temps-là, UBPorts concentrait ses moyens sur le passage à 20.04, objectif qu'il poursuit toujours à l'heure actuelle. Depuis cet été, la version 16.04 n'est plus vraiment supportée par Canonical et il devient compliqué d'utiliser certains programmes dans Libertine, du fait de cette fin de support. Je lus alors qu'il n'était par ailleurs pas du tout certain que le Fairphone 2 puisse passer à la version 20.04 d'UBPorts (ici puis ici, par exemple) et je me dis qu'il fallait peut-être franchir le pas et essayer d'installer autre chose sur mon Pinephone rangé dans un placard en attendant des temps meilleurs.

J'hésitai un peu entre Postmarket OS, Manjaro et Mobian et ce dernier finit par emporter la mise du fait de la possibilité qu'offrait le logiciel d'installation de chiffrer la partition système. Cette disposition basique de sécurité n'était jusque-là offerte sur aucun OS mobile libre, à ma connaissance.

Pour un OS beaucoup plus récent qu'Ubuntu Touch, la surprise est franchement très agréable : tout ce qui peut irriter un peu le linuxien de bureau sur Ubuntu Touch (impossibilité d'installer des applications avec l'outil apt, sauf à utiliser un container Libertine, applications habituelles manquantes etc.) disparaît ici : toutes les applications présentes sous Debian peuvent être installées, même si l'interface n'est pas toujours utilisable. Je peux donc par exemple installer une synchronisation des favoris avec Firefox ou un client de courriel complet comme Geary.

Grâce à Mosh (et à Purism), l'utilisateur de Gnome se retrouve en terrain familier, mais avec une interface plus adaptée aux petits écrans. Si l'ensemble est moins agréable (finitions et gestes) à utiliser que Lomiri (ex-Unity), l'intégration par défaut de tous les composants de la distribution est assez bonne.

J'avais peur de ne pas réussir à intégrer un logiciel de double authentification, mais Gnome Authenticator fonctionne très bien. En plus de LibreOffice, j'ai pu installer une TeXLive parfaitement à jour, Doom Emacs et Unison ; j'ai donc tous les outils dont j'ai besoin pour travailler. Les comptes en ligne, comme un Nextcloud auto-hébergé, sont directement intégrés à Gnome, comme dans la version Bureau de Gnome.

Mon clavier pliable Bluetooth fonctionne très bien. Seule ombre au tableau, la connexion avec l'ordinateur de bord de ma voiture, via Bluetooth, qui fonctionnait assez bien avec mon Fairphone 2 sous UBPorts, ne fonctionne plus ici. En même temps, je ne l'utilisais que rarement.

Bref, après quelques jours d'essai, j'ai transféré ma carte SIM de mon Fairphone 2 à mon Pinephone et suis resté depuis la mi-décembre sur ce nouveau téléphone. Le téléphone démarre plus vite que le précédent, mais le lancement d'application est plus lent. La batterie reste pour l'instant un peu juste pour une utilisation tout au long de la journée. Il faut parfois jouer avec la mise à échelle de l'interface pour pouvoir utiliser certains programmes. Je n'ai pas encore réussi à faire fonctionner le GPS. Mais au quotidien, mon téléphone me sert surtout à prendre des notes org-mode synchronisées, à passer des appels et à envoyer des messages, ce que ce téléphone fait plutôt mieux que le précédent (Emacs graphique contre Emacs en terminal sous Libertine). Finalement, l'ensemble fonctionne assez bien au quotidien, surtout depuis que je l'ai passé à Bookworm, ce qui permet de bénéficier des dernières mises à jour de l'interface Phosh.

LaTeX pour dyslexiques

jdn06 — Sat, 24 Oct 2020 16:51:00 +0200

Cela faisait un moment que je lisais régulièrement, chez les utilisateurs de LaTeX, des propos expliquant que leur productivité avait été grandement améliorée lorsqu’ils s’étaient mis à utiliser des outils de programmation tels que les Makefile ou Git.

Cet été, j’ai finalisé un vieux projet qui m’a amené à produire des pdf d’un livre rédigé en LaTeX dans une dizaine de formats, afin de le rendre facile à lire sur toutes les tailles d’écran. Seuls les en-têtes du livre changeaient, le contenu du livre étant dans un fichier à part, appelé par une commande \input{Texte}. Reste que taper une vingtaine de fois lualatex et le nom du fichier est assez fastidieux, ce qui m’a poussé à m’intéresser de plus près aux Makefile — et à les adopter ensuite pour mes productions scolaires cette année. Pour Git en revanche, je le trouve peu adapté pour mon utilisation professionnelle : je synchronise déjà tous mes fichiers par Unison sur un système avec snapshots ZFS et je ne voyais pas bien comment intégrer Git à tout cela. Pourtant, la gestion de version me paraissait utile et j’ai opté pour un outil plus frugal, RCS qui fera peut-être l’objet d’un article à venir.

Pour l’heure, mon propos est de décrire la manière dont les Makefile m’ont permis d’améliorer ma productivité, lorsque je dois produire parallèlement des documents en format classique et en format adapté aux élèves dyslexiques, c’est-à-dire avec la police OpenDyslexic, un agrandissement en format A3 et éventuellement un nombre de questions et un barème adaptés.

J’ajoute à l’en-tête les lignes suivantes pour la police et l’agrandissement :

:::latex
% Police
\newfontfamily\policedys[Ligatures=TeX]{Open Dyslexic}

% Agrandissement
\pgfpagesuselayout{resize to}[a3paper,landscape]

Je modifie l’environnement avec lequel j’écris le corps de texte, pour y insérer la police définie ci-dessus :

:::latex
% Environnement corpstexte pour police et numéros de ligne
%\newenvironment{corpstexte}{\fontfamily{jkplos}\selectfont\linenumbers\resetlinenumber}
\newenvironment{corpstexte}{\onehalfspacing\policedys\small\linenumbers\resetlinenumber}

S’il s’agit d’un questionnaire, je crée des variables qui me permettront de définir dans l’en-tête s’il s’agit d’une version classique, d’une version dyslexique ou d’un corrigé :

:::latex
\newboolean{correction}
\newboolean{dys}
\setboolean{dys}{true}
\setboolean{correction}{false}

Les différents fichiers d’en-tête se terminent par \input{monControle-Texte} qui va charger la partie commune. Cette partie commune pourra intégrer des conditions portant sur les variables créées dans l’en-tête, grâce au paquet ifthen.

Pour modifier le barème de la question : \question[\ifthenelse{\boolean{dys}}{3}{2}] Ma question La question vaudra 3 points dans la version dyslexique et 2 points dans l’autre.
Pour ne poser une question qu’aux non-dyslexiques : \ifthenelse{\boolean{dys}}{}{\question[1] Ma question}

Chaque question est accompagnée de sa réponse, mais celle-ci n’est utilisée que par le fichier d’en-tête du corrigé, qui commence par \documentclass[11pt,a4paper,answers]{exam}, alors que les versions classiques et dyslexiques ne contiennent pas l’option answers.

La réponse est écrite dans un environnement \begin{solutionorlines}[9em] qui placera ici un espace vide de taille 9em dans la version contrôle — pour que les élèves répondent — et la solution dans la version du corrigé.

Pour construire ou reconstruire si nécessaires les versions classique, dyslexique et corrigé et nettoyer les fichiers intermédiaires, j’utilise donc un Makefile du type :

NOM = monControle

all : $(NOM).pdf $(NOM)-dys.pdf $(NOM)-corrigé.pdf

$(NOM).pdf : $(NOM).tex $(NOM)-Texte.tex
        lualatex $(NOM).tex
        lualatex $(NOM).tex

$(NOM)-dys.pdf : $(NOM)-dys.tex $(NOM)-Texte.tex
        lualatex $(NOM)-dys.tex
        lualatex $(NOM)-dys.tex

$(NOM)-corrigé.pdf : $(NOM)-corrigé.tex $(NOM)-Texte.tex
        lualatex $(NOM)-corrigé.tex
        lualatex $(NOM)-corrigé.tex

clean:
        rm -f $(NOM)*.aux  $(NOM)*.log  $(NOM)*.toc  $(NOM)*.out

Le fait d’utiliser une variable pour le nom du contrôle me permet de recopier le Makefile à chaque nouveau contrôle et de ne modifier que la variable. Il me suffit alors de lancer un petit make all suivi d’un make clean pour mettre à jour les trois fichiers d’un coup !

ZoL - ZFS or Linux ?

jdn06 — Sat, 08 Feb 2020 10:36:00 +0100

C’est avec tristesse que je reprends le titre légèrement modifié d’un billet de 2013 qui célèbrait la sortie de la première version stable du portage de ZFS pour le noyau Linux.

J’exprimais alors mon enthousiasme pour les 6 mois d’utilisation que j’avais derrière moi et mon espoir que son utilisation puisse se simplifier et se généraliser, malgré l’obstacle initial des licenses.

Sept ans plus tard, je reste très admiratif devant le travail accompli et le développement de nouvelles fonctionnalités, au point que toute la communauté d’OpenZFS s’appuie maintenant sur ZFSonLinux et non plus sur Illumos. Techniquement, je n’ai jamais eu de problèmes toutes ces années et suis plus que jamais un fan de ce système de fichiers. BTRFS, qui possède une partie des fonctionnalités qui m’intéressent, a été pour moi beaucoup plus capricieux sur la même période. Heureusement, je ne lui confie mes données qu’avec prudence.

Pourtant, depuis un an, les choses vont assez mal, non techniquement, mais politiquement. J’avais d’abord accueilli favorablement la décision de Canonical d’intégrer ZFS dans Ubuntu en invoquant des arguments juridiques assez vagues. J’avais même espéré que cela inciterait Oracle, qui avait investi dans le développement de BTRFS et possédait aussi ZFS depuis son acquisition de Sun, à régler de manière définitive le problème de la license de ZFS.

Malheureusement, l’initiative de Canonical semble avoir eu l’effet inverse : 2019 aura été l’année où les développeurs du noyau Linux ont paru vouloir la peau de ZFSonLinux. Si je comprends parfaitement que les développeurs du noyau ne veuillent pas intégrer ZFS du fait de sa license, voire qu’ils s’opposent à l’initiative de Canonical, j’ai plus de mal avec l’idée que le développement de modules séparés à compiler soi-même ou à distribuer séparément du noyau leur pose problème. Les déclarations outrancières de Torvalds et d’autres développeurs du noyau contre la technologie ZFS indiquent bien qu’il ne s’agit pas seulement d’une question de license. ZFS vient d’ailleurs, il est meilleur sur bien des points que les systèmes de fichiers intégrés au noyau Linux ; il a peut-être nui au succès de BTRFS ; il doit donc être éradiqué.

L’utilisation de mises à jour du noyau Linux dans le seul but d’empêcher le bon fonctionnement des modules de ZFS sur ce noyau est assez évidente et permet aux développeurs d’éviter d’endosser sous une forme plus juridique (plus coûteuse en termes de finances et d’image) un procès pour violation de licenses.

Je dois dire que devant l’injonction que semblent nous faire Linus Torvalds et Christoph Hellwig de choisir entre Linux et ZFS, je suis assez sûr de rester sur ZFS.

En plus de mon serveur, j’ai déjà un poste de travail sous FreeBSD. Je perdrai moins à quitter Linux qu’à quitter ZFS. Et plus les années passent, et plus la querelle entre GPL et BSD, qui me paraissait byzantine il y a quelques années, m’apparaît comme un véritable enjeu qui définit l’idée qu’on se fait de la liberté.

Gopher et les Pubnix, retour vers le futur

jdn06 — Sat, 13 Apr 2019 10:24:00 +0200

J’ai découvert cette année un protocole et une communauté qui s’accordent bien avec mon goût pour le minimalisme des interfaces technologiques : Gopher et les Pubnix.

Gopher est un vieux protocole qui peut paraître désuet en 2019 du fait de ses limites :

Pas de liens dans les pages de texte elles-mêmes, mais seulement dans les menus de l’arborescence qui les précède.
Pas d’images dans les pages de texte, mais seulement comme des documents téléchargeables depuis les menus de l’arborescence.
Pas de support sur les navigateurs Web d’aujourd’hui, si ce n’est par une extension à ajouter.
Pas de chiffrement TLS.
Aucune mise en forme du texte disponible : les fichiers sont du pur txt.

En fait, il ressemble un peu à du FTP amélioré pour permettre une navigation plus fluide entre les différentes pages d’un serveur et entre les différents serveurs.

Pourquoi donc s’intéresser à une telle vieillerie ? Tout ce que Gopher peut faire, le Web le peut aussi, et de manière plus riche et facile.

Oui, mais le Web est devenu sous bien des aspects un « machin » hors de contrôle pour l’utilisateur. Lorsque j’ouvre une page Web sur mon ordinateur :

Le navigateur communique en réalité avec parfois plusieurs dizaines de sites, pour charger une police, une image, une vidéo, une publicité, un compteur de visites etc.
Le navigateur écrit sur mon ordinateur nombre de cookies sans lesquels de nombreux sites ne fonctionneront pas correctement. Ceux-ci leur permettent de tracer les utilisateurs et de générer des données les concernant.
Le navigateur exécute par défaut des scripts sur ma machine, à moins d’installer une extension pour l’en empêcher. Ces scripts peuvent faire beaucoup de choses que je ne souhaite pas, mais nombre de sites ne fonctionneront pas si je ne les active pas. À moins de les lire un à un, il me faut faire globalement confiance à une industrie qui n’a pas brillé par son respect des utilisateurs ces dernières années.
Il arrive même que le navigateur se mette à télécharger puis lire une vidéo ou un extrait musical de son propre chef, que ce soit à des fins publicitaires ou non.

Bref, naviguer sur le Web est de nos jours un double renoncement : renoncement à la maîtrise technologique et renoncement à la vie privée.

Si Gopher protège de ces travers, c’est en grande partie à cause de son échec : sa technologie n’a pas vraiment évolué depuis le milieu des années 1990 et il n’a plus été utilisé pour vendre quoi que ce soit depuis.

Si ses limitations peuvent paraître frustrantes, il ramène un peu d’efficacité dans la navigation en permettant de se concentrer sur le texte lui-même et en limitant un peu la sérendipité, enrichissante et agréable en soi mais qui limite parfois l’efficacité de la navigation sur le Web en éloignant l’internaute de son intention initiale.

Les outils que j’utilise pour naviguer sur Gopher, Lynx et VF-1, participent aussi de cette frugalité technologique, d’autant que le fait qu’ils s’utilisent en console permet d’interrompre et de reprendre la navigation là où j’en étais en les lançant dans un tmux sur mon serveur, fonctionnalité que les navigateurs graphiques implémentent avec une certaine lourdeur.

J’ai donc ouvert un Gopherhole qui abrite une version texte de mes blogs à l’adresse suivante : gopher://gopher.nappey.org

Ce lien ne peut être ouvert qu’avec un navigateur compatible ou à travers un proxy.

J’ai aussi découvert les Pubnix, des Unix publics dont on peut devenir utilisateur et qui abritent entre autres un serveur Gopher. J’ai choisi republic.circumlunar.space, mais il en existe bien d’autres : sdf.org, tilde.town etc.

Ces communautés sont un peu des contre-réseaux sociaux. Par la taille d’abord, seulement quelques dizaines d’utilisateurs, un peu plus pour les plus gros. Par les principes ensuite, puisque les outils sont libres et co-développés au maximum par les utilisateurs. Ainsi, sur circumlunar.space, le BBS qui permet de communiquer entre utilisateurs, Telem, a été développé localement en Lua.

Si Mastodon est libre et décentralisé, le rapport de ses utilisateurs à l’outil reste globalement le même qu’avec Twitter, même pour ceux qui s’auto-hébergent. Rares sont ceux qui participent au développement ou font évoluer l’outil. Ici, il s’agit bien d’un réseau collaboratif, où les utilisateurs se connaissent et sont acteurs de leur réseau. Ça ne résout pas tous les problèmes des réseaux, mais cela rend les solutions beaucoup plus souples et adaptées : chacun peut par exemple donner son avis sur les informations qui peuvent être publiquement visibles, celles qui ne seront visibles que des autres membres de la communauté et celles qui doivent rester invisibles.

Mon Sway réalisé

jdn06 — Sat, 23 Mar 2019 10:01:00 +0100

Si je relis les propos que j’ai pu tenir au moment de la sortie de GNOME 3, en 2011, je m’aperçois que mon regard sur cet environnement a beaucoup évolué, sans pour autant que l’essentiel ne change :

Les bugs ayant disparu, la lourdeur de l’environnement ayant un peu diminué, l’ensemble est devenu utilisable sur une machine moyennement performante.
Je trouve même l’utilisation agréable et bien conçue quand on est sur un ordinateur mobile ou sur un écran de taille mesurée, avec un clavier sous les doigts.
Je reste rétif à l’idée d’utiliser cet environnement sur un grand écran 25’ avec une souris : bonjour les gesticulations et la nausée. Du coup, mon ordinateur de bureau est resté sous Mate.

Si donc mon Thinkpad d’occasion se révèle très agréable et fluide sous GNOME 3, la puissance limitée de l’eeePC qui l’a précédé m’a obligé à chercher des solutions plus légères ces dernières années, au point que j’ai pris goût à la puissance et à la simplicité du gestionnaire de fenêtre i3. Cet environnement par pavage de fenêtres est d’autant plus agréable qu’on aime travailler sur le terminal et ne pas utiliser la souris. Il sera parfait pour tous ceux qui préfèrent le gestionnaire de fichiers Ranger à Nautilus (appelé de nos jours platement Fichiers).

Comme j’ai fait en sorte d’utiliser quelques technologies encore expérimentales sur ma nouvelle machine, elle est en Btrfs avec snapshots et en Wayland. Du coup, j’étais particulièrement impatient de voir Sway 1.0 sortir sur Archlinux. En effet, j’avais testé Sway en version 0.15 sur ma machine précédente, mais les bugs étaient encore trop nombreux pour une utilisation quotidienne efficace. Sway est la transposition du projet i3 pour le serveur d’affichage Wayland. Il est principalement développé par Drew DeVault, alias sircmpwn, autre amateur de vieux Thinkpads et adepte d’un minimalisme informatique très cohérent, d’un projet à l’autre.

Tous les problèmes qui avaient rendu l’utilisation de Sway 0.15 peu satisfaisante paraissent aujourd’hui réglés. Les fenêtres flottantes fonctionnent comme elles le doivent et les fenêtres un peu chargées de GTK3 ou de QT5 sont pleinement fonctionnelles. Me restaient tout de même deux problèmes à régler :

L’un, commun à tous ces environnements minimalistes, était l’intégration de Gnome-Keyring ou d’un autre agent SSH.
L’autre, commun à plusieurs environnements sous Wayland, était le bon fonctionnement de Smplayer.

Pour Smplayer, le problème était que la vidéo ne démarrait pas et affichait une erreur assez peu explicite, signifiant en fait qu’il essayait en vain d’ouvrir X11, lequel n’étant pas installé se révélait peu disponible. En ajoutant en option à passer à mpv dans les paramètres avancés --gpu-context=wayland le problème disparaissait. Reste que la vidéo démarrait dans une fenêtre séparée avec un ratio déformant. Si on accepte l’idée d’avoir deux fenêtres séparées (une pour Smplayer avec ses menus et commandes) et une pour la vidéo, le problème de ratio se règle en demandant explicitement à Smplayer d’exécuter mpv dans sa propre fenêtre, toujours dans les paramètres avancés.

Pour Gnome-Keyring, j’ai pataugé un peu plus longtemps. La page du wiki d’Archlinux consacrée à ce problème est assez touffue, mais elle ne donne pas la solution exacte du problème, car les variables d’environnement sont un peu retorses avec Wayland :

Celles qu’on essaie de faire passer par .bash_profile ou par .profile ne sont pas chargées.
Celles qu’on passe par .bashrc ne fonctionnent que pour les applications lancées depuis un terminal.
Celles qu’on passe par .config/environment.d/envvars.conf paraissent assez limitées dans leurs possibilités.

J’ai donc trouvé une solution presque satisfaisante avec la configuration suivante (à adapter à l’uid de chaque utilisateur) :

:::text
.bashrc
...
if [ -n "$DESKTOP_SESSION" ];then
    export GSM_SKIP_SSH_AGENT_WORKAROUND=1
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
fi

:::text
.config/environment.d/envvars.conf
...
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"

Pour vérifier après redémarrage que les variables sont bien passées, on peut utiliser systemctl --user show-environment. J’ai pour ma part dû forcer les choses avec un systemctl --user import-environment, mais je ne saurais dire si c’est une étape nécessaire dans tous les cas ou non.

La solution n’est pas parfaite. Le déverrouillage de la clé SSH doit se faire initialement dans un terminal (ce qui est pour moi, de toute façon, l’usage très largement majoritaire). Mais ensuite, une application lancée graphiquement, comme Unison-gtk, peut utiliser les clés déverrouillées, ce qui n’est pas possible avec la seule modification de .bashrc. Jusque-là, je me contentais de lancer les applications graphiques depuis un terminal, ce qui est plus laborieux.

J’avoue que depuis que j’utilise i3 et Sway, je n’utilise presque plus Openbox et plus du tout Enlightenment. En effet, on gagne très largement en légèreté et en puissance, même si la courbe d’apprentissage est un peu plus raide. On renonce en partie à la métaphore du bureau popularisée par MacOS et par Windows, ce qui déroutera peut-être les débutants. En même temps, cette métaphore m’a toujours paru d’une facilité un peu trompeuse et maladroite : j’ai toujours l’impression de mimer des gestes avec une souris, un peu à la manière dont on communiquerait avec quelqu’un qui ne comprendrait pas votre langue. Dans le cas de Sway ou d’i3, on reste au maximum dans la conversation avec la machine grâce au clavier. Moins d’énergie perdue et plus d’efficacité.

Fairphone, la voie de la vertu

jdn06 — Sun, 10 Mar 2019 16:50:00 +0100

Après presque trois ans de bons et loyaux services, il m’a fallu renoncer à mon Aquaris E5. Non qu’il ait fini par manquer de puissance ou de fonctionnalités nouvelles, non que son autonomie ait réduit, non que je m’en sois lassé. J’ai même tout fait pour le garder, mais cela n’a pas été possible.

En octobre dernier, en vacances dans la maison de mes grands-parents, je l’oublie dans la poche de mon pantalon en compagnie d’un trousseau de vieilles clés aux formes baroques et je pars bravement ramasser des pommes au verger. Malgré son étui en tissu matelassé, lorsque je le ressors de ma poche, l’écran est méchamment brisé, au point que la dalle tactile ne fonctionne plus. Très contrarié, je parviens pourtant à l’éteindre sans qu’il redémarre (l’opération n’est pas aisée sans la dalle tactile ; je ne me souviens même plus comment j’ai fait) afin de préserver la batterie, bien décidé à le faire réparer.

Lorsque je prends contact, dans les différentes régions que je parcours pendant les vacances, avec divers réparateurs de téléphones, la réponse est toujours la même : « Nous ne travaillons pas avec la marque BQ. Essayez chez un autre réparateur. » J’en conclus que décidément, les gens ne doivent rien acheter d’autre que des Samsung ou des Apple ; des Wiko pour les plus audacieux.

Lorsque j’entreprends de contacter BQ France qui m’avait vendu l’appareil, j’ai la désagréable surprise de m’apercevoir que le constructeur a fermé son réseau de distribution en France ; il faut contacter directement l’entreprise espagnole. Leur site est très bien fait et je suis rappelé très vite par une personne parlant très bien français. Les nouvelles en revanche n’ont rien de réjouissant :

La réparation de l’écran coûtera au moins 115 €.
Les frais d’expédition sont à ma charge.
Les données du téléphone seront effacées.

Ce dernier point est important car ma dernière sauvegarde remontait à plusieurs mois. J’allais donc perdre des données ; rien de vraiment essentiel, mais c’est un point qui me tient à cœur en informatique : ne jamais perdre de données. Or, il m’est impossible de me connecter en USB ou par wifi au téléphone sans la dalle tactile.

Payer donc presque 130 € pour réparer un téléphone âgé de trois ans qui coûtait 199 € à l’achat, sans même pouvoir conserver ses données, ça ne me paraît pas vraiment avantageux.

Je décide donc de jouer ma dernière carte : tenter de changer moi-même l’écran du téléphone. Après avoir lu quelques tutoriels en ligne, je commande la pièce sur un site qui l’expédiera depuis la Chine pour une trentaine d’euros.

Un mois plus tard (c’est long un mois avec un Samsung à clapet…), je reçois enfin la pièce et j’attends d’avoir quelques heures de calme devant moi pour faire passer le BQ sur le billard. Un ami bien équipé m’a prêté une machine qui sert à chauffer la colle, opération qui me paraissait difficile. Ce n’est finalement pas ça qui coincera, mais une fiche qui, lors du remontage, ne voudra jamais rentrer dans son connecteur et finira par casser, à force de se faire triturer. Résultat, le téléphone est définitivement H.S.

Au passage, le démontage de la bête et la tentative malheureuse de remontage restent une expérience intéressante. Rien à voir avec un ordinateur d’aujourd’hui. Ces engins ne sont pas du tout conçus pour être bricolés. Malgré le prix élevé, tout y est imbriqué et mal fait : colle, vis très nombreuses et mal placées, connecteurs ésotériques et minuscules. L’esthétique de l’engin (finesse, rebords très limités) semble l’emporter sur toute autre considération. Voilà qui ne va pas me réconcilier avec ces machines aujourd’hui si populaires.

Me voilà donc à la recherche d’un nouveau portable qui me permettrait de rester sous UBports. Le choix semble assez simple :

Trouver un portable d’occasion.
Acheter neuf un Fairphone 2.

Comme la démarche de Fairphone (production équitable et téléphone facilement démontable et réparable sans outil) me paraît encore plus judicieuse après cette expérience cuisante, je décide, malgré un prix assez largement supérieur aux 199 € de mon BQ, de leur donner une chance et j’achète ce téléphone à la mi-décembre.

Trois mois plus tard, je ne regrette pas mon choix. Lorsqu’on ouvre le téléphone, c’est clairement le jour et la nuit par rapport aux entrailles du BQ. Voilà un appareil intelligemment conçu, qui est vraiment fait pour être facile à bricoler. De plus, le processeur plus véloce et la mémoire qui fait le double de mon BQ apportent une fluidité bien appréciable à l’expérience. L’apport de la 4G n’est pas négligeable non plus.

Tout n’est pas rose pour autant. La batterie s’épuise plus vite que celle de mon BQ, laquelle était restée trois ans à un niveau vraiment satisfaisant. UBports est moins bien supporté qu’il ne l’était sous le BQ. Les bugs sont connus et assez nombreux : image à l’envers sur la lentille avant, flash qui ne fonctionne pas, menu wifi qui disparaît parfois de la barre d’état, installateur qui plante. Heureusement, aucun n’est vraiment handicapant; les selfies à l’envers ont même quelque chose d’amusant.

Il n’empêche que Fairphone et UBports devraient s’employer à régler ces problèmes anciens.

UBports le devrait car c’est le téléphone qu’il met en avant sur son site et le seul encore vendu neuf qui est supporté. Pour un utilisateur néophyte, le simple fait que l’installateur récent plante et qu’il faille utiliser une ancienne version pour pouvoir procéder à l’installation paraît assez rédhibitoire.
Fairphone fait l’effort de faire évoluer la version d’Android avec laquelle il est livré et fournit des mises à jour régulières. C’est vraiment très appréciable quand on voit le comportement des autres fabricants. Néanmoins, l’argument du libre et de l’indépendance face à Google complèterait bien l’argumentaire publicitaire du Fairphone. Maintenant que Purism va commercialiser son Librem 5, Fairphone devrait renforcer un peu UBports pour pouvoir défendre son produit chez sa clientèle libriste.

Achat d’un Thinkpad : c’est l’occasion !

jdn06 — Sat, 09 Mar 2019 01:09:00 +0100

Depuis quelque temps, mon netbook acheté il y a 8 ans, un eeePC 1001 PX, commençait à donner de sérieux signes de faiblesse. Sa troisième batterie était encore en grande forme, mais la webcam, qui n’avait jamais bien marché, semblait souffrir en plus d’un faux contact, ce qui bombardait régulièrement les logs de reconnaissances de matériel intempestives. La carte wifi plantait une fois par mois, obligeant à un redémarrage. L’écran se mettait par moments à vibrer, comme si la nappe qui le connectait à l’unité centrale connaissait elle aussi un faux contact. Enfin, il m’était depuis longtemps impossible de lire la plupart de mes vidéos récentes : ni les résolutions supérieures à un DVD classique, ni le codec H.265 n’étaient lisibles, du fait de la modestie du processeur et du GPU.

La partie applicative suivait pourtant assez bien. J’avais très vite remplacé la barrette de mémoire de 1 Go par une barrette de 2 Go. Avec les années, j’avais aussi remplacé XFCE par LXDE, par LXQt puis par i3, ce qui avait beaucoup allégé la machine. Pour une machine conçue par les constructeurs pour fonctionner au maximum deux ans, c’était déjà très bien.

Reste que c’était ma seule machine de voyage et qu’elle n’était plus vraiment fiable : il fallait en changer.

Depuis l’été 2017, je cherchais le netbook à moins de 300 € qui pourrait la remplacer. Mais tous les modèles que je trouvais étaient très limités en espace disque, du fait du recours à un SSD, de 32 ou 64 Go, le tiers de la capacité de ma vieille machine. La mémoire était de 2 ou 4 Go non extensibles. Le processeur et le GPU n’étaient pas vraiment véloces. Bref, les nouveaux modèles risquaient de me décevoir.

Finalement, en juillet dernier, dans le vitrine du magasin local d’informatique, je tombe sur un Thinkpad T d’occasion, et l’idée me vient de chercher de ce côté. Je trouve finalement mon bonheur en ligne : un Thinkpad X220, datant de 2011 (ironiquement du même âge que mon eeePC), équipé d’un i5, de 8 Go de mémoire et d’un SSD de 256 Go, le tout pour un peu moins de 300 €.

Après avoir viré Windows 7 et installé Archlinux, je me retrouve avec une machine vraiment très bien conçue, au clavier de rêve et au chassis robuste et élégant. Malgré un poids comparable à l’eeePC, ses dimensions sont un peu plus grandes que ce que j’aurais souhaité (l’écran fait 12'5 contre 10'1), mais le confort est tellement supérieur à celui de l’eeePC, qu’il est impossible d’en regretter la taille.

L’avantage d’une machine bien conçue, surtout à une époque où les processeurs ne progressent plus beaucoup en termes de performance, c’est qu’elle vieillit bien et mérite vraiment d’avoir une deuxième vie lorsque l’entreprise qui l’a achetée 1300 € des années auparavant décide de faire évoluer son parc. Le seul élément qui vieillit mal, la batterie, reste ici utilisable : la 6 cellules fournie avec la machine tient encore presque deux heures. J’ai fait l’acquisition chez Lenovo d’une 9 cellules pour les utilisations en déplacement ; cette nouvelle batterie tient environ dix heures, ce qui est très appréciable pour un processeur de cette époque, moins économe en énergie que ceux d’aujourd’hui.

Autre élément appréciable lié à ce type de matériel : les mises à jour de l’UEFI et des pilotes sont encore assurées par Lenovo, alors que mes cartes-mères Asus pourtant beaucoup plus récentes ne se voient plus proposer de mises à jour. En cette année marquée par les Spectre et autres Meltdown, c’est un point vraiment très appréciable. Quand j’ai acheté en juillet 2018 cet ordinateur de 2011, la dernière mise à jour de l’UEFI datait de juin 2018 ! Chapeau…

LibreOffice typographe !

jdn06 — Mon, 29 Oct 2018 21:46:00 +0100

Le problème, quand on utilise beaucoup LaTeX, c’est qu’on est assez frustré lorsqu’on se retrouve avec des outils plus limités comme un traitement de texte. Or, il existe de nombreuses situations professionnelles dans lesquelles je dois me contenter de LibreOffice. Parmi les choses qui me manquent alors, la plus futile est sans aucun doute les améliorations typographiques façon éditions de la Pléiade comme les ligatures esthétiques (par ex. ﬆ ou ﬁ) et les chiffres elzéviriens.

D’où ma surprise de découvrir qu’il était tout à fait possible d’utiliser ce genre d’ornement typographique sous LibreOffice depuis pas mal de temps. Il suffit de choisir une police OpenType qui contienne ces fonctionnalités (par exemple EB Garamond) puis de cliquer sur la police sélectionnée dans son cadre de la barre d’outils et d’ajouter une balise typographique de type :hlig ou :lnum juste après le nom de la police. La première permet d’insérer ces ligatures esthétiques ; la seconde de renoncer aux chiffres elzéviriens (qui sont présents par défaut dans EB Garamond). Pour sélectionner au contraire les chiffres elzéviriens sur une police où ils ne sont pas présents par défaut, on utilise :onum Pour combiner ligatures et chiffres elzéviriens, :hlig&onum.

Il n’est pas très facile de trouver une documentation précise de ces fonctionnalités. La liste la plus complète de ces balises pour polices OpenType que j’ai pu découvrir en ligne se trouve dans la colonne Tags sur une page consacrée à LaTeX !

Un an sous LaTeX - le bilan

jdn06 — Mon, 25 Jun 2018 18:41:00 +0200

Si j’avais un peu bidouillé du LaTeX ces dernières années, c’était de manière très occasionnelle et par curiosité, en vrai dilettante. Or j’ai pris la décision au mois de juin dernier, après quelques tentatives plus concluantes, d’essayer de n’utiliser professionnellement, pour l’année 2017-2018, que des documents que j’aurai produits sous LaTeX. L’année est terminée ou presque ; j’ai tenu l’engagement, produisant en tout une cinquantaine de documents très variés : il est temps de faire un premier bilan.

La démarche

Précisons tout d’abord que je suis bien conscient d’être un peu à contretemps : une décennie de retard (ou d’avance, qui sait ?)

Si on fait une recherche de type « LaTeX professeur de littérature française » dans un moteur de recherche, les réponses pertinentes seront bien rares.
Même en mathématiques, je ne connais aucun enseignant de collège qui utilise au quotidien LaTeX (alors que la plupart ont quelques bases), alors des littéraires !
Les associations d’utilisateurs de LaTeX ne semblent pas au mieux de leur forme. En France, Gutenberg semble avoir considérablement réduit ses activités, ce qui est d’ailleurs assez frustrant pour le nouvel adhérent que je suis, quand on voit les activités menées il y a dix ans…
Plus anecdotique et amusant, rechercher The LaTeX Companion en librairie vous fait souvent passer pour un fétichiste à la recherche de son homme, ce qui en dit long sur la méconnaissance de LaTeX, y compris parfois chez le personnel du rayon informatique.

Mes objectifs l’an dernier :

Améliorer la typographie de mes productions : polices et ligatures, coupures de mots, taille des espaces insécables etc.
Utiliser Vim pour travailler (ou plus exactement Neovim) et pouvoir au besoin éditer directement sur mon serveur les modifications à faire — par exemple quand je remarque une coquille dans un document et ne dispose que de mon téléphone portable.
Obtenir exactement ce que je veux sans avoir à lutter contre l’outil.
Améliorer éventuellement ma productivité.

Le bilan

Sur plan de la qualité typographique, le bilan est entièrement positif et le gain plus spectaculaire qu’il n’y paraît. Les textes sur lesquels les élèves travaillent me paraissent beaux et plus agréables à lire, leur présentation est plus cohérente. Les élèves n’en sont pas forcément conscients, mais certains semblent tout de même valoriser davantage leur support écrit (moins de photocopies froissées ou laissées dans la salle après le cours, pour m’appuyer sur une observation objective).
Le confort de n’utiliser qu’un éditeur de texte aussi efficace que Vim est évidemment remarquable. Je me suis même mis parfois à rédiger et compiler en LaTeX sur une tablette Android 7 pouces avec clavier externe, grâce au très remarquable Termux. Bonne chance pour obtenir quelque chose d’aussi précis avec un traitement de texte sur un tel engin ! En utilisant un plugin pour Grammalecte la moindre efficacité de la correction orthographique, par rapport à celle de LibreOffice, est en partie atténuée.
Les deux derniers points sont plus discutables :
- S’il est plus chronophage au début de rédiger un document très simple, comme cinq phrases d’exercices, sous LaTeX que sous LibreOffice, le gain de temps est considérable lorsque la complexité du document s’accroît et qu’il n’est plus possible, sous LibreOffice, d’obtenir quelque chose de correct qu’en multipliant les retouches manuelles. Un bon exemple de ce genre de texte complexe ? Un extrait de théâtre en vers ; il faut alors :
  - Bien centrer les vers dans la colonne tout en alignant à gauche et en évitant les vers trop longs.
  - Ne pas compter les noms des personnages et les didascalies dans la numérotation des vers et offrir une typographie qui les distingue nettement.
  - Avoir une numérotation des vers qui ne plante pas lorsqu’un vers est partagé entre deux personnages.
- Respecter toutes ces contraintes avec des environnements LaTeX comme Thalie et Verse par exemple, est assez trivial et rapide.
- Lorsqu’on produit une fiche structurée avec titres, sous-titres, points et sous-points, exemples, tableaux, les indentations automatiques de LibreOffice sont difficiles à piloter et nécessitent beaucoup de retouches manuelles. Avec LaTeX, la structure produit naturellement la disposition si elle a été bien conçue. On ne gagne pas forcément de temps, puisqu’on est souvent amené à retoucher la structure, mais le temps est utilisé à des choses plus constructives qu’à lutter contre la mise en page automatique — et le résultat est souvent plus cohérent et plus satisfaisant.
La productivité est une notion très subjective : lorsque je fais quelque chose que je trouve intéressant, j’ai moins l’impression de perdre mon temps que lorsque je suis contraint d’effectuer des tâches répétitives sans intérêt. Les comparaisons de productivité entre LaTeX et LibreOffice ou Word sont assez nombreuses sur le net et les arguments ressassés souvent les mêmes. Si j’essaie de rester objectif et concret, je peux dire que ma productivité est meilleure sous LaTeX dans au moins trois cas :
- Lorsque je produis un contrôle avec corrigé, le contrôle, le barème et le corrigé sont produits en même temps dans le même document grâce à la classe exam.
- Lorsque je veux produire une version pour les dyslexiques d’un support écrit, il est très facile de ne fabriquer qu’un document avec deux options de construction (passage de A4 en A3 et changement de police, par exemple). Avec le système de références internes, les changements de ligne induits par la nouvelle police sont automatiquement traduits dans les questions qui contiennent des références à un passage. Il est peut-être possible de faire la même chose sous LibreOffice, mais je n’ai jamais essayé. Disons que sous LaTeX, c’est assez simple.
- Pour économiser du papier, j’utilise souvent une page A4 en format portrait sur laquelle j’imprime deux pages A5 en format paysage l’une sous l’autre que je découpe ensuite au massicot. Sous LibreOffice, j’imprimais deux feuilles A4 avec une seule A5 en haut, puis je les superposais dans la photocopieuse afin d’obtenir ce que je cherchais. Il est peut-être possible d’obtenir directement la page souhaitée (avec les en-têtes et les pieds de page) sous LibreOffice, mais cela me paraît improbable. On peut certainement utiliser un logiciel tiers de manipulation des pdf pour obtenir le même résultat, mais l’utilisation de LaTeX est ici beaucoup plus simple et se limite à quelques instructions :

:::latex
\documentclass[12pt,a5paper,landscape]{exam}
\usepackage{pgfpages}
........
\pgfpagesuselayout{2 on 1}[a4paper]
\begin{document}
\mapage
\clearpage
\mapage
\end{document}

Il suffit alors d’écrire une commande \mapage qui contiendra le texte à copier sur les deux pages A5, le tout tenant sur une page A4.

Voilà je crois un assez bon exemple d’un gain de productivité très net sous LaTeX.

Une conclusion donc : je continue l’an prochain !

OpenSMTPd : concis ou taiseux ?

jdn06 — Wed, 19 Jul 2017 16:36:00 +0200

Je viens d’abandonner le vénérable Sendmail 8.15.2 pour un petit jeune, OpenSMTPd ! Pourquoi remplacer quelque chose qui marchait bien et m’a donné toute satisfaction ces sept dernières années ?

Les fichiers de configuration de Sendmail impressionnent et datent d’un autre âge, ce qui fait que toute modification de la configuration donne des sueurs froides. Ceux d’OpenSMTPd semblent par opposition un modèle de clarté et de concision, et cela rassure beaucoup.
Sendmail peut tout faire, mais tout y est compliqué, même les choses simples, ce qui fait qu’on n’est jamais entièrement sûr que le programme fait vraiment ce qu’on lui demande.
Les projets issus d’OpenBSD m’ont toujours paru assez bien faits, notamment Packet Filter ; or sa syntaxe semble justement inspirer le serveur mail maison.
Il faut bien se fixer des challenges, et le mail, c’est toujours titanesque.

J’ai eu mon lot de déconvenues, au point que j’éprouve un peu de déception pour ce programme.

Commençons par les points positifs : la configuration de base est assez bien faite, si bien qu’on peut faire tourner un serveur complet avec signature DKIM avec un fichier de configuration de quinze lignes dans une syntaxe très claire et lisible ! Les valeurs par défaut permettent en effet d’obtenir une authentification SMTP sans programme extérieur en ajoutant le mot auth à la directive listen. Comparé à Sendmail qui n’authentifie rien par défaut et doit s’adjoindre les services d’un élément externe comme cyrus-sasl, il n’y a pas photo !

Mais cette concision et cette clarté sont un peu trompeuses. Ainsi, la syntaxe n’est pas aussi facile à comprendre que celle de Packet Filter, parce que les concepts utilisés restent un peu flous, comme par exemple le mot local qui manque de précision. Il vaut probablement mieux utiliser à la place source { 192.168.1.0/24 } si on veut quelque chose de précis.

Mon premier pépin de configuration a concerné les alias. J’ai voulu réutiliser le fichier qui servait à Sendmail, mais celui-ci mélangeait des noms d’utilisateurs seuls avec des noms d’utilisateurs suivis de leur domaine (utilisateur@domaine.fr). Qu’OpenSMTPd ne veuille que des noms d’utilisateurs sans domaine, pourquoi pas ; après tout, il dispose d’un procédé équivalent par ailleurs. Mais que lorsqu’OpenSMTPd ouvre un fichier aliases de ce genre, il le rejette purement et simplement sans produire d’erreur dans les logs, voilà qui est moins satisfaisant et rend la résolution du problème plus difficile. OpenSMTPd n’est pas seulement concis, il est aussi laconique, voire taiseux !

Si taiseux qu’il avale même parfois les syllabes. En effet, lorsque le nom d’un utilisateur dépasse les huit caractères, il ne conserve dans les logs que les huit premiers caractères. Du coup, quand j’ai été confronté à un problème d’authentification sur un compte de ce type, j’ai d’abord cru que le rejet de l’authentification provenait d’un nom d’utilisateur tronqué, alors qu’il n’est tronqué que dans les logs. Je ne suis apparemment pas le seul à avoir cru dans un premier temps que le problème venait de ces noms tronqués.

Plus ennuyeux encore, les erreurs de configuration ne pardonnent pas. Si par exemple, on croit avoir traité avec une directive local le cas des courriels provenant des autres jails ou des autres serveurs locaux et qu’on ne vérifie pas que tout marche bien, on peut se retrouver avec de sérieux problèmes. Si l’utilisateur local envoie à un autre utilisateur local un message qui n’est pas correctement traité par le fichier de configuration, il va se diriger vers le relay et former une boucle infinie que le serveur ne stoppe pas. Il s’agit certes d’une erreur de configuration, mais elle est assez aisée à commettre par exemple avec root@localhost et peut devenir très problématique lorsque les jails ou les serveurs locaux envoient la nuit suivante des dizaines de messages de bilans journaliers, qui se retrouvent tous dans une boucle sans fin !

Enfin, le module DKIM fourni par le programme fonctionne très bien, mais sa configuration est rendue redoutable par un défaut non documenté qui oblige à coller les arguments des options sans espace. Si l’on écrit filter dkim-sign dkim-signer "-D mondomaine.fr -s monsélecteur -p /chemin/vers/ma/clef.key", le serveur va refuser de démarrer parce qu’il ne trouve pas la clef et si on contourne le problème en utilisant l’emplacement de clef par défaut et en supprimant l’option "-p", le serveur démarrera mais ne validera pas correctement la signature DKIM. Pourquoi ? Parce qu’il lit la configuration comme le domaine " mondomaine.fr" et le sélecteur " monsélecteur", en conservant l’espace initiale ! Il faut donc écrire la configuration ainsi : dkim-sign dkim-signer "-Dmondomaine.fr" "-smonsélecteur" "-p/chemin/vers/ma/clef.key" Mais je n’ai trouvé aucune trace du problème dans la documentation assez pauvre du projet. Il m’a fallu tomber sur cette page par hasard, après des heures de recherche, pour comprendre ce qui se passait !

Tout cela n’est pas bien grave, mais ne donne pas l’impression d’un programme aussi soigneusement écrit et documenté qu’on pourrait l’espérer.

Laissons-nous UBporter

jdn06 — Sun, 09 Jul 2017 09:12:00 +0200

Maintenant que le support de mon Ubuntu Phone est considérablement réduit et qu’il est prévu qu’il cesse complètement fin 2017, c’est le moment de donner une chance à UBports, la version communautaire de feu Ubuntu Touch. De plus, certaines applications - uNav par exemple - ne mettent plus à jour la version de l’Ubuntu Store et appellent les utilisateurs à passer sur l’OpenStore, lequel est un dépôt de logiciels alternatif qui n’est pas géré (enfin, si on peut encore dire cela…) par Canonical.

J’ai donc passé mon Aquaris E5 à la fois à UBports et à l’OpenStore, mais les deux opérations sont totalement indépendantes : l’OpenStore n’est qu’une application qu’on installe à la main et qui ouvre un second dépôt, lequel ne remplace pas le premier. Le détail est important, car certaines applications (Dekko, par exemple) ne figurent pas dans l’OpenStore : les deux dépôts sont utilisables conjointement.

On place le téléphone en mode développeur ; puis on doit nécessairement commencer par une sauvegarde du home, car la procédure de mise à jour actuelle vers UBports efface toutes les données du téléphone. Pour sauvegarder le home, il faut avoir établi une connexion ssh depuis l’ordinateur vers le téléphone, si possible avec des clés. Il suffit ensuite de lancer, en utilisant l’IP du téléphone et en adaptant la clé au besoin, une commande de type :

rsync -r -t -p -o -g -v --partial --progress --delete -l -e 'ssh -i ~/.ssh/id_rsa' phablet@192.168.1.3:/home/phablet/ /chemin/vers/le/backup/

J’ai ensuite suivi la procédure décrite sur le site en choisissant d’utiliser l’outil dédié à cette opération : Magic Device Tool, un outil très simple en console qui permet d’automatiser et de sécuriser l’opération. Attention quand même de bien prendre le temps de lire les instructions et les avertissements ! J’ai cependant rencontré un petit problème agaçant : le téléchargement de la nouvelle image du téléphone (une centaine de Mo, de mémoire) s’interrompait avant la fin, ce qui laissait le téléphone et le programme en rade avec un un message de type Unexpected EOF. Il fallait forcer l’extinction du téléphone, puis le relancer en mode Fastboot. Rien de bien grave, même si on panique un peu la première fois, craignant d’avoir briqué le téléphone. J’ai dû m’y reprendre trois ou quatre fois, et pourtant ma connexion Internet était très bonne. Soit leur serveur est faiblard, soit le succès est immense ! Le même Magic Device Tool peut dans un deuxième temps être redémarré pour installer l’OpenStore de manière automatisée.

Il reste ensuite à rétablir les données du home, ce qui se fait de la même manière :

rétablir une connexion ssh avec clés en plaçant le téléphone en mode développeur, en utilisant la commande adb shell android-gadget-service enable ssh et éventuellement en rétablissant le fichier authorized_keys dans le .ssh.
lancer rsync -r -t -p -o -g -v --partial --progress --delete -l -e 'ssh -i ~/.ssh/id_rsa' /chemin/vers/le/backup/ phablet@192.168.1.3:/home/phablet/
redémarrer le téléphone et réinstaller les applications

Quel bilan tirer de l’opération ?

Ça marche très bien. Pas de gros changement, si ce n’est le logo de démarrage et la traduction de VPN en RPV qui m’a un peu dérouté au début (« Où est passé le VPN ? Pourquoi y en a plus ? »)
L’OpenStore donne beaucoup plus d’informations sur chaque application, notamment en ce qui concerne les autorisations et le confinement.
Il faut soutenir financièrement le projet - lequel accepte plusieurs moyens pour donner, dont les bitcoins, c’est parfait…

Où va Ubuntu ? … la suite

jdn06 — Mon, 10 Apr 2017 11:31:00 +0200

Le pire n’est pas toujours certain, mais les incertitudes sont en train de se lever. Ce que je pressentais dans les déclarations précédentes de Canonical se confirme donc : la technologie Snappy n’est pas dirigée vers les appareils mobiles. La décision était probablement déjà prise il y a trois mois, mais la mise à mort des téléphones et des tablettes a été annoncée en deux temps, pour que la pilule paraisse moins amère. Ubuntu se recentre bien sur son activité serveur, ce qui est cohérent avec la priorité donnée à Snappy.

Au-delà de la déception que peuvent susciter de telles décisions pour un acheteur d’un téléphone Ubuntu, voilà qui ne peut que laisser un goût amer à tout libriste. Ubuntu aura investi massivement dans deux technologies qu’il abandonne aujourd’hui, Unity et Mir, alors qu’il aurait été beaucoup plus efficace de soutenir les projets communautaires correspondants : GNOME 3 et Wayland. Cette décision a toujours été justifiée par le projet de convergence Bureau/Mobile, sans pour autant qu’on comprenne pourquoi il était impossible de partir des projets communautaires pour réaliser cette convergence. Si donc Ubuntu avait soutenu financièrement les projets communautaires, sa tentative aurait été moins chère et aurait bénéficié d’un soutien beaucoup plus net de toute la communauté libriste. De plus, si Unity était le meilleur Bureau libre disponible, alors pourquoi en cesser le développement ? N’est-ce pas avouer, soit qu’on ne croit plus du tout au Bureau Linux, soit que GNOME 3 lui est supérieur. En l’occurence, probablement les deux !

La version grand public de l’OS de Canonical risque donc de se transformer en simple vitrine, plus ou moins bien entretenue, sans véritables projet ou investissements. Fedora en moins bien…

Où va Ubuntu ?

jdn06 — Sat, 07 Jan 2017 17:37:00 +0100

Les oracles annonçaient la nouvelle depuis plusieurs semaines et la nouvelle est finalement tombée ces derniers jours : il n’y aura pas de nouvelle OTA pour les téléphones Ubuntu ; l’OTA-14 publiée en décembre sera la dernière.

Alors, bien sûr, officiellement, le projet n’est qu’en pause jusqu’à l’intégration de la technologie Snappy au sein d’Ubuntu Touch, sans qu’aucune date ne soit avancée, ni aucun modèle de téléphone associé annoncé. Les téléphones déjà vendus ne seront pas compatibles. Seule la tablette BQ Aquaris M10, commercialisée depuis moins d’un an, devrait être un jour compatible, mais il faudra probablement être patient, très patient.

Les possesseurs de téléphones Ubuntu, dont je suis, pourront aussi se consoler si Ubuntu tient son engagement de fournir encore des mises à jour de sécurité pour les deux ans à venir : les téléphones sous Android ne reçoivent pas tous des mises à jour de sécurité si longtemps.

Reste qu’il y a de quoi être en colère devant un tel gâchis ! Soit la stratégie d’Ubuntu est si ténébreuse que personne n’a réussi à deviner leur but ultime, soit ils ne prennent que de mauvaises décisions depuis 5 ans !

Lorsqu’ils décident de remplacer GNOME par Unity, en 2011, ils se justifient par leur volonté de créer une interface unique, utilisable aussi bien sur le desktop que sur un téléphone mobile. La décision est radicale et suppose un investissement en développement massif, nécessité qu’augmentera encore la décision de ne pas participer à Wayland et de créer une solution à nouveau interne à Ubuntu, Mir. Dès lors, le reste du développement pour le desktop semble mis en pause : tous les moyens vont sur Unity et Mir. La suite logique d’une telle politique, c’est la sortie de tablettes et de téléphones fonctionnant sous Ubuntu. Mais il faudra attendre jusqu’en 2015 pour voir enfin un premier modèle proposé : quatre ans de projets divers promettant tous monts et merveilles, tous interrompus avant commercialisation.

Si les téléphones et la tablette vendus depuis 2015 ne sont pas les outils exceptionnels qu’on nous faisait miroiter, ils fonctionnent assez bien et sont utilisables au quotidien pour la plupart des besoins élémentaires. Pourquoi donc faire marche arrière ? Quel objectif non atteint s’était fixé Ubuntu, qui l’amène maintenant à relâcher l’effort ? Difficile de répondre à coup sûr à cette question, d’autant que la communication d’Ubuntu a toujours été assez décalée par rapport à la réalité qu’on pouvait percevoir… Mon impression est que l’objectif de ces appareils était de rallier de nombreux utilisateurs-développeurs qui étofferaient le magasin d’applications sans rien coûter, et que peu d’utilisateurs ont pris la peine de développer.

Pour que les développeurs s’engagent massivement derrière eux, peut-être aurait-il fallu moins d’arrogance et de choix anti-communautaires ? Peut-être aurait-il fallu soutenir GNOME 3, Wayland, quitte à infléchir un peu le cours de ces technologies ? Peut-être aurait-il fallu concevoir des téléphones beaucoup plus ouverts, où apt install n’aurait pas menacé de tout casser, où on aurait pu changer le fichier mirror.list, voire passer son téléphone sous Debian. Bien sûr de tels appareils, qui auraient eu une énorme logithèque, mais totalement inadaptée aux interfaces mobiles, n’auraient pas été à mettre entre toutes les mains. Les téléphones Ubuntu ont réussi le pari assez fou de n’être satisfaisants ni pour le grand public (peu d’applications, pas mal de bugs) ni pour les libristes (beaucoup de Google et peu de souplesse pour installer autre chose que les OTA et les quelques applis dédiées). Je ne veux pas dire par là que je regrette mon achat : contrairement à un téléphone Android, je suis root à l’achat et je peux tout casser si je veux ; les applications disponibles couvrent l’essentiel de mes besoins. Néanmoins, je rêvais clairement d’autre chose, et manifestement pas de ce qui fait rêver Mark Shuttleworth ! La convergence ne m’intéresse pas particulièrement ; acheter des téléphones équipés de processeurs puissants comme des desktops n’est pas forcément une bonne idée en l’état actuel de la technologie. Sans de tels téléphones, forcément très au-dessus de mon budget, la convergence n’est qu’un gadget peu utilisable. Non, ce qui me faisait rêver dans ce projet, c’est d’avoir un téléphone GNU/Linux, où par exemple tous les outils cli de GNU/Linux seraient installables sans problème. Or cela supposait de pouvoir installer tout ce qui était compilable pour les architectures ARM avec un simple apt install. Bien sûr, l’utilisateur d’Android ou d’iOS n’y aurait vu aucun intérêt, mais il ne fallait pas viser ce public si on voulait d’abord séduire les développeurs libristes et s’appuyer ensuite sur eux pour étoffer la plateforme d’applications mobiles.

Une part du problème vient aussi peut-être du choix du noyau : Ubuntu Touch était condamné à faire tourner Ubuntu 15.04 et un noyau Linux 3.4, alors que le Desktop Ubuntu est aujourd’hui en 16.10 avec un noyau 4.8. Or le problème du noyau est aussi je pense ce qui rend le support sous Android si court et fait que les mises à jour cessent avant que le matériel soit hors-service (pour les gens un peu soigneux…). Ce n’est donc pas directement Canonical qu’il faut ici blâmer, mais plutôt les fabricants de composants pour mobile et surtout les entreprises qui assemblent et commercialisent les téléphones, qui pourraient tout à fait faire pression sur leurs fournisseurs. On a l’impression que tout ce monde-là utilise un noyau Linux sans se préoccuper de comprendre cet univers. Ils se contentent de fabriquer un vilain blob propriétaire sur lequel s’appuiera telle version du noyau, interdisant de fait l’utilisation d’un autre noyau que celui de départ. Il serait pourtant dans l’intérêt des fabricants, s’ils veulent déserrer un peu l’étau de Google, d’exiger des composants dont les pilotes seraient intégrés au développement du noyau, comme cela se pratique souvent pour le Desktop, d’autant que contrairement à ce qui concerne le Desktop, leurs composants sont le plus souvent destinés au seul noyau Linux, via Android. Ainsi les mises à jour seraient beaucoup plus faciles pour tout le monde.

Enfin, concernant les Snappy, j’ignore si cette technologie aidera Ubuntu à réaliser cette fameuse convergence, mais je suis d’avis que si elle est une bonne idée concernant les serveurs, un peu comme une version allégée de Docker, elle est une très mauvaise idée pour le Desktop. Pour moi, la beauté des machines tournant sous GNU/Linux ou sur une BSD tient beaucoup à leur système de bibliothèques partagées ; l’occupation disque et mémoire de chaque programme est très inférieure et le matériel est donc utilisé de manière optimisée. Le prix à payer est évidemment le problème de la gestion des dépendances et de la coordination des mises à jour. Les outils pour permettre ce genre de déploiement, les gestionnaires de paquets, sont aujourd’hui nombreux et d’une très grande efficacité. Pourquoi donc vouloir régresser vers des systèmes lourds, à la Windows ou Mac, avec en plus les problèmes de bibliothèques périmées, pleines de trous de sécurité, qui vont avec les logiciels peu mis à jour ?

Feu PC-BSD avait déjà expérimenté ce genre de choses avec le format PBI qui s’était montré pachydermique et assez inefficace. Snappy semble à la fois beaucoup plus ambitieux (en termes d’isolation des processus) et mieux fait ; reste qu’il ne paraît pas forcément judicieux d’alourdir les Desktops, alors que la légèreté est le meilleur argument des distributions GNU/Linux et qu’Ubuntu ne brille déjà pas en la matière par rapport à d’autres…

Bref, Ubuntu est certainement un concurrent imaginatif de Red Hat, mais pour le reste, il aime se tirer des balles dans les pieds, avec régularité et obstination.

Partage de certificats Let’s Encrypt entre plusieurs jails

jdn06 — Mon, 21 Nov 2016 22:54:00 +0100

Let’s Encrypt est vraiment une innovation essentielle pour l’auto-hébergement. Finis les certificats auto-signés déclenchant d’inquiétants messages sur les navigateurs des non-initiés et les incitant à rebrousser chemin ! Les choses sont simples, bien faites, automatisables et gratuites.

Reste que les certificats sont stockés sur l’arborescence du serveur web qui assure le protocole défi-réponse de vérification et que le système de liens symboliques entre les répertoires live et archive, qui permet de ne pas redémarrer les services, complique un peu les choses pour déplacer les certificats d’une jail à l’autre depuis l’hôte.

La solution la plus simple que j’ai trouvée c’est de monter en lecture seule le dossier qui contient les certificats sur les autres jails qui doivent y avoir accès. Pour un utilisateur d’ezjail, il suffit pour cela d’éditer sur l’hôte dans /etc les fichiers de type fstab.majail1 en ajoutant une ligne permettant ce montage :

:::text
/usr/jails/monserveurweb/usr/local/etc/letsencrypt/ /usr/jails/majail1/etc/ssl/letsencrypt/ nullfs ro 0 0

On redémarre la jail et le tour est joué ! Ce n’est cependant pas parfait, car si une seule jail est compromise, toutes les clefs des autres jails le seront aussi, mais il n’est pas possible de ne monter que celles du site concerné, à cause du système de liens symboliques entre live et archive. Si donc on reste sur des données personnelles auto-hébergées, je pense qu’il s’agit d’un compromis acceptable entre sécurité et facilité d’utilisation.

Cyrille a-t-il dépassé les bornes ?

jdn06 — Sat, 29 Oct 2016 16:02:00 +0200

Qu’on me pardonne d’abord ce titre un peu facile, peut-être aussi ce choix d’écrire sur un sujet d’actualité, voire d’actualité de la blogosphère libre francophone, exercice qui n’est pas vraiment dans mes habitudes et dans lequel je ne me sens pas particulièrement à l’aise.

Je suis un lecteur régulier du blog de Cyrille, et lorsque j’ai lu son fameux article où il annonce qu’il passe à Windows 10, j’ai tout de suite eu envie d’écrire quelque chose à ce sujet. Mais comme je me méfie de moi-même, je me suis abstenu. Apparemment, beaucoup n’ont pas eu cette retenue, et Cyrille s’est plaint de certaines réactions très virulentes.

Si je prends le clavier donc finalement pour en dire quelque chose, c’est parce que ce débat (ou plutôt cette tendance à l’invective) rejoint un thème sur lequel je cherche à écrire, sans y parvenir, depuis que j’ai ouvert ce blog : la tentation permanente des libristes à se comporter comme s’ils avaient reçu une révélation et qu’il était de leur devoir d’évangéliser le reste du monde.

Cyrille est un blogueur prolifique (Il écrit en trois jours ce que j’écris en un an…) et très lu. Son blog est assez riche et divers, puisqu’il brasse entre autres à la fois des sujets techniques, des sujets pédagogiques et des sujets que je qualifierais de « polémique libriste ». Lui-même semble avoir beaucoup évolué, à la fois en tant que libriste et que blogueur. Il est revenu de sa période d’évangélisateur, travaillant gratuitement à faire passer les gens à Linux, là où il faisait payer, avec son statut d’auto-entrepreneur, l’aide qu’il apportait aux utilisateurs de Windows. Si j’ai bien compris, il n’essaie plus guère de convertir qui que ce soit à Linux, ayant constaté le caractère finalement très peu productif de ces conversions.

Ce qui m’intrigue depuis plusieurs années, c’est justement ce besoin que ressentent nombre de nouveaux libristes - moi y compris - de convertir ceux qui n’ont pas encore été touchés par la grâce. En analysant un peu mes propres réactions, je vois les choses ainsi :

Tout nouveau libriste qui a été longtemps un utilisateur de Windows a cru durant des années qu’il n’y avait aucune alternative vraiment réaliste, à part Apple - alternative qu’il rejetait par ailleurs pour des raisons diverses.
Le passage à Linux était (ou est) souvent perçu comme périlleux et difficile. C’était d’autant plus vrai à l’époque où la plupart des gens ne possédait qu’un seul ordinateur et aucun autre accès au web. Trouver de la documentation pour sortir de l’ornière lorsque l’installation de Linux avait foiré n’avait rien d’évident et l’expérience pouvait être cuisante.
A posteriori, le nouveau libriste regrette de n’avoir pas franchi ce cap plus tôt, d’avoir été pusillanime. Ce sentiment peut aller jusqu’à une forme de honte ou de culpabilité.
Par réaction, il veut convaincre les autres, les faire sortir de l’erreur qui consiste à croire qu’ils sont condamnés à Windows.

Tant qu’il s’agit d’aider et d’accompagner les néophytes, tout va bien. Mais lorsqu’il s’agit de tanner des gens très heureux sous Windows, ce comportement devient très vite pathologique.

Pour un tel prêcheur, lire que Cyrille Borne, celui qui faisait passer des établissements scolaires de Windows à Linux, un héros de la cause libriste en quelque sorte, se convertissait à Windows pour son usage personnel, voilà qui ne peut que le heurter violemment. Les renégats sont toujours mal vus des croyants exaltés. Il n’est donc pas très surprenant qu’il y ait eu des réactions déplacées.

D’autant que l’article de Cyrille annonçant la nouvelle reflétait plus d’exaspération que de raisonnement, comme si se sentant un peu honteux de sa décision, il en rajoutait dans les critiques à l’égard du libre. Heureusement, l’histoire n’en est pas restée là et il a publié aujourd’hui un très bel article, à mon sens, sur ce que doit être le choix du libre, insistant notamment sur la différence entre les choix des institutions publiques et ceux des simples particuliers.

Si on essaie de sortir des logiques sectaires et quasi-religieuses de certains, il faut justifier le choix du libre par le plaisir, l’utilité, l’efficacité, la pérennité etc. Si j’utilise Linux, c’est avant tout parce que je le trouve beaucoup plus efficace pour l’usage que j’ai de mes ordinateurs et que j’ai davantage confiance en son fonctionnement et en son évolution future. Pas parce que c’est mal d’utiliser Windows. Si donc quelqu’un qui a longuement essayé Linux (même s’il snobe Archlinux) décide qu’il préfère retourner sous Windows, il n’y a pas lieu d’attaquer son choix, ni même vraiment de le regretter. On peut simplement, puisqu’il ne présente pas cela comme un choix d’adhésion mais plutôt comme une petite défaite, le plaindre un peu de ne pas trouver son bonheur sur le plan informatique, sachant que ce domaine lui tient particulièrement à cœur d’après le contenu de son blog.

Si j’avais un reproche à lui faire, ce ne serait certainement pas sur ce choix, mais plutôt sur la mode actuelle, qu’il embrasse avec beaucoup d’autres, des Cassandre du bureau Linux ; ceci dit, je crois qu’il est lui-même très conscient de ce travers, ironisant sur son penchant à voir sans arrêt la fin du monde libriste. Pourquoi imaginer que parce que le bureau Linux reste en dessous de 3% d’utilisateurs, cela signifie que nous devrons y renoncer un jour ? Ne s’est-il pas construit durant une période beaucoup moins favorable, où Microsoft luttait férocement contre Linux, où aucun fabricant ne fournissait quoi que ce soit pour aider à l’écriture des pilotes libres, où il n’existait pas encore de suite de bureautique libre ?

Alors, oui, la défaite devant la Cour de justice de l’Union Européenne est très décevante et sonne le glas des espoirs de certains de voir Linux triompher par le marché. Mais nous n’avons pas besoin d’un jugement favorable pour continuer à utiliser l’OS de notre choix. Et le choix, la liberté, c’est aussi pour certains celui de préférer Windows.

Des jails en IPv6 double stack

jdn06 — Thu, 25 Aug 2016 00:15:00 +0200

Après avoir bien hésité, longtemps inquiet devant quelques témoignages sur les forums datant de 2011, j’ai décidé de passer ma connexion chez OVH Télécom en IPv6. J’avais peur que ma configuration de NAT IPv4 saute et que mon serveur auto-hébergé se retrouve hors-ligne. De plus, je craignais que certains périphériques trop vieux pour supporter IPv6 perdent leur connectivité. Rien de tel n’est arrivé, et tout s’est vraiment très bien passé. Le service technique d’OVH Télécom, que j’avais contacté avant de me lancer dans la manœuvre pour m’assurer que je ne faisais pas de bêtise, a été particulièrement précis dans ses réponses, m’expliquant par exemple comment configurer mon reverse DNS en IPv6, démarche indispensable pour que mon serveur mail puisse fonctionner en IPv6 ; félicitations au passage au concepteur de la dernière interface du Manager, particulièrement bien conçue pour cette configuration du reverse.

Un bémol toutefois, et mon récit aidera peut-être des abonnés d’OVH Télécom : le Manager montrait la case IPv6 cochée d’elle-même avant que je n’intervienne, et alors que l’IPv6 n’était pas disponible. Il fallait décocher la case, laisser le routeur redémarrer, recocher la case, laisser le routeur faire une mise à jour et redémarrer, pour enfin se retrouver en IPv6. De plus, pour pouvoir héberger des services en IPv6, il faut désactiver le pare-feu intégré à la box, ce qui suppose évidemment d’avoir des pare-feu sur tous les éléments connectés en interne ou d’installer un nouveau pare-feu collectif pour une partie du réseau.

Signalons enfin que si l’IPv6 stateless fonctionne très bien, je n’ai pas réussi à faire marcher le RDNSS et ai donc dû me résoudre à rentrer moi-même les adresses des serveurs DNS IPv6 d’OVH sur chaque machine connectée.

Reste la partie intrigante : que faire de l’IPv6 en ce qui concerne mes jails FreeBSD ? En effet, ayant fait le choix d’un double NAT, celui de ma box, puis celui du serveur qui redirige les requêtes vers des adresses IPv4 privées pour chacune des jails, j’étais assez loin de l’IPv6. Or, il est en fait très facile d’obtenir des jails qui fonctionnent parallèlement avec ce NAT tortueux et de belles adresses IPv6 directes.

Pour ce faire, il suffit d’éditer la fichier correspondant à la jail concernée dans /usr/local/etc/ezjail/ :

:::text
export jail_blogs_ip="10.10.10.2"
    devient
export jail_majail_ip="lo2|10.10.10.2,msk0|2001:41d0:fe0b:500:3:3:3:2"

En autorisant le trafic dans le pare-feu, en ajoutant les serveurs DNS dans le resolv.conf de la jail, en modifiant la configuration de l’application qui écoute et en modifiant le fichier de zone DNS pour ajouter des entrées AAAA, on se retrouve très simplement et rapidement avec un service disponible en IPv4 et IPv6, ce qui ouvrira de formidables possibilités… le jour où le reste du monde aura sauté le pas !

Passage du blog de Wordpress à Pelican

jdn06 — Fri, 29 Jul 2016 15:37:00 +0200

Comme il est facile de le constater, mon blog a beaucoup changé en quelques jours, conséquence de mon abandon de Wordpress, au profit de Pelican. Quelles sont les raisons de ce changement ?

Avec deux douzaines d’articles en cinq ans, on ne peut pas dire que j’écrive beaucoup. De plus, mes articles sont en général assez simples et dépouillés, sans grandes fioritures multimedia. Il m’est donc apparu que Wordpress était largement surdimensionné par rapport à mes besoins, avec sa base de données, ses multiples plugins, thèmes et mises à jour, son éditeur visuel et la lourdeur inhérente à ce genre de solution très complète et graphique.

Lorsqu’un site est dynamique – et c’est forcément le cas d’un blog où on attend que le dernier article publié remonte en haut de la page d’accueil – l’ordinateur doit fabriquer les pages HTML à partir de la dernière version de ce que contient le blog. Dès lors, il peut les fabriquer à la demande, lorsqu’une page est consultée, comme c’est le cas avec Wordpress ou avec Django. Ou il peut les fabriquer après l’ajout d’un contenu, jusqu’à l’ajout du contenu suivant. Je crois donc qu’avec un rythme assez lent (moins d’un article par jour et une seule plume), il n’est pas forcément rationnel de reconstruire les pages à la demande et qu’il vaut mieux toutes les recréer en une fois à chaque modification du contenu. À titre indicatif, pour l’instant, la recontruction des vingt-cinq articles prend deux ou trois secondes sur un ordinateur assez ancien.

C’est le raisonnement qui m’avait déjà fait choisir Sigal plutôt qu’un système de gestion dynamique de galeries de photos comme il en existe beaucoup. D’autant qu’une fois la galerie fabriquée, sa technologie en simple HTML paraît plus pérenne qu’une technologie avec PHP et MySQL qui pourrait être cassée dans dix ou vingt ans sans possibilité de mise à jour.

Parmi les différents moteurs de blog fondés sur ce principe, le principal concurrent est PluXml, le moteur du champion du déréférencement Cyrille Borne, probablement plus connu dans la blogosphère française. Cependant, après quelques expériences très positives avec Django et Sigal, j’ai préféré cette solution pythonesque et ne suis pas déçu du résultat. Je blogue en console depuis vim, en Markdown. La configuration prend quelques minutes, le script de transition est assez performant et j’ai eu très peu à retoucher à la main. Bref, c’est à la fois simple, efficace et assez raffiné.

Le seul vrai problème que j’ai eu à régler concernait des lignes de code de type fichiers de configuration. En effet Pelican essaie automatiquement d’y associer un langage et encadre en rouge les caractères qui ne correspondent pas au langage qu’il a cru deviner. Pour régler ce problème, il suffit de faire suivre la balise de début de paragraphe de code de :::text afin qu’il n’essaie plus d’associer ce paragraphe à un langage.

Longue vie à Pelican !

NFS avec Kerberos

jdn06 — Sat, 23 Jul 2016 18:21:00 +0200

Après plusieurs années passées à regretter le manque de sécurité de mon partage NFS domestique, reposant sur les seules adresses IP, sans authentification par défaut, et à lancer périodiquement un bref regard sur Kerberos, avant d’en conclure rapidement que c’était décidément trop compliqué, j’ai profité des vacances pour regarder de plus près ce protocole intimidant – et pas seulement de nom…

Bon, je ne vais pas non plus mentir : je me suis cassé les dents deux bonnes journées avant de parvenir à le faire marcher, mais a posteriori, je dois dire que ce n’est finalement pas aussi difficile qu’on pourrait le croire. Non que deux journées soient un temps négligeable, mais simplement parce que j’ai beaucoup perdu de temps sur des choses stupides, faute de chercher immédiatement les bons outils de débogeage.

Je veux donc dire qu’en respectant quelques règles de bon sens, on doit pouvoir faire beaucoup mieux. Je renvoie tout d’abord au meilleur tutoriel en ligne que j’ai trouvé.

Quand on débute dans ce genre d’entreprise, il est inévitable de tâtonner un peu et de commettre des erreurs. Le problème est de les trouver sans tourner en rond pendant des heures. Or, la mise en place d’un tel système requiert tout un ensemble de démons et de protocoles qui coopèrent, en ne produisant par défaut que bien peu de traces dans les logs.

Essayons de tracer brièvement les étapes de la mise en place d’un serveur NFS Kerberisé sans FQDN, seulement avec des noms de machine sur un réseau local. J’utilise par défaut Kerberos MIT (la présence du concurrent Heimdal sur FreeBSD m’a posé d’ailleurs quelques problèmes pour les clients sur FreeBSD…)

Une fois krb5 installé, il faut commencer par éditer /etc/krb5.conf. Le realm qu’il faut créer sera en quelque sorte la marque de ce serveur Kerberos, qui le distingue des autres serveurs Kerberos avec lesquels les clients pourraient être en contact. De plus le fichier doit contenir quelques éléments minimaux. La documentation (et les conseils de débogeage) insistent beaucoup sur la nécessité d’utiliser exclusivement des FQDN. En fait, il est possible d’utiliser des noms de machines locales, à condition qu’elles figurent toutes dans les /etc/hosts du serveur et des clients.

Cela donne donc en gros :

[realms]
    MONREALM = {
        kdc = mon_serveur_kerberos
        admin_server = mon_serveur_kerberos
        nfs-server = mon_serveur_kerberos
        }

[domain_realm]
    mon_serveur_kerberos = MONREALM

[logging]
    default = /var/log/kerberos.log
    kdc = /var/log/kerberos.log
    admin_server = /var/log/kerberos.log

Il faut ensuite créer un fichier /var/lib/krb5kdc/kadm5.acl et placer dedans : */admin@MONREALM *

Il faut aussi ouvrir les ports suivants sur le serveur Kerberos à tous les clients potentiels et au serveur nfs : 88 et 749 en tcp et en udp.

Puis on intialise la base de données avec un sudo kdb5_util create -r MONREALM -s et on peut alors se connecter en admin localement avec un simple sudo kadmin.local, ce qui va nous permettre de lancer des commandes dans le shell de Kerberos :

listprincs permet de voir tous les principaux existants ; un principal est en quelque sorte un utilisateur et un contexte.
add_principal -randkey nfs/mon_serveur_nfs@MONREALM va permettre d’ajouter un principal pour le serveur nfs. On utilise l’option -randkey car on ne veut pas créer un mot de passe, mais une clé qui permettra au serveur nfs de s’authentifier tout seul.
ktadd nfs/mon_serveur_nfs@MONREALM pour ajouter la clé au fichier /etc/krb5.keymap

Il faudra ajouter comme principaux nfs/client1@MONREALM et nfs/client2@MONREALM, à nouveau avec des clés exportées, puis root/admin@MONREALM avec mot de passe (donc sans l’option -randkey), afin de pouvoir se connecter depuis les autres machines.

Il faut ensuite configurer les autres machines (serveur nfs et clients) pour pouvoir utiliser le serveur Kerberos. L’étape pour le serveur nfs est inutile s’il est sur la même machine que le serveur Kerberos. A chaque fois, il suffit de copier le fichier /etc/krb5.conf du serveur sur ces différentes machines (et de vérifier que leur fichier /etc/hosts est correctement complété) puis de lancer sudo kadmin, d’indiquer le mot de passe de sudo, puis celui que Kerberos demande. On importe ensuite la clé qui concerne cette machine, avec par exemple la commande ktadd nfs/client1@MONREALM afin que Kerberos transfère la clé depuis le serveur vers le fichier /etc/krb5.keymap du client1. Pour vérifier que cela a marché, on sort de kadmin et on essaie, toujours depuis le client, un sudo kinit -k nfs/client1@MONREALM. La commande ne doit pas produire d’erreur. On vérifie le résultat avec sudo klist.

Une fois tout cela ajouté, et les vérifications faites, la partie Kerberos proprement dite est terminée. Reste à faire marcher NFS avec Kerberos. Théoriquement, c’est le plus facile. En pratique, c’est là que j’ai beaucoup perdu de temps. Et comme je n’étais pas très l’aise avec Kerberos, j’étais persuadé qu’il s’agissait d’un problème avec la configuration de ce dernier, alors que ce n’était pas vraiment le cas.

Tout d’abord, il faut utiliser la norme récente du fichier /etc/exports, à savoir :

:::properties
/srv/nfs4                 192.168.1.0/24(ro,fsid=0,no_subtree_check,async,all_squash,sec=krb5)
    et non :
/srv/nfs4                 gss/krb5(ro,fsid=0,no_subtree_check,async,all_squash)

Ensuite, tout devrait fonctionner avec un simple sudo mount -v -o ro -t nfs4 mon_serveur_nfs:/ /point_de_montage_nfs depuis le client. Si le shell rend la main sans message d’erreur, vous avez gagné. Il reste cependant à obtenir des droits pour les autres utilisateurs que root sur la machine client. Pour cela, le plus simple est de faire créer un principal utilisateur@MONREALM avec mot de passe, dans le serveur Kerberos. Lorsque l’utilisateur veut se connecter au partage NFS monté par root, il suffit qu’il tape kinit dans une console et renseigne le mot de passe indiqué à la création du principal en question. Le ticket ainsi créé lui donne ensuite un accès de 24 heures.

Si vous avez moins de chance, il faut alors déboguer, et ça peut être long et fastidieux. Mon premier réflexe, puisque c’est le serveur nfs qui refuse le montage, a été de regarder, en m’inspirant du très bon article du wiki d’archlinux.org, les logs du côté serveur et client en activant :

pour le serveur

:::bash
sudo rpcdebug -m rpc -s all
sudo rpcdebug -m nfsd -s all

et pour le client

:::bash
sudo rpcdebug -m nfs -s all

Vu la verbosité du résultat, j’ai mis beaucoup de temps à comprendre que l’erreur ne figurait pas dans ces logs et qu’il fallait chercher ailleurs. Mais où ? Il faut regarder du côté des mécanismes qui assurent la transisition entre Kerberos et NFS, à savoir sous Archlinux les démons rpc-gssd (sur le client) et gssproxy (sur le serveur). J’ai ajouté un fichier de configuration pour gssproxy avec un mode debug, /etc/gssproxy/gssproxy.conf :

[gssproxy]
  debug = true

[service/nfs-server]
  mechs = krb5
  socket = /run/gssproxy.sock
  cred_store = keytab:/etc/krb5.keytab
  trusted = yes
  kernel_nfsd = yes
  euid = 0

J’ai ensuite placé une option de debug dans le lanceur du démon rpc-gssd (en faisant ça assez salement par un ajout d’option dans le fichier /usr/lib/systemd/system/rpc-gssd.service ExecStart=/usr/sbin/rpc.gssd $GSSDARGS -vvv) Avoir cette idée plus vite m’aurait fait gagner beaucoup de temps, plutôt que de tâtonner pendant des heures du côté de Kerberos, de RPC, de NFS et de leurs logs. J’ai fini par trouver un problème rapporté depuis un bon moment concernant la version 0.5.1 de gssproxy. En revenant à une ancienne version, 0.4.1, le problème a disparu et tout s’est mis à fonctionner selon mes attentes.

Happy end ? Par encore tout à fait, mais ça vient…

Il me restait encore à configurer mon client sous FreeBSD 10.3 ; or ce dernier utilise par défaut la version Heimdal et non la version MIT du protocole Kerberos. Tant que c’est le même protocole, tout doit être compatible, me disais-je, avant de déchanter un peu. En effet, toute utilisation de kadmin figeait le processus indéfiniment sans aboutir. En réalité, kadmin n’est pas compatible entre ces deux versions. Or, pour transférer la clé, il faut d’une manière ou d’une autre l’utiliser. J’ai donc installé la version MIT depuis les ports pour transférer la clé, puis l’ai désinstallée. Pour permettre le montage NFS via Kerberos, il faut lancer trois démons :

nfsclient
nfsuderd
gssd

Restait aussi un autre problème que j’ai contourné sans en comprendre l’origine, à savoir le fait que le ticket n’était pas créé automatiquement au montage NFS, provoquant l’échec de celui-ci. J’ai donc créé le script suivant pour lancer le client NFS sous FreeBSD :

:::bash
#!/bin/sh
sudo service nfsclient onestart
sudo service nfsuserd onestart
sudo service gssd onestart

sudo kinit -k nfs/client2@MONREALM
sudo mount_nfs -v -o nfsv4 mon_serveur_nfs:/ /point_de_montage_nfs

kinit

Et tout fonctionnait… enfin !

Ubuntu Phone : Aquaris E5

jdn06 — Sat, 13 Feb 2016 23:37:00 +0100

Petit compte-rendu, après deux mois d’utilisation de mon nouveau smartphone.

Une petite précision, pour commencer, qui limitera certainement le crédit accordé à ma prose, mais je dois préciser qu’il s’agit de mon premier smartphone. Mes éléments de comparaison seront donc les smartphones Android de mon entourage (plutôt des premiers prix) et ma tablette Asus sous Android.

Après la mort de FirefoxOS, il est évidemment essentiel que Canonical ne jette pas l’éponge. Je pense que le choix d’un milieu de gamme est assez judicieux en comparaison avec la stratégie de Mozilla : il s’agit de prouver que l’OS est efficace, ce qui est toujours compliqué avec un matériel qui l’est très peu. Offrir peu de références (2 BQ et 1 Meizu), même si ce n’est pas forcément un choix, est aussi assez rassurant pour l’acheteur : Canonical devrait pourvoir fournir du support pour ces modèles initiaux pendant un bon moment.

Contrairement à certains acheteurs que j’ai pu lire en ligne, je suis très très très satisfait de mon appareil. Il faut dire que je l’ai attendu, ce téléphone GNU/Linux ! Alors, oui, un certain nombre de fonctionnalités sont encore inexistantes et buguées, mais les choses avancent tout de même assez vite à chaque mise à jour. Et puis mes attentes n’étaient pas d’avoir mille applications dédiées, ni des jeux.

Voici donc une liste de ce que j’apprécie le plus sur cet appareil :

Un terminal intégré et plutôt bien pensé et un client openssh qui me permettent de me connecter à mon serveur en toute situation en un instant. Ce que j’avais vu fonctionner sous Android m’apparaît à la fois moins sécurisé et moins pratique, et ne fait pas partie de l’installation de base, de la partie du téléphone dont on peut être vraiment sûr.
Un accès root facilement accessible qui permet de tout casser si on a envie de s’amuser, ou plus simplement de risquer des usages non prévus (installer des softs par apt par exemple). Je suis le patron dès l’achat ; pas besoin de pirater son propre téléphone, comme sous Android. Au passage, je reste toujours stupéfait qu’il reste tant de brèches dans cet OS de Google, ce qui laisse penser que sa sécurité est toute relative…
Des mises à jour mensuelles du cœur de l’OS et aucun intermédiaire entre le téléphone et les développeurs. Ras-le-bol des tablettes pleines de trous de sécurité, parce que le fabricant, Asus en l’occurence, a décidé qu’après deux ans, tout le monde devrait racheter une nouvelle tablette et qu’il n’était plus la peine d’assurer les MAJ de sécurité d’Android.
Le partage de connexion via le wifi, apparu je crois juste au moment de mon achat. Il ne s’agit pas ici d’un avantage sur Android, mais d’une limite qui était très pénalisante et qui n’existe plus aujourd’hui : rassurons les éventuels acheteurs !
Un magasin d’applications certes encore mince, mais qui fournit l’essentiel dans une qualité utilisable, même si la plupart sont encore en bêta. Citons par exemple celles que j’utilise le plus : le courriel, le navigateur, l’agenda, les contacts, les notes, la visionneuse Libreoffice (bien meilleure que sous Android !), l’agrégateur rss, Openstreetmap (en connecté et en déconnecté), le journal Le Monde, Météo-France, la RATP, la SNCF et même une version mobile de Stellarium !
Une barre d’état beaucoup plus riche et agréable que celles des versions 4 & 5 d’Android (je ne connais pas la 6)
Les scopes : même si leur utilisabilité varie beaucoup d’un élément à l’autre, l’idée a clairement du potentiel.

Alors, oui, il manque encore beaucoup de choses. Citons les progrès que j’attends avec le plus d’impatience :

La possibilité d’utiliser un proxy ou Tor dans le navigateur
Un client XMPP pour Jabber
Des applications pour lire la vidéo ou la musique plus performantes
Le chiffrement de tout le téléphone, ou au moins du /home

Et puis in fine, la grande convergence : pouvoir lancer une application tournant sous Xorg depuis son téléphone, mais ce n’est pas encore pour tout de suite. D’ici là, je profiterai déjà pleinement de toutes les possibilités qu’offre déjà ce téléphone.

Du vin dans un bac à sable - Wine in a sandbox

jdn06 — Sat, 06 Dec 2014 01:24:00 +0100

Wine est un instrument merveilleux pour tous ceux qui ne veulent plus de Windows, mais ne peuvent pas non plus se passer entièrement d’une poignée d’applications dont les équivalents sous OS libre sont décevants. Ainsi, pour les maniaques de la copie audio parfaite, Exact Audio Copy est largement supérieur à Rubyripper (moins efficace et dont le développement a cessé) ou à Morituri (sans aucune souplesse en ce qui concerne les tags).
Cependant, Wine a un inconvénient majeur : il ouvre la machine aux menaces spécifiques à Windows. Sur les forums, on lit souvent des réponses à ce problème du type : « Mais comme on ne lance pas Wine en root, on ne compromet pas sa machine. » Certes, mais on expose toutes les données auxquelles l’utilisateur de l’application a accès, ce qui est très suffisant pour faire peur…

Les méthodes de sécurisation les plus simples (comme winetricks sandbox, qui supprime des lecteurs avec winecfg) n’étant pas très efficaces, mieux vaut se tourner vers la virtualisation. Cependant, outre que cette solution est lourde, EAC ne fonctionnera pas correctement sur un Wine de machine virtuelle Virtualbox, à cause du pilote virtualisé du CD-ROM.

Sous FreeBSD, il suffit de faire tourner Wine dans une jail. Mais sous Linux, la mise en place de container LXC était une opération lourde, assez décourageante pour un besoin aussi basique.

La donne a cependant changé avec l’arrivée de Docker : il devient en effet assez facile de créer un container pour faire tourner une application graphique sous Wine.

Voici comment je m’y suis pris.

Fichier Dockerfile pour créer le container :

:::text
FROM ubuntu:

ENV DEBIAN\_FRONTEND noninteractive

RUN apt-get update -y  
RUN apt-get install -y python-software-properties software-properties-common
RUN add-apt-repository -y ppa:ubuntu-wine/ppa  
RUN dpkg --add-architecture i386  
RUN apt-get update -y  
RUN apt-get install -y wine1.7 winetricks  
RUN apt-get purge -y python-software-properties  
RUN apt-get autoclean -y

\# Remplacer 1002 & 100 avec user & group id  
RUN export uid=1002 gid=100 && \
    mkdir -p /home/developer && \
    echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
    echo "developer:x:${uid}:" >> /etc/group && \
    echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
    chmod 0440 /etc/sudoers.d/developer && \
    chown ${uid}:${gid} -R /home/developer

USER utilisateur  
ENV HOME /home/utilisateur  
CMD /usr/bin/wine

Un petit coup de docker build utilisateur/wine.
Le container est construit. Reste qu’il ne faut pas y placer les données, si on veut pouvoir le faire évoluer et se mettre à jour. Le plus pratique pour pouvoir aussi échanger des fichiers entre l’hôte et le container est de créer un dossier Wine sur l’hôte qu’on montera comme home dans le container avec : -v emplacement-dossier-Wine:/home
Il faut créer à l’intérieur un dossier au nom de l’utilisateur : mkdir utilisateur
Pour rediriger le container vers la sesson X de l’hôte : -e DISPLAY=\$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix

Ce qui donnera, pour ouvrir un shell dans le container :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/bash

Il faut ensuite créer un environnement wine pour 32 bits, ce qu’on peut faire avec l’instruction dans le shell ouvert dans le container :
WINEARCH=win32 winecfg

On procède ensuite, toujours dans le shell à l’installation normale d’une application wine. On l’essaie ensuite en la lançant depuis le shell. Si tout marche correctement, on peut ensuite se fabriquer un lanceur depuis l’hôte, de type :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/sh -c "cd /home/utilisateur/.wine/drive_c/Program\ Files/Programme/ && wine Prgramme.exe"

Le container se lance et se ferme en même temps que l’application. Voilà notre vin en sécurité dans le bac à sable…

TF1 raconte n’importe quoi…

jdn06 — Thu, 18 Jul 2013 17:55:00 +0200

J’écris rarement sur le coup de la colère, car cela fait souvent dire des bêtises. Je ne sais pas si le directeur de e-TF1 était en colère quand il s’est adressé à l’auteur de Captvty, mais son incompétence technique et sa mauvaise foi m’ont beaucoup énervé.

Apparemment, ce monsieur et ses services techniques et juridiques ignorent tout de la différence entre un site et une application et considèrent que l’utilisation de leur très médiocre site de Replay est en soi une intrusion dans leur système de traitement informatisé si elle ne se fait pas comme ils imaginent qu’elle doit se faire, au motif qu’ils subissent un manque à gagner publicitaire. Je pense qu’ils devraient aussi porter plainte contre Adblock Plus et exiger qu’on n’utilise pas une machine contrôlée par l’utilisateur du genre Linux sous peine de poursuites. Il faudrait aussi créer des télévisions dont on ne peut couper le son pendant les pubs, car il existe tant de gens malintentionnés…

Je ne connais pas personnellement le développeur de Captvty, son logiciel n’est pas libre et est développé sous .NET. Je n’ai donc aucune sympathie particulière pour lui, si ce n’est :

Qu’il a fait l’effort de modifier son outil afin de le rendre plus utilisable sous Wine, ce qui est exceptionnel dans le monde du développement sous Windows !
Qu’il est tout à fait disponible aux suggestions et répond très vite aux courriels qu’on peut lui adresser.
Que son logiciel rend des services très appréciables.

En ce qui me concerne, il n’y a aucun manque à gagner pour TF1 lorsque j’utilise Captvty puisque je ne télécharge pas d’émission de TF1. Cependant, même si je le faisais, il n’y aurait toujours aucun manque à gagner possible, car je n’ai aucune intention de regarder le direct, ne recevant pas la télévision, ni d’utiliser leur Replay en Flash qui lague affreusement entre deux publicités.

Un dernier point : quand on écrit une mise en demeure, on relit son courrier, pour corriger les éventuelles fautes d’orthographe ; sinon on risque de passer pour un pas grand-chose…

ZoL - ZFS on Linux

jdn06 — Fri, 29 Mar 2013 21:32:00 +0100

Un tout petit billet pour fêter la sortie d’une version, la 0.6.1 !

Cela fait maintenant six mois que j’utilise, parallèlement à ZFS sous FreeBSD, ZoL sous Archlinux, grâce aux paquets AUR de demizer — grâce lui soit rendue ! Les différents Release Candidates se sont montrés particulièrement stables et je n’ai eu aucun problème malgré de nombreuses pannes de courant malheureuses. J’utilise même régulièrement ZoL pour de gros diques USB externes sans aucun problème à signaler, alors que BTRFS m’avait joué de vilains tours sur ce type de support.

La création de dépôts pour Debian, Fedora et CentOS devrait grandement faciliter la mise en œuvre pour les utilisateurs de ces distributions, alors que seule Ubuntu permettait jusque-là une mise en oeuvre vraiment très simple grâce au PPA zfs-native.

Espérons donc que son usage va maintenant se développer largement dans l’univers linuxien, car il est toujours dommage de ne pas utiliser ce qui existe de mieux… FreeBSD n’est pas nécessairement l’outil le plus adapté à tous les usages. Quant à OpenIndiana, la dernière mise à jour remonte à octobre dernier, ce qui n’est pas bon signe. Pouvoir choisir son OS et son système de fichiers indépendamment, ce serait un progrès important.

Tous en prison - Harmonie entre jails et systèmes de fichiers - Épisode 2

jdn06 — Sun, 22 Jul 2012 20:31:00 +0200

Intéressons nous un peu à la manière dont on gère concrètement les transferts et les sauvegardes de jails sous FreeBSD. Il y a un avant et un après ZFS, mais dans les deux cas, j’utilise le très pratique ezjail pour créer et administrer les jails. Il contient même une option pour que les jails sous ZFS se créent automatiquement dans un nouveau système de fichiers séparé.

Sans ZFS

J’utilise une partition UFS2 avec les soft updates activés que je monte en /usr/jails. J’utilise ensuite le vieux mais très performant couple dump/restore sur un snapshot de cette partition. L’option -L de dump pourrait automatiser le snapshot, mais il se trouve que l’idée est de minimiser l’arrêt des jails et que dump n’indique pas de manière précise le moment où le snapshot est terminé. La séquence est donc la suivante :

:::shell
ezjail-admin stop
time mksnap_ffs /usr/jails /usr/jails/.snap/2012.MM.JJ #(compter 4 à 20mn pour 10Go en fonction du nombre de snapshots déjà présents)
ezjail-admin start
mdconfig -a -t vnode -f /usr/jails/.snap/2012.MM.JJ -u 4
time dump -0auf /media/backup/2012.MM.JJ.dump /dev/md4 #(compter 1h30 pour 10Go)
mdconfig -d -u 4

Le mieux est de commencer par supprimer les snapshots précédents, car cela joue un rôle très important pour minimiser le temps d’arrêt des jails durant la création du snapshot.

Pour transférer les jails sur un autre serveur, il faut y copier le fichier, puis formater la partition où l’on placera les jails et la monter. Enfin, on lance :
cd /usr/jails restore -r -f /media/backup/2012.MM.JJ.dump

Si on veut ne restaurer qu’une jail, on utilise :
restore -f /media/backup/2012.MM.JJ.dump -x prison1 Specify volume? 1 Set owner mode? y

Ce qui est évidemment très appréciable est l’utilisation du snapshot : 4mn d’arrêt pour mon serveur domestique, cela reste vraiment très acceptable. Alors que si j’archivais directement avec tar ou dump, il faudrait plus d’une heure et demie d’arrêt des jails.

Ce qui est un peu pénible, c’est qu’il faut transférer ce gros fichier vers le serveur et le restaurer, mais les niveaux de dump permettent d’alléger l’opération et de faire des sauvegardes incrémentielles avec une commande de type :

:::shell
time dump -1auf /media/backup/2012.MM.J1.dump /dev/md4
time dump -2auf /media/backup/2012.MM.J2.dump /dev/md4 etc.

Il est vrai qu’il faut être bien organisé et méthodique pour ne pas faire de bêtises et mélanger les différents niveaux de dump sur le serveur de sauvegarde.

Avec ZFS

Le principe est un peu différent et encore plus performant. Mes jails sont dans un pool nommé prison. Elles se situent dans prison/jails et sont montées sur /usr/jails

Chaque jail est sur son propre système de fichiers : il n’est donc pas nécessaire de faire un snapshot de l’ensemble des jails ; on peut n’arrêter qu’une jail et la transférer. Ceci dit, vu la rapidité et la performance du système de fichiers, je n’utilise même pas cette possibilité pour l’instant.
Les snapshots sont réellement instantanés – quel que soit le nombre de snapshots déjà existants. Comme j’arrête quand même les jails (la cohérence des données est pour moi plus importante qu’une toute petite interruption de service), le temps d’arrêt des jails tient simplement au temps d’exécution du script d’arrêt et de démarrage d’ezjail.
L’envoi des données modifiées depuis la dernière sauvegarde vers un fichier ou vers un serveur est vraiment très rapide et facile.

Cela donne concrètement la séquence suivante :

:::shell
ezjail-admin stop
zfs snapshot -r prison/jails@2012.MM.J1
ezjail-admin start

On peut envoyer vers un serveur via ssh un flux complet ou les modifications effectuées depuis la dernière sauvegarde : dans ce dernier cas, l’avantage par rapport aux niveaux de dump des snapshots d’UFS2, c’est que le système signalera toute erreur dans l’ordre des snapshots importés.

:::shell
zfs send -R prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv prison/jails
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | ssh adresse.de.mon.serveur zfs recv -F prison/jails

On peut aussi envoyer les données – complètes ou incrémentielles – vers des fichiers de sauvegarde. Vu la rapidité de l’opération, je les compresse systématiquement :

:::shell
zfs send -R prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1.zfs.gzip
zfs send -Ri prison/jails@2012.MM.J0 prison/jails@2012.MM.J1 | gzip > /media/backup/2012.MM.J1-diff-2012.MM.J0.zfs.gzip

Quelques chiffres pour donner une idée des choses, toujours avec des jails d’environ 10Go en tout :

0.013s pour créer le snapshot – à comparer aux 4mn sous UFS2
20mn pour créer un fichier de sauvegarde complète sans compression – à comparer à 1h30 sous UFS2
40mn pour créer le même fichier compressé en gzip
5 à 8 mn pour une sauvegarde incrémentielle d’environ 450Mo, que ce soit vers un serveur ou vers un fichier

Par sa souplesse et sa rapidité, ZFS est donc remarquablement bien adapté à la sauvegarde et au transfert des jails et permet d’optimiser encore ce qui marchait déjà bien sous UFS2.

Tous en prison - Harmonie entre jails et systèmes de fichiers - Épisode 1

jdn06 — Sat, 14 Jul 2012 10:31:00 +0200

Les jails sont vraiment une formidable technique pour les serveurs auto-hébergés. Comme mes interlocuteurs linuxiens restent souvent assez sceptiques devant cet enthousiasme, commençons par en expliquer l’intérêt à qui n’en a pas eu l’usage.

Les jails permettent de créer des dizaines de machines partiellement virtualisées au sein de son serveur avec la plupart des avantages d’une machine virtuelle, sans la lourdeur (en ressources de la machine et pour l’administration) inhérente à la virtualisation. Par exemple, mon modeste eeePC 900 pourvu d’un seul giga de RAM accueille sans qu’il y paraisse 10 machines virtuelles. Si je passais à 50, je pense que le seul changement vraiment significatif serait le démarrage de 50 jails, forcément un peu long ; mais ensuite, processeur et mémoire ne semblent pas plus affectés que si les services contenus dans ces jails tournaient directement sur la machine.

Bon, donc, techniquement, c’est très performant, mais ça sert à quoi ? Je n’insisterais pas sur l’aspect sécuritaire, même si mon titre semble appeler de tels développements : le cloisonnement des services est évidemment une protection intéressante ; néanmoins, dans le cas d’un serveur domestique, la chose n’est pas forcément essentielle.

Non, l’intérêt principal, c’est la sauvegarde et le transfert des services d’une machine à l’autre. Je m’explique : lorsqu’on héberge des services importants (mails par exemple), on tient :

à préserver ses données
à pouvoir reconstruire très rapidement son serveur à l’identique ailleurs en cas de défaillance

Pour cela, il faut utiliser une politique de sauvegarde bien conçue qui serve ces deux objectifs. Dans le cas d’un serveur hébergeant une dizaine de services directement, les données importantes à préserver sont assez éclatées :

Configuration du parefeu
Configuration desdits dix services (dans /etc ou dans /usr/local/etc)
Données des services (dans /var/mail, dans /srv/http, dans /home etc.)

Bref, tout est dispersé et le seul moyen de pouvoir reconstruire rapidement le serveur est le backup complet. J’imagine que vous ne voyez peut-être pas le rapport avec les systèmes de fichiers, annoncé dans le titre, mais nous y sommes presque.

De nombreux linuxiens proposeront quelque chose comme un tar ou un rsync sur l’ensemble de la machine. Mais il faut tenir compte d’une seconde problématique : pour pouvoir être correctement sauvegardés, certains services demandent à être arrêtés, sans quoi les données sauvegardées par tar à l’instant t ne seront pas compatibles avec leurs compléments contenus dans d’autres fichiers sauvegardés à l’instant t+1. J’ai mesuré l’ampleur de ce problème à mes dépens avec OpenJabNab, un jour où j’avais vraiment besoin de ma sauvegarde… inutilisable.

Qu’à cela ne tienne : arrêtons le serveur, démarrons-le même depuis un livecd (nous sommes auto-hébergés, donc tout-puissants !) et lançons le tar en question pour les heures à venir. Soit, mais :

Il faut être chez soi ; pas de sauvegarde pendant les vacances… On peut certes renoncer au livecd et se contenter d’arrêter les daemons des services qui peuvent poser problème, mais on ne sait pas qu’il y aura problème avant d’en faire l’expérience ; il faudrait tester la reconstruction du serveur et sa mise en ligne pour être sûr de n’avoir pas péché par optimisme.
Les services hébergés ne permettent pas toujours de rester hors-ligne durant plusieurs heures toutes les semaines. Quid du mail, par exemple ?

Et c’est là que le système de fichiers (ou pour Linux le gestionnaire de volume logique) entre en jeu, grâce aux clichés ou snapshots : ils permettent de figer en quelques instants un état du système de fichiers qu’on copiera ensuite, plutôt que de copier directement les fichiers. Résultat : un serveur coupé quelques minutes et non plus quelques heures.

Si l’on combine les jails et les snapshots, le bonheur est total, puisque les services forment des blocs homogènes (et non plus dispersés sur tout le système) qu’on peut copier intégralement, sans pour autant être obligé de les arrêter plus que quelques minutes ou quelques secondes, selon le type de système de fichiers.

Voilà pour l’intérêt de la chose. Nous examinerons la méthode dans l’épisode suivant…

FreeBSD : la saga continue - de 8.2 à 8.3

jdn06 — Wed, 04 Jul 2012 19:27:00 +0200

Vous vous souvenez peut-être de mes déboires lors de la dernière mise à jour de FreeBSD. J’ai réussi à faire encore plus fort cette fois-ci… Pourtant, tout avait bien commencé. J’avais tenu mes bonnes résolutions d’alors et avais répété la manœuvre sur une machine virtuelle. Cette machine ne servait pas d’ailleurs qu’à répéter : grâce au système des jails – dont je ne dirais jamais assez de bien – il s’agissait de transférer tous les services en ligne sur la machine virtuelle pendant que je mettais à jour le serveur en dur. Comme ça, même en cas de pépin, pas d’interruption de service et donc pas de coup de stress. Eh bien, j’ai rudement bien fait de procéder ainsi.

Comme je suis joueur, je décide de réutiliser freebsd-update et lance la procédure sur ma machine virtuelle :

Copier le /etc et vérifier la copie (ne pas faire deux fois la même bêtise…)
Remettre un noyau générique dans /boot/GENERIC
Lancer un petit nextboot -k GENERIC et redémarrer
freebsd-update -r 8.3-RELEASE upgrade
La machine répond par Preparing to download files… done.- Fetching 27286 patches - Prévoir donc un bon moment
Puis se lance le merge des fichiers de config : 21 files changed, 119 insertions(+), 117 deletions(-) L’instrument est toujours aussi mal fait, surtout en comparaison de mergemaster que j’ai appris à utiliser entre temps. Pourquoi n’est-il pas intégré à freebsd-update ? Cela me dépasse… et donne très envie de ne plus mettre à jour que par les sources ; mais je m’obstine.
freebsd-update install
nextboot -k GENERIC à nouveau puis reboot
freebsd-update install
Ensuite, je mets à jour les ports puis je recompile tous les logiciels tiers avec portmaster -afd
nextboot -k GENERIC à nouveau puis reboot
Je recompile ensuite mon noyau perso allégé et qui intègre ALTQ et redémarre
J’arrête les jails et lance un ezjail-admin update -s 8.3-RELEASE -u

Ensuite il ne reste plus qu’à effectuer un mergemaster de chaque jail :

mount_nullfs /usr/src /usr/jails/jail1/mnt # Depuis l’extérieur de la jail
echo "IGNORE_FILES='/boot/device.hints /etc/motd /etc/hosts'" > /etc/mergemaster.rc # Depuis l’intérieur de la jail
mergemaster -iFU -m /mnt`

et une recompilation des logiciels tiers avec portmaster -afd après un ezjail-admin update -P

L’ensemble est assez long, mais se déroule parfaitement. Je prends note du détail de la procédure, transfère le routage vers le serveur virtuel et me lance dans la mise à jour du véritable serveur. Comme j’ai pu mesurer la longueur du téléchargement et de l’application des patches, je le laisse tourner la nuit suivante pour s’y employer. Au matin, je retrouve la machine méchamment plantée. Au redémarrage le fsck de la partition qui contient /var bloque. Il faut dire que la partition est pleine à 109%. J’ai oublié de vider /var/db/freebsd-update/files et les patches téléchargés ont rempli la partition à bloc. Lorsque j’essaie de libérer de l’espace, l’opération plante, comme si l’écriture des métadonnées n’était plus possible tant le disque était plein. Je redémarre en single user, puis même avec la clé USB d’installation pour un fixit. Rien n’y fait : je descends à 105%, mais le disque finit toujours par planter et le fsck qui suit réécrit dans lost+found les fichiers effacés.

Je suis assez agacé, et cette fois, le problème paraît paradoxalement plus compliqué à régler que la dernière fois : je pourrais formater la partition et la réinstaller depuis une sauvegarde, mais je finis par me dire que c’est peut-être le bon moment pour réinstaller le système et régler les problèmes d’alignement que j’avais sur les systèmes de fichiers présents sur des supports SSD et faire passer ma partition /var de 6 Go à 12 Go.

La mise à jour se transforme donc en installation de 8.3. Comme je veux utiliser des partitions gpt, je renonce à utiliser le traditionnel sysinstall et me lance dans une installation à la main, qui rappelle beaucoup OpenBSD, en suivant ce tutoriel.

L’installation se déroule très bien et je peux utiliser mergemaster, pour mettre à jour mes anciens fichiers de configuration. Mais le disque dur USB sur lequel se trouvent mes jails n’est plus reconnu au démarrage, pour une raison qui je crois m’échappera définitivement : si je le débranche et le rebranche, alors tout rentre dans l’ordre : pas très pratique pour un serveur, même si les redémarrages sont rares !

Je vais donc pousser plus loin l’expérimentation et remplacer ce disque dur par deux autres installés en miroir : en effet, j’avais connu un vilain crash en janvier et ce disque dur alimenté par USB reste le point faible de mon serveur. Quant à faire, puisque mes services sont toujours sur machine virtuelle, passons donc ces disques dédiés aux jails en ZFS et testons la fiabilité : ce serait quand même sympathique d’utiliser ça sur mon vieux eeePC 900 32 bits avec 1Go de ram. En prenant quelques précautions, l’ensemble semble tout à fait opérationnel. En lançant plusieurs grosses copies en même temps, le serveur semble tenir la charge. Après 2 semaines en utilisation réelle, je n’ai pas constaté de problème. Et le gain d’administration dépasse encore mes attentes. Mais laissons cela pour un prochain article.

Mes conclusions restent à peu près inchangées depuis la dernière mise à jour :

Éviter freebsd-update upgrade
Répéter l’opération en virtuel
Disposer de pas mal de temps devant soi

OpenBSD sur un ordinosaure

jdn06 — Sun, 01 Jan 2012 13:01:00 +0100

Petit point de début d’année. Voici un bon moment que je n’ai rien écrit sur ce blog. Pourtant, les derniers mois ont été très actifs sur le plan informatique :

finalisation de mes jails FreeBSD et mise en place de règles pf un peu plus serrées ; recompilation du noyau FreeBSD avec altq
installation d’un serveur OpenJabNab pour libérer le lapin de ma femme
Changement de FAI : j’ai quitté Orange pour OVH notv.
Remplacement du Debian Squeeze de mon vieux Pentium 200MMX par un OpenBSD 5.0

Je reviendrai peut-être sur différents points dans les semaines qui viennent, mais je vais développer ici cette dernière expérience car le résultat m’a agréablement surpris.

Expliquons d’abord le démarche. Mon Pentium 200MMX, avec ses 64Mo de RAM, souffrait d’une lenteur rédhibitoire sous Debian Squeeze. J’avais très vite renoncé à l’idée initiale d’utiliser une plate-forme LAMP dessus (je débutais, j’étais plein d’illusions.) J’avais décidé d’en faire un serveur FTP pour un usage ponctuel, après l’avoir allégé de tout ce qui semblait possible. J’avais aussi réduit le nombre de tty, remplacé le bash des utilisateurs normaux par un simple sh, diminué le hash des mots de passe de pam (sauf pour root). Tout cela avait bien accéléré les opérations, mais le démarrage durait bien 5mn jusqu’à l’obtention d’un shell ssh utilisable. La vitesse des échanges sous ssh par ethernet plafonnait à 40K/s ; à peine mieux par ftp. Le démarrage des sessions ftp mettait une trentaine de secondes. Quant aux mises à jour du système via aptitude, elles prenaient réellement plusieurs heures. Bref, décevant.

J’avais donc décidé de passer cette machine à Slitaz et d’attendre pour cela la prochaine stable (4.0) qui devait sortir sous peu. Mais les mois passant, la distribution ne sortait pas. Comme j’avais un peu de temps ces derniers jours et que je m’étais amusé avec un OpenBSD 5.0 virtuel qui fonctionnait très correctement, je décidai d’essayer une installation en dur, sans grand espoir de vitesse cependant (une installation de type laptop sous eeePC m’avait paru bien lente il y a deux ans).

L’installation, pas très rapide vu les vitesses du disque dur et du lecteur CDROM, se fait tout de même beaucoup plus rapidement que Debian. Mais la surprise vient surtout de la vitesse de démarrage après installation. J’obtiens un shell sous ssh en moins de deux minutes. Toutes les commandes sont très réactives sans changer quoi que ce soit à la configuration par défaut. ftpd se configure très facilement de manière satisfaisante et je préfère largement pf à iptables pour configurer le parefeu.

Comme les mises à jour du système sont très très rares, elles me prendront peu de temps. Reste la question des logiciels supplémentaires installés, dont la mise à jour n’est pas forcément aisée. En même temps, si je me limite à l’utilisation prévue initialement, un serveur ftp, il n’y a rien à ajouter au système de base.

Ce qui n’était qu’un essai un peu au hasard s’avère donc une excellente opération et cet OS devrait a priori rester un bon moment sur cette machine !

Prosody sur un serveur FreeBSD

jdn06 — Sat, 09 Jul 2011 17:11:00 +0200

Prosody est un serveur Jabber léger écrit en Lua. Sa compilation par les ports est très facile. La configuration m’a demandé un peu plus d’effort et les informations étant assez disséminées (même si le site de Prosody est assez bien documenté), je synthétise ici les opérations de base pour la mise en service.

Le problème du pid

Le serveur refuse de démarrer indiquant qu’il ne trouve pas le pid. Il faut éditer le fichier de configuration /usr/local/etc/prosody/prosody.cfg.lua, vérifier que posix apparaît dans les modules_enabled (ça doit être le cas par défaut) et ajouter après la fermeture des {} des modules la ligne suivante

pidfile = "/usr/local/var/lib/prosody/prosody.pid"

J’avais d’abord voulu placer ce pidfile dans /var/run, mais le script du démon veut le lancer dans l’adresse ci-dessus et du coup ça ne fonctionnait pas.

Les certificats SSL

La création d’une paire de clés autosignées étant bien documentée, je n’insiste pas sur ce point. Dans le fichier de configuration, il faut au moins placer le chemin de ces clés à deux endroits :

dans les SSL/TLS-related settings
dans chaque Virtualhost, avec des clés qui reprennent le nom du Virtualhost.

Le point où ça a coincé pour moi, c’est la gestion des droits du .key : si on le met en chmod 400, il faut alors effectuer un

chown prosody:prosody nom_de_la_clé.key

pour que le programme puisse le lire, puisqu’il démarre en démon sans les droits root. L’utilisateur et le groupe prosody sont normalement créés automatiquement lors de la compilation-installation du programme.

Les logs

Dans log = … le plus simple est d’utiliser syslog. Ou il faut créer des fichiers de log sur lesquels prosody ait des droits d’écriture (puisqu’il ne démarre pas en root)

Les ports à ouvrir

Par défaut, prosody utilise les ports suivants (on peut les changer assez facilement d’après la doc) :

5222 : écoute des connexions de clients
5269 : écoute des connexions serveur à serveur
éventuellement 5280 : écoute des connexions via http (avec un serveur de type BOSH) qui permettent de se connecter par un navigateur web et par exemple ainsi de contourner les filtrages de port.

Ce qui donne, pour tous ceux qui utilisent Packet Filter, l’ajout des lignes suivantes dans pf.conf :

:::text
pass in on $interface proto { tcp, udp } from any to $interface port 5222
pass in on $interface proto { tcp, udp } from any to $interface port 5269
pass in on $interface proto { tcp, udp } from any to $interface port 5280

Le lancement de Prosody

Deux manières possibles :

/usr/local/etc/rc.d/prosody start (si prosody_enable="YES" ajouté dans /etc/rc.conf)
prosodyctl start

Ajout d’utilisateurs :

Il est bon d’avoir ajouté un utilisateur administrateur dans le fichier de configuration (admins = { "user1@example.com"})

Si la configuration de base n’a pas été changée (allow\_registration = false;) il faut créer les utilisateurs par une ligne de commande sur le serveur :

prosodyctl adduser nom_de_l'utilisateur

Sinon modifier dans la configuration :

allow_registration=true ;

pour que tous ceux qui ont accès au serveur puissent se créer un compte directement par leur client jabber.

Et voilà… Bel outil…

Ajout du 10 février 2014 :

Le serveur aura tourné presque trois ans sans toucher à la configuration. Vraiment un bel outil.

Le passage à la version 0.9.2 demande une petite manipulation pour ceux qui le font tourner derrière un nat. En effet, le serveur semble par défaut vouloir se connecter à l’adresse ip publique, qu’il ne trouve évidemment pas sur l’interface. Le message du mainteneur du port est tout sauf clair, puisqu’il semble décrire l’inverse de ce qu’il faut faire :

If you're running Prosody in a jail and experience problems, please add the
following to the global section of your prosody.cfg.lua:
interfaces = { 'x.x.x.x' }
where 'x.x.x.x' is the public IP you wish Prosody to bind to.

En réalité, il faut placer l’adresse interne du serveur à la place des 'x.x.x.x', par exemple '10.2.2.3'.

Enlightenment vs Openbox

jdn06 — Sun, 26 Jun 2011 17:01:00 +0200

Ces deux dernières années, j’ai essayé pas mal de gestionnaires graphiques, principalement intéressé par ceux qui se présentaient comme très légers, afin de pouvoir les utiliser sur des machines anciennes ou virtuelles. Les deux qui m’ont le plus séduit, dans cette catégorie, sont sans conteste Enlightenment et Openbox. Si le premier avait mes préférences l’an dernier, c’est le second que j’utilise le plus aujourd’hui. Je vais essayer de présenter ce qui fait à mes yeux leurs atouts respectifs.

Beauté, effets visuels et performances

La question est évidemment subjective et les thèmes, très nombreux dans les deux cas, multiplient les possibilités de trouver chaussure à son pied.

Là où Openbox a un côté minimaliste zen, Enlightenment arrive par défaut avec une série de thèmes assez bling-bling, mais pas désagréables pour autant. D’autres thèmes existent, comme celui de la saisie d’écran ci-dessous.

Openbox :

Enlightenment :

Ajoutons que les performances d’Enlightenment sont plus impressionnantes : la fluidité des transitions, par exemple en passant d’un bureau à l’autre, est très belle même sur une machine très limitée. Pour obtenir la même chose sur Openbox, il faut activer un gestionnaire de composite (genre cairo-compmgr) et la machine perd beaucoup en légèreté et en stabilité…

L’occupation en mémoire

Je ne prétends pas ici faire un benchmark rigoureux, mais simplement faire part des chiffres que j’obtiens après démarrage de la machine sous divers gestionnaires graphiques. Les pourcentages donnent la fraction de mémoire occupée par l’application et le chiffre qui suit free est la quantité de mémoire totale restée libre, exprimée en Ko, sachant que l’ordinateur concerné dispose d’un giga de RAM.

Openbox & tint2 : (version spartiate, donc…)

X 1.1%

openbox 0.8%

tint2 0.7%

TOTAL 2,6%

free 544864 libres

Openbox & tint2 avec cairo & xcompmgr :

X 1.1%

cairo-dock -o 3.2 %

openbox 0.8

tint2 0.7

xcompmgr -c 0.2

TOTAL 6%

free 507080 libres

Enlightenment :

X 1%

enlightenment 3.5 %

lib enlightenment 0.3

TOTAL 4,8%

free 518000 libres

À titre de comparaison, XFCE :

X 1.2%

xfce4-panel 2

xfdesktop 1.7

xfwm4 1

xfce4-session 0.7

thunar --daemon 0.6

xfsettingsd 0.4

xfce4-settings-helper 0.4

TOTAL 8%

free 494528 libres

Openbox est donc largement devant si l’on se contente du strict minimum, mais à effets graphiques équivalents, Enlightenment l’emporte assez largement.

Stabilité

Openbox n’a jamais été pris en défaut durant les mois où j’ai travaillé avec. Enlightenment est nettement plus capricieux, notamment du fait du développement continuel qui a longtemps eu pour conséquence l’absence de version stable dans la branche e17. Sous Archlinux, par exemple, la mise à jour régulière du svn était à l’origine de nombreux problèmes, dont le plus évident était l’obsolescence soudaine de certains morceaux essentiels, non remplacés sur le moment par une nouvelle application : entrance (l’équivalent de gdm ou de slim), par exemple, a cessé d’être développée un beau jour sans prévenir. Résultat : l’application installée ne permettait plus de lancer une session mise à jour d’Enlightenment. Elsa, qui doit le remplacer, n’existe toujours pas en version stable, plus d’un an après.

Il m’est arrivé aussi plusieurs fois d’avoir à supprimer tous les fichiers de configuration contenus dans home/.../.e afin de pouvoir démarrer, le remplacement de certains programmes bloquant sinon le démarrage de la session.

Ceci dit, la situation semble s’être un peu améliorée depuis le passage d’e17 en 1.0.

Pour être juste cependant, il faut aussi parler des petits problèmes liés à l’utilisation d’un gestionnaire composite et d’un dock de type cairo-dock avec Openbox, programmes qui ajoutent une certaine instabilité. Avantage cependant de cette solution : les éléments sont bien séparés les uns des autres et peuvent être tués et redémarrés de manière indépendante sans avoir à redémarrer la session.

Facilité d’usage et de configuration

Dans un premier temps, la bataille semble perdue pour Openbox, et cela m’a retenu un bon moment de vraiment m’y plonger. Openbox arrive complètement nu : pas de panel, un grand écran vide avec un menu accessible par le clic droit, mais qui n’aide pas beaucoup puisqu’il ne contient qu’une collection de lanceurs par défaut sans rapport avec ce qui est installé sur la machine. Tout reste à bâtir.

À l’opposé, Enlightenment s’utilise très bien out of the box : la barre se trouve en bas de l’écran et le menu permet de lancer les applications installées.

Il ne faut pas cependant en rester à cette première impression.

Openbox est extrêmement bien documentée et sa personnalisation se fait de manière simple, cohérente et logique par quelques fichiers de configuration contenus dans le home. Les changements peuvent être testés sans avoir besoin de relancer la session. En cas d’erreur, rien ne bloque. Pour un archlinuxien, cette façon de faire s’intègre parfaitement au reste du système et mérite incontestablement la qualification de KISS.

Enlightenment me semble beaucoup plus contestable dans ses choix. Une précision avant de continuer ; ce qui suit est assez critique vis à vis d’un projet que j’aime beaucoup et auquel je n’ai pas du tout pris la peine de contribuer, pas même par un rapport de bug. Il ne s’agit pas de râler ou de se plaindre, mais juste de présenter mon point de vue subjectif sur les points forts et les points faibles pour l’utilisateur que je suis.

Pour faciliter la configuration, tout se fait de manière graphique (si quelqu’un a trouvé des infos sur une édition des fichiers de configuration, qu’il me mette un lien en commentaire !) D’ailleurs, la presque totalité des fichiers de configuration présents dans home/.../.e/ sont des fichiers non éditables de type .cfg. Si j’ai bien compris, Enlightenment tire en partie sa force de cette compilation des fichiers de configuration, mais cela rend leur édition impossible sans passer par la configuration graphique. Je ne suis pas du tout allergique à cette manière de faire, loin de là. Le problème est que l’outil graphique de configuration est à la fois labyrinthique et très peu ergonomique à mon goût (voir saisie d’écran plus haut).

Les menus sont assez foisonnants et étroits, mais surtout leur organisation n’est pas des plus intuitives (et la documentation reste assez pauvre ou alors obsolète).

Un exemple : pour installer une extension (appelée module dans le langage Enlightenment) dans le panel (appelé rack), il ne faut pas éditer le rack, mais éditer d’abord les modules, activer ceux dont on a besoin, puis éditer le rack et y activer le module voulu. La configuration du menu n’est guère plus aisée (ajout d’un lanceur personnalisé, par exemple).

Pour moi, si un outil graphique n’est pas intuitif, alors il est beaucoup plus pénible à utiliser qu’un fichier de configuration bien documenté.

Openbox fait un peu peur au début, mais il est beaucoup plus souple à l’usage qu’Enlightenment.

Autre avantage, il se limite à quelques tâches (l’ouverture de la session, l’affichage des fenêtres et le menu), ce qui permet de choisir les outils qu’on veut utiliser avec (le panel, le dock, le gestionnaire de bureau, le menu dynamique etc.) De plus, quelques outils graphiques minimalistes ont été créés qui permettent simplement d’éditer les fichiers de configuraton de manière plus conviviale : obconf, obmenu…

Bref, Openbox a les qualités de ses défauts et Enlightenment doit encore progresser sur le troisième point pour devenir pleinement ce qu’il promet d’être : un système beau, léger et fonctionnel.

GNOME-shell ou les occasions gâchées

jdn06 — Thu, 02 Jun 2011 10:51:00 +0200

Le sujet commence à être vraiment rebattu, mais j’ai préféré prendre le temps de la réflexion plutôt que de hurler mon indignation à chaud.

Pour moi, le passage à GNOME-shell n’a pas été un choix. J’avais testé sur mon netbook un live-cd d’une alpha de Fedora 15 et j’avais trouvé l’engin élégant mais étais resté perplexe devant ses fonctions. À l’époque, on répondait sur les forums aux utilisateurs inquiets, que tout n’était pas encore finalisé.

Puis un vent de panique a commencé à souffler sur les archlinuxiens en avril avec l’arrivée de GNOME-shell dans testing. Tout le monde commençait à réaliser que la logique de la rolling-release était impitoyable et qu’à moins de bricoler, il faudrait assez vite abandonner GNOME2. Début mai, GNOME2 quitte Archlinux ; après quelques jours d’hésitation, je franchis le pas. Et là, la catastrophe. Ayant lu de virulentes critiques d’utilisateurs très conservateurs, je m’étais promis de l’essayer au moins 15 jours pour lui donner vraiment sa chance. J’aurai tenu une journée, mais j’ai une circonstance atténuante : l’affichage bogue méchamment ; au-delà de 7 ou 8 fenêtres ouvertes, les suivantes apparaissent entièrement noires, à moins de les réduire fortement. Bug dans Xorg ? Insuffisance de ma carte graphique ? Problème de pilote ? Toujours est-il que ça rend l’interface inutilisable pour moi. En revanche, je trouve les fenêtres gtk3 très élégantes, mais je peux en profiter sous openbox sans les inconvénients décrits.

Ne nous dérobons pas cependant. Que penser de GNOME-shell ?

D’un côté l’interface est vraiment innovante, belle et efficace.

D’un autre côté elle souffre de deux défauts pour moi rédhibitoires que sont l’absence de personnalisation possible et l’impossibilité d’utiliser du matériel un tout petit peu ancien. Comme ces deux points sont pour moi indissociables de mon goût pour les distributions Linux, j’ai du mal à considérer que ça ne soit qu’une contrepartie aux avancées graphiques du projet. Après tout enlightenment, openbox ou xfce parviennent aussi à des résultats esthétiquement aboutis sans sacrifier la légèreté. Mais il est vrai qu’avec GNOME-shell, on a l’impression d’entrer dans un autre monde qui ringardise un peu ceux que je viens de nommer.

En même temps, au-delà même des limites techniques évoquées, je reste sceptique sur l’aspect pratique dans le cas de mon desktop. Essayer de dépasser le « J’aime pas » oblige au fond à s’interroger de manière plus générale sur ce qui me plaît et déplaît dans les différentes interfaces graphiques que j’ai pu utiliser. Je peux partir par exemple de ma stupeur lorsque j’entends dire que l’interface graphique de Windows 7 est idéalement conçue ou que KDE est de loin meilleur que GNOME2. Je ne veux pas nourrir quelque troll que ce soit mais expliquer pourquoi j’aimais GNOME2 et détestais Windows XP, par exemple. En gros, je m’aperçois que je ne supporte pas de passer par de nombreux sous-menus pour arriver à lancer ce que je veux. D’autant qu’une erreur d’embranchement oblige souvent à recommencer du début. Ce que j’aime en revanche, c’est avoir le lanceur directement accessible. Sous GNOME2, j’avais donc chargé mon panneau du haut d’un très grand nombre de lanceurs, ce qui n’est plus possible sous GNOME3. J’aimais aussi les trois menus déroulants qui économisaient un niveau (celui qui permet de choisir entre Applications, Raccourcis et Préférences du système), lorsqu’il fallait malgré tout utiliser les menus. Windows ou KDE, en plaçant tout (menu, lanceurs, barre de tâches, zone de notification) sur un seul panneau et à partir d’un seul bouton menu, me paraissaient étouffants. Ces interfaces me semblaient faites pour fonctionner sur les 15 pouces d’autrefois, afin de laisser de la place aux fenêtres ouvertes. Aujourd’hui, ça n’a plus de sens ; autant profiter de la place que nous laissent nos écrans.

À part en utilisant l’outil de recherche où taper le nom de l’appli à lancer, très pratique et bien conçu, GNOME-shell oblige à de nombreuses manipulations à la souris qui me semblent assez absurdes. Mais le paradoxe est qu’il apparaît en revanche tout à fait idéal dans le cas d’une utilisation tactile : mouvements plus que clics, grosses icônes s’étalant sur tout le bureau plutôt que petits menus et sous-menus. Malheureusement, à ma connaissance, aucun projet allant en ce sens n’est actuellement développé. L’outil sera certainement très bon, mais il se trouve pour moi utilisé à contre-emploi. Peut-être peut-on voir dans ce choix des développeurs l’influence d’une idée à mon avis pernicieuse, assez dans l’air du temps, qui voudrait unifier les interfaces graphiques de toute la nébuleuse d’appareils, la plupart mobiles, qui tendent à compléter voire remplacer la tour de bureau. Il est certain que la stratégie longtemps suivie par Microsoft qui voulait mettre son bouton démarrer et ses menus sur tous les appareils mobiles était assez absurde ; le client s’y retrouvait, mais ne s’y plaisait pas. A contrario, je ne suis pas sûr que vouloir imposer à ce stade une interface graphique de tablette pour des postes destinés à la bureautique soit beaucoup plus pertinent.

Oracle joue perdant-perdant

jdn06 — Fri, 22 Apr 2011 14:39:00 +0200

On pourrait se réjouir de la victoire des développeurs partis développer librement LibreOffice sur le géant Oracle et sa vision très autoritaire du développement d’OpenOffice. Ce serait à mon avis faire fausse route. Je crois qu’on ne peut ajourd’hui que regretter l’énorme gâchis qu’ont occasionné les événements de ces derniers mois :

Au moment où les développeurs prennent leur indépendance, ils lancent un appel à Oracle pour qu’il libère le nom d’OpenOffice et laisse la communauté s’approprier le développement du programme. Oracle refuse et somme les développeurs de choisir leur camp : c’est le fork.
Oracle lance ensuite une série de projets (pour quel coût ?!) pour montrer son intérêt pour OpenOffice : changement de nom de la version commerciale, développement d’une offre dans les nuages, lancement de mises à jour pour ne pas donner l’impression que LibreOffice avance plus vite etc.
Aujourd’hui, plutôt que d’annoncer qu’Oracle accepte de céder le nom afin de confier le projet à la communauté et de permettre ainsi une éventuelle fusion des deux projets concurrents, ce qui lui donnerait (mieux vaut tard que jamais) le rôle de bon perdant, Oracle communique de manière particulièrement vague et l’avenir reste pour l’instant très incertain.

Si les deux projets demeurent séparés et que le développement d’OpenOffice cesse progressivement, alors tout cet épisode aura été une catastrophe. En effet, si je soulignais il y a quelques mois l’inocuité du fork pour les utilisateurs lambda sous Windows, c’était au nom de la continuité des mises à jour gratuites par Oracle. Je doutais fort en revanche que ces utilisateurs passent d’eux-mêmes à la version LibreOffice (d’autant que ceux qui auraient essayé, dans mon collège, se seraient heurtés à un vilain bug plutôt décourageant), surtout si les fonctionnalités ne permettent pas clairement de les distinguer. Je crains donc que l’arrêt du développement d’OpenOffice, s’il devait se produire, réduise simplement le nombre d’utilisateurs de la suite, hors Linux et autres OS libres.

L’image d’Oracle n’en sortirait pas grandie, mais celle de la suite bureautique libre de référence non plus.

Éloge de Crunchbang Statler

jdn06 — Mon, 04 Apr 2011 20:04:00 +0200

Xubuntu 9.10 tourne sur le vieil ordinateur récupéré chez mon père depuis sa sortie, remplaçant le 8.10 tout d’abord installée. Comme je l’ai expliqué, cette Xubuntu 8.10 était la première distribution Linux que j’ai maniée. Après quelque temps sous Ubuntu sur mes autres postes, l’idée de changer de distribution tous les 6 mois m’apparut comme un vrai handicap ; d’où ma découverte d’Archlinux, non réinstallée sur mon poste principal depuis janvier 2010 et parfaitement à jour.

Reste qu’utiliser Archlinux suppose de procéder à de fréquentes mises à jour, ce qui ne peut convenir dans le cas d’une machine reliée à internet de manière épisodique. Ce bon vieux Pentium 733 était donc resté sous Xubuntu jusqu’à décembre dernier. Mais je savais qu’il faudrait installer autre chose d’ici avril, date de fin de support des màj, si possible quelque chose d’encore plus léger et réactif, même si la barrette de 512 Mo récupérée entre temps avait bien amélioré les performances.

Ayant choisi pour sa légèreté en utilisation mémoire archbang en octobre pour me construire une machine virtuelle à utiliser dans les différentes salles où je fais cours toute la semaine (sur des PC avec 1 Go de mémoire tournant avec XP ; ce qui laisse environ 300Mo pour la machine virtuelle), ayant installé en novembre dernier une archlinux + openbox à la main sur le vieux portable d’un collègue dont le Windows venait de rendre l’âme, je me sentais dans une phase très openboxophile. L’an dernier, mon intérêt allait plutôt à Enlightenment, que je ne renie pas aujourd’hui, mais qui me paraît moins souple à configurer (et beaucoup moins stable).

Je souhaite donc mettre en place une distribution très stable, utilisable plusieurs années sans être réinstallée, nécessitant peu de mises à jour et utilisant openbox. Linux Mint Isadora existe en version fluxbox (pas trop éloignée d’openbox, donc) et Lubuntu 10.04 utilisant lxde utilise donc openbox ; ces deux distributions sont fondées sur Ubuntu 10.04 LTS, ce qui assure encore deux ans de tranquillité. Mais il y a mieux à faire à mon avis : Crunchbang Linux Statler, la dernière version de Crunchbang, propose une openbox pré-configurée très bien conçue fondée sur Debian Squeeze. Very Very Long Term Support, donc.

L’installation se fait très simplement après vérification de la bonne reconnaissance du matériel grâce au livecd. La traduction en français n’est pas entièrement automatique, mais tout cela demande tout de même assez peu de travail. Mais surtout la machine devient d’une réactivité et d’une fluidité impressionnantes, vu son âge honorable. La stabilité est au rendez-vous, alors que pourtant mon installation s’est faite sur une période où Squeeze n’était pas encore entièrement stabilisée. Il ne faut donc pas prendre trop au pied de la lettre la phrase de présentation de #! : "As always with CrunchBang, this release is not recommended for anyone who requires a stable system. Anyone who uses CrunchBang should be comfortable with occasional or even frequent breakage." Le développeur principal et la communauté semblent avoir beaucoup d’humour. Pour ceux qui maîtrisent mal l’anglais, il semble que cet avertissement, lié au nom même de Crunchbang (crac-boum) soit en quelque sorte un examen d’entrée, un moyen d’éloigner les fâcheux.

Visuellement, je trouve le dépouillement du thème par défaut du plus bel effet. Mais des goûts et des couleurs… Ce qui n’est pas subjectif, en tout cas, c’est la manière dont l’ordinateur encaisse maintenant les sollicitations lourdes en multitâche (genre surfer en compressant et en écoutant de la musique en FLAC)…

Comment vieillir prématurément : FreeBSD, de 8.1 à 8.2

jdn06 — Sun, 06 Mar 2011 17:28:00 +0100

L’ouvrage classique de Michael W. Lucas sur FreeBSD le dit bien : « Toute mise à jour d’un système d’exploitation peut accélérer la pousse de vos cheveux blancs. » (FreeBSD 7.0 chez Pearson, p.387) Il faut cependant le vivre pour le comprendre.

Hier soir, de retour à la maison, je décidai de faire une pause dans la correction des montagnes de copies que je dois avoir terminé de corriger demain. Pause geek donc, avec la mise à jour vers Wordpress 3.1. Sauvegardes et installation en moins de cinq minutes ; impeccable.

Comme une pause de cinq minutes est un peu trop courte à mon goût, je prends une décision de bleu, une vraie : passer dans la foulée un serveur FreeBSD de 8.1 à 8.2. C’est vrai, quoi : pourquoi rester sur une vieille branche (même si les màj de sécurité sont assurées pour un bon moment) alors qu’une nouvelle branche toute belle, toute neuve et stable est apparue ?

Après une brève lecture du guide de la nouvelle release et de quelques articles sur les màj de FreeBSD, je lance une magnifique séquence :

freebsd-update upgrade -r 8.2-RELEASE
freebsd-update install
reboot
freebsd-update install

Le changement de noyau ne pose pas de problème, mais le programme de màj me demande de fusionner à la main dans vi tous les fichiers de /etc : ça fait un paquet ! Les instructions annonçaient effectivement pudiquement : « During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. » Le plus ridicule (je pèse mes mots) dans l’histoire, c’est que pour 99% des fichiers, les seules différences concernent le commentaire en en-tête :

# nsswitch.conf(5) - name service switch configuration file

<<<<<< current version

# \$FreeBSD\$

=======

# \$FreeBSD: src/etc/nsswitch.conf,v 1.1.10.1.6.1 2010/12/21 17:09:25 kensmith Exp \$

>>>>>> 8.2-RELEASE

#

Un temps fou perdu pour des tâches sans aucun impact sur le fonctionnement de la machine. Je suis assez agacé, je l’avoue. J’envoie donc paître l’ordinateur à grands coups de :q dans chaque fichier ouvert par vi, ayant vérifié que les fichiers restaient ainsi intacts.

Après une bonne vingtaine de minutes de labeur particulièrement répétitif et absurde, l’ordinateur reprend chaque fichier et me demande :

Does this look reasonable (y/n)?

J’appuie donc frénétiquement une centaine de fois sur la touche « y », manière bourrin, puis je m’aperçois, avec l’arrêt brutal de la séquence de mise à jour, que je viens de faire une grosse bêtise. Au lieu de garder inchangés mes fichiers de configuration, ils les a tous modifiés avec une syntaxe illisible puisqu’il a laissé tous les magnifiques caractères qui soulignent les différences :

<<<<<<< current version

=======

>>>>>>> 8.2-RELEASE

Résultat : tout mon /etc est devenu inutilisable tel quel. Heureusement, j’en avais fait une sauvegarde auparavant sur mon poste de travail, avec scp.

Un peu secoué par la catastrophe en cours, je me lance donc dans le rétablissement du répertoire /etc initial. Pas facile car le ssh ne fonctionne plus et le montage de clés USB (que je ne maîtrise pas bien sous FreeBSD) refuse toute partition en ext2 ou xfs (mon poste de travail est sous Linux) et n’accepte que fat32, ce qui fait perdre les droits des fichiers /etc : inacceptable. Je m’en sors avec un tar des fichiers, copié sur la clé en fat32. Mais je commets deux erreurs :

Comme ssh est configuré pour ne pas pouvoir se connecter avec root, j’ai effectué le scp avec un nom d’utilisateur. Les fichiers qui ne peuvent être lus que par root sont donc absents de ma sauvegarde (cela je l’ai évidemment réalisé après avoir tout modifié et redémarré, devant l’absence de certains fichiers importants… trop tard…)
L’autre erreur est beaucoup plus stupide et triviale. Stressé comme je commence à l’être à l’idée qu’il risque de falloir réinstaller le serveur et m’en passer plusieurs jours, je redémarre sans avoir rétabli les propriétaires (root:wheel) des fichiers de /etc.

Le redémarrage qui suit est donc bourré d’erreurs et le login ne fonctionne plus : tous les authentifications d’utilisateurs ont disparu, y compris celle de root.

Là, évidemment, difficile de ne pas blêmir. Qu’à cela ne tienne, il me reste le mode single user. Je redémarre dans ce mode, exécute un mount -a pour disposer de toutes les commandes, puis réinstalle /etc en prenant soin de rétablir les propriétaires légitimes : root:wheel. Après redémarrage, cela ne règle pas tout : je n’ai toujours plus d’utilisateurs. Redémarrage en mode single user mais la commande passwd root se termine par une erreur.

Il faut récupérer un fichier master.passwd, lancer une commande :

pwd\_mkdb -p /etc/master.passwd

Puis passwd root fonctionne, mais pour les utilisateurs, il faut les recréer, après avoir déplacé leur home, puis recopier le contenu dans le nouvel home créé par la création de l’utilisateur.

Le système est sauvé. Restent les services Apache et MySQL. Plus rien ne marche !

Après bien des questionnements, une recompilation des deux (l’utilisateur-système mysql avait disparu de /etc/passwd après la réinitialisation des comptes utilisateurs), je m’aperçois qu’en fait chacun essaie de démarrer deux fois : une première fois depuis /etc/rc.d/ et une seconde fois (comme cela doit être) depuis /usr/local/etc/rc.d/. Le second démarrage échoue puisque le service est déjà lancé (mais avec de mauvais paramètres puisqu’il ne va pas les chercher dans /usr/local/etc/ mais dans /etc/)

Je supprime donc les lanceurs dans /etc/rc.d/ et tout rentre dans l’ordre.

Ma pause geek aura duré cinq heures au lieu d’une demi-heure… J’en sors plus expérimenté, certes, mais assez peu reposé.

En conclusion :

Ne jamais utiliser freebsd-update upgrade. Ça sonne comme du Debian, mais ça n’est pas du Debian. Il existe plusieurs autres méthodes de màj ; je ne compte cependant pas les tester de sitôt.
Répéter la màj sur une machine virtuelle avant de s’attaquer au serveur : ça prend un peu de temps, mais je suis sûr qu’on en gagne beaucoup plus qu’on en perd.
Ne pas mettre à jour un serveur sans nécessité.
Ne pas mettre à jour un FreeBSD sans avoir plusieurs heures devant soi. Je pense cependant que cette remarque est à peu près vraie pour tous les systèmes. C’est là qu’on apprécie vraiment les rolling release : les petits problèmes sont plus fréquents, mais ils s’étalent dans le temps.
Un point positif tout de même : le système est costaud, puisqu’on parvient à le rétablir, même quand il manque un gros morceau (l’authentification des utilisateurs et plusieurs autres services)
Je suis un peu moins « bleu » et un peu plus « blanc » (de cheveux)

Présentation libre

jdn06 — Tue, 01 Mar 2011 23:07:00 +0100

Je profitais des vacances pour regarder quelques vidéos de conférences récentes de Benjamin Bayart. Elles m’ont donné envie d’approfondir des points que je connaissais peu (les DNS, le fonctionnement des MTA lors du cheminement des courriels…) Cependant, ma curiosité était aussi aiguisée par des choses plus futiles. Quel logiciel utilisait-il pour fabriquer ses éternels slides, plus ou moins visibles selon les conférences ?

Eh bien, je crois avoir trouvé ! Le blog de Bertrand Masson m’a fourni la réponse, dans son dernier article présentant la classe LaTeX Beamer : Benj utilise LaTeX !

Plaisanterie mise à part, le tutoriel de Bertrand Masson est, comme toujours, excellent et je regrette presque de n’avoir pas souvent de présentations à faire, car j’ai très envie de m’initier à cet usage de LaTeX. Certains thèmes sont très beaux et l’ensemble dégage une impression de simplicité et d’efficacité. Impression que je n’ai jamais ressentie en côtoyant Impress ou PowerPoint…

Quand EDF aide les auto-hébergés

jdn06 — Mon, 28 Feb 2011 18:46:00 +0100

Ayant quitté pour une douzaine de jours, mon domicile et son serveur, je me trouvais, depuis presque une semaine dans une situation agaçante. J’avais mis sur mon serveur personnel depuis quelque temps la version finale du montage d’un film tourné avec des élèves l’an dernier, pour ceux qui ont quitté le collège. Problème : ma connexion saute toujours après environ 200 Mo d’upload, sans que les solutions évoquées sur les forums d’Orange ou les réponses du service technique n’y changent rien. Une seule solution jusque-là (à part quitter Orange), redémarrer le modem ; ce qui suppose d’être chez soi.

Mardi dernier, donc, une élève choisit la période des vacances pour se lancer dans le téléchargement et m’envoie un courriel pour me prévenir qu’il s’est bloqué à 85%. Problème habituel, mais qui, du fait de l’auto-hébergement engendre une nouvelle série de difficultés : plus de blog ni de services disponibles depuis mon serveur. Bon, comme pour l’instant le blog n’a pas un grand nombre de lecteurs, je suis à peu près le seul à le remarquer, mais ça m’ennuie !

Je patiente quelques jours en espérant que la connexion va finir par se relancer. Rien à faire. Alors que les boutiques Orange de mon séjour de vacances me renvoyaient à la hotline (hors de question depuis un téléphone portable), je commençais à désespérer quand EDF entreprit de résoudre mon problème. Si mes voisins n’avaient pas les clés pour entrer redémarrer le modem, EDF a les moyens de le faire sans entrer. Cela s’appelle une micro-coupure et c’est très à la mode dans les campagnes du Sud de la France. Bon évidemment, un serveur secondaire, qui n’a pas d’onduleur sur batterie, a cessé toute activité depuis. Avec un peu de chance, il obéira à son bios et se relancera à minuit, comme il est programmé pour le faire.

Ma première galère d’auto-hébergé se termine donc plutôt bien, mais il va falloir réfléchir à des solutions plus souples que d’utiliser EDF pour redémarrer mon modem…

Les premiers seront les derniers

jdn06 — Wed, 16 Feb 2011 16:35:00 +0100

Comment ne pas manifester incrédulité et ironie face à l’annonce de l’alliance entre Nokia et Microsoft ? Le moins qu’on puisse dire est que s’appuyer sur le successeur de Windows Mobile pour échapper au naufrage est un choix étrange. Malgré toutes les publicités qui nous ont inondés à la sortie de WP7, je n’ai pas le sentiment qu’il fasse vendre beaucoup de smartphones et n’en ai pas encore vus autour de moi. Si les patrons de Nokia faisaient tout pour perdre le prestige jusque-là associé au fabricant finlandais, ils ne s’y prendraient pas mieux.

Comme tout bon libriste j’attendais avec une certaine impatience (et une pointe d’agacement même devant la lenteur du processus) la sortie d’un téléphone sous MeeGo. J’étais un peu agacé que l’alliance entre Intel et Nokia ait surtout semblé dans un premier temps retarder l’apparition d’un système libre. Arrivé trop tard pour Maemo ou Openmoko, projets qui semblent n’avoir connu que des succès mitigés, je préférais attendre plutôt que de me résoudre à googliser à coups d’Android. J’aime être le maître chez moi ; l’idée d’acheter un objet sans posséder les droits pour l’administrer à ma guise ne me plaisait pas du tout, même si la manœuvre pour s’en rendre maître est bien documentée.

Le projet MeeGo lui-même dépassant la seule question du smartphone, j’avais testé la version netbook 1.1 dans une machine virtuelle. Si l’interface a l’air assez pratique et pas trop laide, la lenteur d’exécution était franchement rédhibitoire (clutter ?), au point que je n’ai même pas tenté d’installation en dur.

Quoi qu’en dise Nokia, l’annonce faite il y a quelques jours met un terme au suspense : MeeGo ne sera pas le concurrent libre d’Android. Si Nokia affirme son intention de produire un mobile sous MeeGo avant la fin de l’année 2011 et d’utiliser cette plateforme comme base de test sur le long terme dans le développement de ses prochains appareils mobiles, avant le passage par Symbian puis WP7, on voit bien que le rôle dévolu à MeeGo est très marginal (ainsi probablement que les investissements dans cette technologie).

Un dernier espoir avant de faire une croix sur Nokia, l’initiative d’un groupe d’actionnaires en colère a rapidement tourné à la déroute, laissant la place à un site satirique et à de nombreuses contre-propositions humoristiques. Quelques propositions de bon sens émergent ici ou là, mais je doute qu’elles soient entendues. Au passage, il est intéressant de noter que l’argumentaire du plan B (qui a disparu d’internet entre le moment où j’ai commencé à rédiger ce billet et le moment où je l’ai mis en ligne) laissait entendre que le partenariat avec Intel ralentissait l’avancée du projet MeeGo.

LibreOffice et OpenOffice

jdn06 — Sun, 06 Feb 2011 16:20:00 +0100

Quelques mots concernant le grand sujet du moment, après la sortie des deux premières versions stables distinctes : LibreOffice vs OpenOffice, ou plus exactement que penser de ce fork ?

Je n’aborderai pas la question du point de vue des développeurs ou du modèle économique, car le sujet me dépasse largement. Le point de vue développé ici sera celui de l’enseignant qui essaie de promouvoir l’usage de la suite de bureautique libre dans le cadre de sa vie professionnelle.

Partons de la manière dont OpenOffice est perçu avant le fork.

Pour les collègues, les principales résistances à son utilisation viennent :

des documents qu’ils ont déjà produits en .doc avec la suite de Microsoft et dont il faut refaire la mise en page. Ceci dit, Microsoft est notre allié sur ce point, car la rétro-compatibilité n’a jamais été leur fort. Il ne suffit donc pas de payer une licence pour n’avoir aucun problème de mise en page avec ses vieux documents. Si LibreOffice parvient à améliorer le rendu des documents produits sous Office, comme il s’y est engagé, les interventions nécessaires sur la mise en page pourraient devenir à peu près équivalentes entre les deux suites. Reste à le faire comprendre à des collègues qui restent rassurés par la continuité de la marque Microsoft.
de la lenteur et de la lourdeur du démarrage de la suite. Il est vrai que sous Windows, c’est assez spectaculaire alors que le problème n’existe presque pas sous Linux. Ce n’est pas entièrement un problème de pré-chargement du programme, car je ne pré-charge pas non plus sous Linux et qu’activer le pré-chargement sous Windows améliore la vitesse sans la rendre équivalente à ce qu’elle est sous Linux. Ce n’est pas non plus uniquement lié à la qualité de l’OS (Linux, je t’aime !!!), car la différence entre Windows et Linux est nettement moins sensible avec Firefox, par exemple. La Document Foundation annonce des améliorations ; nous verrons bien.
du manque de fonctionnalités de la suite libre. Là, il faut distinguer entre les collègues qui n’y connaissent pas grand-chose et concluent simplement qu’une fonctionnalité n’est pas présente lorsqu’elle n’est pas à l’endroit où ils la trouvent sur Office, et ceux, plus sérieux, qui regrettent les limitations de Calc ou d’Impress. Il faut cependant dire que la plupart n’utilisent que Writer et que cet argument ne me semble pas valable concernant le traitement de texte.

Le nom d’OpenOffice est bien connu de la plupart, mais souvent associé à de lointains essais sur des versions 1 ou 2 qui ne leur ont pas laissé un bon souvenir. La plupart ne le voit que comme un logiciel gratuit, bas de gamme, pour les pauvres ! La notion de logiciel libre n’est que rarement comprise. Le changement de nom risque donc de ne pas changer grand-chose, ni en bien ni en mal.

Le cas des élèves de collège est assez différent. Ils ne connaissent généralement pas OpenOffice et ont très souvent à la maison une version d’Office qui date de l’acquisition de l’ordinateur. Certains confondent Word et Wordpad ; d’autres confondent Office et Works. Les questions de format et de conservation de la mise en page ne se sont jamais clairement posées pour eux. S’ils constatent que ça ne marche pas toujours, ils ne savent pas pourquoi.

Lorsqu’on leur demande d’utiliser OpenOffice et le format .odt pour rendre un travail et qu’on leur explique que télécharger le logiciel en ligne est légal et gratuit (ce qui pour eux n’est pas intuitif : téléchargement gratuit = piratage, forcément), ils sont nombreux à revenir le lendemain en me disant : « Votre logiciel, il est payant ; je ne l’ai pas téléchargé. » Quand je m’informe un peu de ce qu’ils ont fait, je m’aperçois qu’ils utilisent tous Google comme moteur de recherche, prennent le premier lien sans se poser de questions, alors qu’il s’agit d’un lien commercial, et se voient proposer par des sociétés qui escroquent l’internaute peu doué un téléchargement d’OpenOffice contre un SMS !

Pour leur redonner envie d’essayer, il faut alors leur montrer comment choisir le site sur lequel télécharger et le faire devant eux sans payer par SMS !

Dans ces conditions, le passage à LibreOffice est pour quelque temps une aubaine puisque je ne crois pas que ce type d’arnaque existe déjà avec ce nouveau nom…

Pour nous résumer, je crois que penser, comme on peut le lire ici ou là , que l’affaire LibreOffice risque de décrédibiliser le logiciel libre dans les milieux non libristes est assez erroné. Cela ne peut avoir cet effet que chez les fans de Microsoft qui ont une opinion sur le logiciel libre. La plupart des utilisateurs ignorent ce qu’est le logiciel libre et ont une connaissance assez limitée d’OpenOffice. Le changement en cours ne saurait donc les perturber beaucoup. S’ils sont utilisateurs réguliers et ne s’intéressent pas au libre, ils poursuivront les mises à jour d’Oracle sans même se poser de questions tant que la suite reste gratuite.

Il est cependant un domaine dans lequel j’ignore l’impact de ce fork : il s’agit des entreprises travaillant avec OpenOffice. Je crains cependant qu’elles ne soient pas très nombreuses. La liste donnée sur le site d’OpenOffice peut paraître fournie ; en même temps, imagine-t-on Microsoft composer une telle liste ?

De l’achat de musique en ligne pour les linuxiens

jdn06 — Sun, 30 Jan 2011 18:58:00 +0100

Le SACD ou Super Audio CD n’a malheureusement pas connu le succès. Bon, évidemment, la technologie était tout ce qu’il y a de plus fermée et propriétaire, mais le CD aussi à ses débuts. Le succès aurait certainement fait évoluer les choses. En termes de qualité sonore, la chose était superbe. On trouve encore de courageux petits éditeurs pour poursuivre dans cette voie, mais les majors ont renoncé depuis longtemps
Comme il est absurde de se contenter du fameux "son CD" alors que la technique actuelle permet bien mieux, certains sites de vente de musique en ligne permettent l’achat, sous l’appellation Studio Master, de fichiers musicaux en PCM 24 bits / 88.2 ou 96 KHz, soit une qualité presque équivalente au DSD du SACD.
C’est le cas notamment de :

Gimell Records, le label des Tallis Scholars
Pristine Classical, spécialiste de la restauration des archives tombées dans le domaine public
Hdtracks, un site plus éclectique
Qobuz, site français

Mon article est motivé par ce dernier vendeur. Lors de mon premier achat, il y a un an, j’avais rencontré quelques difficultés. Le téléchargement sans leur application de téléchargement maison destinée à Windows était un peu laborieux, mais surtout les formats disponibles alors n’étaient pas très satisfaisants pour un Linuxien :

WMA Lossless
ALAC

Il m’avait fallu passer sous mon Windows virtuel pour en faire d’honnêtes FLAC. Comme j’avais contacté leur SAV pour quelques problèmes de téléchargement vite résolus, j’en avais profité pour leur en faire la remarque.
Les mois ont passé et lors de mon dernier achat, hier, j’ai pu apprécier le changement. Non seulement le FLAC est maintenant disponible, mais le OGG aussi pour faire pendant au MP3.
Et comme la célèbre Mme Michu pourrait se perdre dans cette abondance de formats, le vendeur a eu la bonne idée de joindre un sélecteur OS + programme (avec préselection selon en-têtes du navigateur) qui permet d’orienter l’acheteur vers le bon format. Les saisies d’écran seront plus parlantes :

Voilà qui tranche avec la pratique de beaucoup ; nous ne sommes pas condamnés à pirater ou à nous soumettre aux choix de la Pomme qui se paie notre poire.

Quel OS pour un serveur auto-hébergé ?

jdn06 — Thu, 27 Jan 2011 18:34:00 +0100

Choisir une distribution pour un serveur auto-hébergé est un sujet très rebattu sur le net. La conclusion la plus fréquente à ce sujet est de dire qu’il faut opter pour la distribution qu’on connaît le mieux, celle avec laquelle on se sent à l’aise et qu’on maîtrise.
Soit. La chose est irréfutable.
Néanmoins, lorsque la distribution qu’on connaît le mieux est Archlinux, comme c’est mon cas (Voilà une déclaration qui me classera dans les prétentieux pour Cyrille Borne…), alors il faut y réfléchir à deux fois. En effet, s’il me semble intéressant qu’un serveur soit à jour, cela n’a d’intérêt qu’en termes de sécurité et non pour profiter de logiciels récents. De plus, l’impératif me semble, pour un serveur, qu’il plante le moins possible et demande le moins d’interventions possibles après installation. Aussi intelligemment conçue que soit une rolling release, elle restera toujours moins stable qu’une distribution stabilisée pour plusieurs années.
Exit donc, de mon point de vue, Archlinux.
Comme j’hésitais entre Debian et FreeBSD et que j’avais deux serveurs à installer, je me suis amusé à en installer un de chaque.
Debian s’installe et s’entretient avec une facilité déconcertante. Installer Apache, PHP, MySQL et phpMyAdmin dessus se fait à petits coups de

sudo aptitude install apache2

et le tour est joué. D’autant qu’une boîte de dialogue apparaît en console pour configurer facilement les programmes qui ont besoin de l’être (par exemple créer le compte root de mysql). Les modifications à faire à la main dans les fichiers de configuration sont donc très limitées et l’ensemble marche « out of the box ».
FreeBSD s’apprivoise de manière un peu plus difficile. Je l’avais déjà installé plusieurs fois sur des postes de travail, mais jamais sur un serveur. L’installation est presque aussi facile que celle de Debian, mais les choses se gâtent lorsqu’il s’agit de mettre en place Apache, PHP et MySQL.
Je me suis d’abord lancé sans trop me poser de questions à coups de

pkg_add -r apache22

Puis j’ai essayé de configurer à la main les différents services et ai ajouté leur lancement dans /etc/rc.conf Mais phpMyAdmin résistait avec des erreurs multiples au lancement. Renseignements pris sur le web, il manquait plusieurs modules à mon PHP. J’ajoute alors le paquet php5-extensions, mais rien n’y fait.
Je décide alors de me tourner vers les ports.

portsnap fetch install cd /usr/ports/lang/php5-extensions make config

où je sélectionne entre autres BZ2 (utile pour compresser une base de données), MCRYPT (pour crypter les mots de passe stockés dans la base), MYSQL, MYSQLI, OPENSSL, PDO, PDO_SQLITE, SESSION (celui-là semblait manquer cruellement au lancement de phpMyAdmin), TOKENIZER, XSL et ZIP (bien utile pour les mises à niveau d’un Wordpress, par exemple).

make install clean

Je relance le tout et patatras : marche toujours pas.
Je vous passe les lectures intenses et les bidouillages divers. Finalement, je désinstalle tous les paquets concernés et recompile le tout par les ports en surveillant de près le « make config ».
Et là, tout de même, ça marche impeccablement.

Pour conclure, vous me direz que Debian, c’est donc mieux car plus facile et vous aurez tort. Non que je veuille jouer le puriste de l’UNIX et autres postures ridicules. Je dirais plutôt que :

Debian, c’est mieux pour faire des choses « simples », comme installer un blog WordPress ou même une simple base de données gérée par phpMyAdmin.

En revanche, des choses plus complexes comme installer un service dans une prison (jail) ou recompiler un logiciel pour optimiser et sécuriser son fonctionnement en désactivant les modules non utilisés, voilà des opérations parfaitement documentées et faciles à réaliser sur FreeBSD en comparaison avec ce qui existe à ma connaissance pour faire de même sur Debian.
Dernier point pour être complet : le serveur ftp inclus par défaut dans FreeBSD, ftpd, qui ne demande qu’à être activé au démarrage, est vraiment très facile à configurer et à utiliser « out of the box ».
Bref, comme souvent, tout dépend des besoins et de l’expérience de chacun !

Remboursement de Windows

jdn06 — Fri, 21 Jan 2011 18:19:00 +0100

Profitant des soldes, j’ai acheté la semaine dernière un nouveau netbook : un eeePC 1001 PX à 215 €. L’idée était de recycler le précédent en un serveur pour abriter ce blog. Évidemment, la politique d’Asus a changé depuis 2009 : plus de choix possible entre Linux et Windows. Tout juste peut-on (pour peu de temps encore ?) choisir entre XP et Seven. XP donc pour moi, et aussitôt rentré, je décolle l’étiquette de la licence Windows pour me faire rembourser l’OS selon la démarche décrite sur ce site par ce document.

L’opération demande un peu de minutie ; plus que pour la création d’une nouvelle table de partitions (en ligne de commande tout de même car les partitions d’origine ne plaisent pas à Gparted) et l’installation d’une Archlinux 64 bits toute neuve et d’un petit Openbox aux oignons.

La réponse, en recommandé, d’Asus fut particulièrement rapide, mais pour me signaler que mon formulaire n’était pas le bon et me demander une adresse de courriel pour m’envoyer les deux nouveaux formulaires à remplir.

Là où la chose devient piquante, c’est que l’un des deux formulaires, un .docx, affichait une mise en page totalement inutilisable (une lettre par ligne !) sous Libreoffice. Lorsque je m’étonne dans un nouveau courriel qu’on envoie un document impossible à lire sans Windows à un client qui ne veut pas acheter Windows et que je demande une version odt ou pdf du formulaire, on me répond d’abord qu’Asus ne travaille pas avec Openoffice et que je n’ai qu’à trouver une machine équipée de ce qu’il faut pour lire le fichier (sous-entendu pas un Asus pourri avec Linux vendu deux ans avant ?). Finalement trois heures après, Asus travaille avec Openoffice et m’envoie le fichier demandé. Si j’ai pu les aider à découvrir Openoffice, alors tout est bien qui finit bien…

Présentation

jdn06 — Fri, 21 Jan 2011 16:07:00 +0100

Je n’ai pas découvert Linux à ses débuts. Les choses ont commencé un peu par hasard. Ancien utilisateur, dans mon enfance de TRS-80 (ça ne dira rien aux moins de trente ans) puis de Commodore 64 & 128, j’étais passé au DOS puis aux différentes versions de Windows jusqu’à XP dans les années 90. Un jour, j’ai récupéré l’ancien ordinateur de mon père, un Pentium 733, pour l’installer dans un appartement où je ne séjournais qu’occasionnellement. Mais l’idée d’en faire un poste utilisable devint bien vite plus difficile à réaliser que je ne l’imaginais. L’ordinateur tournait – très mal – sous Windows ME. La machine portait quelques virus ; l’OS n’avait jamais été réinstallé depuis plus de 5 ans. Ma première idée – le faire passer à XP – butait sur l’achat de mémoire (256 Mo, c’est vite un peu juste) et sur l’acquisition d’une nouvelle licence XP pour cet ordinateur. Il semblait évident que l’investissement ne serait pas très rentable. Quant à réinstaller Millénium, cela m’amusait assez peu. En cherchant un peu sur internet, je tombai sur plusieurs sites parlant d’ordinosaures (même si le mien n’en était pas encore un) et expliquant qu’y faire tourner un Linux était très confortable. En faisant des recherches sur Linux, je tombai sur Ubuntu, dont le nom et le logo me parurent sympathiques, puis sur Xubuntu qui était présenté comme plus léger.

Je l’installai en second OS sur la machine et son fonctionnement fut effectivement beaucoup plus fluide et agréable, tout en autorisant l’utilisation de logiciels récents. Agréable surprise donc, mais le fonctionnement de l’OS me paraissait vraiment très exotique. Je n’avais lu aucune documentation sur les systèmes de fichiers et les montages de disque de type UNIX. Mon accès à internet était limité à un modem 33600. Bref, j’en vins à trouver tout un tas d’astuces absurdes pour retrouver mes documents sur la partition Windows, et je limitai l’utilisation de l’ordinateur aux quelques fonctions (navigation internet et courrier) qui m’intéressaient vraiment sur cette machine.

L’été 2009, j’achetai sur un coup de tête le premier ordinateur que je vis à moins de 200 € : un eeePC 900 tournant sous Linux. Le dernier portable que j’avais possédé (un 486 monochrome payé plus de 10.000 FF à l’époque) m’avait lâché assez vite et je m’étais promis de ne plus acheter ce genre de machines, chères, fragiles et peu évolutives. Évidemment, les choses étaient ici fort différentes : pas de disque dur mais 16Go de carte flash. Un petit format permettant de l’avoir toujours avec soi au besoin. Bref, pour moi, une révolution.

Mais ce qui fut au moins aussi important se trouvait du côté de l’OS. Asus avait fait le choix de Linux pour offrir des machines moins chères et avait parié sur Xandros pour rallier le grand public à une utilisation simple. Pour moi, Xandros fut essentiel, puisque son manque d’évolution et d’ouverture m’incitèrent presque aussitôt à chercher une distribution digne de ce nom pour le remplacer. Je me mis alors à parcourir les blogs et les forums parlant de distributions Linux et autres UNIX, activité chronophage s’il en est tant le sujet est massivement présent sur internet, mais activité dont je ne me suis pas lassé depuis.

Aujourd’hui, tous mes ordinateurs sont sous Linux (Archlinux et Debian principalement) et autres UNIX (FreeBSD et OpenSolaris, même s’il va bien falloir décider quelque chose à ce sujet) et je m’amuse avec de nombreuses distributions exotiques virtuelles.

Dans ce blog, je parlerai de mon utilisation au quotidien, chez moi et en milieu scolaire, et des questions qui agitent la blogosphère du libre. J’évoquerai aussi les questions liées à l’auto-hébergement, sujet qui paraît particulièrement important ces derniers mois.

À propos

wp-admin — Wed, 19 Jan 2011 00:49:00 +0100

Blog d’un utilisateur de différentes distributions linux et de quelques bsd…