Migrer un syst

Le
dethegeek
Bonjour,

J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un volume
chiffré. Mes recherches ne m'ont doné que des méthodes d'installation
frâiche.

Quelqu'un a t il une bonne ressource pour m'éviter de tout réinstaller
(et perdre du temps à tout reconfigurer) ?
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
David BERCOT
Le #26485855
Bonjour,
J'imagine qu'il n'y a peut-être pas la place de tout dupliquer ;-)
Sinon, je pense en effet qu'il n'y a pas de migration possible.
D'ailleurs, quand je ré-installe mon ordinateur, je suis obligé de tout
sauvegarder au préalable (via rsync d'ailleurs), d'effectuer une
nouvelle installation et enfin de tout ré-injecter (mon home, toujours
via rsync).
L'idéal serait une solution pour reprendre une partition chiffrée lors
d'une nouvelle installation (à moins que je ne sois passé à côté de
quelque chose)...
David.
Le 23/08/2018 à 11:49, Pierre Malard a écrit :
Et pourquoi pas simplement un rsync du FS source vers le FS crypté monté ?
Le 23 août 2018 à 10:44, dethegeek
Bonjour,
J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un volume
chiffré. Mes recherches ne m'ont doné que des méthodes d'installation
frâiche.
Quelqu'un a t il une bonne ressource pour m'éviter de tout réinstaller
(et perdre du temps à tout reconfigurer) ?

-- 
Pierre Malard
   «/Le courage, c'est de chercher la vérité et de la dire, /
