Cyril Brulebois a écrit 652 commentaires

+1 pour Gandi → Infomaniak pour les mails pro, un peu pour le prix (la boîte pouvait absorber les frais supplémentaires), mais surtout pour le foutage de gueule absolu.

(J'auto-héberge les mails perso depuis bien plus longtemps, mais j'ai préféré avoir deux canaux différents.)

Debian Consultant @ DEBAMAX

(Il paraît que se répéter est à la mode, à la mode, à la mode…)

Quand lire la doc de la distribution (et des autres, notamment celle d'ArchLinux suggère qu'il peut manquer des morceaux…) ne suffit pas, j'ai tendance à aller regarder le code, et surtout l'historique.

Je te suggère donc ceci dans systemd.git :

git log --grep IPMasquerade

Certains messages de commit sont plutôt verbeux, par exemple 715a70e7218710d6a6c033e9157bf97fdf5d8ede, qui mentionne :

table ip io.systemd.nat {
        set masq_saddr {
                type ipv4_addr
                flags interval
                elements = { 192.168.59.160/28 }
        }
[…]
        chain postrouting {
                type nat hook postrouting priority srcnat + 1; policy accept;
                ip saddr @masq_saddr masquerade
        }
}

Et oui, la transition entre iptables et nftables est complètement chaotique, puisque les deux sont co-installables (avec iptables qui tire nftables), des alternatives disponibles pour iptables en mode legacy ou nft mais bien évidemment, en fonction de comment les règles sont positionnées, les différents outils les voient ou non…

Et bien évidemment, de nombreux outils continuent à dépendre (via Depends plutôt que Recommends, donc non négociable…) d'iptables, ce qui exclut de purger ce paquet pour limiter les interactions foireuses…

En fonction de l'ensemble des paquets installés, tu peux essayer de virer iptables pour voir si ça aide.

Si c'est plutôt un problème côté systemd, tu peux essayer de regarder ce que fait src/shared/firewall-util-nft.c pour voir si ça te donne une piste quant à un éventuel réglage manquant dans ta configuration ?

Enfin, il existe un backport pour Debian stable, si tu soupçonnes un éventuel problème upstream qui serait déjà corrigé, mais ça fait plein de paquets à mettre à jour (dont udev et différentes bibliothèques), et c'est un peu pénible de revenir en arrière ensuite.

Debian Consultant @ DEBAMAX

Et heureusement, parce que les noms des disques peuvent permuter au gré des redémarrages, sans qu'il y ait le moindre changement au niveau des nappes…

(Je le vois ± régulièrement avec deux paires de disques rotatifs nommés /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd.)

Ajout : Voir également mmcblk0 vs. mmcblk1 sur certains modèles de Raspberry Pi.

Debian Consultant @ DEBAMAX

Oui, c'est vite fait de passer à côté d'une blague dans pavucontrol.

J'aurais tendance à partir de l'onglet Configuration, vérifier le mode (e.g. « Analog Stero Duplex » vs. des dizaines d'options HDMI), puis basculer sur Output Devices et vérifier les différentes sorties, leur volume, l'éventuel mode muet, et terminer par Playback pour la vue applicative. C'est parfois étrange de ne rien entendre mais de voir bouger des vumètres, et ça peut aider à comprendre quel bouton cliquer.

Sinon, pour répondre à une interrogation précédente, ce ne serait pas la première fois que des réglages positionnés dans le monde Windows impactent le monde Linux, que ça soit avec des choses stockées dans une EEPROM quelque part, dans le firmware UEFI, etc. Ceci dit, c'est plutôt quand le Windows est silencieux que le Linux peut le devenir/rester (jusqu'à changement de l'autre côté), ce qui ne semble pas être le cas ici.

Debian Consultant @ DEBAMAX

lhpx mentionnait ajouter la performance tout en conservant le format.

→ +1 pour la pertinence de la mention de pigz.

Quant à xz -T, attention à la reproductibilité de sa sortie, ce qui n'est pas génial par les temps qui courent (voir les commentaires de la fonction compress_xz dans les sources de dpkg, d'où les performances minables quand on génère de gros paquets Debian, même si on a plein de cœurs).

→ J'en profite donc pour mentionner pixz (que je n'ai pas vu avoir de problème de ce côté-là).

Debian Consultant @ DEBAMAX

Mettre en place une redirection suppose indiquer un port source (idéalement dans la tranche attribuée) et un port destination…

Debian Consultant @ DEBAMAX

