Contrôler les Mises à jour provoquant : update-grub Le sujet est résolu

[dezix]

Bonjour,

Comme j'ai déjà évoqué dans un précédent sujet : Problème de détection des OS par grub/os-prober
j'ai à présent 2 systèmes Debian (bullseye = futur stable) installés pour dual-boot sur des volumes dédiés chiffrés LUKS.

En usage normal, seul le volume "racine" de l'OS en cours est déchiffré,
l'autre racine restant inaccessible.


Le problème :

Avec cette configuration,
si une mise à jour concerne au moins 1 paquet "trigger" de update-grub,
typiquement linux-image-* et linux-headers-*
....mais pas seulement => c'est là le problème !


Dans ce cas il faut donc que le volume chiffré portant le 2d OS soit ouvert avant d'effectuter la MàJ qui déchenchera la mise à jour de GRUB
afin que os-prober le trouve.


Solutions envisagées


Piste N°1

Ma 1ère idée (simple) un script gérant les mises à jour
et
qui compare la liste des paquets candidats à la mise à jour avec une liste pré-établie de paquets à surveiller.

Si un de ces paquets est candidat, le script propose luksOpen

Cette méthode est la plus accessible pour moi,
mais je ne sais pas :

Comment obtenir la liste des paquets capables de déclencher update-grub ?


J'ai demandé hier sur IRC #debian si une commande pouvait fournir cette liste de paquets triggers de grub => pas de réponse immédiate :(


Donc pour le moment, à part compléter ma liste a posteriori,
je n'ai pas de solution.



Piste N°2

Sur IRC on m'a mis sur une piste qui semble contourner la liste précédente.


Utiliser un "hook" de GRUB pour qu'il fasse le job automatiquement.

il s'agirait de modifier : /etc/grub.d/30_os-prober
pour y insérer la commande luksOpen appropriée avant l'exécution de os-prober

ou

une variante consistant en la création d'un nouveau "hook" spécialement pour cela,
mais on ne m'a pas précisé comment :(

L'idée de modifier /etc/grub.d/30_os-prober semble excellente.
Mais :

1. Je ne sais pas trop comment car ce script va au-delà de mon entendement.
2. Même si je savais où placer ma commande, je ne vois pas trop comment cela pourrait se passer au niveau du mot de passe qu'il faudra bien fournir à un moment.
3. J'ai pas envie de tout casser

Merci pour vos avis sur la question.


REMARQUE: ce sujet vient en complément de : Mise à jour : Surveillance/Alerte sur certains paquets

[vv222]

La solution que je conseille est de poser un nouveau hook, /etc/grub.d/25_custom_luks-open, qui s’exécutera donc avant /etc/grub.d/30_os-prober.

Je ne connais pas le fonctionnement de ces hooks, mais il semble que ce ne soit rien d’autre que de bêtes scripts shell.

[PascalHambourg]

si une mise à jour concerne au moins 1 paquet "trigger" de update-grub,
typiquement linux-image-* et linux-headers-*

Tu es sûr pour linux-headers-* ? Je ne vois pas pourquoi cela déclencherait update-grub.
En ce qui concerne linux-image-*, cela passe par un script zz-update-grub déposé dans /etc/kernel/postinst.d/ et /etc/kernel/postrm.d/. Il est possible d'ajouter d'autres scripts qui vont s'exécuter avant et après (avec l'ordre lexical, par exemple z-open-luks et zzz-close-luks.
Mais ces scripts ne s'exécuteront pas en cas de mise à jour du paquet grub-pc (si BIOS) ou grub-efi-amd64 (si UEFI), qui exécute aussi update-grub. Ni en cas d'exécution manuelle de update-grub, mais c'est moins gênant car c'est toi qui contrôles dont tu peux aussi ouvrir et fermer le volume chiffré.

