GuiGui's Show

Je vais faire mon libriste au melon démesuré, mais pour ce dernier point je pense que tu ne couvre pas l'ensemble du problème qui est aussi en grande partie que les "alternatives" libres ne sont pas le même logiciel, et ne s'uitlisent pas pareil. Au final la qualité de l'outil n'a que peu de rapport avec la question, la question est beaucoup que la personne est là pour faire son taf, pas pour prendre en main quelque chose de nouveau.

C'est vrai, mais il y a une limite à ce raisonnement : pour qu'un gus prenne sur lui l'étude d'un autre logiciel (libre ou pas, ce n'est pas mon sujet), il faut que celui-ci soit techniquement ou qualitativement supérieur à la norme. Or, winwin versus nux ou MS Office versus LibreOffice, y'a pas de différence quand t'es une secrétaire. Les deux vont faire chier (si, nux peut faire chier), les deux permettent de saisir le courrier demandé par le boss, sur les fonctions de base, GIMP apporte rien par rapport à Photoshop (et inversement), etc. C'est juste une guéguerre de chapelles (genre en vrai winwin, quand t'as compris la logique, que tu t'es formé, que t'as les bons outils d'administration et les bonnes pratiques, ça juste fonctionne aussi bien que nux, faut arrêter de mentir). Donc quand tu vois l'ordi comme un simple outil pour faire le taff demandé afin de toucher ton salaire, t'en a rien à faire d'une alternative tant que ça t'apporte rien, que ça ne te simplifie pas la vie, que ça ne te permet pas d'aller plus vite (et même, si le boss s'en rend compte et qu'il te file plus de taff, t'as rien gagné, donc, parfois, faut pas chercher à optimiser son temps), etc. En gros, si je devais faire plus court : je ne blâme pas le salarié lambda, il a raison de ne pas se poser de questions, car, dans l'écrasante majorité des cas, ça lui apportera aucun avantage. C'est mon point de divergence avec toi.

Tous les logiciels métiers n'existent pas en logiciels libres utilisables par le commun des mortels (tu ne fais pas de la comptabilité sérieuse ‒ = comptes à rendre ‒ à grande échelle ‒ = Grande Entreprise ‒ avec Ledger, GNUCash ou Odoo, par exemple) et inversement, y'a des domaines ou le libre remplace avantageusement la bouse privatrice (genre pour piloter certaines machines dans les laboratoires de recherche ou pour de l'enseignement très ciblé).

Dans le cas que j'ai présenté, il me semble que cette personne a essayé GIMP (elle en donne l'impression en tout cas), d'où l'ampleur de sa réaction outrée "arrêtez de vouloir m'apprendre mon métier alors que vous avez jamais utilisé GIMP pour effectuer mon travail !" (ce qui est vrai). Du coup, j'en arrive à la conclusion qu'il y a plusieurs manières de faire une chose et que, si cette personne n'a pas accroché à GIMP, ça sert à rien de la forcer ni de râler ni de la former. C'est dommage et tout ce qu'on veut, mais elle a fait son choix.

Et, dans les deux cas, on retombe sur les blocages formation et notoriété que j'énonce dans mon premier shaarli.

Pendant mes repas, je regarde des vidéos sur le web. Si une vidéo n'est pas terminée, j'en reprends la lecture au repas suivant.

Sur ce point, PeerTube est gonflant. Si tu regardes une vidéo à un repas, que t'arrêtes la lecture, que tu veux la reprendre des heures après (autres repas), ça lit le petit bout de vidéo qui avait été mis en cache puis ça s'arrête et ça mouline indéfiniment dans le vide, ça ne charge pas le segment suivant de la vidéo. Je précise que je ne change pas d'adresse IP.

Il faut mémoriser l'estampille temporelle, rafraîchir la page (F5) puis cliquer pour lire. Ça lit le début de la vidéo. Il faut se déplacer jusqu'à l'estampille temporelle. PeerTube fait semblant de charger… mais continue de lire le début de la vidéo. Il faut à nouveau se déplacer sur l'estampille temporelle, et, là, ça charge et ça lit le bon segment, youpi.

C'est comme ça à chaque repas, sur plusieurs instances PeerTube.

En comparaison, YouTube gère la reprise. Ça interrompt la lecture après avoir lu le segment resté en cache, mais au moins, ça charge et lit la suite de la vidéo automatiquement. Et si jamais un F5 s'avère nécessaire, la vidéo reprend là où on avait arrêté.

C'est le genre de truc pénible.

De leur aveu même, ils ont compris la tempête citoyenne qui suivrait si ce projet de loi devait être adopté...
[…]
De l'utilité des contre-pouvoirs dans la société civile ...

C'est du pipeau.