Des souvenirs de mon expérience de retour chez Free, je dirais que du point de vue du monde extérieur, on existe pas si on fait partie des #2, 3 ou 4. Et on n'existe que pour 1/4 des ports si on est le #1.
Pour preuve (ou "preuve" ?), aucun mail ne rentrait chez moi durant la période où j'étais dans le flou.

Dans ce contexte, c'est (souvent) 1 IP = 4 abonné⋅e⋅s, chacun⋅e avec sa tranche de ports.

Si tu es #1, tu as 25, 80, 443, notamment.

Si tu es #4, tu as le port par défaut de WireGuard…

Mon interrogation initiale étant : si tu es #1, #2 ou #3, la Freebox te permet-elle de configurer une redirection depuis le port 51820, qui n'est pas à ta disposition ? Cela me semblerait étrange…

Debian Consultant @ DEBAMAX

La box accepterait de mettre en place une redirection depuis un port qui ne serait pas dans la tranche de ports attribuée en cas de CGNAT ?

Debian Consultant @ DEBAMAX

Aucun besoin de toucher la configuration de la box du voisin a priori.

En revanche, l'endpoint configuré ici, 192.168.1.202:51820, est probablement l'IP de ton PC sur le réseau local de ta box, qui n'est pas visible/accessible depuis le réseau de ton voisin. À la place, il faudrait mettre ton adresse IP publique, ou un nom de domaine, pointant vers ta box.

(Le tout en partant du principe que tu fais tourner WireGuard sur ton PC, puisque tu as redirigé le port UDP de la box vers le PC.)

Debian Consultant @ DEBAMAX

Je vois au moins deux limites qui peuvent poser problème :

• le nombre de fichiers dans un même répertoire — même si cela me semble peu probable dans ton cas, c'est bon de savoir que ça peut être un facteur limitant ;
• la taille de la ligne de commande.

Ici ton *.jpg fait probablement exploser la 2e limite. Tu peux essayer avec un simple ls *.jpg pour confirmer.

Debian Consultant @ DEBAMAX

Sans ChatGPT… il y a a priori beaucoup d'extensions qui touchent de près ou de loin au concept de session, cf. une recherche de session sur https://extensions.gnome.org/

Installer/utiliser une extension ou réutiliser le code devrait être plutôt simple…

Debian Consultant @ DEBAMAX

Le rappel en sujet étant fait…

Un rétroportage existe :

incron     | 0.5.12-3~bpo11+1 | bullseye-backports       | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

Sinon, inotify-tools propose inotifywatch (entre autres outils).

Debian Consultant @ DEBAMAX

Si on veut quelque chose de robuste, il faut passer par \0 (cf. find -print0 et xargs -0).

Trop de blagues possibles autrement (coucou les apostrophes, guillemets simples ou doubles, entre autres choses).

Debian Consultant @ DEBAMAX

