Cyril Brulebois a écrit 652 commentaires

Ça fait des années que certaines configurations globales sont déployées sous /usr. Quelques exemples :

• /usr/share/fontconfig/conf.avail/10-autohint.conf
• /usr/share/X11/xorg.conf.d/40-libinput.conf
• /usr/share/X11/xorg.conf.d/70-wacom.conf

Et il est possible de changer du comportement par défaut en créant/modifiant/adaptant ces fichiers sous /etc en tant qu'admin local.

C'est exactement la même chose avec les configurations systemd et udev, les règles par défaut sont catapultées sous (/usr)/lib/{systemd,udev} et les admins locaux peuvent adapter sous /etc.

Pour l'aspect « textuel » d'/etc, je vois des zip, des clés publiques/privées (SSH, X.509), des trousseaux GPG, et des choses vraiment binaires comme /etc/ld.so.cache ou du Berkeley DB pour les fichiers de postfix. J'ai un peu la flemme de sortir les vieilles sources d'UNIX pour voir à quel point ce « Editable Text Configuration » est un backronym, mais au moins la page wikipedia FHS suggère qu'il y a débat… :)

Debian Consultant @ DEBAMAX

Vu d'ici, la différence i386 vs. amd64 devrait être absolument sans rapport.

Je soupçonne plutôt l'existence ou l'absence d'un fichier, lien, autre, quelque part, que ça soit une vieille règle udev ou quelque chose de similaire, qui a pu provoquer ce souci. Vu le nommage « moderne » que tu avais avant la mise à jour, j'imagine que tu n'avais pas de net.ifnames qui traîne…

En regardant la page de wiki NetworkInterfaceNames j'imagine que tu as pu avoir un 70-persistent-net.rules… mais si c'est bien ça, pourquoi est-il ignoré avant la mise à jour ?

Il y a peut-être la réponse dans tes logs. :)

Debian Consultant @ DEBAMAX

Tu aurais les logs de la mise à jour ? Typiquement, sous /var/log/apt/, fichiers term.log*.

J'ai du mal à voir comment l'installation d'un noyau a pu « oublier » de déployer vmlinuz & friends dans /boot, surtout sans laisser de message d'erreur explicite, et un statut « pas content » au niveau dpkg… ENOSPC chemin faisant ?

Note que les deux commandes apt-get et apt gère la commande reinstall (pour install --reins(in)tall). ;)

Debian Consultant @ DEBAMAX

Au passage, attention à /proc/sysrq-trigger.

Debian Consultant @ DEBAMAX

À tout hasard, la pagination (via more, less, most, etc. ou bien un pager interne à systemctl) a été activée pour une raison ou pour une autre, et il suffit de faire q (ou équivalent en fonction de l'outil) pour en sortir ?

Debian Consultant @ DEBAMAX

Mon premier réflexe serait de vérifier si la box-bidule propose des baux statiques. 1 MAC = 1 IP (× 2) et hop ? C'est le genre de réglage qui ne devrait pas facilement sauter lors d'une mise à jour future de la box, ça ferait une manip one-shot ?

Debian Consultant @ DEBAMAX

Tu as des mécanismes en place pour empêcher les pisteurs de remonter tout plein d'infos sur ton téléphone, ta navigation, etc. chez les data brokers ? Tu peux choisir d'interdire la localisation précise, l'accès à tes contacts, le fait de passer un coup de fil, etc. et l'application fonctionne quand même ?

Debian Consultant @ DEBAMAX

Ça se passe comment dans cet environnement, pour tout ce qui est pisteurs/permissions ?

Le rapport d'Exodus Privacy m'inciterait bien à ne jamais songer à installer une telle application sur mon téléphone, quel que soit l'environnement. (J'ai fait le tour des applis des grands groupes bancaires français il y a quelques temps, c'est le même niveau d'indécence environ partout.)

Debian Consultant @ DEBAMAX

C'est comme les rapports de bogue, c'est plus simple si on est complet dès le début… préciser la banque ne coûterait pas trop cher et ça éviterait de jouer aux devinettes.