« Rassurer les élus », ça veut dire la même chose que loi d'amnistie. C'est formulé différemment, c'est tout. La différence, c'est que rassurer les élus, ça ne sera pas matérialisé par une loi, donc ça sera informel, inattaquable, propre, chacun, y compris les juges, fera ce qu'il a à faire, on ne se blesse pas entre gens de la caste. Ça se passera donc comme d'habitude : les personnes prétendument responsables s'en sortiront tranquillou. C'est toujours comme ça : un chef (au travail ou en associatif), un parent (vis-à-vis d'un enfant mineur), un politicien, etc. rend jamais de compte. Christine Lagarde dans l'affaire Tapie, les maires / députés / ministres qui tapent dans la caisse, les patrons qui ont aucun compte à rendre sur leur mauvaise gestion, Didier Lombard et compagnie pas condamnés (sursis ou peine aménageable), etc. Le système est conçu pour qu'un """"responsable"""" n'ait pas à rendre de comptes et pour qu'il ne soit pas inquiété. La justice, les contraintes, c'est bon pour les grouillots de base, eux auront droit à la violence policière (qui n'existe pas, dixit Macron), à la violence symbolique d'un procès (qui n'existe pas non plus, c'est une invention du méchant gauchiste Bourdieu), et aux comparutions immédiates (qui, quand tu sais en quoi ça consiste te font passer l'envie de nommer ça « Justice »). Ho, parfois on fait un exemple afin de rassasier la plèbe et de lui faire verser une petite larme "snif, les méchants pas beaux sont sanctionnés, la Justice fonctionne, je suis trop heureux de vivre dans un tel système, snif".

Quant à la « tempête citoyenne »… Le gouvernement était contre l'amendement du Sénat et il a émis un avis défavorable lors de son examen. Donc, avant que la « tempête citoyenne » débute, le gouvernement était déjà contre. Il ne l'est pas par conviction, mais par certitude que c'était un coup électoraliste du Sénat et qu'il est inutile (loi Fauchon depuis 20 ans + ce que j'ai écrit au premier paragraphe c'est-à-dire que l'amnistie existe déjà de fait pour les trouducs prétendument responsables, c'est l'essence même de leur statut, c'est inclus dans le pack). Ça se saurait si les « tempêtes citoyennes » faisaient reculer les politiciens (loi Renseignement 2015, loi Travail 2017, etc. où les mobilisations étaient plus fortes que sur ça).

Shaarli originel.

@Abel :

Dans les chaussures il ne faut pas se tromper la qualité ça se paye forcement . Je ne parle pas de la marque, mais de la qualité du produit .

Je suis d'accord, mais j'étais convaincu que la différence de prix entre mon modèle à 25 € et des modèles vendus plus cher allait dans la marque. C'était un des points de blocage.

Sans faire de publicité , pour ma part j’achète depuis au moins 30 ans des tennis de la marque TBS qui sont increvables . Elles sont fabriquées en France , en cuir et d'un confort que je n'ai jamais retrouvé dans d'autres chaussures .

Increvable comment ? Elles te font combien de temps pour quel usage ?

Quand j'ai lu « cuir », je me suis dit « nope, nope, nope ». Mais ils ont un modèle de baskets en cuir qui ne me répugne pas, donc à voir.

Fabriquées en France, faudra que je vérifie, ils en parlent très peu sur le site web, ça sent le "conçues en France, fabriquées en Italie". Déjà, le site web est hébergé chez Amazon…

@Orangina Rouge :

Le week-end/en balade, c'est des chaussures de "marche sportive" (le feu modèle "propulse run 400 newfeel") : c'est ma 3e paires depuis… 6 ? 7 ans ?

Puisque ce produit n'existe plus, par quoi l'as-tu / vas-tu le remplacer ?

Après, Decathlon = famille Mulliez = je ne suis pas fan.

Au boulot c'est des "Clarks Desert Boots"

Pas pour moi du tout. :-

bon sauf mon modèle en cuir noir, le daim couleur crème doit être mieux

Elles ?

@OpenNews :

La solution a ton problème de semelles s'appelle vibram. Une bonne référence en semelle de qualité.

Tu parles bien des semelles extérieures que Vibram peut greffer sur des chaussures existantes ?

Niveau budget on est à environ 11€ / mois avant l'upgrade vibram et à 8,5€/mois après réparation mais elles vont me durer encore plusieurs mois facile.

Comment ça peut être moins cher après alors que t'as payé chaussures + semelle ?

pour un bon cordonnier je recommande dossman à strasbourg qui monte du vibram et travaille par internet

Je note.

@Strak :

J'en ai lu une bonne partie et j'ai souri car je me retrouve pas mal dans ce discours autour de la chaussure ! :)
Pendant très longtemps, j'achetais l'exact même modèle quand mes pompes actuelles étaient défoncées, car je m'en foutais grave...

Je me sens moins seul. \o/

Lol, lg : il y a même un hommage pour toi sur cette page :P

Ton installation web / PHP est cassée ce soir : le lien me fait télécharger un fichier doku.php vide.

Quel est cet hommage ? Une capture d'écran du film Le dictateur ou la mention d'une personne que je connais ou une autre chose qui m'a échappé ?

Concernant le reste de ton shaarli : j'ai déjà testé i3. Pas pour moi.

• J'ai besoin de fenêtres qui se distinguent très clairement les unes des autres sinon je sais jamais où je me trouve, quelle fenêtre est active, etc. (j'ai jamais plusieurs fenêtres au premier plan ni un screen / tmux splitté, par exemple, je préfère largement avoir plusieurs onglets). HS-157 m'avait dit qu'on peut arriver à un résultat satisfaisant avec i3 à coup de configuration, mais j'ai la flemme. Je ne personnalise pas mon environnement de bureau par désintérêt, il faut que ça fonctionne et que ça me convienne de base ;
  
  
• Je ne parviens pas à mémoriser les raccourcis clavier. J'en connais quelques-uns, mais c'est le minimum du minimum syndical. Ça ne veut pas entrer, même par la pratique.

Comme à chaque passage à une nouvelle version de Debian GNU/Linux, voici un résumé de tout ce qui a foiré ou changé quand je suis passé à Buster.

Résumé des points qui peuvent poser problème (triés par niveau de risque) : suites cryptographiques faibles (RSA / DHE < 2048 bits, ECDSA / ECDHE < 224 bits) non prises en charge par défaut par OpenSSL (débrayable) + TLS 1.2 par défaut avec OpenSSL (débrayable), fin de la prise en charge des certificats x509 utilisant SHA-1 par OpenSSL (débrayable) et GnuTLS (non négociable), AppArmor activé par défaut, et traduction auto iptables->nftables.

Arborescence

/bin, /lib et /sbin n'existent plus. Il reste /usr/{bin,lib,sbin}.

Sur un système fraîchement installé, /bin, /lib et /sbin sont des liens symboliques. Sur un système mis à jour, rien change, sauf si l'on installe et utilise le paquet usrmerge.

Attention donc aux scripts qui contiennent des chemins absolus vers des binaires : il n'y aura pas toujours un lien symbolique sur /bin, /lib et /sbin.

Apache HTTPd + GnuTLS

Après la mise à jour, Apache HTTPd ne démarre plus. sudo journalctl -x -u apache2 affiche :

apachectl[6296]: AH00526: Syntax error on line 6 of /etc/apache2/mods-enabled/gnutls.conf:
apachectl[6296]: Could not find socache provider 'dbm', please make sure that the provider name is valid and the appropriate module is loaded (maybe mod_socache_dbm.so?).

GnuTLS active par défaut le cache partagé des sessions TLS. Il est stocké dans le backend DBM. Soit on désactive ce cache, soit on change de backend, soit, meilleure solution, on active le module correspondant avec a2enmod socache_dbm && systemctl restart apache2.

AppArmor

Généralités

AppArmor est installé et activé par défaut, sauf si apt est configuré pour ne pas installer les paquets recommandés (car AppArmor est une recommandation du noyau, pas une dépendance).

Je n'avais pas compris un truc : pour l'instant, l'utilisation d'AppArmor par chaque logiciel est basé sur le volontariat. Si un logiciel n'a pas de profil AppArmor, alors il n'est pas embêté. Actuellement, les profils sont fournis par les paquets apparmor, apparmor-profiles, apparmor-profiles-extra, par les logiciels volontaires (exemples : bind9, ntpd, haveged, tcpdump) et par les logiciels qui ne veulent pas se faire embêter (exemple : MariaDB livre un profil vide afin de désactiver AppArmor).

Pour voir les profils chargés et les processus contraints à un instant T, il y a la commande aa-status.

Problème avec BIND9

Sur mes systèmes, le seul logiciel qui a été contraint à tort par AppArmor est bind9. Dans son journal, je lisais :

named[551]: could not configure root hints from '/var/named/zones/defaultdb/db.root': permission denied
named[551]: loading configuration: permission denied
named[551]: general: error: dumping master file: /var/named/zones/slave/tmp-DwqA5s4Tm6: open: permission denied

C'est normal : le profil livré avec BIND9 (/etc/apparmor.d/usr.sbin.named) ne prévoit pas l'utilisation de /var/named. Or, je mets la configuration du serveur dans /etc/bind et le contenu servi par le serveur dans /var/named, car ce contenu est normalisé (il est le même quel que soit le serveur DNS utilisé BIND9, NSD, PowerDNS, etc.). Comme on met le contenu servi par un serveur web dans /var/wwwet la configuration de ce serveur web dans /etc/apache2 ou /etc/nginx.

Pour débloquer la situation, on crée un profil local qui surchargera le profil par défaut. Il se nomme /etc/apparmor.d/local/usr.sbin.named et son contenu est le suivant :

# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
/var/named/** r,
/var/named/zones/slave/* rw,

Il ne reste plus qu'à recharger la conf' d'AppArmor et à redémarrer BIND9 : systemctl reload apparmor.service && systemctl restart bind9.

Journalisation

Je déteste que tout soit consigné dans /var/log/syslog. J'aime bien avoir un journal pour chaque logiciel. Or, AppArmor tombe dans /var/log/syslog.

Pour remédier à ça, je crée un fichier /etc/rsyslog.d/apparmor.conf qui contient :

if $msg contains 'apparmor' then /var/log/apparmor.log
& stop

Je redémarre rsyslog : systemctl restart rsyslog (un reload ne suffit pas, de mémoire).

Pour l'archivage, je crée un fichier /etc/logrotate.d/apparmor contenant :

/var/log/apparmor.log
{
        monthly
        missingok
        rotate 12
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        olddir /var/log/archives/systeme
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

apt

• apt vérifie désormais que la date des fichiers d'un dépôt n'est pas dans le futur. Une option de configuration permet de revenir au comportement antérieur ;
  
  
• L'utilisation de dépôts non-authentifiés (absence de la clé OpenPGP, par exemple) émet désormais une erreur (qu'il faut contourner avec une option de configuration), plus un avertissement ;
  
  
• apt prend en charge nativement https. Plus besoin du paquet apt-transport-https qui contient désormais uniquement de la doc' ;
  
  
• La prise en charge des dépôts FTP est désactivée par défaut. Debian compte éteindre ses dépôts FTP… depuis novembre 2017. Une option de configuration permet d'activer la prise en charge de FTP par apt. En ce qui me concerne, je suis passé, à regret (le "tout sur HTTP" me pose un problème éthique, car ça rend le développement de nouveaux protocoles très compliqués en fermant le jeu), à HTTP.

deluged / deluge

Au démarrage de l'interface deluge-gtk, on doit démarrer le démon deluged puis s'y connecter. Or, là, il ne veut plus démarrer. Aucun message d'erreur.

On le lance en ligne de commande :

$ deluged
[…]
[ERROR   ] 00:41:33 rpcserver:378 [('SSL routines', 'SSL_CTX_use_certificate', 'ee key too small')]

Il existe un rapport de bug. La clé pour communiquer avec deluged ne respecte pas les critères de robustesse appliqués par défaut par OpenSSL dans Buster (voir ci-dessous).

Solution ? rm ~/.config/deluge/ssl/*. Une nouvelle clé sera générée et l'on pourra lancer deluged comme avant.

Dovecot

• Dovecot ne génère plus lui-même ses paramètres Diffie-Hellman. La directive de configuration ssl_dh_parameters_length est invalide. Il faut désormais générer nous-même nos DH avec openssl dhparam et les fournir à Dovecot. Exemple : ssl_dh = </etc/dovecot/ssl/dh_4096.pem.
  
  
• ssl_protocols est remplacé par ssl_min_protocol. Exemple : ssl_protocols = !SSLv3 devient ssl_min_protocol = TLSv1.
  
  
• La compression TLS est désactivée par défaut (ssl_options = no_compression), ce qui est une bonne chose vu les attaques que la compression rend possibles (CRIME).

dnssec-trigger

J'utilise ce logiciel depuis huit ans. Jamais un souci, rien. Mais après le passage à Buster, il refuse de démarrer :

dnssec-triggerd[1155]: [1581725206] unbound-control[31667:0] warning: control-enable is 'no' in the config file.
dnssec-triggerd[1155]: [1581725206] unbound-control[31667:0] error: connect: Connection refused for 127.0.0.1 port 8953
[…]
dnssec-triggerd[10688]: error: Error setting up SSL_CTX client cert
dnssec-triggerd[10688]: 140194432980928:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310:
dnssec-triggerd[10688]: [10688] warning: unbound-control exited with status 256, cmd: /usr/sbin/unbound-control forward 80.67.169.40 80.67.169.12
dnssec-triggerd[10688]: Traceback (most recent call last):
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 774, in <module>
dnssec-triggerd[10688]:     main()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 761, in main
dnssec-triggerd[10688]:     Application(sys.argv).run()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 472, in run
dnssec-triggerd[10688]:     self.method()
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 556, in run_setup
dnssec-triggerd[10688]:     self._unbound_set_negative_cache_ttl(UNBOUND_MAX_NEG_CACHE_TTL)
dnssec-triggerd[10688]:   File "/usr/lib/dnssec-trigger/dnssec-trigger-script", line 641, in _unbound_set_negative_cache_ttl
dnssec-triggerd[10688]:     subprocess.check_call(CMD, stdout=DEVNULL, stderr=DEVNULL)
dnssec-triggerd[10688]:   File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
dnssec-triggerd[10688]:     raise CalledProcessError(retcode, cmd)
dnssec-triggerd[10688]: subprocess.CalledProcessError: Command '['unbound-control', 'set_option', 'cache-max-negative-ttl:', '5']' returned non-zero exit

On trouve deux rapports de bug : #898969 et #919256. La clé pour communiquer avec Unbound ne respecte pas les critères de robustesse appliqués par défaut par OpenSSL dans Buster (voir ci-dessous).

Je ne suis pas parvenu à résoudre ce problème en supprimant les clés actuelles et en en générant de nouvelles, du coup, j'ai bourriné :

• killall dnssec-trigger-panel ;
  
  
• sudo apt-get autoremove --purge dnssec-trigger unbound unbound-anchor ;
  
  
• sudo find / -iname '*dnssec-trigger*' + supprimer ce qui est pertinent, notamment /etc/dnssec-trigger et /etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook ;
  
  
• sudo apt-get install dnssec-trigger ;
  
  
• sudo dnssec-trigger-control-setup -i ;
  
  
• sudo systemctl restart unbound dnssec-triggerd

EasyRSA / OpenVPN

Plusieurs options de configuration ont été supprimées dans la version 2.4 d'OpenVPN (présente dans Debian depuis Stretch) comme tun-ipv6 et tls-remote. Ce n'est pas bloquant : OpenVPN émet un avertissement et utilise l'option de remplacement.

D'autres options seront supprimées dans OpenVPN 2.5. ns-cert-type, par exemple. Ce ne sera pas bloquant : OpenVPN émettra un avertissement et utilisera l'option de remplacement. Il n'est déjà plus possible d'émettre des certificats x509 comportant cet attribut avec EasyRSA.

ejabberd

Comme à chaque mise à jour majeure de Debian, la configuration d'ejabberd change pas mal : des modules qui n'existent plus / sont dépréciés, des directives de configuration qui n'existent plus, etc. :

[warning] <0.81.0>@ejabberd_config:emit_deprecation_warning:1436 Module mod_http_bind is deprecated, use mod_bosh instead
[warning] <0.81.0>@ejabberd_pkix:opt_type:131 Option 's2s_certfile' is deprecated, use 'certfiles' instead
[warning] <0.81.0>@ejabberd_c2s:listen_opt_type:984 Listening option 'certfile' for ejabberd_c2s is deprecated, use 'certfiles' global option 

La nouvelle version empaquetée de la configuration apporte également des macros qui permettent de configurer TLS pour les échanges entre serveurs et pour les échanges avec un client (certfiles, DH_FILE, TLS_CIPHERS, TLS_OPTIONS, etc.). C'est très pratique puisque ça factorise la conf'.

Vu que je modifie peu la configuration livrée (réduction d'un cran de la verbosité du journal (4 -> 3), domaine, certificat x509, paramètres DH, suites de chiffrement TLS, pas d'auth interne, et activation du module Message Archive Management), j'ai sauvegardé mon ancienne conf', j'ai pris celle livrée par le paquet et je l'ai modifiée.

ÉDIT DU 21/06/2020 à 19 H 30 : 1) Vu qu'on remet la configuration à zéro, il faut bien penser à désactiver, à nouveau, l'interface web en commentant le port 5280 dans la section « listen ». Par défaut, ejabberd écoute le monde entier… Si l'on veut conserver l'interface web, on peut changer la ligne « ip » de ce module afin qu'il écoute uniquement en local. 2) Ça ne date pas de Buster, mais epmd, un composant erlang dont dépend ejabberd, écoute le monde entier sur le port tcp/4369. Ça sert à agréger plusieurs serveurs et à piloter le serveur avec ejabberd. J'ai écrit un article pour configurer epmd afin qu'il écoute uniquement en local car cela se fait du côté de systemd, pas (plus ?) depuis la configuration d'ejabberd, contrairement à ce que prétend la doc' d'ejabberd. FIN DE L'ÉDIT DU 21/06/2020 à 19 H 30.

Firefox / Thunderbird

(Ce point a aucun rapport avec Debian Buster, mais Buster est l'ocassion de faire un rappel.)

DNS over HTTP (DOH) est en cours de généralisation. Il y a de bonnes raisons de ne pas vouloir utiliser DoH Pour le désactiver dans Firefox et dans Thunderbird (qui partage une grande partie de son code avec Firefox), on affecte la valeur « 5 » à la clé de configuration « network.trr.mode » dans « about:config » (ou menu « Édition » -> « Préférences » -> « Avancé » -> « Éditeur de configuration », pour Thunderbird). On peut aussi configurer cela plus finement comme l'expose l'article pointé.

GnuPG

Suite à l'attaque de 2019 contre les serveurs de clés consistant à saturer une clé de signatures, le projet GnuPG a choisi d'appliquer par défaut la politique "recevoir uniquement ses propres signatures depuis les serveurs de clés". Debian suit ce changement.

Je trouve que c'est une idiotie. Lire cet avis.

GnuTLS

On passe de la version 3.5.X à la version 3.6.X. Le principal changement est que SHA-1 n'est plus un algorithme de hachage convenable quand il est utilisé dans le cadre d'une signature de certificat, donc sa prise en charge dans ce contexte a été anihilée à la compilation. Les outils de manipulation LDAP (ldap-utils), qui utilisent GnuTLS, foireront sur un certificat SHA-1, par exemple.

hash-slinger

hash-slinger n'est pas empaqueté dans Buster à cause d'une dépendance à python3-m2crypto non satisfaite.

La version de hash-slinger qui utilise python2 que t'as pu installer avant de mettre à jour ton système pourrait ne pas fonctionner dans certains cas à cause de l'obsolescence de la bibliothèque TLS. Exemple :

tlsa --verify --port 25  <serveur>
Traceback (most recent call last):
  File "/usr/bin/tlsa", line 774, in <module>
    sslStartTLSConnect(connection, (str(address), int(args.port)), args.starttls)
  File "/usr/bin/tlsa", line 251, in sslStartTLSConnect
    ret = connection.connect_ssl()
  File "/usr/lib/python2.7/dist-packages/M2Crypto/SSL/Connection.py", line 293, in connect_ssl
    return m2.ssl_connect(self.ssl, self._timeout)
M2Crypto.SSL.SSLError: wrong version number

On remarque la présence d'autres bugs. Exemple :

$ tlsa --create --usage 3 --selector 0 --mtype 1 --certificate mycertfile.pem <nom_machine>
Could not verify local certificate: no start line (Expecting: CERTIFICATE).
Traceback (most recent call last):
  File "/usr/bin/tlsa", line 889, in <module>
    genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype)
NameError: name 'chain' is not defined

Heu ? Osef de la chaîne de certificats, on veut un usage 3 (mettre dans le DNS le seul certificat du serveur). Si l'on regarde le code :

chain = connection.get_peer_cert_chain()
genRecords(args.host, args.protocol, args.port, chain, args.output, args.usage, args.selector, args.mtype)

Heu ? Osef de récupérer le certificat auprès du pair c'est-à-dire du serveur puisqu'on le passe en paramètre (--certificate mycertfile.pem). C'est un bug connu.

Mieux vaut utiliser la version du dépôt git officiel du projet. Néanmoins, elle utilise la version 3 de Python. Donc il faut installer le module M2Crypto (sinon on aura l'erreur ModuleNotFoundError: No module named 'M2Crypto').

La compilation du module M2Crypto nécessite swig, donc on l'installe : sudo apt-get install swig.

On installe le module M2Crypto pour Python 3 : sudo pip3 install m2crypto.

On récupère hash-slinger : git clone https://github.com/letoams/hash-slinger.

On l'installe : cd hash-slinger && sudo make install.

ifupdown

• Une interface VLAN marquée « allow-hotplug » monte en même temps que l'interface physique parente quand celle-ci est branchée ;
  
  
• Le traitement des interfaces est désormais parallélisé. Attention aux scripts pre-up, post-up, etc.
  
  
• On peut désormais appliquer une regex minimaliste sur le nom / l'adresse MAC / le type d'une interface (exemple : « /eth* ») et lui donner un surnom qu'on peut réutiliser par la suite (exemple : « /eth*/=foo »).

