Cyril Brulebois a écrit 670 commentaires

Il semblerait qu'exiftool puisse faire le boulot, en cherchant Title dans la sortie, mais seulement si on a mis un titre explicitement dans les métadonnées du document… (Je n'arrivais pas à vérifier le bon fonctionnement localement parce que je ne prends jamais la peine de le faire.)

Debian Consultant @ DEBAMAX

Tu as tout à fait raison pour la récupération automatique du titre pour les PDF, cf. file_rename_pdf() dans le fichier src/file_pdf.c des sources de testdisk → https://sources.debian.org/src/testdisk/7.1-5/src/file_pdf.c/#L65

Les fichiers opendocument (au sens large) semblent gérés via src/file_zip.c, qui ne semble que positionner la bonne extension en fonction du type MIME (d'après une lecture rapide du fichier) → https://sources.debian.org/src/testdisk/7.1-5/src/file_zip.c/

Je suppose que le plus efficace serait de reprendre les fichiers *.odt, *.ods, etc. sauvés par photorec et les analyser après coup pour essayer de retrouver les métadonnées à l'intérieur et les exploiter pour faire un renommage ?

Debian Consultant @ DEBAMAX

C'est mégachelou… (mais c'est exact).

Si les paquets s'appellent libcurl3 et libcurl4, c'est justement pour qu'il soit possible pour certains paquets de dépendre d'une version, et pour d'autres, de l'autre… Mais visiblement, la transition compliquée du côté d'OpenSSL (1.0 vs. 1.1) a été accompagnée de joyeusetés, ce qui explique ton problème pour ce cas particulier de bibliothèques (dans le cas général, on ne colle pas de Conflicts, Replaces, ou Breaks entre les différentes « versions »)… :/

Debian Consultant @ DEBAMAX

Ça ne répond pas directement à ta question, mais je crois que je commencerais par essayer de maximiser mes chances d'obtenir d'éventuelles traces lors de l'extinction. Si c'est quelque chose qui déclenche un OOPS noyau puis le redémarrage, ça a peu de chance d'arriver sur le disque, mais il peut y avoir une possibilité de l'attraper en utilisant netconsole. En fonction de si le noyau récupère un événement lié à une éventuelle perte d'énergie, avant que tout s'éteigne, ça pourrait également laisser une trace dans les logs…

Debian Consultant @ DEBAMAX

Dur à dire sans voir l'erreur d'ao_play, ou sans lui coller un coup de strace avec les paramètres qui vont bien, mais je soupçonne une connexion à pulseaudio qui fonctionne quand tu es en local, mais pas quand tu es en distant ? J'ai eu des blagues un peu différentes mais qui pourraient avoir un lien… (<full-disclosure>en essayant de faire tourner un Firefox dans un chroot pour avoir une version plus récente, Firefox depuis lequel je voulais récupérer la sortie son pour suivre les matches de basket</full-disclosure>).

En regardant rapidement mon alias pour démarrer ce Firefox chrooté, et si je me souviens bien, j'ai activé le mode TCP de pulseaudio :

/etc/pulse/default.pa:load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1 listen=127.0.0.1

et je positionne une variable d'environnement pour éviter que Firefox essaie d'utiliser la socket UNIX : PULSE_SERVER=127.0.0.1.

En fonction des erreurs/blocages de ton côté, ça peut n'avoir aucun rapport ou bien être une piste. Je te laisse nous tenir au courant… ;)

Debian Consultant @ DEBAMAX

Voir aussi la configurabilité du comportement noyau en cas d'accès non aligné, sur certaines plateformes (ARM) → https://www.kernel.org/doc/html/latest/arm/mem_alignment.html

Debian Consultant @ DEBAMAX

La taille d'un tableau statique doit être connue à la compilation, donc ça ne peut pas dépendre d'un paramètre qui pourrait varier d'un appel à l'autre.

C'est plutôt malloc (ou autre technique assimilée) que l'on utilisera pour gérer un tableau de taille variable.

Debian Consultant @ DEBAMAX