Je serais toi, je me renseignerais sur le lecteur CAP qui est probablement un lecteur de carte à puce (chez CE) ou le lecteur PASS CyberPlus (chez BP). Chez CM/CIC j'ai opté pour le boîtier DIGIPASS pour éviter d'avoir à utiliser la moindre application (modulo 29 € à l'acquisition).

Debian Consultant @ DEBAMAX

J'ai l'impression qu'il y a une grosse confusion.

Pour commencer, à propos du « si c'est possible » : À ma connaissance, sur architecture PC, une machine estampillée Windows 8 doit pouvoir laisser la possibilité de désactiver Secure Boot et/ou d'enrôler une MOK (Machine Owner Key).

Quant à « OS signé par Microsoft » c'est un beaucoup trop gros raccourci. Il faut que le chargeur de démarrage soit signé par une autorité de confiance, c'est très différent d'un système d'exploitation complet. On trouve souvent le composant shim qui fait effectivement un tour pour se faire tamponner cryptographiquement, mais le reste peut être signé par d'autres clés (par exemple Debian Secure Boot CA). Cela inclut (mais n'est pas limité à) : GRUB, le noyau Linux, fwupd, etc. Des modules complémentaires (module patché, module propriétaire nvidia, etc.) peuvent être signés par l'administrateur local grâce à la MOK, qu'il conviendra d'enrôler dans le firmware (cf. mokutil).

Debian Consultant @ DEBAMAX

Sur tout un tas de distributions, dont je pense Kubuntu, Secure Boot ne devrait pas poser de problème, tu peux donc le laisser activé.

Si tu démarres avec Secure Boot activé, ça sous-entend démarrer en mode UEFI (plutôt que BIOS = Legacy = CSM…), et ça veut dire avoir une partition ESP (EFI System Partition) sur le système déployé. Le système d'installation de ta distribution devrait faire le boulot pour toi.

Debian Consultant @ DEBAMAX

Cf. logrotate(8) :

maxsize size

Log files are rotated when they grow bigger than size bytes even
before  the additionally specified time interval (daily, weekly,
monthly, or yearly).  The related size option is similar  except
that  it  is  mutually exclusive with the time interval options,
and it causes log files to be rotated  without  regard  for  the
last  rotation  time,  if specified after the time criteria (the
last specified option takes the precedence).   When  maxsize  is
used, both the size and timestamp of a log file are considered.

Debian Consultant @ DEBAMAX

À tout hasard, si la piste Secure Boot se confirme (bootctl peut aider, indépendamment de vboxconfig), un coup de MOK + signature des modules out of tree ?

Debian Consultant @ DEBAMAX

Sous Thunar 4.16.8 (Debian bullseye), j'ai un View > Side Pane > Shortcuts (Ctrl+B) qui semble commander la disparition/la réapparition de ladite barre latérale. Au hasard, le problème est apparu après un Ctrl+V qui aurait dérapé ? :)

Debian Consultant @ DEBAMAX

Sinon, pour la détection, mettre les infos %b/%B en regard de %s via stat peut être une idée, mais je ne suis pas sûr de comprendre l'intérêt de courir après ces fichiers en particulier.

Édition : j'ai tendance à utiliser indifféremment l'un ou l'autre pour préallouer des fichiers, mais fallocate est un outil bien plus complet que truncate.

Debian Consultant @ DEBAMAX

Extrait de la page de manuel de truncate :

NAME
       truncate - shrink or extend the size of a file to the specified size

SYNOPSIS
       truncate OPTION... FILE...

DESCRIPTION
       Shrink or extend the size of each FILE to the specified size

       A FILE argument that does not exist is created.

       If  a  FILE  is larger than the specified size, the extra data is lost.
       If a FILE is shorter, it is  extended  and  the  sparse  extended  part
       (hole) reads as zero bytes.

Exemple :

kibi@tokyo:~$ truncate -s 1T toto
kibi@tokyo:~$ ls -l toto
-rw-r--r-- 1 kibi kibi 1099511627776 Jun  4 20:25 toto
kibi@tokyo:~$ du -h toto
0   toto

Voire aussi l'option --sparse de rsync, ou les outils qui manipulent des images disque (au sens qemu-img), avec lesquels ça peut être une bonne idée de ne pas prendre de la place si on n'en a pas (encore) besoin.

Je ne sais pas trop pourquoi tu n'es pas content des « pages wiki habituel[le]s », mais après l'avoir seulement survolée, https://wiki.archlinux.org/title/Sparse_file semble intéressante, tout comme https://en.wikipedia.org/wiki/Sparse_file qui est en lien à la fin…

Debian Consultant @ DEBAMAX

Je pense que ça dépend beaucoup de l'implémentation au niveau du firmware UEFI.

Vu récemment sur une permanence LUG, un système qui disait oui-oui à toute modification des paramètres via efibootmgr, mais qui s'obstinait à chaque fois à démarrer Windows, quelle que soit la configuration spécifiée. Sur une install party, j'ai également vu des firmwares qui se vautraient avec des erreurs mémoire quand on essayait de manipuler les entrées, par exemple pour… les afficher ! (Genre efibootmgr était OK mais efibootmgr -v explosait dans tous les sens.)

Voir également le besoin assez classique d'utiliser l'astuce du removable media path.

Bref, sur le papier, ça pourrait être une excellente piste. Dans la réalité, les implémentations sont… tout autant plein de bogues que l'étaient les BIOS historiques. :(