iptables / ebtables / arptables

iptables (iptables-nft de son vrai nom), ebtables (ebtables-nft) et arptables (arptables-nft) utilisent désormais le sous-système noyau nf_tables au lieu de xtables. Le but est de préparer la migration d'iptables (et co) vers nftables qui aura prétendument lieu dans la prochaine version stable de Debian (je n'y crois pas : la commande ip (remplaçante de ifconfig, route, vlan et d'autres) et la commande ss (remplaçante de netstat) ont plus de 10 ans, comme nftables, et il ne s'est rien passé malgré les menaces de déprécier ifconfig et compagnie).

La syntaxe des règles iptables ne changedonc pas, grâce à iptables-nft (et compagnie) qui effectue la conversion en douce, mais il faudrait migrer vers nftables.

Si l'on veut migrer, iptables-translate et iptables-restore-translate permettent de traduire les règles existantes. iptables-translate pour traduire une règle, iptables-restore-translate pour traduire un fichier de règles (obtenu avec iptables-save, par exemple). Attention : il n'y pas de contrôle de la syntaxe sur les éléments variants (nom d'une interface, nom d'une chaîne, nom d'une cible, etc.). Exemple :

$ sudo iptables-translate -t nat -A POSTROUTINGE -o tun0 -j TOTO
nft add rule ip nat POSTROUTINGE oifname "tun0" counter jump TOTO

On notera également que certaines traductions ne sont pas proposées (je donne la traduction de cet exemple plus bas) :

$ sudo iptables-translate -P FORWARD ACCEPT
Translation not implemented
nft 

Voici ma procédure pour migrer d'iptables vers nftables à partir d'un système équipé de netfilter-persistent :

sudo iptables-restore-translate -f /etc/iptables/rules.v4 > /tmp/nftables.conf.tmp
sudo ip6tables-restore-translate -f /etc/iptables/rules.v6 >> /tmp/nftables.conf.tmp

# Un script nftables commence par « #!/usr/sbin/nft -f »
sed -i '1s&^&#!/usr/sbin/nft -f\n&' /tmp/nftables.conf.tmp

# iptables-restore-translate crée les tables nat et mangle alors que je ne les utilise pas ou rarement.
# Je les vire afin d'améliorer la visibilité 
sed -i '/ip nat/d' /tmp/nftables.conf.tmp
sed -i '/ip mangle/d' /tmp/nftables.conf.tmp

# Vu que je vais temporairement être sans pare-feu (surtout s'il y a des règles cassées), je me déconnecte du réseau
sudo ifdown eth0

# Je vire toutes les règles (filtrage, NAT, etc.) IPv4 et IPv6 actuellement en place
sudo nft flush ruleset

# J'importe les règles au format nftables avec l'outil d'administration adéquat
sudo nft -f /tmp/nftables.conf.tmp

# Je vérifie que les règles sont en place
sudo nft list ruleset

# Puisque tout est OK, je me connecte au réseau
sudo ifup eth0

# Puisque tout est OK, je crée le fichier de configuration utilisé par l'unit systemd pour charger les règles
# -s permet de ne pas inclure les compteurs (de paquets / octets) dans l'export
# Oui, le format issu de la commande ip[6]tables-restore-translate aurait fonctionné, mais je voulais conserver le format du fichier /etc/nftables.conf
sudo nft -s list ruleset | sudo tee /etc/nftables.conf

# J'insère l'entête obligatoire pour un script nftables
# + je purge toutes les règles de filtrage. Cela permet de partir sur un jeu de règles sain lors d'un start ou d'un restart
sudo sed -i '1s&^&#!/usr/sbin/nft -f\n\nflush ruleset\n\n&' /etc/nftables.conf

# J'active l'unit systemd nftables et je la démarre
sudo systemctl enable nftables
sudo systemctl start/restart nftables

# Je veux pouvoir revenir facilement à iptables, donc je ne vais pas le désinstaller
# donc j'empêche netfilter-persistent de charger les vieilles règles au démarrage
sudo systemctl disable netfilter-persistent
sudo systemctl mask netfilter-persistent

ATTENTION :

• Quand des règles ont été créées avec nftables dans une chaîne de type « ip[6] », ip[6]tables ne peut plus lire le contenu d'une table. Le message d'erreur suivant s'affiche : iptables v1.8.2 (nf_tables): table 'nat' is incompatible, use 'nft' tool.. C'est normal : il ne faut pas utiliser les commandes iptables-legacy / iptables-nft en même temps que nft, car elles utilisent des sous-systèmes différents du noyau ;
  
  
• Comme avec netfilter-persistent, si des règles ne peuvent pas être appliquées, aucune alerte est levée. SystemD remonte aucune info, aucun code retour. Attention donc à ne pas se retrouver à poil.

Commandes utiles :

• Démarrer / arrêter le pare-feu : sudo systemctl start nftables / sudo systemctl stop nftables ;
  
  
• Nettoyer les règles ajoutées temporairement à la mano : sudo systemctl restart nftables ;
  
  
• Voir toutes les règles (filtrage, nat, mangle, arp, ebtables) IPv4 et IPv6 en vigueur : sudo nft list ruleset ;
  
  
• Voir toutes les tables, les chaînes et les règles d'un protocole (IPv4, IPv6, etc.) : sudo nft list ruleset ip6 (ici, que les règles IPv6 ‒ je simplifie, ce n'est pas vrai, voir ci-dessous ‒) ;
  
  

