Cyril Brulebois a écrit 670 commentaires

Effectivement, il y a dpkg qui sait si un des conffiles d'un paquet a été modifié par l'administrateur tandis qu'une nouvelle version du paquet embarque une configuration différente, et qui peut proposer un prompt pour choisir la version modifiée ou la nouvelle version. En fonction de la réponse, du côté interactif ou non, des options passées via apt/dpkg, on peut se retrouver avec des fichiers suffixés .dpkg-dist, .dpkg-old, .dpkg-new.

Et il y a ucf qui permet d'être plus subtil que « version A ou version B », et de fusionner des modifications. Même si c'est bien mieux sur le papier, en pratique ça n'est presque pas utilisé. Sur mon système principal je vois 17 scripts postinst qui contiennent ucf, sur 4400+ paquets… Il y a probablement plus malin pour faire l'équivalent de la manipulation debsums (avec les bonnes options) ou dpkg --audit, directement avec ucf, mais de mon côté je vérifierais les paquets éventuellement concernés par des modifications de type ucf via grep -l ucf /var/lib/dpkg/info/*.postinst.

Debian Consultant @ DEBAMAX

C'est probablement un jugement de valeur, mais je trouve cela plutôt rassurant que le chargeur de démarrage arrive bien à faire son boulot, et qu'il « suffise » de disposer d'un noyau avec un correctif ou d'une option qui évite de tomber sur le bogue en question… J'avais peur qu'il y ait un problème entre le firmware UEFI et le chargeur de démarrage. :)

Vu la cadence infernale côté mainline et la « rétroportabilité » habituelle de pleins de patches, j'imagine que des corrections pourraient arriver facilement dans les branches stable/longterm et dans les distributions…

Debian Consultant @ DEBAMAX

Ta publication me paraît tout à fait appropriée, et je comprends également l'aspect potentiellement hyper-modulable de la rémunération en fonction des missions confiées et des clients en question.

Je t'invite à ne pas te laisser décourager par le trolling malheureusement habituel sur ce site.

Debian Consultant @ DEBAMAX

cosmoff :

il est toujours enabled

Je ne comprends pas car normalement systemctl gere systemd, donc il devrait me passer le service en disabled.

Non, il n'est pas enabled. Cf. la ligne :

 Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: enabled)

C'est le vendor preset qui est activé. Le service est en mode static, qui est une variante de disabled.

Cf. la page de manuel systemctl(1) :

           ├──────────────────┼──────────────────────────────┼───────────┤
           │"static"          │ The unit file is not         │ 0         │
           │                  │ enabled, and has no          │           │
           │                  │ provisions for enabling in   │           │
           │                  │ the "[Install]" unit file    │           │
           │                  │ section.                     │           │
           ├──────────────────┼──────────────────────────────┼───────────┤
…
           ├──────────────────┼──────────────────────────────┼───────────┤
           │"disabled"        │ The unit file is not         │ > 0       │
           │                  │ enabled, but contains an     │           │
           │                  │ "[Install]" section with     │           │
           │                  │ installation instructions.   │           │
           ├──────────────────┼──────────────────────────────┼───────────┤

À vue de pif, je dirais qu'autre chose se charge de lancer le gestionnaire de connexion graphique. Un exemple sur Debian :

kibi@armor:~$ systemctl cat graphical.target 
# /lib/systemd/system/graphical.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes


kibi@armor:~$ systemctl cat display-manager.service
# /lib/systemd/system/lightdm.service
[Unit]
Description=Light Display Manager
Documentation=man:lightdm(1)
After=systemd-user-sessions.service

[Service]
# temporary safety check until all DMs are converted to correct
# display-manager.service symlink handling
ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ]'
ExecStart=/usr/sbin/lightdm
Restart=always
BusName=org.freedesktop.DisplayManager

Et cette unité display-manager.service est mise en place par le script de post-installation de lightdm. Extrait :

if [ "$1" = "configure" ];
then
  invoke-rc.d dbus reload || true

  # set default-display-manager systemd service link according to our config
  if [ -e "$DEFAULT_DISPLAY_MANAGER_FILE" -a -d /etc/systemd/system/ ]; then
    SERVICE=/lib/systemd/system/$(basename $(cat "$DEFAULT_DISPLAY_MANAGER_FILE")).service
    if [ -e "$SERVICE" ]; then
      ln -sf "$SERVICE" /etc/systemd/system/display-manager.service
    else
      echo "ERROR: $SERVICE is the selected default display manager but does not exist" >&2
    fi
  fi
fi

Cela doit être similaire pour les autres display managers.

À voir en fonction de ta distribution (que tu n'as pas spécifiée).

Debian Consultant @ DEBAMAX

La prochaine fois, coller l'intégralité du fichier /etc/apt/sources.list (et des éventuels autres fichiers sous /etc/apt/sources.lists.d) serait une bonne idée.

D'après la sortie, je suis assez certain que c'est non-free qui est mal orthographié, d'où la recherche des composants non et free…

Debian Consultant @ DEBAMAX

C'est différent car il n'y a absolument rien à faire : on a directement accès à l'image détourée qui avait été initialement utilisée. Pour éviter cela il faudrait passer par un rendu de type « bitmap » plutôt que le PDF habituellement en vectoriel auquel on a ajouté un fichier image. Mais là, il faut choisir la résolution avec laquelle on fait le rendu. Et la taille/l'utilisation disque peuvent exploser…

Debian Consultant @ DEBAMAX

J'utilise xournal pour signer des PDF depuis très longtemps et j'en suis plutôt content. Pas eu de retour négatif de la part des différents services/professionnels concernés.

Attention cependant, quand tu génères un export en PDF, il est très possible que l'image de la signature soit incorporée sous forme d'une image qui se superpose au reste. D'où un éventuel risque de réutilisation…

Exemple avec un CERFA « Soins reçus à l'étranger » (12267*04) signé avec xournal :

$ mutool info 2019-06-26-demande-remboursement-signee.pdf 
2019-06-26-demande-remboursement-signee.pdf:

PDF-1.5
Info object (142 0 R):
<</Creator(cairo 1.14.8 \(http://cairographics.org\))/Producer(cairo 1.14.8 \(http://cairographics.org\))>>
Pages: 2

Retrieving info from pages 1-2...
Mediaboxes (1):
    1   (21 0 R):   [ 0 0 595.22 842 ]

Fonts (21):
    1   (21 0 R):   Type0 'BSYCBJ+TimesNewRomanPS-BoldMT' (5 0 R)

[Sortie tronquée : 21 références au total]

Images (1):
    1   (21 0 R):   [ Flate ] 664x244 8bpc DevRGB (20 0 R)

Extraction :

$ mutool extract -r 2019-06-26-demande-remboursement-signee.pdf 
extracting image img-0020.png
extracting image img-0022.png
extracting font MBBGFV+TimesNewRomanPS-BoldMT-0039.cff
[Sortie tronquée : 21 références au total]

$ file img-0022.png
img-0022.png: PNG image data, 664 x 244, 8-bit/color RGB, non-interlaced

Et hop, signature prête à être réutilisée…

Debian Consultant @ DEBAMAX

Autant faire une installation BIOS à la main, c'est assez gérable. Autant une installation UEFI, ça peut être plus délicat. J'aurais plutôt tendance à demander à voir des captures d'écran des différents choix disponibles pour cette histoire de disques, histoire de comprendre quelles sont les options (au passage le lien vers le manuel d'installation n'est pas correct dans le message initial). C'est dommage de devoir faire faire aux utilisateurs le boulot du système d'installation…

Debian Consultant @ DEBAMAX

Dans un LUG local, je vois passer ± régulièrement des machines avec des disques durs plutôt que des SSD, et l'expérience utilisateur me semble catastrophique. Vu les tarifs actuels des SSD, et si ça rentre dans le budget, ce serait dommage de s'en priver…

Debian Consultant @ DEBAMAX

Je te confirme que D-I sait faire réseau ouvert, WEP, WPA, WPA2 en mode PSK (Pre-Shared Key). Pas de WPA2 Enterprise cependant.

J'ai de vagues souvenirs de modules cryptographiques côté noyau qui ont pu être manquants par le passé et qui limitaient les choix de type de chiffrement.

Si tu as pu continuer en contournant le problème, et obtenir un réseau qui fonctionne après redémarrage, cela pourrait être un problème similaire. Un rapport d'installation serait le bienvenu. Notamment, les sorties de lsmod dans D-I et dans le système installé seraient intéressantes à comparer.

Debian Consultant @ DEBAMAX

Je crois que les deux dernières lignes (commentaires) expliquent pourquoi swapoff -a fonctionne bien pour désactiver la swap (elle est activée par un outil particulier, plutôt que via des éléments de configuration dans /etc/fstab) et pourquoi swapon -a ne fait rien : il n'y a pas d'entrée de swap configurée dans ce fichier.

Debian Consultant @ DEBAMAX

Sauf si cela a changé ces dernières années : c'est plutôt l'inverse. N-M se propose de gérer les interfaces qui sont unmanaged, c'est à dire qui n'ont pas de configuration explicite dans /etc/network/interfaces (ou un des fichiers du plus récent répertoire /etc/network/interfaces.d/).

Mais effectivement, la période de transition « interface gérée par N-M parce qu'absente de /e/n/i » vers « elle est configurée dans /e/n/i » peut nécessiter de redémarrer (ou arrêter+démarrer) le service N-M pour qu'il arrête de s'occuper de cette interface en particulier. ;)

Debian Consultant @ DEBAMAX

NaN c'est pour Not a Number. Ce pourcentage serait le résultat de la division 0/0, ce qui n'a pas de sens ; on peut donc retrouver cette notation en fonction des langages, des affichages, etc.

Debian Consultant @ DEBAMAX

La documentation, et surtout le comportement de systemctl sans paramètre, semblent contredire cette assertion.

COMMANDS
       The following commands are understood:

   Unit Commands
       list-units [PATTERN...]
           List units that systemd currently has in memory. This includes
           units that are either referenced directly or through a dependency,
           units that are pinned by applications programmatically, or units
           that were active in the past and have failed. By default only units
           which are active, have pending jobs, or have failed are shown; this
           can be changed with option --all. If one or more PATTERNs are
           specified, only units matching one of them are shown. The units
           that are shown are additionally filtered by --type= and --state= if
           those options are specified.

           This is the default command.

Debian Consultant @ DEBAMAX

C'est pourquoi je mentionnais des menus dans le système de récupération, plutôt que des commandes (tu parles de chroot, de grub-install, mais ce que je suggérais fonctionne sans avoir besoin de savoir tout cela). Du moment que c'est corrigé de toute façon, tant mieux.

Debian Consultant @ DEBAMAX

Ce serait dommage de ne pas utiliser l'installateur Debian qui vient avec un mode de récupération (rescue) → https://www.debian.org/releases/stable/amd64/ch08s07.html

Surtout qu'il y a des items spécifiques pour ce genre de manipulations dans le menu.

Debian Consultant @ DEBAMAX

Si lien = lien physique : impossible entre périphériques différents.

Si lien = lien symbolique : par définition c'est lrwxrwxrwx pour root:root et les permissions sont résolues en fonction de vers quoi ça pointe.

Debian Consultant @ DEBAMAX

Étape numéro 1 : copier l'intégralité du disque vers un autre disque (par exemple en créant un fichier image).

Étape numéro 2 : travailler sur l'image ainsi générée (voire sur une copie, si tu as de la place suffisante pour conserver un exemplaire de l'image originale).

Étape numéro 3 : utiliser testdisk.

Ce dernier sait retrouver des fichiers en fonction de leur signature (utile pour repêcher des fichiers audio/vidéo avec une signature caractéristique) mais également réparer un système de fichiers endommagé. J'ai eu le cas précédemment, sur un disque NTFS, dont une copie du secteur de boot était conservé en fin de disque. Après restauration dudit secteur, la magie opéra.

Ceci n'est en aucun cas une garantie que tu auras le même résultat. Mais une piste à explorer, potentiellement en te faisant accompagner (manipuler des données dont on détient une seule copie, ça met du stress et ça peut faire faire des bêtises).

Bon courage.

Debian Consultant @ DEBAMAX

L'affichage et la saisie sont effectués par l'émulateur de terminal (gnome-terminal, xterm, etc.), qui démarre une session shell (bash, dash, etc.), et qui fait le passe-plat.

Debian Consultant @ DEBAMAX

Pourquoi un /boot séparé ?

200 Mo, ça fait un peu petit, surtout si tu prévois de l'utiliser sur les deux distributions.

Debian Consultant @ DEBAMAX

Je vote bullshit complet.

En général on essaie de mettre une chaîne de certificats afin de faciliter les vérifications. Si une racine A signe un certificat intermédiaire B qui signe le certificat final www.example.org, c'est plus sympa d'inclure a minima le certificat B et le certificat final pour que les clients n'aient besoin que de connaître la racine A. Avoir le certificat B (la partie publique) ne met en danger ni B ni A… Et quand on est parti là-dedans, autant avoir A, B, et le certificat final (dans le bon ordre, suivant les applicatifs).

Et le jour où le certificat B est remplacé par B', ou B'', etc., les clients n'ont pas besoin de mise à jour, il suffit de continuer à faire confiance à A…

Debian Consultant @ DEBAMAX

Si tu n'as pas fait de manipulations particulières, notamment si tu ne savais pas ce qu'étaient les termes CSM, Legacy BIOS, etc., tu n'as probablement pas modifié toi-même d'option dans ton firmware. Celui-ci était donc probablement configuré pour booter en EFI plutôt qu'en BIOS.

Dans ce cas, les différents OS sont stockés dans des variables persistantes, qui ont probablement été vidées lors de la remise à zéro. Il faudrait donc réussir à rétablir ces entrées.

Je ne sais pas quelle distribution tu utilises, mais au moins côté Debian, il est possible de démarrer le système d'installation en mode Récupération (Rescue), de détecter le système installé, et de rejouer l'installation du chargeur de démarrage (ce qui doit avoir comme effet de bord la réinscription de l'entrée correspondante côté firmware). Une alternative pourrait être de lancer soi-même la bonne commande efibootmgr depuis le système en question.

Debian Consultant @ DEBAMAX

Le genre de cas où on pourrait demander la sortie de lsblk plutôt que dire une bêtise, en fait. ;p

Debian Consultant @ DEBAMAX

Mais si tu souhaite la laisser sur le même disque, il faut la laisser en RAID, car je ne crois pas que tu puisse mettre en RAID juste une partie du disque.

Bien sûr que si.

Le RAID se configure sur des block devices. Donc sur disque entier, partition, ou n'importe quel autre block device (que ça soit du LUKS, du LVM, etc.).

Debian Consultant @ DEBAMAX

De mémoire swapon vérifie qu'il y a bien une signature de swap avant d'activer une telle partition, mais ce serait un peu dommage de pointer vers une éventuelle autre partition, le jour où il y aura des changements côté stockage…

Debian Consultant @ DEBAMAX