Je ne recommande pas de modifier le fichier /etc/grub.d/30_os-prober car il appartient au paquet grub-common et est géré en conffile donc sera soit écrasé soit pas mis à jour en cas de mise à jour du paquet. L'ajout de scripts avant et après pour ouvrir et fermer le volume chiffré me semble une meilleure idée. Attention à vérifier si le volume est déjà ouvert, et dans ce cas il ne faut pas l'ouvrir une deuxième fois ni le fermer.

Autre possibilité : ne pas utiliser os-prober pour ajouter l'autre installation. Via /etc/grub.d/40_custom tu peux ajouter une entrée de menu qui va simplement charger le fichier /grub/grub.cfg (commande configfile) dans la partition /boot de l'autre installation Ainsi pas besoin d'ouvrir le volume chiffré, et autre avantage, pas besoin d'exécuter update-grub dans l'OS principal pour prendre en compte une mise à jour de noyau dans l'OS secondaire. Inconvénient : la sélection de l'OS secondaire dans GRUB se fera en deux temps.

[dezix]

Une fois encore vous m'avez apporté une aide précieuse, MERCI !


@vv222

100% dans le vrai !

Tu es sûr pour linux-headers-* ? Je ne vois pas pourquoi cela déclencherait update-grub.

Après vérification... tu as raison => C'est corrigé !


J'ai testé sur une VBox les 2 solutions :



Solution 1

Script qui ouvre le volume LUKS portant la racine de l'autre OS ; ici -> sda3

Suivant le conseil de :

Attention à vérifier si le volume est déjà ouvert, et dans ce cas il ne faut pas l'ouvrir une deuxième fois ni le fermer.

J'ai créé 2 scripts pour ouvrir puis refermer le volume chiffré en vérifiant sont état.

J'ai fait au plus simple,
mais dans mon cas ça devrait être fiable,
dans la mesure où c'est :

• toujours le même volume : /dev/sda3
• monté avec le même nom : sda3_crypt

Pour des cas plus complexes, il faudrait un script plus élaboré qui prenne en compte toutes les situations...

Ce qui donne :

Ouverture

Code : Tout sélectionner

# vim /etc/grub.d/25_extra_luksOpen

code
------------------------------------
#!/bin/bash
# Script additionnel pour Ouverture du Volume LUKS portant la racine de l'OS2
if [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] ;
	then cryptsetup luksOpen /dev/sda3 sda3_crypt ;
fi
------------------------------------

# chmod +x /etc/grub.d/25_extra_luksOpen

Fermeture

Code : Tout sélectionner

# vim /etc/grub.d/50_extra_luksClose

code
------------------------------------
#!/bin/bash
# Script additionnel pour Fermeture du Volume LUKS portant la racine de l'OS2
if ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] ;
	then cryptsetup luksClose sda3_crypt ;
fi
------------------------------------

# chmod +x /etc/grub.d/50_extra_luksClose

J'ai testé en supprimant/installant des paquets linux-image-*
et
j'obtiens bien le prompt interactif pour fournir le MdP du volume LUKS


Il me reste à le tester en réel sur mon installation,
mais selon toute vraisemblance cela devrait fonctionner pile-poil !





Solution 2

Celle qui consiste à ajouter des entrées statiques dans /etc/grub.d/40_custom

Je ne vais pas détailler ce que j'ai testé,
il suffit p.ex de copier dans /boot/grub/grub.cfg du système à rajouter,
les sections menuentry qui nous intéressent,
se trouvant sous :

### BEGIN /etc/grub.d/10_linux ###

et de les ajouter à la fin de : /etc/grub.d/40_custom

Puis un coup de :

Code : Tout sélectionner

# update-grub
# grub-install /dev/sdx

pour avoir ces nouvelles entrées au bas du Menu GRUB.


L'inconvénient majeur de cette solution est que les mises à jour des versions du noyau ne se font pas (statique).

Il faudra donc :
soit éditer manuellement 40_custom
soit écrire un script qui le fera pour nous.