/    c'est de ne pas subir la loi du mensonge triomphant qui passe /
/    et de ne pas faire écho de notre âme, de notre bouche et de nos mains /
/    aux applaudissements imbéciles et aux huées fanatiques./»
        Jean Jaures - "Discours de jeunesse" - 1903
   ("`-/")_.-'"``-._
    . . `; -._    )-;-,_`)
   (v_,)'  _  )`-.  ``-'
  _.- _..-_/ / ((.'
((,.-'   ((,/         πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  )
)-,_. , (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'_):
24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
dethegeek
Le #26485890
Bonjour
Le jeudi 23 août 2018 à 11:49 +0200, Pierre Malard a écrit :
Et pourquoi pas simplement un rsync du FS source vers le FS crypté
monté ?

Si je duplique l'ancien système de fichiers vers celui qui est chiffré
ça ca ête très pénible de booter la machine. Je compte donc trouver une
procédure que je validerai au préalable. J'ai un brouillon avec une
procédure que j'ai mise au point mais il me manque un petit bout pour
que ça soit fiable (pour le moment il y a une part de tâtonnement et le
succès est aléatoire).
l'idéal é&tant de profiter d'un miroir raid ou lvm pour migrer en
douceur et continuer à booter sur la version non chiffrée en cas de
pépin de migration.
Le 23 août 2018 à 10:44, dethegeek Bonjour,
J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un
volume
chiffré. Mes recherches ne m'ont doné que des méthodes
d'installation
frâiche.
Quelqu'un a t il une bonne ressource pour m'éviter de tout
réinstaller
(et perdre du temps à tout reconfigurer) ?

--
Pierre Malard
«Le courage, c'est de chercher la vérité et de la dire,
c'est de ne pas subir la loi du mensonge triomphant qui passe
et de ne pas faire écho de notre âme, de notre bouche et de nos
mains
aux applaudissements imbéciles et aux huées fanatiques.»
Jean Jaures - "Discours de jeunesse" -
1903
("`-/")_.-'"``-._
. . `; -._ )-;-,_`)
(v_,)' _ )`-. ``-'
_.- _..-_/ / ((.'
((,.-' ((,/ πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- )
)-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_):
24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
dethegeek
Le #26485891
bonjour
J'ai la chance d'avoir pris un réflexe: ne pas allouer tout l'espace
disque avec mes volumes logiques. De plus mes disques font 2 To et j'ai
des 4 To qui attendent la fin de l'opération pour aller dans une
machine de sauvegarde. L'espace disque n'est pas un souci.
Le jeudi 23 août 2018 à 13:59 +0200, David BERCOT a écrit :
Bonjour,
J'imagine qu'il n'y a peut-être pas la place de tout dupliquer ;-)
Sinon, je pense en effet qu'il n'y a pas de migration possible.
D'ailleurs, quand je ré-installe mon ordinateur, je suis obligé de
tout
sauvegarder au préalable (via rsync d'ailleurs), d'effectuer une
nouvelle installation et enfin de tout ré-injecter (mon home,
toujours
via rsync).
L'idéal serait une solution pour reprendre une partition chiffrée
lors
d'une nouvelle installation (à moins que je ne sois passé à côté de
quelque chose)...
David.
Le 23/08/2018 à 11:49, Pierre Malard a écrit :
Et pourquoi pas simplement un rsync du FS source vers le FS crypté
monté ?
> Le 23 août 2018 à 10:44, dethegeek
> >
> Bonjour,
>
> J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un
> volume
> chiffré. Mes recherches ne m'ont doné que des méthodes
> d'installation
> frâiche.
>
> Quelqu'un a t il une bonne ressource pour m'éviter de tout
> réinstaller
> (et perdre du temps à tout reconfigurer) ?
>
--
Pierre Malard
«/Le courage, c'est de chercher la vérité et de la dire, /
/ c'est de ne pas subir la loi du mensonge triomphant qui
passe /
/ et de ne pas faire écho de notre âme, de notre bouche et de
nos mains /
/ aux applaudissements imbéciles et aux huées fanatiques./»
Jean Jaures - "Discours de jeunesse" - 1903
("`-/")_.-'"``-._
. . `; -._ )-;-,_`)
(v_,)' _ )`-. ``-'
_.- _..-_/ / ((.'
((,.-' ((,/ πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A-
)
)-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_):
24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--

Pierre Malard
Le #26486064
--Apple-Mail=_6F7362CF-342C-4664-81E6-E170D78D3E9A
Content-Type: multipart/alternative;
boundary="Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5"
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Le 24 août 2018 à 10:34, Daniel Caillibaud Le 23/08/18 à 16:38, dethegeek
bonjour
J'ai la chance d'avoir pris un réflexe: ne pas allouer tout l'espace
disque avec mes volumes logiques. De plus mes disques font 2 To et j'ai
des 4 To qui attendent la fin de l'opération pour aller dans une
machine de sauvegarde. L'espace disque n'est pas un souci.

Dans ce cas, tu peux comme le suggérait Pierre créer une partition et tout
copier
- si /boot n'est pas séparé, créer une petite partition /boot
non-chiffrée, y copier ton /boot actuel et l'ajouter à ton fstab actuel
(prévoit quand même ~200Mo mini, sinon ça peut se retrouver plein dès que
tu as plusieurs noyaux installés)
- créer une partition chiffrée (ou deux si tu veux sépare r /home)
- la monter dans ta debian actuelle
- rsync -ax / /partitionChiffreeMontee

Personnellement, j’ajouterai la copie d’éventuelles ACL (-A), exclurait les inutiles dans ce cas (—exclude), afficherait les statistiques à la fin (—stats) et, histoire de mettre les points sur les « i » j’ajouterai un « / » à la fin. Ce qui donnerai après avoir copié le contenu de « /boot » sur la nouvelle partition :
# rsync -aAx --exclude="/lost+found" --exclude="/boot" —stats /partitionChiffreeMontee/
Pour les modifications suivantes j’utiliserais un chroot pour éviter les erreurs :
# mount <Device_Chiffrée> /<partitionChiffreeMontee> (je suppose queque chose comme /dev/sdbN)
# mount <Nouvelle_Partition_BOOT> /<partitionChiffreeMontee>/boot
# mount --bind /dev /<partitionChiffreeMontee>/dev
# mount --bind /dev/pts /<partitionChiffreeMontee>/dev/pts
# mount --bind /sys /<partitionChiffreeMontee>/sys
# mount -t proc /proc /<partitionChiffreeMontee>/proc
# chroot /<partitionChiffreeMontee> /bin/bash
Sur une seule ligne :
# mount --bind /dev /<partitionChiffreeMontee>/dev && mount --bind /dev/pts /<partitionChiffreeMontee>/dev/pts && mount --bind /sys /<partitionChiffreeMontee>/sys && mount -t proc /proc /<partitionChiffreeMontee>/proc && chroot /<partitionChiffreeMontee> /bin/bash
Après on peut modifier le « /etc/fstab » de la partition cryptée, les autres fichiers et lancer un « update-grub ». Si on doit retirer le disque d’origine, il faut le faire suivre d’un « grub-install <Device du disque crypté> » si on est dans un disque formaté MBR ou, pour un disque GPT auquel on aura prévu une petite partition « BIOS boot » un « update-grub —modules=part_gpt <Device du disque crypté> » (/dev/sdb je présume).
Enfin, toujours si on retire le premier disque non crypté, il faut modifier le « grub.cfg » qui ne pointera plus sur le bon disque (/dev/sda = hd0 et /dev/sdb = hd1). Si le nouveau disque crypté est sur /dev/sdb, il va prendre la place du 1er si on le retire, il va donc s’appeler /dev/sda. Il faut donc modifier cela dans le fichier « grub.cfg » :
# sed --in-place=.OLD --expression='s/hd1/hd0/g' /<Nouvelle_Partition_BOOT>/grub/grub.cfg

- modifier /partitionChiffreeMontee/etc/fstab pour qu'elle ait une chance
de booter correctement, lui ajouter éventuellement un point de montage
pour la partition initiale non chiffrée
- créer un /partitionChiffreeMontee/etc/cryptab avec la bonne partition
(blkid pour avoir son uuid)
- update-grub et vérifier qu'il a bien trouvé cette nouvelle debian
- tenter un reboot sur ta nouvelle debian
Sinon, peut-être plus rapide, faire une nouvelle install et migrer ensuite
(les lignes suivantes supposent que tu as le même /boot pour l'ancienne et
la nouvelle, adapter si c'est pas le cas)
- enregistrer la liste des paquets de ta debian actuelle :
aptitude -F "%p" search ~i!~M > /boot/packages.list
# avec les paquets installés automatiquement
aptitude -F "%p" search ~i > /boot/packages.all.list
- lancer une install debian chiffrée sur de nouvelles partitions (install
minimale)
- booter sur cette debian chiffrée en root
- installer tous tes paquets avec
aptitude install $(</boot/packages.list)
- vérifier que tu as les mêmes dépendances
aptitude -F "%p" search ~i > /boot/packages.new.all.list
diff /boot/packages.new.list /boot/packages.new.all.list
- mount de ton ancienne partition
- rsync de ton home
- regarder chaque différence de /etc
diff -qr /etc /oldDebian/etc
il devrait pas y en avoir bcp plus que fstab et cryptab, pour vérifier que
tu oublie pas une config perso que tu avais faite
- reboot "normal" et login avec ton user ordinaire sur ta debian chiffrée
- après qq semaines tu devrais pouvoir virer l'ancienne debian
--
Daniel
Le philosophe cherche des solutions aux problèmes et
ne trouve que des problèmes sans solutions.
Sim


--
Pierre Malard
« le passé n'éclairant plus l'avenir, l'esprit marche dans les ténèbres »
Alexis de Tocqueville - Démocratie en Amérique
| _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'---''(_/--' `-'_) πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
</div>
<br class=""></body></html>
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5--
--Apple-Mail=_6F7362CF-342C-4664-81E6-E170D78D3E9A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
Comment: GPGTools - http://gpgtools.org
iQIzBAEBCgAdFiEE0KHTJ+AWKhmI+acm/pSWHuad/BgFAlt/+qMACgkQ/pSWHuad
/BgpUQ/9E/dg90OELqiDRvqcOKKQ3/TI0WmtrUPsvDa6FEjleCbj9H8YM6L+t/HF
sIb9vn2DOdFgh2/Yo4CFBqn2F67Y1QR6afoqnNexDA31xLzCcahHhbciZwlmWkM6
2KfSABSW5wDgzg8YMqVZDRmdMUBIltjBRZcIOVydGk1HwD4tzy6C0oNpXZvs8zX6
eEWd9DSKtOwsv1+bcQMe1Yo33VpcNdy4fF+OGr5Rrq/GuJ4B+T0VsSUw7z/3CDyt
SElfmemvM3xKv3nrAjENVHAqCW/wNKD4g6dx3TOgseJ60NrnjNain7ZWfn3yjpxU
Y6bXrNqeRT6VGlQXYgSDZgkf7XaSU/eRo4j0hwz1qMpQCrG/qOGvN1OW6VDxTpiN
zuRo1cEYadAlVTe9qvt3qaGg9kUiUDS8peafEHDCD4WY0yG/MSA9CnHVydwYDwjS
eJ4zmjJ4aM15H1oU5cgZBufGtZ4jf5uGmouXx6kV2lCaEsylX0KsukfypMfJWZKy
TOEwddyKHhPhiLZLatn3o7MnemyINfOT7mQ5/sQMeICR8eq9cybihP0R0w6qATqq
GWU53C9hc+z4SJcFWGM3PbHXT5URfHd0abc4IAZVJWyYfJ4S4O/BzGWvS0nwr8+e
8jHGI5y/0D9K+jJl22wLhRyNfdVVB5NuzGHEkT1GjaWLEm4LYWA =4WYE
-----END PGP SIGNATURE-----
--Apple-Mail=_6F7362CF-342C-4664-81E6-E170D78D3E9A--
dethegeek
Le #26486063
Bonjour
Le vendredi 24 août 2018 à 14:31 +0200, Pierre Malard a écrit :
Le 24 août 2018 à 10:34, Daniel Caillibaud écrit :
Le 23/08/18 à 16:38, dethegeek > bonjour
>
> J'ai la chance d'avoir pris un réflexe: ne pas allouer tout
> l'espace
> disque avec mes volumes logiques. De plus mes disques font 2 To
> et j'ai
> des 4 To qui attendent la fin de l'opération pour aller dans une
> machine de sauvegarde. L'espace disque n'est pas un souci.
Dans ce cas, tu peux comme le suggérait Pierre créer une partition
et tout
copier
- si /boot n'est pas séparé, créer une petite partition /boot
non-chiffrée, y copier ton /boot actuel et l'ajouter à ton fstab
actuel
(prévoit quand même ~200Mo mini, sinon ça peut se retrouver plein
dès que
tu as plusieurs noyaux installés)
- créer une partition chiffrée (ou deux si tu veux séparer /home)
- la monter dans ta debian actuelle
- rsync -ax / /partitionChiffreeMontee

Personnellement, j’ajouterai la copie d’éventuelles ACL (-A),
exclurait les inutiles dans ce cas (—exclude), afficherait les
statistiques à la fin (—stats) et, histoire de mettre les points sur
les « i » j’ajouterai un « / » à la fin. Ce qui donnerai après avoir
copié le contenu de « /boot » sur la nouvelle partition :


Je suis plus partisan d'un miroir lvm pour cette étape, on peut
"mirrorer", puis "splitter" le mirror en 2 lv distincts. J'ai testé.
C'est pour moi infiniment plus sûr qu'un rsync, bien que j'aime
beacuopup cet outil.
Ma difficulté réside dans la config manuelle de ceryptsetup, pour être
au plus proche d'un crytpsetup fait via une install fraiche.
--
Pierre Malard
« le passé n'éclairant plus l'avenir, l'esprit marche dans les
ténèbres »
Alexis de Tocqueville -
Démocratie en Amérique
| _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'---''(_/--' `-'_) πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- )
)-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_):
24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
dethegeek
Le #26486168
j'ai prévu un seul vg chiffré, contenant tous mes lv sensibles: rootfs
et home. J'ai initialement prévu que boot soit non chiffré, mais c'est
pas une bone idée. On peut techniquement attaquer ce volume pour y
mettre un keylogger.
La bonne pratique est donc de chiffrer /boot, grub , de ce que je lis,
le gère; et vérifier avant tout déchiffrement qu'il n'y a pas de
hardware suspect sur un port USB, un clavier modifié, et autres
joyeusetés. Reste encore des failles côté bios / uefi; ça devient
vraiment de la paranoïa à ce stade, mais à force d'apprendre ce qu'il
est possible de faire pour pénétrer une forteresse numérique, je finis
par me dire qu'on ne peut que se protéger des "petits joueurs".
Cela dit il y a encore cette solution pour attaquer:
https://www.engadget.com/2008/10/20/keyboard-eavesdropping-just-got-way-easier-thanks-to-electrom/
Il s'agit d'écouter les émissions éléctromagnétiques des claviers pour
trouver les frappes. Ca peut se faire au travers d'un mur, à 20m de
distance. Pour votre gouverne...
A défaut de solution prêt à l'emploi, je vais continuer la création de
ma procédure en comparant ce que j'ai fait avec vos propositions. Je
sais que je ne suis pas très loin; je peux presque migrer à chaud, avec
une toute petite iinterruption de service (j'adore chercher la solution
qui vise à ne pas interrompre la machine ou très peu; LVM aide
énormément pour cela).
Le vendredi 24 août 2018 à 16:32 +0200, Daniel Caillibaud a écrit :
Le 24/08/18 à 16:13, Daniel Caillibaud
/dev/mapper/sda5_crypt est le pv dans lequel j'ai mes 3 lv root,
swap et
home

Juste une remarque, la plupart des tutos / docs parlent de chiffrer
un lv
puis y mettre un filesystem, mais si tu as plusieurs partitions
chiffrées
et ne veut taper qu'une seule passphrase au boot, ça oblige à mettre
la
passphrase dans un fichier [1]
Je trouve plus simple de chiffrer une partition et de l'utiliser
comme pv
pour lvm, tous les lv qu'il contient seront de fait chiffrés (faut
juste
faire attention si tu as un vg à cheval sur plusieurs pv, mais ça
peut
justement servir dans ton cas pour déplacer un vg d'un pv non chiffré
à un
chiffré, et inversement, ou bien quand tu changera de disque à
déplacer le
vg d'un pv chiffré à un autre pv chiffré).
Si tu réussis à créer le pv chiffré et y déplacer ton vg et ses lv,
raconte
ça ici, ça servira sûrement à d'autres ;-)
[1] sur la partition / qui va monter les autres avec ce fichier, pas
si
grave car si elle est montée c'est qu'on a déjà tapé la passphrase,
mais
quun qui peut accéder aux droits root sur la machine qui tourne déjà
pourra
lire ce fichier même si c'est pas lui qui a tapé la passphrase)
Pascal Hambourg
Le #26486218
Le 24/08/2018 à 21:50, dethegeek a écrit :
j'ai prévu un seul vg chiffré, contenant tous mes lv sensibles: rootfs
et home. J'ai initialement prévu que boot soit non chiffré, mais c'est
pas une bone idée. On peut techniquement attaquer ce volume pour y
mettre un keylogger.
La bonne pratique est donc de chiffrer /boot, grub , de ce que je lis,
le gère

Oui. Mais la core image de GRUB (qui demande de taper la passphrase pour
déchiffrer le volume contenant /boot) reste en clair et donc vulnérable.
Si le but est de se protéger de la divulgation des données en cas de
perte ou vol de l'ordinateur, alors le chiffrement de /boot n'est pas
nécessaire, il ne contient pas de donnée sensible.
Si le but est de se protéger contre une intervention illicite sur
l'ordinateur passée inaperçue, alors le chiffrement quel qu'il soit ne
suffit pas car il reste toujours une partie en clair pour l'amorçage. Il
faut y ajouter la vérification de l'intégrité.
dethegeek
Le #26486565
Bonjour,
Le samedi 25 août 2018 à 10:11 +0200, Pascal Hambourg a écrit :
Le 24/08/2018 à 21:50, dethegeek a écrit :
j'ai prévu un seul vg chiffré, contenant tous mes lv sensibles:
rootfs
et home. J'ai initialement prévu que boot soit non chiffré, mais
c'est
pas une bone idée. On peut techniquement attaquer ce volume pour y
mettre un keylogger.
La bonne pratique est donc de chiffrer /boot, grub , de ce que je
lis,
le gère

Oui. Mais la core image de GRUB (qui demande de taper la passphrase
pour
déchiffrer le volume contenant /boot) reste en clair et donc
vulnérable.
Si le but est de se protéger de la divulgation des données en cas de
perte ou vol de l'ordinateur, alors le chiffrement de /boot n'est
pas
nécessaire, il ne contient pas de donnée sensible.
Si le but est de se protéger contre une intervention illicite sur
l'ordinateur passée inaperçue, alors le chiffrement quel qu'il soit
ne
suffit pas car il reste toujours une partie en clair pour l'amorçage.
Il
faut y ajouter la vérification de l'intégrité.

Bonne remarque. Du coup il faut un certificat pour vérifier GRUB ainsi
que /boot si elle n'est pas chiffrée. Avoir /boot chiffré permettrait
de réduire le volume de données à valider. Un système TPM aiderait.
Publicité
Poster une réponse
Anonyme