• Voir toutes les chaînes et les règles d'une table : sudo nft list table ip6 filter (ici, que les règles de filtrage IPv6) ;

• Ajouter une règle à la fin d'une chaîne existante (oui, il faut utiliser les guillemets et les apostrophes dès qu'on veut insérer un commentaire contenant plusieurs mots) : sudo nft 'add rule ip filter INPUT iifname "eth0" udp dport 666-999 counter accept comment "Ceci est un commentaire de plusieurs mots"' (ajout d'une règle dans la chaîne nommée INPUT de la table filter du protocole ip autorisant les paquets UDP destinés aux ports entre 666 et 999 inclus qui entrent par l'interface eth0) ;

  • Insérer une règle au début d'une chaîne existante : nft insert rule ip filter INPUT iifname "eth0" udp dport 666-999 counter accept ;

• Comme avec iptables, la case est importante : si le nom d'une table ou d'une chaîne est en majuscule, il faut respecter cela sinon on a un message d'erreur abscons : « Error: Could not process rule: No such file or directory » ;

• Supprimer une règle à chaud (la logique est identique pour une chaîne et une table) :

  # Récupérer le « handle » (numérotation interne) d'une règle
  sudo nft -a list ruleset
  # Supprimer cette règle (ici une règle dans la chaîne nommée INPUT de la table nommée filter du protocole IPv4)
  sudo nft delete rule ip filter INPUT handle <handle>

  
  

