Cyril Brulebois a écrit 670 commentaires

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

1) Les détails linguistiques sont donnés dans le premier paragraphe de « 3.4 Shell Parameters », non ? Cf. également POSIX, qui utilise le même vocabulaire.

2) C'est incomplet, on ne fait pas que modifier au besoin la variable en question. La valeur est également remplacée. Tu peux t'en convaincre en remplaçant : par echo.

Quant à :, à l'extérieur des accolades, c'est un no-op, cf. bash-builtins(7) :

       : [arguments]
              No effect; the command does nothing beyond expanding arguments and performing  any  specified  redirec‐
              tions.  The return status is zero.

3) À l'intérieur des accolades, il ne s'agit pas d'un : unitaire, mais de :-, :=, :+, etc., il s'agit donc d'une partie d'un séparateur entre la variable à gauche et des trucs plus sophistiqués à droite. Bien évidemment, le fait que dans l'exemple donné pour :-, la syntaxe utilisée est… celle d'une autre opération n'aide pas.

Le tableau côté POSIX donne les subtilités, mais en résumé pour ces deux opérations :

kibi@tokyo:~$ a=; echo ${a-123}

kibi@tokyo:~$ unset a; echo ${a-123}
123

vs.

kibi@tokyo:~$ a=; echo ${a:-123}
123
kibi@tokyo:~$ unset a; echo ${a-123}
123

Je ne pense pas qu'il y ait de différences fondamentales entre les deux syntaxes d'export… Jouons avec deux variables au lieu d'une :

kibi@tokyo:~$ unset A; unset B; export A=${B:-"$HOME/.config"}; echo $A; echo $B
/home/kibi/.config

kibi@tokyo:~$ unset A; unset B; export A=${B:="$HOME/.config"}; echo $A; echo $B
/home/kibi/.config
/home/kibi/.config

Mais comme dans ton cas il s'agit d'une seule et même variable…

Debian Consultant @ DEBAMAX

Les DTBs ne sont pas remontées dans le noyau mainline par l'équipe Raspberry, les overlays non plus.

(Ce qui ne veut pas dire que le mécanisme d'overlay activable via le paramètre dtoverlay= ne fonctionne pas avec le noyau mainline, comme on le lit très souvent. J'utilise cela sur des produits depuis de nombreuses années.)

Debian Consultant @ DEBAMAX

Tu pourrais faire des captures d'écran de ton firmware, les points intéressants étant les éventuels modes de compatibilité BIOS, Legacy, CSM (que je désactiverais) et l'éventuelle priorité des disques. Vu la configuration évoquée, UEFI-only, avec Secure Boot activé, serait la bonne configuration.

Indépendamment de cela, tu pourrais nous montrer le contenu de la partition ESP (montée sous /boot/efi) et éventuellement effacer les traces de Windows Boot Manager à coup d'efibootmgr. Mais je ne pense pas que ces dernières soient en lien avec l'entêtement à essayer de démarrer sur l'autre disque… Après, ça reste un firmware et tout est possible, tout est imaginable…

Debian Consultant @ DEBAMAX

Dans ce contexte, il s'agit de python3-gi (introspection pour GObject). Il faut d'autres paquets de ce type, cf. mon autre réponse et le fichier debian/control dans le dépôt.

Debian Consultant @ DEBAMAX

Une fois n'est pas coutume, je me permets de répondre légèrement à côté. En vérifiant si le paquet était disponible dans unstable (ce qui peut mettre le pied à l'étrier, en envisageant un backport vers stable), j'ai noté un screenkey qui se dit inspiré de key-mon.

Pour revenir à la question initiale, la doc mentionne pip (pip3 dans Debian) et easy_install, qui sont des solutions classiques pour déployer du Python sans utiliser de paquets. Il existe également venv. Cependant, en regardant les dépendances documentées, pas de choses incroyables, tout est disponible dans Debian et on peut imaginer soit faire une compilation locale, soit improviser un paquet… Or il y a déjà tout ce qu'il faut dans le dépôt : un répertoire debian/ et les différents fichiers nécessaires pour préparer un paquet. Je n'ai pas regardé le contenu en détail, mais un dpkg-buildpackage -b et un sudo dpkg -i plus tard, j'ai un key-mon qui tourne sur une Debian oldstable. Je n'ai pas trop de doute que cela fonctionne aussi sur Debian stable.

Debian Consultant @ DEBAMAX

Que donnent ip l et sudo iwlist scan ?

En fonction de ça, ne pas garder pour toi les logs noyau pourrait être une bonne idée.

Debian Consultant @ DEBAMAX

Buster c'est 4 ans avant Bookworm, la première version concernée.

Debian Consultant @ DEBAMAX