Les clients mail peuvent garder en cache local certaines informations. Historiquement je crois me souvenir qu'il s'agissait souvent de se concentrer sur les entêtes (et pas nécessairement le contenu/les pièces jointes). Tu peux vérifier les réglages du compte concerné dans ton Thunderbird, il y a des cases à cocher sur ce thème (aperçues lors d'une migration sur un poste qui n'est pas le mien, je n'ai plus le détail en tête).

Pour ce qui est effectivement sur le disque (et donc normalement dans tes sauvegardes), tu peux regarder ce qu'il y a dans le répertoire ImapMail de ton profil Thunderbird.

Beaucoup de précautions de langage dans cette réponse puisque j'ai opté il y a 15+ ans pour avoir l'intégralité de mes mails en local, d'abord via offlineimap (attention aux bugs de synchro… :/) puis avec mbsync (de la suite isync — aucun rapport avec Apple).

Ajout : Concernant une méthode (que je considère) sûre, je synchronise via mbsync les mails de certaines personnes sur une machine, et ça part dans les backups toutes les 6 heures, ce qui laisse l'opportunité de rattraper les mails qui disparaissent (que ça soit suite à un souci serveur ou à une mauvaise manipulation humaine).

Debian Consultant @ DEBAMAX

Si c'est dû à une restriction AA, ça laisse des traces dans les journaux système.

Exemple au hasard :

kibi@tokyo:~$ sudo dmesg | grep DENIED | tail -1
[707276.981016] audit: type=1400 audit(1717452001.495:132): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=1127333 comm="cupsd" capability=12  capname="net_admin"

Debian Consultant @ DEBAMAX

Falsehoods Programmers Believe About Names

Debian Consultant @ DEBAMAX

Contrairement au chemin que je mentionnais, le tien est bien évidemment aléatoire (suffixe .IUSSO2), et va changer à chaque connexion sur ta session graphique.

(Cela peut se vérifier dans le code de Mutter.)

Depuis la crontab, il est probablement suffisant de faire une recherche dans le répertoire runtime pour trouver le fichier .mutter-Xwaylandauth.XXXXXX du jour, et positionner XAUTHORITY en conséquence.

Debian Consultant @ DEBAMAX

Historiquement, xauth créait ~/.Xauthority. Depuis plein de versions, les gestionnaires de connexion (comme GDM) créent un fichier ailleurs, e.g. /run/user/1000/gdm/Xauthority et passent le chemin via l'environnement à la session graphique (et donc aux programmes démarrés dedans), cf. XAUTHORITY.

Debian Consultant @ DEBAMAX

• Utiliser des clés SSH revient à restreindre à des clés données, puisqu'elles doivent être déclarées explicitement (authorized_keys).
• Désactiver les mots de passe est une très bonne idée (et en fonction des distributions/versions c'est le cas par défaut) mais ne change rien au bruit dans les logs.
• Utiliser AllowUsers/AllowGroups peut être un bon complément (et à nouveau aucun impact sur le bruit dans les logs).
• Changer le port de connexion peut limiter le bruit mais le bruteforce peut être tenté sur n'importe quel port…
• Limiter l'accès au port du serveur SSH via le firewall peut être une option, mais cela peut être embêtant si on n'a pas d'IP fixe depuis laquelle se connecter.
• Implémenter du port-knocking peut compléter le point précédent. Par exemple : depuis chez moi ou depuis les autres serveurs que j'administre, je peux me connecter en direct à certaines machines, mais si je suis « on the go », il faut envoyer la bonne séquence de paquets pour faire ouvrir le port SSH pour cette IP, de manière temporaire (attention aux limitations de certains réseaux, e.g. UDP vs. Wi-Fi TGV).
• Enfin, ne pas exposer du tout le service SSH sur internet permet de s'épargner tout ce bruit. Cela peut être implémenté en le rendant accessible uniquement au travers d'un VPN, cf. modèle du fromage suisse.
• Bonus : CrowdSec et son firewall bouncer permettent de bloquer des IPs en avance de phase (par rapport à fail2ban qui est uniquement réactif), grâce aux listes de blocage construites avec la communauté.

Debian Consultant @ DEBAMAX

Je ne suis pas sûr de comprendre le point sur les images d'installation Debian. Elles supportent le démarrage en UEFI et en BIOS (aka. Legacy, CSM, etc.).

Debian Consultant @ DEBAMAX

Je mets une petite pièce sur partition pleine, la machine arrive à démarrer parce qu'il reste un peu d'espace réservé pour root (potentiellement avec quelques services en erreur), mais l'ouverture de session ne fonctionne pas dès lors qu'il y a quelques écritures dans des fichiers qui ne sont pas faites en tant que root ? Historiquement, l'erreur ENOSPC est très mal gérée par les applications (i.e. souvent pas du tout), ce qui donne une expérience lamentable.

Debian Consultant @ DEBAMAX

https://git.dotclear.org/dev/dotclear/issues/649

Debian Consultant @ DEBAMAX

Je ne vois pas le rapport avec la demande initiale. Ni avec ma proposition de ne pas utiliser une unité qui ne fait rien, reste en vie pendant toute la vie du système, avant de lancer des actions lorsqu'elle est stoppée (ce qui n'est pas nécessairement lors de l'arrêt/redémarrage, une typo lors d'un appel kill est si vite arrivée).

Quoi qu'il en soit, s'il y a des dépendances et/ou un ordre à exprimer, la section [Unit] est faite pour cela, comme d'habitude.

Debian Consultant @ DEBAMAX

Et si on inversait la logique inversée pour la (re)mettre à l'endroit ? J'ai des choses comme ça localement :

[Unit]
Description=<redacted>
Documentation=<redacted>
Before=systemd-poweroff.service
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/usr/sbin/one-thing
ExecStart=/usr/sbin/another-one-if-needed

[Install]
WantedBy=poweroff.target

et :

[Unit]
Description=<redacted>
Documentation=<redacted>
Before=systemd-reboot.service
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/usr/sbin/yet-another-thing

[Install]
WantedBy=reboot.target

Debian Consultant @ DEBAMAX

Tout à fait d'accord avec toi concernant l'aspect « dernier log affiché », cela me semble impossible de conclure quoi que ce soit de ça uniquement.

À tout hasard, enlever quiet, potentiellement ajouter debug, sur la ligne de commande du noyau, pour avoir plus d'infos.

Debian Consultant @ DEBAMAX