• Changer à chaud la politique par défaut d'une chaîne : sudo nft chain ip filter FORWARD { policy drop \; } (la politique par défaut de la chaîne nommée FORWARD de la table filter du protocole IPv4 est désormais drop (rejet silencieux) ;

• Créer une table, une chaîne et une règle :

          sudo nft add table ip nat
  # type et hook : à quelle interface réseau et à quelle partie de la pile réseau veut-on brancher la chaîne ? Ça détermine les paquets reçus par la chaîne
  #   valeurs possibles : https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types
  #   On peut créer des chaînes persos, non-reliées à la pile réseau, qui recevront des paquets via d'autres chaînes (-j nom_chaîne)
  # policy : politique par défaut de la chaîne : que fait-on d'un paquet qui a matché aucune règle ?
  # priority : ordonner les chaînes d'un même type+hook entre elles (le nombre le plus élevé l'emporte)
  #   \ + positionnement dans le processus de filtrage : exemple < - 200 = le paquet sera transmis à la chaîne avant la mise en place du suivi de connexion
  #   valeurs possibles : https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
  sudo nft add chain ip nat POSTROUTING '{ type nat hook postrouting priority 100; policy accept; }'
  sudo nft add rule ip nat POSTROUTING oifname "tun0" counter masquerade

• Du point précédent, on retient que le nom d'une table et d'une chaîne est totalement personnalisable. Avec iptables, la chaîne qui s'occupe du filtrage en sortie est forcément la chaîne nommée OUTPUT de la table nommée filter. Avec nftables, ça peut être la chaîne nommée « toto » de la table « LOL » :

  table ip LOL { # handle 82
      chain toto { # handle 1
          type filter hook output priority 0; policy drop;
          icmp type echo-request accept # handle 2
      }
  }

iptables-restore-translate traduit un jeu de règles ligne par ligne, donc on ne profite pas des possibilités de factorisation de nftables :

