Avant, j'utilisais GNOME 2. Puis il a fallu passer à GNOME 3. Sauf que GNOME 3, shell ou non, ça ne me convient pas. MATE, un fork de GNOME 2 était disponible dans les paquets Debian (mais pas dans l'installeur). J'ai donc installé MATE à côté d'un GNOME 3.

Bien plus tard, j'ai commencé à supprimer GNOME 3 sauf ce qui me plaisait : la calculette GNOME (gnome-calculator) a une interface qui me parle plus que celle de MATE (mate-calculator) en plus d'avoir un historique des opérations effectuées ; garder un nautilus (explorateur de fichiers de GNOME) permet d'avoir un explorateur de fichier de secours quand caja (idem, mais de MATE) se gèle totalement durant une copie sshfs, etc.

À moment donné (je date ça de mon passage à Debian Stretch, mais je n'en suis pas sûr), ça part en live. Quand je saisis mon identifiant et mon mot de passe afin d'ouvrir ma session, si c'est les bons, les champs se grisent, l'affichage se fige (plus de souris) et rien se passe. Pour afficher l'environnement de bureau, je devais attendre un peu que MATE démarre, faire ctrl+alt+f2 puis ctrl+alt+f3 puis ctrl+alt+f2. Revenir sur ctrl+alt+f1, ça fermait brutalement la session et les champs identifiant et mot de passe étaient de nouveau éditables. L'environnement de bureau s'affichait dans ctrl+alt+f2… au lieu de l'habituel ctrl+alt+f7… qui était vide.

C'était pénible, mais vu que je suis le seul utilisateur de l'ordinateur et que je l'éteins jamais (je fais du suspend-to-ram), je m'en fichais. Et puis essaye de décrire ce problème avec des mots-clés pour un moteur de recherche web, toi…

Lors de mon passage à Debian Buster, j'ai voulu virer les derniers bouts de GNOME dont je ne me sers pas. Mais gdm3 (gestionnaire d'affichage de GNOME) dépend d'eux… Allons-y pour installer lightdm comme remplaçant de gdm3. Impossible d'ouvrir une session. J'ai le même problème d'affichage gelé mais mon astuce ctrl+alt+f2 puis ctrl+alt+f3 puis ctrl+alt+f2 ne fonctionne plus.

C'est donc un problème commun à plusieurs gestionnaires d'affichage ou à plusieurs gestionnaires de sessions.

Ne sachant pas trop quoi faire, je crée un compte utilisateur. J'arrive à ouvrir une session avec celui-ci. L'origine de mon problème est donc un fichier de configuration dans mon homedir.

Je regarde viteuf le déroulement de l'ouverture d'une session graphique. L'interface de connexion ne me laisse pas choisir la session à ouvrir (et pour cause, j'ai un seul gestionnaire de session, mate-session). J'ai bien un lien symbolique ~/.xsession vers un fichier ~/.xinitrc. Je le mets de côté avec mv.

Je peux ouvrir une session avec gdm3 sans utiliser une quelconque combine. Je peux également ouvrir une session avec lightdm. \o/

Je ne sais plus ce que contenait le script .xinitrc, mais c'était très probablement des instructions spécifiques à GNOME.

Je suis donc un récent utilisateur de lightdm.

Sur ma machine perso et depuis sa mise en service, le serveur graphique X.Org me crache des tonnes d'erreurs dans ~/.local/share/xorg/Xorg.0.log. Toujours la même : « (EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy ». En permanence, dès que je bouge ma souris. ÉDIT DU 12/10/2020 À 20 H 50 : La procédure ci-dessous permet également de résoudre la coulée permanente d'erreurs « (EE) modeset(0): present flip failed ». FIN DE L'ÉDIT.

Le message d'erreur étant plutôt générique, je ne trouvais pas d'aide sur le web, donc j'avais laissé tomber. Je pensais à un problème de pilote graphique, de fonctionnalités non-supportées par ce dernier, quelque chose comme ça. Ce n'était pas gênant, car une rotation / nettoyage automatique du journal avait lieu, donc il consommait quelques Go à tout casser.

J'ai mis à jour mon système Debian GNU/Linux à la version Buster. Ce problème continue. J'ai un peu craqué : mon modèle d'ordinateur date de 2012-2013, il est équipé d'un GPU Intel greffé sur le CPU. Le GPU le plus simple et compatible au monde, et ça continue de foirer en 2020 ?!

Mon fichier de config' /etc/X11/xorg.conf date de 2014. Peut-être faut-il en générer une version actualisée ? Ouais, je sais : avec l'autoconfiguration Xorg, KMS et compagnie, on n'est plus censé devoir faire ça… sauf que ça a jamais vraiment fonctionné chez moi.

Pour générer un nouveau fichier xorg.conf (adapté de ce tuto) :

