Cyril Brulebois a écrit 612 commentaires

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

Étant donné que compilation et édition de liens sont découplées ici, il faut penser à indiquer testLib.o sur la dernière ligne.

Alternativement, ceci fait le job en une passe :

gcc useTestLib.c -o useTestLib -ltestLib -L.
LD_LIBRARY_PATH=$(pwd) ./useTestLib

Debian Consultant @ DEBAMAX

Ça en fait deux. ;p

(Une) version Perl : perl -ne 'print "$1\n" if /EPSON .* id=(\d+)/'

Debian Consultant @ DEBAMAX

Les deux domaines que j'ai migrés jusqu'à présent (un .fr et un .com) l'ont effectivement été en payant une année, qui s'est ajoutée à la date d'expiration précédente (sur une migration Gandi → Infomaniak). Je me garderais bien d'en tirer une quelconque conclusion définitive cependant, c'est mon tout premier changement…

Debian Consultant @ DEBAMAX

Si tu gardes Gandi comme registrar, j'imagine que c'est (aussi) pour conserver la partie DNS chez eux aussi, donc pas de bascule vers un DNS externe nécessaire pour juste avoir les mails ailleurs, non ?

Dans les choses qu'il faut s'attendre à paramétrer, il y a bien sûr le(s) enregistrements MX (Mail eXchangers), les éventuels champs pour SPF/DKIM/DMARC, mais la partie NS ne devrait pas bouger si tu continues à gérer la zone chez Gandi.

Debian Consultant @ DEBAMAX

Avertissement : Je ne connais rien à Manjaro.

Cependant, deux cas probables selon moi :

• Secure Boot est activé, et il y a un problème avec l'utilisation d'une clé de signature « MOK » (Machine Owner Key) pour signer les modules compilés localement.
• Indépendamment du premier point, il peut y avoir un problème de compilation locale des modules.

Dans le second cas :

• Les modules pourraient ne pas avoir été compilés du tout, soit parce que leur code n'est pas compatible avec la version du noyau, soit parce que le système d'automatisation n'a pas fait son boulot. Je m'attendrais à ENOENT plutôt qu'à ENOEXEC si les modules étaient complètement absents, mais j'ai déjà vu des cas d'erreur en espace utilisateur où il pouvait y avoir confusion entre ces deux codes d'erreur.
• Le système de compilation pourrait ne pas avoir (re)compilé les modules pour une nouvelle version de noyau, ce qui pourrait donner une tentative d'utiliser des vieux modules avec un nouveau noyau… ce qui est souvent une très mauvaise idée si on n'a pas de garantie de compatibilité binaire.

Pistes :

• Vérification de l'existence ou non des modules.
• Comparaison de leur date de modification vs. date d'installation du noyau.
• Surveillance de la sortie de dmesg.
• Tentative de chargement manuel des modules via modprobe (et point précédent).

Debian Consultant @ DEBAMAX

Je ne suis pas sûr de comprendre la contrainte sur le navigateur qui ne fait que GET et POST. Pour faire du REST (complet) depuis un navigateur, des greffons comme RESTED existent, et offrent toute la panoplie ?

Debian Consultant @ DEBAMAX

Merci pour tes efforts de reformatage mais attention :

• ${symbol} (permutation des deux premiers caractères) ;
• ${LENGHT} (manque le dollar) — dont ça n'est pas l'orthographe au passage.

Je ne comprends pas le problème de gzgtrhe :

1. Que signifie « ne passe pas » ?
2. Le code en dehors de la fonction utilise tr --delete, le code dans la fonction utilise tr --delete --complement.

Alors oui, si on passe en paramètre [:space:], on demande à supprimer tout ce qui n'est pas espace, et il reste des espaces. Et retour au premier point.

Debian Consultant @ DEBAMAX

Certains paquets peuvent être marqués comme étant Multi-Arch: allowed, Multi-Arch: foreign ou Multi-Arch: same, ce qui permet en fonction des cas d'installer libfoo42:amd64 et libfoo42:arm64 sur un même système en même temps, tandis que dans d'autres cas, c'est l'un ou l'autre. Si tu compares abiword et le plugin, tu verras que le premier n'a pas ce champ, tandis que le second a Multi-Arch: same, d'où l'indication supplémentaire concernant l'architecture. On parle alors d'arch-qualified package name.

Debian Consultant @ DEBAMAX