Cyril Brulebois a écrit 613 commentaires

Vu également :

• échange de radios par messagerie sur téléphone portable (donc Google ou Apple, je suppose) parce que le SI de l'école dentaire flambant neuve (de cette grande ville bretonne que je ne nommerai pas) « ne marchait pas » (ou n'était pas aussi pratique/rapide/habituel que les téléphones, je n'ai pas osé demander) ;
• même endroit : postes Windows XP avec mot de passe = prénom + année de naissance, communiqué aux collègues devant les patients.

Debian Consultant @ DEBAMAX

Tu peux m'en dire plus ?
Comment dois je adapter ma configuration ?

Cf. ma réponse précédente : il faut modifier l'URL que tu utilises dans git clone, ou bien modifier ton .git/config dans un clone existant pour que git fetch utilise l'URL modifiée. Il ne faut plus que ça pointe directement vers github.com mais vers gitlab-perso ou gitlab-pro tel que renseigné dans ton ~/.ssh/config

J'avais même suggéré une commande à utiliser directement, en me basant sur ta configuration…

Debian Consultant @ DEBAMAX

Hello,

Ça me semble normal : il faut que tu adaptes la configuration lors du git clone ou du git fetch pour utiliser un des paragraphes que tu as ajoutés, sinon c'est la configuration par défaut qui va être utilisée. Dans ton cas, tu peux essayer avec : git clone git@gitlab-perso:gitlabperso/cloud.git

(Tu pourrais également ajouter le nom d'utilisateur dans la configuration ~/.ssh/config, pour éviter d'avoir à le spécifier dans ta ligne de commande et/ou ton .git/config.)

Debian Consultant @ DEBAMAX

Dans la configuration de chaque dépôt : ssh://gitlab1/… ou ssh://gitlab2/…

Puis dans le fichier ~/.ssh/config :

Host gitlab1
    Hostname gitlab.com              # le vrai hostname
    IdentityFile ~/.ssh/id_rsa-user1 # vérifier qu'un chemin absolu ne soit pas nécessaire

Host gitlab2
    Hostname gitlab.com              # le vrai hostname
    IdentityFile ~/.ssh/id_rsa-user2 # vérifier qu'un chemin absolu ne soit pas nécessaire

Vérifier avec git fetch dans chaque checkout, et hop.

Bien évidemment, on peut imaginer des choses plus pertinentes que gitlab1 et gitlab2 d'un point de vue nommage…

Debian Consultant @ DEBAMAX

Exemples :

kibi@armor:~$ a=1.0; for b in 0.9 1.0 1.1; do dpkg --compare-versions $a '<<' $b; echo $?; done
1
1
0
kibi@armor:~$ a=1.0; for b in 0.9 1.0 1.1; do dpkg --compare-versions $a '<=' $b; echo $?; done
1
0
0

Extrait de la page de manuel :

       --compare-versions ver1 op ver2
              Compare version numbers, where op is  a  binary  operator.  dpkg
              returns  true  (0)  if the specified condition is satisfied, and
              false (1) otherwise. There are two groups  of  operators,  which
              differ  in  how they treat an empty ver1 or ver2. These treat an
              empty version as earlier than any version: lt le eq  ne  ge  gt.
              These  treat  an  empty version as later than any version: lt-nl
              le-nl ge-nl gt-nl. These are  provided  only  for  compatibility
              with  control  file  syntax:  <  <<  <=  =  >= >> >. The < and >
              operators are obsolete and should not be used, due to  confusing
              semantics. To illustrate: 0.1 < 0.1 evaluates to true.

Debian Consultant @ DEBAMAX

Ce que tu essaies de voir, c'est avec quelle adresse IP tu sors. Celle-ci peut ensuite et optionnellement donner lieu à une recherche inverse, pour remonter un nom de domaine qui pourrait être associé à cette adresse.

Dans le premier cas, tu as une connectivité IPv4, avec potentiellement une adresse IP fixe (cf. zones dégroupées, etc.).

Dans le second cas, tu as une connectivité IPv6 qui est privilégiée par rapport à la connectivité IPv4. D'où le format différent. Par ailleurs, en IPv6, c'est souvent un préfixe qui est fixe (no pun intended), avec les derniers octets qui peuvent varier d'une fois sur l'autre.

Debian Consultant @ DEBAMAX

Je pense surtout que c'est le contenu de ton toto.img qui s'y prête…

Debian Consultant @ DEBAMAX

losetup te permet d'obtenir un lien entre un périphérique loop et ton image.

kpartx -asv /dev/loopX te permet d'activer chaque partition, ce qui permet de les retrouver en tant que /dev/mapper/loopXpY, avec lesquelles tu peux jouer via mount.

Pour le clean-up : umount, kpartx -dsv /dev/loopX et losetup avec les bonnes options.

Note que tu peux appeler kpartx -asv directement sur ton image. Le /dev/loopX sera mis en place automatiquement, et nettoyé quand tu appelleras kpart -dsv (flag autoclean ou équivalent).

Debian Consultant @ DEBAMAX

Juste une précision en passant : c'était historiquement des CD mais de nos jours il s'agit d'image ISO que l'on peut déployer sur clé USB. ;)

C'est effectivement le plus simple quand on n'a pas envie de s'embêter à vérifier/valider/fournir spécifiquement un seul micrologiciel/firmware (en admettant qu'un seul suffise, il peut y avoir des blagues avec la partie graphique également).