• Fermer ses logiciels / fichiers ;
  
  
• Basculer en console tty avec ctrl+alt+F[1-6] et se connecter en root ;
  
  
• Copier la conf' actuelle : cp /etc/X11/xorg.conf ~/xorg.conf.bak ;
  
  
• Stopper le gestionnaire d'affichage (gdm, dans mon cas, même si, depuis, je suis passé à lightdm) : systemctl stop gdm3 ;
  
  
• Générer la conf' : X -configure ;
  
  
• Déplacer la conf' au bon endroit : cp xorg.conf /etc/X11/xorg.conf ;
  
  
• Relancer le gestionnaire d'affichage : systemctl start gdm3.

Hop, plus aucune erreur dans ~/.local/share/xorg/Xorg.0.log depuis plusieurs mois. \o/

Sur mon serveur d'emails, j'utilise OpenDKIM pour signer quelques entêtes de mes emails sortants et pour vérifier la signature des entrants dans un contexte anti-spam (il ne s'agit pas de garantir la confidentialité / l'authenticité / l'intégrité de l'échange). J'ai configuré OpenDKIM pour qu'il vérifie les signatures DNSSEC afin de garantir l'authenticité et l'intégrité des clés publiques DKIM récupérées dans le DNS. Ça sert à rien (déjà que DKIM c'est du vent…), mais bon, ça fait joli.

Depuis bientôt 1 an (juin 2019), j'ai remarqué que la signature des emails entrants n'est plus vérifiée. J'avais constaté l'absence de l'entête « Authentication-Results » dans les emails. J'avais constaté que Postfix consigne ce qui suit pour chaque email reçu : « warning: milter inet:127.0.0.1:10028: can't read SMFIC_EOH reply packet header: Success ». Tant que je pouvais envoyer des emails et en recevoir, je m'en fichais.

Il y a 3 mois, j'ai décidé d'étudier cela attentivement, car, à moment donné, il faut bien se sortir les doigts.

Le message consigné par Postfix est trop générique : c'est le constat d'un milter défectueux, rien de plus.

OpenDKIM consigne rien excepté exited with status 1, restarting à chaque email reçu ou presque. Le lancer à la main (systemctl stop opendkim && opendkim -f -vvv) ne le rend pas plus bavard.

J'ai aucune idée. Dans ces moments-là, je reviens aux bases, j'essaye de me souvenir comment fonctionne précisément le logiciel incriminé, je relis la doc' relative à mon système d'exploitation, etc. La doc' Debian pour OpenDKIM est ici. Et la réponse s'y trouve sous forme d'un gros avertissement :

The Debian unbound package installs a default configuration file at /etc/unbound/unbound.conf. Do not attempt to use this file unchanged with ResolverConfiguration! opendkim will just quietly shut down.

The reason for the incompatibility is that the shipped unbound.conf includes an auto-trust-anchor-file setting, for which opendkim does not have the necessary permissions. Unfortunately, libunbound is rather fragile in this area. Prepare your own unbound.conf for opendkim and test carefully. 

Une fois qu'on a connaissance de ça, une recherche sur le web avec de nouveaux mots-clés permet d'obtenir une confirmation : Question [#293418](./add-tag/293418) : Questions : opendkim package : Ubuntu.

Je n'utilise pas /etc/unbound/unbound.conf, mais, dans ma configuration pour la bibliothèque Unbound, j'utilise bien auto-trust-anchor-file. Ce que je ne comprends pas, c'est que je stocke la clé publique de la racine DNS dans une arborescence dédiée à OpenDKIM : /var/lib/dkim/. C'est aussi là qu'est stockée la clé privée avec laquelle sont signés les emails. Ça devrait donc fonctionner.

Pour une raison qui m'échappe totalement, l'utilisateur OpenDKIM n'était plus propriétaire ni du dossier /var/lib/dkim, ni de la clé publique de la racine DNS. La bibliothèque Unbound exécutée par OpenDKIM (uid:gid identique, donc) ne pouvait donc pas l'actualiser. J'ai corrigé ça de cette manière :

chown opendkim:root /var/lib/dkim
chmod 755 /var/lib/dkim
chown opendkim:opendkim /var/lib/dkim/dnssec.root.key
chmod 664 /var/lib/dkim/dnssec.root.key

On redémarre OpenDKIM (systemctl restart opendkim) et c'est fini.

Quelques remarques :

• Ce principe de fonctionnement est valable pour tout protocole, pas seulement SSH. Ping une adresse du réseau fe80::/10 ? ping6 fe80::1%<nom_interface>. Netcat ? nc -u fe80::1%<nom_interface> 8112 ;
  
  
• Il est préférable d'encadrer une IPv6 globale entre crochets. C'est même obligatoire pour les commandes où l'on précise un numéro de port en l'apposant à l'adresse IP (puisque le séparateur IP/port, « : », intervient également dans la représentation des adresses IPv6) et, d'une manière générale, dans toute commande où l'on appose quelque chose à la suite de l'adresse IP (genre avec rsync ou scp, il faut préciser la destination de la copie… avec « : »… donc, pour faire la différence entre la représentation d'une IPv6 et le séparateur, on utilise les crochets : scp test <identifiant>@[<adresse_IPv6>]:.) ;
  
  
• Une adresse IPv6 fe80::/10 est spécifique à un même réseau niveau 2, à un même segment, à un même réseau local pour faire simple. Comme tous les réseaux niveaux 2 ont le même adressage (ce sera fe80::/10 que tu sois chez toi, au travail, chez des amis, en filaire ou en Wi-Fi ou…) et qu'une machine lambda est connectée à plusieurs réseaux en même temps (filaire, Wi-Fi, 4G, etc.), il faut préciser l'interface réseau qui sera utilisée pour l'émission, car l'algorithme de sélection de l'adresse IP source ne peut pas fonctionner. Une adresse locale au lien (fe80::/10) ne traverse pas un routeur (genre une box Internet), donc elles ne sont pas utilisables entre deux réseaux distincts. Une adresse fe80::/10 est soit tirée au sort (donc elle change avec le temps), soit dérivée à partir de l'adresse MAC de l'interface réseau (auquel cas, l'adresse fe80::/10 d'une interface réseau ne change pas avec le temps) ;
  
  
• Les adresses fe80:/10 sont plutôt destinées à un usage technique interne aux protocoles autour d'IPv6 (routage, résolution MAC/IP, etc.). Je déconseille leur utilisation courante au niveau des applications (surtout si elles sont générées aléatoirement…), quitte à utiliser des adresses IPv6 """"privées""" (fc00::/7) pour adresser le serveur et le client. En faisant ainsi, il n'y a pas lieu de se plaindre que "pas le même comportement gnagna".

DANE OPENPGPKEY, c'est utiliser le DNS, signé avec DNSSEC, pour récupérer une clé publique OpenPGP (pas pour en prouver l'authenticité, attention !). Pour les détails, voir l'article de tonton Bortz.

J'avais déjà tenté d'utiliser DANE OPENPGPKEY quand j'en avais appris l'existence en 2016, mais je n'étais pas parvenu à forger l'enregistrement DNS qui le matérialise. Mais, cette fois-ci, je suis outillé.

Pour créer un tel enregistrement, on va utiliser la suite logicielle hash-slinger (qui permet, également et entre autres, la manipulation des enregistrements DNS SSHFP et des enregistrements DNS DANE TLSA). Installons-le (il n'est pas dans les dépôts Debian GNU/Linux Buster à cause d'une dépendance à python33-m2crypto non-satisfaite) :

$ sudo apt-get install swig
$ sudo pip3 install m2crypto
$ git clone https://github.com/letoams/hash-slinger
$ cd hash-slinger && sudo make install

La clé publique que l'on veut publier doit être présente dans le trousseau GnuPG courant. Voir mon tutoriel complet pour créer / gérer sa paire de clés OpenPGP.

Créer l'enregistrement : openpgpkey --create <adresse_emails_de_l'identité_de_la_clé_OpenPGP>.

Publier l'enregistrement dans la zone DNS concernée.

On vérifie que l'enregistrement est correct :

$ openpgpkey --verify <adresse_emails>
All OPENPGPKEY records matched with content from the local keyring

Pour tester la récupération, soit on tente depuis une autre machine (virtuelle), soit on utilise un compte utilisateur différent sur la même machine ou même un trousseau différent sur le même compte utilisateur. J'ai choisi cette troisième option.

$ mkdir /tmp/testOPK
$ export GNUPGHOME=/tmp/testOPK
$ gpg -k # doit rien retourner puisque trousseau vide
$ gpg --auto-key-locate dane --locate-keys <adresse_emails>

Si la clé OpenPGP a plusieurs identités, seule l'identité qui correspond à l'adresse emails a été publiée et est donc récupérable. Les autres identités doivent être publiées chacune dans leur zone respective et être récupérée séparément.

Les signatures de la clé ne sont pas publiées et ne sont pas récupérables. De toute façon, suite à l'attaque de 2019 des serveurs de clés OpenPGP par surcharge de signatures, les développeurs de GnuPG ont décidé de ne plus récupérer les signatures tierces sur les serveurs de clés. Donc, DANE ou serveur de clés = même résultat.

Bien évidemment, DANE OPENPGPKEY est un moyen supplémentaire de récupérer une clé OpenPGP : serveurs de clés, téléchargement web, pièce jointe d'un email, etc. DANE OPENPGPKEY ne permet pas de garantir qu'il s'agit de la clé du correspondant avec lequel tu veux échanger. En effet, DNSSEC garanti que l'enregistrement DNS n'a pas été altéré durant son transport entre le serveur qui fait autorité sur le domaine du correspondant et le serveur DNS récursif qui effectue la validation. Rien dit qu'un attaquant n'a pas inséré sa clé OpenPGP dans l'enregistrement OPENPGPKEY du correspondant. Rien dit qu'un attaquant actif entre ton serveur DNS récursif et toi n'a pas modifié l'enregistrement DNS. Bref, comme d'habitude, il faut vérifier l'authenticité de la clé récupérée en contactant le correspondant sur un autre canal (de visu, téléphone, etc.) avant de signer la clé et de lui accorder une quelconque confiance.