Debian Consultant @ DEBAMAX

Oh, je crois reconnaître un client CM/CIC avec un Digipass ? :)

Debian Consultant @ DEBAMAX

Dans le paquet source lvm2, je vois ceci :

        # Example
        # Accept every block device:
        # filter = [ "a|.*|" ]
        # Reject the cdrom drive:
        # filter = [ "r|/dev/cdrom|" ]
        # Work with just loopback devices, e.g. for testing:
        # filter = [ "a|loop|", "r|.*|" ]
        # Accept all loop devices and ide drives except hdc:
        # filter = [ "a|loop|", "r|/dev/hdc|", "a|/dev/ide|", "r|.*|" ]
        # Use anchors to be very specific:
        # filter = [ "a|^/dev/hda8$|", "r|.*|" ]

Debian Consultant @ DEBAMAX

Node-RED permet notamment de programmer visuellement des (ro)bots, et probablement d'autres choses…

Debian Consultant @ DEBAMAX

J'ai joué avec ce genre de choses lorsque j'ai piloté une migration chez un client, impliquant de transformer du stockage sur LVM.

Rapide digression, tu parles de LV, mais je vais évoquer ce que j'ai déjà fait pour des PV, histoire de démontrer ce qu'on peut faire avec ce fichier de configuration…

Il était question de s'assurer que certains périphériques de type bloc ne s'activent pas automatiquement, ce qui fut implémenté via :

sed "/devices {/aglobal_filter = [ \"r|/dev/mapper/loop.*|\" ]" -i.bak /etc/lvm/lvm.conf

Autrement dit, dans la section ouverte par devices {, ajouter une ligne :

    global_filter = [ "r|/dev/mapper/loop.*|" ]

tout en conservant le fichier original en tant que /etc/lvm/lvm.conf.

En regardant mon /etc/lvm/lvm.conf généré automatiquement par une installation Debian en mode encrypted LVM, je note qu'il y a une section activation, avec plein de réglages possibles mentionnés en commentaires, dont volume_list, auto_activation_volume_list, read_only_volume_list. D'après une lecture rapide, pas de mécanisme d'exclusion, mais ça devrait te permettre de faire ce que tu souhaites ?

Debian Consultant @ DEBAMAX

Ce soft est packagé e.g. dans Debian depuis longtemps (jamais utilisé cependant donc je ne peux pas t'en dire plus…) → https://github.com/projecthamster/hamster

Debian Consultant @ DEBAMAX

Je vois le même SIGSEGV sur bullseye :

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e7fffc in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
(gdb) bt
#0  0x00007ffff7e7fffc in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#1  0x000055555555565e in close ()
#2  0x00007ffff7038bd4 in _dbus_close () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3  0x00007ffff7036bef in _dbus_file_get_contents () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4  0x00007ffff7032fb1 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#5  0x00007ffff703a2ff in _dbus_read_local_machine_uuid () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#6  0x00007ffff70331e7 in _dbus_get_local_machine_uuid_encoded () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#7  0x00007ffff70276bf in dbus_try_get_local_machine_id () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#8  0x00007ffff7027774 in dbus_get_local_machine_id () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#9  0x00007ffff7f228ed in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x00007ffff7f2301b in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x00007ffff7f2251f in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#12 0x00007ffff7f073ff in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#13 0x00007ffff7f0e467 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#14 0x00007ffff7ee8db3 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#15 0x00007ffff7e41f47 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#16 0x00005555555553e9 in init ()
#17 0x0000555555555703 in main ()

et une fois que le close() du fichier principal est renommé en autre chose, ça se passe beaucoup mieux. Sans cela, on a :

kibi@tokyo:/tmp$ gcc -O0 foo.c  -lSDL2 -lSDL2_image -lSDL2_ttf && nm -D a.out | grep close
0000000000001646 T close

et le symbole close est défini dans l'exécutable. close étant (également) un appel système fréquemment utilisé (plus haut, dans libdbus), boum.

Debian Consultant @ DEBAMAX

Référence de l'offre

Contrat : Mission temporaire
Durée : 24 mois
Début du contrat : Dès que possible
Rémunération : 2033 à 2441 euros brut mensuel
N° de l'offre : OT-11487
Date limite : 17/05/2021

Debian Consultant @ DEBAMAX

Tout d'abord, merci pour le résumé des nouveautés dans GnuPG, monde… compliqué s'il en est.

Est-ce que la génération de sommaire se dit qu'il doit exister du h1/# parce qu'il y a du h2/##, ce qui expliquerait la puce supplémentaire (avec un retrait plus important) dans la liste ?

Debian Consultant @ DEBAMAX