Voilà, pour ma part,
je vais commencer par configurer la Solution 1 sur mon installation,
et
je reviendrai peut-être ICI pour un éventuellement retour...

[dezix]

Et bien ça n'a pas tardé... je suis déjà de retour

À la relecture de :

Autre possibilité : ne pas utiliser os-prober pour ajouter l'autre installation. Via /etc/grub.d/40_custom tu peux ajouter une entrée de menu qui va simplement charger le fichier /grub/grub.cfg (commande configfile) dans la partition /boot de l'autre installation Ainsi pas besoin d'ouvrir le volume chiffré, et autre avantage, pas besoin d'exécuter update-grub dans l'OS principal pour prendre en compte une mise à jour de noyau dans l'OS secondaire. Inconvénient : la sélection de l'OS secondaire dans GRUB se fera en deux temps.

Je me rends comptes que j'avais tout compris de travers
et que cela ne correspond pas DU TOUT à ma Solution 2


Je comprends à présent que la commande configfile de GRUB sert à insérer un autre fichier de configuration grub,
en l’occurrence, celui de l'autre OS.


Dans mon exemple,
/dev/sda2 est la partition montée sur /boot du system2

Donc dans 40_custom
ça donne :

Code : Tout sélectionner

configfile (hd0,msdos2)/grub/grub.cfg

Cette méthode fonctionne aussi.

La seule chose un peu étrange,
le système secondaire est placé en haut du Menu GRUB

Ce n'est pas vraiment gênant,
mais il faudrait pouvoir différentier clairement les 2 systèmes
(sans que se soit écrasé à la prochaine MàJ)
car dans mon cas, ce sont 2x la même version de Debian.

[PascalHambourg]

Commentaire sur ton script /etc/grub.d/50_extra_luksClose : il ferme systématiquement le volume chiffré s'il est monté (ce qui est normalement le cas puisqu'il a été ouvert par le script /etc/grub.d/50_extra_luksOpen si besoin), alors qu'en toute rigueur il ne devrait le fermer que si c'est /etc/grub.d/50_extra_luksOpen qui l'a ouvert. Ce qui nécessite de passer une information d'état entre les deux scripts.

configfile (hd0,msdos2)/grub/grub.cfg

Il serait plus sûr d'utiliser l'UUID car rien ne garantit que que (hd0) est le bon disque.

La seule chose un peu étrange,
le système secondaire est placé en haut du Menu GRUB

C'est normal puisqu'il s'agit du menu de GRUB du système secondaire.
Tu peux faire la même manip sur le système secondaire pour pouvoir revenir au menu primaire, désactiver os-prober devenu inutile sur les deux systèmes, et pour les distinguer, sur chacun d'eux,
- personnaliser l'entrée Linux en modifiant la valeur de GRUB_DISTRIBUTOR dans /etc/default/grub
- libeller l'entrée ajoutée par 40_custom de façon explicite

Par exemple "Debian primaire" et "Debian secondaire".

[dezix]

Voici une nouvelle version des scripts qui prennent en compte l'état initial (ouvert/fermé) du volume chiffré de l'autre OS (secondaire).

L'état est enregistré dans un fichier temporaire :

• 1 => Volume Ouvert par le script > à refermer
• 2 => Volume initialement Ouvert > à conserver Ouvert après le script

Noter également que les 2 OS utilisent LVM,
il est donc nécessaire de désactiver le groupe de volume du système secondaire pour pouvoir refermer son volume chiffré ; sans cela on obtient un message d'erreur et le volume reste ouvert.

Remarque : Je n'ai pas vérifié, mais je ne pense pas que cela puisse avoir une conséquence sur le résultat de la config de GRUB, vu que le script extra de fermeture vient en tout dernier lieu.




Ouverture

Code : Tout sélectionner