J'aurais tendance à conseiller l'utilisation de Debian Installer directement plutôt que de passer par un environnement de type « live ».

Enfin, pourquoi désactiver Secure Boot ? Buster le gère désormais. Et quand bien même, sur les machines récentes, booter en UEFI est souvent une meilleure idée que rester en mode Legacy. C'est le chemin de code qui est particulièrement validé côté constructeur et on a (au moins en théorie) moins de problèmes qu'en mode compatibilité BIOS/Legacy/CSM.

Debian Consultant @ DEBAMAX

La formulation du message d'erreur est plus qu'étrange.

Tu parles de certificat de serveur web alors que ton problème est remonté par Thunderbird, qui est un client mail (IMAP/IMAPS, POP/POPS)… Es-tu sûr que le certificat récupéré via Let's Encrypt est bien (re)déployé vers les services gérant la messagerie, et que ceux-ci n'utilisent pas un certificat expiré (ce qui devrait donner un message d'erreur bien plus explicite).

Si tu veux faciliter la vie des gens qui pourraient vouloir t'aider, mentionner le nom de domaine serait le plus rapide… (openssl s_client -connect … -showcerts est notre ami)

Debian Consultant @ DEBAMAX

Note, le commentaire est en doublon de celui-ci, posté quelques minutes avant, qui apporte déjà des réponses…

→ https://linuxfr.org/nodes/118246/comments/1785596

Debian Consultant @ DEBAMAX

C'est donc une mauvaise solution, puisque cela met en place une boucle qui ne fait qu'un seul tour de boucle avec comme seul objet la concaténation de l'ensemble de la sortie de find, non ?

Debian Consultant @ DEBAMAX

Plutôt que suggérer resize2fs (qui peut être contre-intuitif quand on a ext4 comme FS) : il existe fsadm resize qui est générique et va faire ce qu'il faut quel que soit le système de fichiers.

Debian Consultant @ DEBAMAX

La boucle n'est pas bonne, il suffit d'ajouter un peu de texte autour de $f pour s'en convaincre :

for f in "$(find * -maxdepth 0 -type f)"; do echo "1 seul résultat >>>$f<<<"; echo "fin de ligne"; done

Normal : le résultat de find est encadré par des guillemets, for opère sur un seul mot, donc un seul tour de boucle.

Au passage, je ne comprends pas à quoi sert find * plutôt que find. Cela va même provoquer une erreur quand un répertoire est vide, puisque * ne sera pas remplacé, donc find va essayer de travailler sur (littéralement) *…

Debian Consultant @ DEBAMAX

Au passage, apt est censé aider l'utilisateur à ne pas scier la branche sur laquelle il est assis :

kbi@armor:~$ sudo apt-get remove apt
[…]
The following packages will be REMOVED:
  apt apt-file apt-listchanges apt-utils apticron autopkgtest d-shlibs debian-el debian-ports-archive-keyring
  dgit dpkg-dev-el libguestfs-hfsplus libguestfs-perl libguestfs-reiserfs libguestfs-tools libguestfs-xfs
  libguestfs0 libsbuild-perl python-guestfs python3-guestfs python3-reportbug reportbug ruby-guestfs sbuild
  supermin task-british-desktop task-desktop task-english task-laptop task-print-server task-ssh-server tasksel
  tasksel-data unattended-upgrades
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt
0 upgraded, 0 newly installed, 34 to remove and 10 not upgraded.
After this operation, 54.2 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] 

en VO ou bien ceci en VF :

kibi@armor:~$ sudo LANG=fr_FR.UTF-8 apt-get remove apt
[…]
Les paquets suivants seront ENLEVÉS :
  apt apt-file apt-listchanges apt-utils apticron autopkgtest d-shlibs debian-el debian-ports-archive-keyring
  dgit dpkg-dev-el libguestfs-hfsplus libguestfs-perl libguestfs-reiserfs libguestfs-tools libguestfs-xfs
  libguestfs0 libsbuild-perl python-guestfs python3-guestfs python3-reportbug reportbug ruby-guestfs sbuild
  supermin task-british-desktop task-desktop task-english task-laptop task-print-server task-ssh-server tasksel
  tasksel-data unattended-upgrades
ATTENTION : Les paquets essentiels suivants vont être enlevés.
Vous NE devez PAS faire ceci, à moins de savoir exactement ce
que vous êtes en train de faire.
  apt
0 mis à jour, 0 nouvellement installés, 34 à enlever et 10 non mis à jour.
Après cette opération, 54,2 Mo d'espace disque seront libérés.
Vous êtes sur le point de faire quelque chose de potentiellement dangereux
Pour continuer, tapez la phrase « Oui, faites ce que je vous dis ! »
 ?]

Debian Consultant @ DEBAMAX

C'est effectivement supporté (avec partitionnement assisté) dans Debian Installer, depuis de très nombreuses versions…

Debian Consultant @ DEBAMAX

Tout à fait d'accord. Le classique, stable, et éprouvé ici, c'est LVM. Pas BTRFS. Et c'est empilable sur/sous les autres couches, qu'il s'agisse de RAID ou LUKS.

Debian Consultant @ DEBAMAX

Je te confirme que la saisie de la passphrase à distance via la console IPMI est une solution possible. Attention cependant aux jeux de caractères et aux caractères spéciaux, il s'agit souvent de consoles Java qui sont peu pratiques. → C'est souvent une bonne idée de vérifier dès le départ qu'on peut taper tous les caractères à travers celle-ci. ;)

Debian Consultant @ DEBAMAX

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