• Une unique règle qui s'applique à plusieurs interfaces réseau sans utiliser ipset : sudo nft add rule ip filter INPUT iifname {"tun0", "wlan0"} counter accept ;
  
  
• Une unique règle qui s'applique à plusieurs adresses IP source ou destination sans utiliser ipset (destination dans cet exemple) : sudo nft add rule ip filter OUTPUT ip daddr {192.0.2.1, 198.18.0.0/15} counter accept ;
  
  
• Une unique règle qui s'applique à plusieurs protocoles de la couche 4 : sudo nft add rule ip filter FORWARD ip protocol {tcp, udp} accept ;
  
  
• Une unique règle qui s'applique à plusieurs ports d'un même protocole de couche 4 : sudo nft add rule ip filter INPUT udp dport {53, 5353} counter accept ;
  
  
• Et si l'on veut autoriser un même port pour plusieurs protocoles comme autoriser, en une seule règle, le DNS (qui nécessite les ports udp/53 et tcp/53) ? Ce n'est pas vraiment prévu : le mot clé « dport » est relatif au mot clé (tcp ou udp). On peut ruser, mais c'est crade : sudo nft 'add rule inet filter INPUT ip protocol {tcp, udp} @th,16,16 53 counter accept comment "DNS udp et tcp"'. Attention : cela nécessite que le port de destination soit stocké au même emplacement dans l'entête des deux protocoles.

nftables permet également d'appliquer une même règle en IPv4 et en IPv6. Cela se fait avec une table de type « inet ». Cela signifie que des règles concernant IPv4 peuvent se trouver dans une table de type inet ET dans une table de type ip (d'où sudo nft list ruleset ip6 n'affiche pas toutes les règles IPv6 mais toutes les tables de type ip6). Exemple pour autoriser SSH en entrée en IPv4 et en IPv6 :

sudo nft add table inet filter
sudo nft add chain inet filter INPUT '{ type filter hook input priority 0; policy drop; }'
sudo nft add rule  inet filter INPUT tcp dport ssh counter accept

Attention : à hook identique et à priorité égale ou même supérieure une chaîne de type inet passe avant une chaîne de type ip. Si la chaîne inet ne drop pas le paquet, la chaîne ip le verra passer, sinon non. Source. Cela peut poser problème. Exemple : virt-manager crée un réseau NATé pour les machines virtuelles. Pour ce faire, il utilise des chaînes de type / de la famille ip. J'effectue tout mon filtrage dans des chaînes de type inet dont la politique est de drop sauf ce qui va dans un VPN. Conclusion : la machine virtuelle n'aura pas d'IP (DHCP foiré) et ne pourra pas sortir sur Internet.