#!/bin/bash
# Script additionnel pour Ouverture du Volume LUKS portant la racine de l'OS ADM
if [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] ;
	then cryptsetup luksOpen /dev/sda3 sda3_crypt && echo '1' > /tmp/grub_extra_luks_state ;
	else echo '2' > /tmp/grub_extra_luks_state ;
fi

Fermeture

Code : Tout sélectionner

#!/bin/bash
# Script additionnel pour Fermeture du Volume LUKS portant la racine de l'OS ADM
if [[ $(cat /tmp/grub_extra_luks_state) == '2' ]] ;
	then exit 0 ;
	elif ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] && [[ $(cat /tmp/grub_extra_luks_state) == '1' ]]  ;
	then vgchange -a n vg_adm && cryptsetup luksClose sda3_crypt ;
			
	else exit 0 ;
fi

Configuration du système secondaire

J'hésite encore entre y ajouter le même type de scripts "extra" ou lui indiquer la configuration du système principal.

Dans les 2 cas, il faudra rester vigilant à l'ordre des mises à jour — secondaire puis principal — si je veux m'éviter des update-grub manuels pour prendre en compte les nouvelles versions noyaux sur le système secondaire.

Cela n'aurait pas de conséquence fâcheuse,
vu que la version antérieure du noyau reste installée sur le secondaire,
c'est juste pour éviter des actions superflues.

[PascalHambourg]

Voici une nouvelle version des scripts qui prennent en compte l'état initial (ouvert/fermé) du volume chiffré de l'autre OS (secondaire).

Il est possible d'optimiser plusieurs points.
- Utiliser comme indicateur la présence ou l'absence du fichier temporaire et non son contenu.
- utiliser le code de retour de grep plutôt que faire une comparaison sur le contenu de la sortie standard.

Code : Tout sélectionner

[ dmsetup ls --target crypt | grep -q sda3 ]

- Il serait plus sûr de ne pas utiliser "sda3" mais l'UUID LUKS du volume chiffré, les noms des disques pouvant changer.
- Je ne comprends pas à quoi sert l'expression

Code : Tout sélectionner

elif ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] && [[ $(cat /tmp/grub_extra_luks_state) == '1' ]]

il faudra rester vigilant à l'ordre des mises à jour — secondaire puis principal — si je veux m'éviter des update-grub manuels pour prendre en compte les nouvelles versions noyaux sur le système secondaire.

D'où l'intérêt de la méthode alternative utilisant configfile qui n'a pas cet inconvénient. Elle a aussi l'avantage d'accélérer l'exécution de update-grub en évitant le recours à os-prober dont l'exécution prend du temps.

[dezix]

- utiliser le code de retour de grep plutôt que faire une comparaison sur le contenu de la sortie standard.

Tu veux dire remplacer :

Code : Tout sélectionner

if [[ $(cat /tmp/grub_extra_luks_state) == '2' ]] ;
	then exit 0 ;
	elif ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] && [[ $(cat /tmp/grub_extra_luks_state) == '1' ]]  ;
	then vgchange -a n vg_adm && cryptsetup luksClose sda3_crypt ;
			
	else exit 0 ;
fi

par :

Code : Tout sélectionner

grep -q 2 /tmp/grub_extra_luks_state 2>/dev/null && exit 0 ;
(dmsetup ls --target crypt | grep -q sda3 2>/dev/null) && \
grep -q 1 /tmp/grub_extra_luks_state 2>/dev/null && \
(vgchange -a n vg_adm && cryptsetup luksClose sda3_crypt) || \
exit 0

[ dmsetup ls --target crypt | grep -q sda3 ]

- Il serait plus sûr de ne pas utiliser "sda3" mais l'UUID LUKS du volume chiffré, les noms des disques pouvant changer.

Je ne vois pas comment, car cette commande va — je crois — rechercher dans /dev/mapper les speudo-points de montage des volumes.

Dans mon cas ça donne p.ex :