Depuis ce week-end il est possible d'utiliser un Raspberry Pi CM3 (et même CM3+) avec Debian Buster sans avoir à craindre de problème de DTB manquante. Rigolo, le timing du sondage, j'ai publié quelques détails sur la démarche, en anglais et en début de semaine : Adding Raspberry Pi CM3 support to Debian Buster.

Debian Consultant @ DEBAMAX

Dans le cas LVM chiffré, la partition /boot est à part, et n'est pas chiffrée (ça n'est pas spécifique à Buster, c'est une limitation historique qu'on pourrait imaginer lever dans Debian Installer…).

J'ai donné quelques détails dans une présentation à la Mini-DebConf Hamburg 2019.

Debian Consultant @ DEBAMAX

C'est documenté dans les notes de publication de Buster, LUKS2 est effectivement le format par défaut à partir de Buster, et ça n'était pas connu dans Stretch, d'où ton problème. Comme tu l'as noté, c'est bien --type luks1 qui va te permettre de (re)basculer sur le format historique. Tu aurais pu également imaginer installer un backport de cryptsetup dans Stretch, mais il n'y en a pas de disponible pour ce paquet…

Debian Consultant @ DEBAMAX

J'y vois aussi l'occasion de contribuer des patches, même si j'ai dû prioriser les clients et les préparatifs pour la première point release de Buster. ;)

Debian Consultant @ DEBAMAX

Oh, bravo.

(Ma « fonctionnalité préférée » pour les raccourcis restera probablement le fait de ne pas pouvoir désaffecter F1, d'où l'aide qui surgit une fois sur deux quand je tente un F2 pour changer une formule…)

Debian Consultant @ DEBAMAX

Il dit qu'il ne voit pas le rapport avec le pavé numérique : sur une disposition azerty standard, taper Ctrl+Shift+&/1 ça donne Ctrl+1 ; Ctrl+shift+é/2 donne Ctrl+2, etc.

Debian Consultant @ DEBAMAX

Tiens, ça ressemble assez à ce que j'utilise : zim.

Debian Consultant @ DEBAMAX

Parce que DURATION n'est pas facultatif quand tu appelles timeout :

timeout [OPTION] DURATION COMMAND [ARG]...

Si tu enlèves les redirections, tu verras l'erreur :

kibi@armor:~$ timeout --kill-after=5 openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org
timeout: invalid time interval ‘openssl’
Try 'timeout --help' for more information.

… ce qui explique que la commande de l'autre côté du pipe se plaigne. Au passage, tu pourrais t'épargner -in /dev/stdin.

Debian Consultant @ DEBAMAX

Cf. les options -s et -k ? Le signal par défaut peut avoir été ignoré, du coup c'est comme si timeout n'avait rien fait ?

Debian Consultant @ DEBAMAX

Au hasard, les variables disparaissent dès qu'on sort du bloc ${execp …} ? Du coup ton test « fonctionne » parce que tu compares deux chaînes vides, mais il n'y a rien à afficher ?

Debian Consultant @ DEBAMAX

Si tu veux imbriquer des guillemets, il faut protéger ceux qui sont à l'intérieur. Ou plus simplement, utiliser des apostrophes autour…

kibi@armor:~$ bash -c 'if [[ "1" = "1" ]]; then echo "plop"; else echo "not good"; fi'
plop
kibi@armor:~$ bash -c "if [[ \"1\" = \"1\" ]]; then echo \"plop\"; else echo \"not good\"; fi"
plop

Debian Consultant @ DEBAMAX

Et c'est encore mieux après un café… C'est la même chose avec [[ … ]] :