Dans une chaîne de type inet, il est possible de filtrer uniquement IPv4 ou IPv6. Soit en utilisant une directive spécifique à un protocole (exemple : sudo nft add rule inet filter INPUT ip daddr 192.0.2.1/32 accept, soit en utilisant les mots-clés « meta nfproto ipv(4|6) » (exemple : sudo nft add rule inet filter OUTPUT meta nfproto ipv4 udp dport 666 reject with icmp type admin-prohibited).

Documentations utiles :

• nftables dans le wiki Debian ;
  
  
• Doc' poussée sur les chaînes, hook, priorités, etc. sur le wiki nftables ;
  
  
• Mots-clés de référence utilisables dans une règle sur le wiki nftables.

logrotate / rsyslog

Mes journaux consignés par rsyslog n'étaient plus archivés par logrotate. De plus, dans /etc/logrotate.d/rsyslog, je constate qu'on n'utilise plus invoke-rc.d rsyslog rotate > /dev/null, mais /usr/lib/rsyslog/rsyslog-rotate.

Ces deux éléments sont liés : il y a un bug (l'unit systemd fait démarrer rsyslog sans PID, alors qu'on en a besoin pour invoke-rc.d) et Debian a mis en place le magnifique (ironie) script /usr/lib/rsyslog/rsyslog-rotate (résumé : si systemd est en cours d'utilisation, alors on utilise systemctl kill pour envoyer un signal à rsyslog, sinon on utilise invoke-rc.d).

J'ai modifié toutes mes configurations logrotate afin d'utiliser /usr/lib/rsyslog/rsyslog-rotate dans l'action de post-rotate, même si ça ne me semble pas pérenne…

man-db

CRON me rapporte une erreur :

/etc/cron.daily/man-db:
/usr/bin/mandb: error while loading shared libraries: libgdbm.so.3: cannot open shared object file: No such file or directory
run-parts: /etc/cron.daily/man-db exited with return code 127

Regardons les bibliothèques de fonctions qui sont liées dynamiquement à man-db :

$ ldd /usr/bin/mandb 
linux-vdso.so.1 (0x00007ffeb36fe000)
libmandb-2.7.6.1.so => /usr/lib/man-db/libmandb-2.7.6.1.so (0x00007fb4ffa8b000)
libman-2.7.6.1.so => /usr/lib/man-db/libman-2.7.6.1.so (0x00007fb4ff868000)
libgdbm.so.3 => /usr/lib/x86_64-linux-gnu/libgdbm.so.3 (0x00007fb4ff661000)
libpipeline.so.1 => /usr/lib/x86_64-linux-gnu/libpipeline.so.1 (0x00007fb4ff453000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4ff0b4000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb4fee9a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb4ffeb3000)

Hum… Il y a bien libgdbm.so.3… qui n'existe plus au profit de libgdbm.so.6.

""""Solution"""" ? apt-get install --reinstall man-db

Merci pour le poisson.

MariaDB

MariaDB 10.3 ne s'est pas installé tout seul, j'ai dû le faire à la mano (sudo apt-get install mariadb-server). J'imagine que j'avais installé le paquet mariadb-server-10.1 quand j'étais sous Stretch au lieu du paquet mariadb-server…

Durant l'installation, je lis mysql_install_db : Installation of system tables failed!. Dans le journal MariaDB (/var/log/mysql/…), je lis : Unable to lock ./ibdata1 error: 11.

Hum… Fichier déjà ouvert. Donc : systemctl stop mariadb && mysql_install_db && systemctl start mariadb.

MATE

Durant la mise à jour, le texte de toute fenêtre déjà ouverte (ou ouverte après-coup) foire : flou, difficile à lire, etc. Les intitulés des menus sont parfois tronqués comme le menu « fichier » dans Pluma. Sur tout site web, les caractères sont remplacés par des carrés. Après vérification, ce n'est pas un changement de définition (1920x1080) ni de résolution (en DPI).

On se dit qu'on va reboot. Depuis le menu MATE, ça ne fonctionne pas : je tombe sur un GNOME shell (qu'est-ce qu'il fout ici, celui-là ?!) qui me demande mon mot de passe comme si la session était verrouillée. Toute saisie est impossible. Le bouton arrêter / redémarrer en haut à droite de l'écran fait rien. Pas d'accès aux consoles (ctrl+alt+fx). On est parti pour un REISUB / BUSIER…

Au redémarrage, tout est OK : les textes et les menus s'affichent correctement et l'extinction / le redémarrage via le menu MATE sont fonctionnels. Même chose pour les tty.

Néanmoins, la sensibilité de la souris a été clairement abaissée. Mon pointeur se traîne… On corrige ça dans les paramètres.

Je note aussi que, quand caja (explorateur de fichiers MATE) gueule « failed to activate device operation not permitted », ça signifie que je n'ai pas saisi la bonne passphrase pour déverrouiller un disque dur interne (le message qui s'affiche pour pareille boulette sur un disque dur externe n'a pas changé…).

mumble

Prise en charge des suites de chiffrement qui permettent la Perfect Forward Secrecy (en clair : utilisation de clés de chiffrement symétrique temporaires qui ne sont pas échangées entre le client et le serveur grâce aux algos DHE / ECDHE, ce qui fait que si la clé privée asymétrique est compromisse, les échanges passés restent secrets). Cool. \o/

ntpd / tzdata

Le paquet tzdata livre désormais un fichier qui annonce les secondes intercalaires (ça permet de les gérer). ntpd est configuré par défaut pour utiliser ce fichier (leapfile /usr/share/zoneinfo/leap-seconds.list). Avant, il fallait récupérer manuellement le fichier auprès du NIST (ou de l'IANA ou…) et configurer ntpd nous-même. Cool.

Ça ne changera pas grand-chose puisque les serveurs NTP de strate 1 bien connus communiquent la seconde intercalaire via le protocole NTP lui-même.

ntpdate

Ce paquet ne fournit plus de hooks ifupdown permettant à ntpdate d'être exécuté à chaque fois qu'une connexion au réseau est établie. Il faut utiliser un démon NTP (ntpd, chrony, etc.) ou, au pire du pire, bidouiller ses propres scripts.

C'est positif, ça posait souvent problème : synchronisation aléatoire, ça n'utilisait pas les serveurs NTP du réseau reçus en DHCP, etc.

OpenDNSSEC

Lors de son démarrage, ods-enforcerd consigne Token.cpp(482): Could not get the token flag dans son journal. Cela fait penser à ce bug, mais il est trop vieux pour ne pas avoir été corrigé dans Buster. De plus, un simple systemctl restart ods-enforcerd suffit à faire rentrer les choses dans l'ordre. Je pense à une race-condition au démarrage du serveur, car ça n'est pas reproduit après le deuxième redémarrage. À défaut d'une solution, je me note d'être vigilant à chaque redémarrage de mon serveur…

J'ai découvert que, dans le cadre des DNS adapters (source), le signeur écoute sur les ports TCP et UDP 15354 de toutes les interfaces, et évidemment pas que sur localhost… Ce n'est pas ce que dit la documentation, mais c'est ce que je constate. Pour rattraper le coup, j'ai remplacé le bloc Listener dans /etc/opendnssec/conf.xml par celui-ci :

<Listener>
        <Interface>
                <Address>127.0.0.1</Address>
                <Port>5353</Port>
        </Interface>
</Listener>

OpenSSH

• Les variables d'environnement (y compris celles positionnées dans le fichier authorizedkeys) ne peuvent plus surcharger les variables « SSH* » de sshd ;
  
  
• La journalisation de l'authentification est plus précise durant la phase de pré-auth et le format de certains messages a changé donc attention aux outils qui examinent les journaux SSH.

OpenSSL

Par défaut, c'est la version 1.2 ou supérieure du protocole TLS qui sera utilisée.

Par défaut, les suites de chiffrement faibles sont désactivées. Adieu RSA / DHE avec des clés inférieures à 2048 bits et ECDSA / ECDHE < 224 bits. Adieu les certificats dont la signature repose sur SHA-1 pour en créer le condensat.

Dans les deux cas, cela peut être contourné dans /etc/ssl/openssl.cnf en remplaçant :

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

Par :

[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

Attention : les applications peuvent faire comme elles veulent. Exemples : wpa_supplicant accepte les certificats x509 dont l'algo de hachage avant signature est SHA-1. openssl s_client affiche un message « Verify return code: 68 (CA signature digest algorithm too weak) »

PHP

J'utilise le module PHP pour Apache HTTPd. Je suis quasiment sûr que le paquet libapache-mod-php (et non pas libapache-mod-php7.2) était installé. Pourtant, j'ai dû activer moi-même le module PHP 7.3 (version empaquetée dans Buster) à la main (a2endmod php7.3 && systemctl restart apache2). Au préalable, j'ai migré ma conf' PHP (php.ini) personnalisée de /etc/php/7.2/apache2 vers /etc/php/7.3/apache2 (ne pas faire un cp sinon on ne bénéficie pas des nouveautés…, préférer diff).

Thunderbird

La date et l'heure des emails s'affichaient au format anglais. Le paquet thunderbird-l10n-fr était bien installé. J'avais vérifié mes locales. J'avais tenté de lancer Thunderbird depuis un shell en précisant la locale juste avant. J'avais tenté de bidouiller mail.ui.display.dateformat.default et ses amies Sans succès.

Depuis la mise à jour vers Buster, les dates et l'heure des emails sont au format français…

ssmtp

ssmtp n'est pas empaqueté dans Buster, mais il est présent dans testing et sid, donc, comme le T-800, il reviendra.

xsane

Depuis octobre 2018, xsane n'est plus maintenu (le site web officiel affiche « XSane (temporarily offline!) »).

#Debian 9 à Debian 10 ; Debian 9 à 10

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

Résumé : si t'as configuré ton serveur d'emails Postfix pour qu'il prenne en compte les enregistrements DNS DANE TLSA et qu'un email n'est pas envoyé au motif d'erreur « Server certificate not verified », vérifie la validité de l'enregistrement TLSA associé au serveur emails du destinataire avec l'outil tlsa de la suite logicielle hash-slinger : il ne correspond très probablement pas au certificat x509 présenté par le serveur emails. Contacte l'hébergeur du serveur en utilisant whois -B <adresse_IP_du_serveur. On notera que le message d'erreur de Postfix n'est pas explicite, donc qu'il y a encore du boulot de ce côté-là avant une généralisation de DANE TLSA.

DANE TLSA permet de stocker, dans le DNS signé avec DNSSEC, les certificats x509 afin d'obtenir une deuxième chaîne de validation et de combler ainsi les immenses lacunes conceptuelles du modèle de sécurité de la norme x509. Détails et utilisation concrète ici.

Il y a quelques jours, j'ai rencontré, en production, mon premier pépin dont l'origine est DANE TLSA.

J'envoie un email. Un jour après, pour comprendre une toute autre chose, je consulte le journal de Postfix, mon serveur d'emails. Par hasard (tail -f et nouvelle tentative d'envoi récente), j'y lis ceci :

postfix/smtp[23743]: 235AB2AE: to=[CENSURE], relay=[CENSURE][[CENSURE]]:25, delay=82176, delays=82176/0.15/0.13/0, dsn=4.7.5, status=deferred (Server certificate not verified)

Notons que si je n'avais pas consulté le journal, j'aurais quand même été informé du problème en recevant, après 5 jours (valeur par défaut du paramètre maximal_queue_lifetime de Postfix), un email présentant le problème émis par « Mail Delivery System / MAILER-DAEMON », c'est-à-dire Postfix lui-même.

Je cherche à obtenir plus d'infos.

Ajouter « -v » dans la colonne « command + args » des services « tlsmgr » et « smtp » dans master.cf (exemple : « tlsmgr unix - - y 1000? 1 tlsmgr -v ») + systemctl reload postfix rend Postfix plus causant mais cela m'apprend rien.

Dans main.cf, je suis déjà en smtp_tls_loglevel = 1. En changer la valeur pour « 2 » et recharger Postfix ne m'en apprendra pas d'avantage.

Rien permet de comprendre l'origine du problème, pas un seul indice. Un message d'erreur explicite serait le bienvenu avant une généralisation de DANE TLSA.

Je connais les compétences des salariés de l'hébergeur emails de mon destinataire, donc je choisis de remettre en cause mon installation plutôt que la leur.

Comme m'y incite le premier résultat d'une recherche du message d'erreur « Server certificate not verified » dans un moteur de recherche, je commence à creuser la politique de validation d'un certificat x509 appliquée par Postfix (paramètres smtp_tls_(verify|secure)_cert_match) : avec quoi compare-t-on le Common Name / SubjectAltName ? Avec le nom du serveur ? Avec le nom de domaine du destinataire ? Avec celui de l'hébergeur emails ? Ma recherche en ce sens donnera rien.

Je réfléchis (enfin). Comme l'écrasante majorité des serveurs emails, le mien est configuré pour tenter un envoi en clair si l'envoi chiffré a été impossible (on nomme ça TLS / chiffrement opportuniste). Pourquoi mon serveur n'a pas agit comme ça cette fois-ci ?

Il est configuré pour prendre en compte les enregistrements DNS TLSA : smtp_dns_support_level=dnssec + smtp_tls_security_level=dane (attention : les versions de TLS et les suites de chiffrement autorisées se définissent désormais dans smtp_tls_mandatory_protocols et smtp_tls_mandatory_ciphers !). Si l'hébergeur emails du destinataire a positionné un enregistrement TLSA, cela signifie qu'il veut qu'on échange avec lui de manière chiffrée, donc on n'essaye pas de communiquer en clair. DANE TLSA pallie à la principale limite du chiffrement opportuniste : sans TLSA, si le message d'initialisation du chiffrement, STARTTLS, est perdu ou volontairement stoppé par un méchant, alors la communication s'effectue sans chiffrement.

Je vérifie la présence d'un enregistrement TLSA avec dig TLSA _25._tcp.<nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>. Il y en a bien un.

J'utilise tlsa, un petit script de la collection hash-slinger (qui permet, également et entre autres, la manipulation des enregistrements DNS SSHFP et des enregistrements DNS DANE OpenPGP) pour vérifier la validité de cet enregistrement.

Attention si tu utilises Debian GNU/Linux Buster : hash-slinger n'est pas empaqueté dans cette version à cause d'une dépendance à python3-m2crypto non satisfaite. La version de hash-slinger qui utilise python2 que t'as pu installer avant de mettre à jour ton système pourrait ne pas fonctionner dans certains cas à cause de l'obsolescence de la bibliothèque TLS (« M2Crypto.SSL.SSLError: wrong version number », c'est du vécu). Bref : sudo apt-get install swig && pip3 install m2crypto + installer hash-slinger depuis le dépôt git officiel (git clone + sudo make install).

Je vérifie donc la validité de l'enregistrement TLSA positionné par l'hebergeur emails :

$ tlsa --verify --port 25 <nom_du_smtp_distant_qui_est_mentionné_dans_relay_dans_le_journal_Postfix>
FAIL (Usage 3 [DANE-EE]): Certificate offered by the server does not match the TLSA record ([CENSURE])

Oups… Tout s'explique… Le certificat x509 présenté par le serveur emails ne correspond pas à l'enregistrement TLSA.

Afin d'être sûr de moi, je calcule moi-même le RDATA de l'enregistrement DNS en fonction du certificat actuellement utilisé avec $ openssl s_client -connect [CENSURE]:25 -starttls smtp -showcerts < /dev/null 2> /dev/null | openssl x509 -pubkey | openssl rsa -pubin | head -n -1 | tail -n +2 | base64 -d | sha256sum et, oui, il ne correspond pas à celui mis en service. Pour les détails : l'enregistrement présent est un condensat SHA-256 (mtype = 1) de la clé publique (selector = 1) du seul certificat du serveur (usage = 3), d'où cet enchaînement de commandes publié sur le blog de Stéphane Bortzmeyer pour le synthétiser.

Je contacte l'hébergeur emails. Comment ? whois -B <IP_du_serveur_emails>. D'une manière générale, ne pas oublier « -B » : cela permet d'obtenir des adresses emails autres que celle qui permet de signaler les abus. J'ai mis de côté d'autres paramètres bien utiles de la commande whois dans mon article Découvrons la RIPE database.

En fin de matinée du premier jour ouvré suivant mon email, l'enregistrement DANE TLSA a été retiré. Fin du problème, mais c'est dommage d'avoir laissé tomber… Peut-être est-ce un repli stratégique pour réfléchir à un meilleur déploiement, avec supervision et tout et tout ?

Ce matin, je veux appliquer les mises à jour de sécurité sur mon système Debian GNU/Linux Buster et…

Paramétrage de linux-image-4.19.0-8-amd64 (4.19.98-1+deb10u1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-8-amd64
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.19.0-8-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: erreur de traitement du paquet linux-image-4.19.0-8-amd64 (--configure) :
 installed linux-image-4.19.0-8-amd64 package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 linux-image-4.19.0-8-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Lançons update-initramfs nous-même :

# update-initramfs -vuk 4.19.0-8-amd64
Calling hook growroot
Adding binary /sbin/sfdisk
Adding library-link /lib/x86_64-linux-gnu/libfdisk.so.1.1.0
Adding library /lib/x86_64-linux-gnu/libfdisk.so.1.1.0
Adding library-link /lib/x86_64-linux-gnu/libsmartcols.so.1.1.0
Adding library /lib/x86_64-linux-gnu/libsmartcols.so.1.1.0
Adding library-link /lib/x86_64-linux-gnu/libtinfo.so.6.1
Adding library /lib/x86_64-linux-gnu/libtinfo.so.6.1
E: /usr/share/initramfs-tools/hooks/growroot failed with return 1.

Regardons /usr/share/initramfs-tools/hooks/growroot (premier script qui termine en erreur) :

# cat /usr/share/initramfs-tools/hooks/growroot
#!/bin/sh
set -e

PREREQS=""
case $1 in
    prereqs) echo "${PREREQS}"; exit 0;;
esac

. /usr/share/initramfs-tools/hook-functions

##
copy_exec /sbin/sfdisk /sbin
copy_exec /usr/bin/growpart /sbin
[…]

Ça échoue sur « copy_exec /usr/bin/growpart ».

# ls -lh /usr/bin/growpart
ls: impossible d'accéder à '/usr/bin/growpart': Aucun fichier ou dossier de ce type

Intéressant. Il vient d'où, ce fichier ?

$ apt-file search /usr/bin/growpart
cloud-guest-utils: /usr/bin/growpart

Du paquet logiciel cloud-guest-utils. Cloud-init est utilisé par mon fournisseur de machines virtuelles et, en effet, je l'ai viré de mon VPS (machine virtuelle) depuis quelques mois. Pourquoi ça n'a pas supprimé le hook initramfs ?

$ apt-file search /usr/share/initramfs-tools/hooks/growroot
cloud-initramfs-growroot: /usr/share/initramfs-tools/hooks/growroot

Il est installé par un autre paquet logiciel. Peut-être que ce paquet est toujours installé ?

# apt-cache policy cloud-initramfs-growroot
cloud-initramfs-growroot:
  Installé : (aucun)
  Candidat : 0.18.debian7
[…]

Non. Peut-être y a-t-il de la configuration résiduelle ?

# dpkg -l | grep cloud-initramfs-growroot
#

Non.

""""Solution"""" : apt-get install --no-install-recommend cloud-initramfs-growroot && apt-get autoremove --purge cloud-guest-utils cloud-image-utils cloud-initramfs-growroot cloud-utils genisoimage qemu-utils.