Cyril Brulebois a écrit 657 commentaires

C'est pour moi la référence incontournable, fournissant à la fois une CLI (mmcli) et une interface D-Bus.

Je me suis plutôt concentré sur la partie connexion de données, mais la messagerie semble être accessible également, cf. mmcli --help-messaging, comme la voix, cf. mmcli --help-voice, ou les SMS, cf. mmcli --help-sms. On notera au passage une certaine cohérence dans les options proposées…

Debian Consultant @ DEBAMAX

Archéologie dans systemd.git, recherche sur TimeoutStopSec= :

commit d568a3350ee8a45877eef87cd026a954124e2cf8
Author: Michal Sekletár <msekleta@redhat.com>
Date:   Tue Aug 7 14:41:48 2012 +0200

    systemd: introduced new timeout types

    Makes possible to specify separate timeout for start and stop of
    the service.

    [ Improved the manpage. Coding style fix. -- michich ]

2012

Debian Consultant @ DEBAMAX

Le forwarding est lié au fait que mon serveur est aussi un pare-feu (configuré avec netfilter et règles iptables) et je souhaite donc que ce serveur soit ma gateway (actuellement le cas), et que ce soit par l'occasion lui qui fasse office de serveur DNS pour interroger les root DNS et top level domains…

OK, donc aucun rapport avec le sujet initial.

Navré mais je ne comprends pas ce que tu veux dire quand tu dis que /etc/resolv.conf pointe vers dsnmasq est compliqué? Comment, en quoi?

Si dnsmasq utilise /etc/resolv.conf pour savoir à qui poser les questions, et si /etc/resolv.conf pointe vers dnsmasq, ça s'appelle une boucle (aka. « problème de bootstrap », voir également « poule vs. œuf »). L'option log-queries de dnsmasq est très pertinente pour vérifier le comportement côté DNS.

Je n'ai pas besoin de service DHCP car j'ai une ip fixe pour savoir paramétrer mon serveur avec Putty.

La précision sur mon utilisation de dnsmasq n'avait pas pour vocation à attirer l'attention sur DHCP, mais sur l'aspect « je pose les questions DNS à d'autres machines »…

je réitère donc ma question de savoir comment paramétrer un serveur DNS (peu importe le programme) sur mon Raspberry qui se chargera de toutes les requêtes.

J'ai répondu à cette question…

Aussi, je voudrais savoir comment le sécuriser et où se trouvent les logs pour les effacer si besoin.

La réponse habituelle (pour les deux composants mentionnés) est journalctl, sauf configuration contraire.

Debian Consultant @ DEBAMAX

Dans le désordre :

• Je ne vois pas à quoi servirait le forwarding/masquerading.
• dnsmasq s'appuie sur un ou plusieurs serveurs « upstream » qui vont répondre à ses questions, et si /etc/resolv.conf pointe vers dnsmasq, ça me semble compliqué… (localement, j'ai un dnsmasq qui fournit DHCP+DNS pour un sous-réseau, le tout sur une machine qui pointe vers un unbound d'une autre machine + la box du FAI en fallback).

Quelques possibilités :

• Faire pointer dnsmasq vers le DNS de la box/du datacenter.
• Utiliser unbound pour la résolution DNS, ce qui a le mérite d'éviter les réponses foireuses des DNS menteurs (cf. « la main rouge »).

La seconde solution… est autosuffisante (pas besoin de dnsmasq).

Debian Consultant @ DEBAMAX

Ça fait plusieurs années que j'utilise mbsync pour maintenir une copie locale de mes boîtes IMAP (que je consulte avec mutt), avec une grande satisfaction.

Je l'ai également utilisé pour la migration Gandi → Infomaniak de plusieurs comptes, en ayant :

• pull depuis Gandi ;
• pull depuis + push vers Infomaniak.

Et enfin je l'utilise pour synchroniser localement (puis sauvegarder) des comptes qui ne sont pas les miens.

Pour ce qui est du quota quotidien, ça peut être pénible si on est pressé, mais si tu t'y prends un peu à l'avance, tu peux faire des synchronisations incrémentales, ça ne devrait poser aucun problème ? La première s'arrête avec une erreur une fois le quota dépassé, le lendemain tu peux en lancer une second, qui reprend avec le reste à faire ?

Jamais joué avec OAuth cependant.

Debian Consultant @ DEBAMAX

+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