Code : Tout sélectionner

# dmsetup ls --target crypt
sda5_crypt	(254, 0)
sda6_crypt	(254, 4)

qui renvoie les noms fournis dans /etc/crypttab ou par la commande cryptsetup luksOpen ...

Rien dans le manuel, ni dans la doc The dmsetup Command Red Hat Enterprise Linux 7
n'indique un moyen de configurer cela autrement.

Je ne comprends pas à quoi sert l'expression

Code : Tout sélectionner

elif ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] && [[ $(cat /tmp/grub_extra_luks_state) == '1' ]]

À vérifier avant d'envoyer la commande de fermeture du volume que les 2 conditions sont satisfaites :

1. le volume est ouvert
2. le volume a été ouvert par le script précédent ; dans le cas contraire il restera ouvert.

Il me semble que cela correspond à ce que tu avais proposé au début.

[PascalHambourg]

Tu veux dire remplacer (...)

Je suggérais seulement d'optimiser les expressions utilisant grep, pas d'introduire grep dans celles qui ne l'utilisaient pas, d'autant plus que j'ai suggéré par ailleurs d'utiliser comme indicateur booléen la présence ou l'absence du fichier temporaire et non son contenu.

Je ne vois pas comment, car cette commande va — je crois — rechercher dans /dev/mapper les speudo-points de montage des volumes.

Ça m'étonnerait qu'elle aille voir quoi que ce soit dans /dev/mapper qui ne contient que des liens symboliques pointant vers les véritables périphériques /dev/dm-* dont les noms ne donnent aucune information.

Je ne me souvenais plus de la forme de la sortie de "dmsetup ls", je pensais que ton test y recherchait une correspondance avec le nom du périphérique source /dev/sda3) mais pas du tout, c'est avec le nom du périphérique créé par le device-mapper (/dev/mapper/sda3_crypt).
Du coup pour que ce soit plus clair tu pourrais utiliser le nom complet "sda3_crypt". En fait tu n'as même pas besoin d'utiliser dmsetup, il suffit de tester la présence de /dev/mapper/sda3_crypt. De toute façon les deux ne marchent que si le volume chiffré a bien été ouvert avec ce nom. Pour se baser sur l'UUID, on peut utiliser "dmsetup info".

À vérifier avant d'envoyer la commande de fermeture du volume que les 2 conditions sont satisfaites

Ces deux conditions ont déjà été vérifiées dans la première ligne du script.

[dezix]

J'espère que cette version prend correctement en compte les précédentes suggestions.


25_extra_luksOpen

Code : Tout sélectionner

#!/bin/bash
( ls /dev/mapper | grep -q  sda3_crypt ) \
&& echo '2' > /tmp/grub_extra_luks_state \
|| ( cryptsetup luksOpen /dev/sda3 sda3_crypt && echo '1' > /tmp/grub_extra_luks_state ) ;
exit 0

55_extra_luksClose

Code : Tout sélectionner

#!/bin/bash
if ! [[ -f /tmp/grub_extra_luks_state ]] ;
	then
		exit 0 ;
	else

		if [[ $(cat /tmp/grub_extra_luks_state) == '2' ]] ;
			then
				exit 0 ;
			elif
				[[ $(cat /tmp/grub_extra_luks_state) == '1' ]]  ;
			then
				vgchange -a n vg_adm && cryptsetup luksClose sda3_crypt ;
			else
				exit 0 ;
		fi
fi
exit 0

Ce n'est probablement pas LA solution parfaite,
mais je pense qu'elle va fonctionner dans toutes les possibilités du fichiers d'état (absent ; contient /1/2/autre chose)
et je ne veux pas abuser d'avantage de ta bonne volonté.


MERCI !

[PascalHambourg]

Code : Tout sélectionner

ls /dev/mapper | grep -q  sda3_crypt

Encore un usage inutile de grep. La commande test ou [ ] du shell a des opérateurs pour tester l'existence et le type d'un fichier, par exemple