kibi@armor:~$ dash 
$ if [[ "1" = "1" ]]; then echo "plop"; else echo "not good"; fi 
dash: 1: [[: not found
not good

Debian Consultant @ DEBAMAX

Il se passe quoi si tu changes == en = ? Le premier n'est pas standard, le second si. Si ton shell système n'est pas bash mais par exemple dash, ça peut expliquer que le test renvoie une erreur…

Debian Consultant @ DEBAMAX

Cela semble fonctionner mais uniquement sur certaines variables exposées par Puppet. Un grep rapide dans la configuration Puppet utilisée pour l'infrastructure Debian (dsa-puppet.git) donne ces couples occurrence/variable :

      1 confdir
      1 environment
      1 environmentpath
      1 libdir
      1 server
      2 ca
      2 cadir
      3 ca_name
      3 default_file_terminus
      3 hostcrl
      3 localcacert
      4 cacrl
      4 modulepath
      6 cacert
      7 vardir

Cela ressemble beaucoup à ce qu'on peut configurer dans /etc/puppet/puppet.conf !

Dans le cas ldapserver, on pourrait se poser la question d'une éventuelle variable « sortie du chapeau », mais c'est également défini dans Puppet. Dans 4.8.2 que j'ai sous la main, c'est via un appel define_settings dans lib/puppet/defaults.rb.

(Et si on se pose la question de tricher en ajoutant un test = youhou dans la section [agent] de la configuration Puppet, ça semble être ignoré.)

Debian Consultant @ DEBAMAX

Un problème de droits sur un ou plusieurs fichiers/répertoires ? Ce serait plutôt simple à corriger, plutôt qu'un éventuel de système de fichiers/disques… Les « I/O errors », ça fait toujours un peu peur…

Voir aussi :

--ignore-errors
        Tells --delete to go ahead and delete files even when there are I/O errors.

Debian Consultant @ DEBAMAX

Tu as des messages d'erreurs à nous indiquer ?

Je ne vois pas du tout pourquoi rsync aurait des problèmes avec des noms de fichiers contenant des espaces. Exemple en local :

$ mkdir foo "bar baz"
$ for i in $(seq 0 9); do touch foo/$i; done
$ rsync -av --delete foo "bar baz"
sending incremental file list
foo/
foo/0
foo/1
foo/2
foo/3
foo/4
foo/5
foo/6
foo/7
foo/8
foo/9

sent 583 bytes  received 210 bytes  1,586.00 bytes/sec
total size is 0  speedup is 0.00
$ rm foo/{2,4,6,8}
$ rsync -av --delete foo "bar baz"
sending incremental file list
deleting foo/8
deleting foo/6
deleting foo/4
deleting foo/2
foo/

sent 146 bytes  received 52 bytes  396.00 bytes/sec
total size is 0  speedup is 0.00

Au passage : attention aux slashes en fin de nom de répertoire, ils sont significatifs pour rsync.

Debian Consultant @ DEBAMAX

Je partirais plutôt sur chmod o-rx /home/* ou chmod o-rwx /home/*.

• Je ne vois pas trop pourquoi on aurait w pour o, mais bon la deuxième commande permet d'être absolument certain.
• Pas besoin d'aller modifier tout le monde récursivement si x est absent de chaque répertoire utilisateur.
• Et surtout les fichiers créés par la suite (probablement avec un umask tout aussi permissif que les permissions initiales) ne seront pas accessibles non plus…

Debian Consultant @ DEBAMAX

Bonne question.

Je note que ça n'est pas supporté par iptables-translate (ou sa variante iptables-restore-translate), puisque la commande en question est recopiée comme telle en sortie, préfixée par #.

La page de manuel contient :

LIMITATIONS

Some (few) extensions may be not supported (or fully-supported) for whatever reason (for example, they were considered obsolete, or we didn't have the time to work on them).

Dans les sources iptables, je note qu'il n'y a pas de fichier extensions/libipt_TTL.txlate… Ce qui semble confirmer qu'il n'est pas prévu de proposer de traduction automatique de règle pour la cible TTL, implémentée dans le noyau par :

config NETFILTER_XT_TARGET_HL
        tristate '"HL" hoplimit target support'
        depends on IP_NF_MANGLE || IP6_NF_MANGLE
        depends on NETFILTER_ADVANCED
        ---help---
        This option adds the "HL" (for IPv6) and "TTL" (for IPv4)
        targets, which enable the user to change the
        hoplimit/time-to-live value of the IP header.

        While it is safe to decrement the hoplimit/TTL value, the
        modules also allow to increment and set the hoplimit value of
        the header to arbitrary values. This is EXTREMELY DANGEROUS
        since you can easily create immortal packets that loop
        forever on the network.

Et mes recherches semblent suggérer que la gestion TTL n'est prévue que côté matching…

Et ça semble confirmé par : https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables

Debian Consultant @ DEBAMAX