Code : Tout sélectionner

[ -e /dev/mapper/sda3_crypt ]

ou bien pour vérifier aussi qu'il s'agit d'un lien symbolique

Code : Tout sélectionner

[ -h /dev/mapper/sda3_crypt ]

Les tests du fichier d'état pour la fermeture sont encore inutilement compliqués. Le test de la valeur 2 ne sert à rien et tout peut se faire sur une ligne.

Code : Tout sélectionner

fichier existe && fichier contient '1' && vgchange && cryptsetup

Il y a un cas où tes scripts ne marcheront pas : si le volume chiffré et ouvert mais ses volumes logiques ne sont pas activés.

[dezix]

J'ose espérer avoir enfin une solution simple et adaptée :

Ouverture

Code : Tout sélectionner

#!/bin/bash
test -e /dev/mapper/sda3_crypt  \
&& echo '2' > /tmp/grub_extra_luks_state \
|| ( cryptsetup luksOpen /dev/sda3 sda3_crypt && echo '1' > /tmp/grub_extra_luks_state ) ;
exit 0

Je conserve l'écriture du "2" pour une trace de l'état initial.
Je doute que cela soit vraiment utile, mais ça ne coûte pas grand-chose.

Fermeture

Code : Tout sélectionner

#!/bin/bash
( test -f /tmp/grub_extra_luks_state && [[ $(cat /tmp/grub_extra_luks_state) == '1' ]] ) \
&& ( vgchange -a n vg_adm && cryptsetup luksClose sda3_crypt ) ;
exit 0

J'ai pris cette mauvaise habitude d'utiliser abusivement des conduites grep lorsque j'utilise la ligne de commande en "live"
... et je reproduis cela dans les scripts.

Tu fais très bien de me le faire remarquer ... je suis d'un naturel (trop) compliqué

Il y a un cas où tes scripts ne marcheront pas : si le volume chiffré et ouvert mais ses volumes logiques ne sont pas activés.

Cela ne devrait pas se produire,
dans la mesure où j'utiliserai ces scripts depuis un système qui utilise lui-même LVM,
lvm2-monitor.service étant actif, il devrait activer le nouveau groupe dès son apparition ... ou pas ???

[PascalHambourg]

C'est quand même plus concis comme ça, non ?

Je conserve l'écriture du "2" pour une trace de l'état initial.
Je doute que cela soit vraiment utile, mais ça ne coûte pas grand-chose.

J'ai compris que tu n'en démordrais pas et je n'insiste pas. Mais effectivement c'est inutile, et ça coûte un test en plus.

lvm2-monitor.service étant actif, il devrait activer le nouveau groupe dès son apparition ... ou pas ???

En principe, je suppose. A vrai dire je ne me suis jamais penché sur ce genre de détails.

[dezix]

C'est quand même plus concis comme ça, non ?

Très clairement,
et je compte bien m'appliquer à remettre cet enseignement en pratique pour mes prochains scripts

[dezix]

Petit retour après un bon mois d'usage ...

La solution fonctionne parfaitement

PH comme d'habitude avait raison quant au peu d'utilité du test sur l'état initial "Déjà ouvert"
qui par ailleurs faisait interférence avec un autre script que j'utilise maintenant pour la gestion des mises à jour (apt upgrade)
car il teste l'état du volume LUKS "sda3" avec le même fichier ...


Bref, maintenant je me contente de :

Ouverture

Fichier : /etc/grub.d/25_extra_luksOpen

Code : Tout sélectionner

#!/bin/bash
test -e /dev/mapper/sda3_crypt  \
|| ( cryptsetup luksOpen /dev/sda3 sda3_crypt && echo '1' > /tmp/grub_extra_luks_state ) ;
exit 0

en conservant l'autre fichier : /etc/grub.d/55_extra_luksClose
à l'identique.