Bestehendes RAID + LVM im Betrieb verschlüsseln?

[mclien]

Momentan sieht das Datenerzeichnis auf mein Server so aus:
RAID1 (sda3 und sdb3) + RAID1 (sdc1 und sdd1) -> LVM -> /daten
nun würde ich das ganze gerne Verschlüsseln ohne alles neu aufsetzten zu müssen.
(backup ist vorhanden)
Kann ich formal so vorgehen?:
Partition aus den RAID aushängen,
part. verschlüsseln, wieder einhängen,
Raid syncen.
-> der reihe nach mit allen part.

Klar Ich muss dann (zunächst) bei jedem start allen Platten die Passphrases einzeln übergeben, wäre aber akzeptabel, weil der Rechner eher selten neu gestartet wird.
Ausserdem, kann ich ja nach erfolgter Verschlüsselung, die keys auf der 1. zu entschlüsselnden Platte ablegen.

[jph]

Gegenvorschlag: du verschlüsselst nicht LV für LV, sondern das Device, auf dem das Physical Volume liegt. Dadurch wird die komplette VG verschlüsselt. Ich würde allerdings, wenn man es vorher nicht gemacht hat, einen solchen Stunt zuerst in einer virtuellen Maschine ausprobieren. Ein minimales Debian mit RAID ist ja schnell aufgesetzt.

Bei einer aus mehreren PVs bestehenden VG wird es allerdings interessant.

[mclien]

Ich will daoch gar nicht die LV sverschlüsseln, auch nicht die PVs. Würde ja beides im Betrieb nicht funktionieren ohen Daten neu hin und her zu copieren.

Also:
sda3 und sdb3 bilden md2 (RAID1), erstes PV
sdd1 und sde1 bilden md3 (RAID1), 2. PV
diese beiden PVs bilden dann vg0 und hierauf liegt dann ein LV

Die eigentliche Frage ist, ob folgendes Vorgehen funktionieren kann:
sda3 aus dem raid verbund entfernen,
sda3 verschlüsseln
sda3 wieder in den raid verbund einhängen.
--sync abwarten
mit sdb3 wiederholen.
selbe vorgehen mit sdd1 und sde1

dann müsste ich -alles läuft fehlerfrei- danach alle Daten auf einem verschlüsselten LV haben ohne Daten aus dem Backup zurück holen zu müssen.

[rendegast]

Das dm-device "sda3-entschlüsselt" sollte weniger Platz bieten als das vorher im raid eingebundene sda3,
daher läßt sich das dm-device eventuell nicht wieder dem raid hinzufügen.

[jph]

Wenn ich dich recht verstehe, willst du eine Verschlüsselung einführen, ohne die bestehenden Dateisysteme und die darauf gespeicherten Daten anfassen zu müssen. Kann klappen – du musst halt sicherstellen, dass der Device Mapper die Devices in der richtigen Reihenfolge hochfährt und du immer noch bootfähig bist. Da sind wir wieder dabei, so etwas in einer VM auszuprobieren.

Folgende Anmerkungen:

• Zunächst ist da die bereits angesprochene Größenproblematik beim Wiedereinfügen des entschlüsselten Device, da sich LUKS etwas Platz zum Ablegen der Schlüssel abzweigen wird. Dir steht es natürlich frei, auf LUKS zu verzichten und dein Glück stattdessen mit cryptoloop zu versuchen.
• Wichtig: du fügst nicht sda3 wieder in dein RAID ein, sondern das entschlüsselte Gerät, das anders heißt.
• Jedes RAID besteht in deinem Szenario aus zwei unabhängig voneinander verschlüsselten Partitionen, d.h. du hast die doppelte CPU-Last gegenüber einem verschlüsselten PV. Bei letzterem wird nur einmal verschlüsselt und dieser Schlüsseltext identisch auf zwei Partitionen geschrieben.

Ich an deiner Stelle würde den „sauberen“ Weg gehen, d.h. die PVs verschlüsseln mit allen damit verbundenen Konsequenzen (LVs neu, Dateisysteme neu, Daten sichern und zurücksichern).

[mclien]

das mit dem doppelten CPU Aufwand hatte ich tatsächlich nicht auf dem Schirm. Zumal das ja noch schlimmer wird, wenn ich das 2. raid mit in das LV aufnehme. dann wären wir bei dem 4-fachen an CPU Rechnerei. Das wir der atom CPU sicher nicht helfen...
Plus die Platz Problematik. Wäre jetzt meine 3. Platte (die einzeln gemountet ist) nicht gerade am verrecken wäre, könnte ich mit der arbeiten..
OK, also erstmal neue Platten besorgen.

[mclien]

Nachdem ich mir mal angeschaut haeb, wieviel Plattenplatz ich den tatsächlich auf dem Server nutze, werde ich von meinem 4-Platten System (2x RAID1 als ein LVM) auf ein 2-Plattensystem wechseln.
Das habe ich zur Zeit:

Code: Alles auswählen

# / was on /dev/md1 during installation
UUID=5f85e5ee-80b2-440c-97fb-f93cb0b995c6 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/md0 during installation
UUID=1a5636d9-1e8e-4583-8fb6-e5e97749044e /boot           ext3    defaults        0       2
/dev/mapper/vg0-data_lv0 /daten          ext4    defaults        0       2
# swap was on /dev/sda3 during installation
UUID=8e0a2dea-a435-4a11-a351-ea4a9619c4b2 none            swap    sw              0       0
# swap was on /dev/sdb3 during installation
UUID=6ad85707-5036-440e-8433-3c4bb81d2de2 none            swap    sw              0       0

Die neuen Platten sollen dann 3 RAID Partitioinen haben
/boot (unverschlüsselt)
/ (verschlüsselt)
/daten (verschlüsselt)

Die Frage ist jetzt: System neu aufsetzen oder RAID aufsetzen verschlüsselung drauf und per rsync alles kopieren?
Im wesentlichen macht der Server NFS und dient als interner IMAP Server (dovecot). Eigentlich scheue ich vor alle den IMAP Server wieder neu aufzusetzen.

Für die Verschlüsselung scheint mir allerdins die Variante mit der Neuinstallation einfacher...

[jph]

rsync! Wenn du das PV verschlüsselst und VG/LVs wie zuvor benennst, kannst du sogar die fstab in großen Teilen behalten.

Das kopieren der Daten kann der Rechner ja unbeaufsichtigt über Nacht machen.

[mclien]

OK. das ganze muss ich ja mit einem live system machen, sonst habe ich ja ein Problem mit den sich ändernden Daten.

das heißt doch aber ich muss nach dem boot mein RAID/LVM manuell zusammenbauen...
Das habe ich bisher noch nicht gemacht/machen müssen.

Wie gehe ich denn das an?

[mclien]

So, nochmal ein bisschen Analyse betrieben:
In 10 Jahren habe ich von 2,5TB 0,5TB belegt.
Daraus folgere ich mal, dass ich wesentlich eher defekte Platten ersetzen muss, als ein LVzu vergrössern,weil der Platz knapp wird.

Somit werde ich dann auf LVM verzichten und alles von meinem LVMauf RAID 1 mit verschlüsselung wechseln.

Mein Plan sieht dann so aus:
alte und neuePlatten in den Rechner bauen, Live System starten.

bestehende RAID und LV starten mountpoint -> /old
neue Platten partitionieren RADI einrichten verschlüsseltes Dateisystem draufbauen (ausser /boot) mount point -> /new

rsync von /old nach /new
/etc/fstab auf den neuen Platten anpassen mit UUIDs

grub auf beide MBR der Platten des /boot RAID

Livesystem aus. alte Platten raus, System booten.

Habe ich was übersehen,vergessen?
(/etc/mdadm/mdadmd.conf, /etc/fstab und alle LVM Ausgaben habe ich local gesichert)

[jph]

/etc/crypttab pflegen, damit das System beim Booten die Platten entschlüsselt bzw. nach dem Passwort fragt.

Theoretisch reicht es, wenn via crypttab nach dem Passwort für / gefragt wird. Die Passwörter für mögliche weitere Dateisysteme kannst du ja auf / speichern, bspw. in einer .mount-Unit.

[mclien]

System ist jetzt mit systemrescuecd gestartet, alle bestehenden RAID wurden erkannt.

Zunächst muss ich jezt das LM wieder zusammen bauen, wasichunter den Umständen noch nicht gemacht habe.

Und die Frage, ob ich die neuen Platten jetzt erstmal mit Zufall vollschreibe oder nicht.

EDIT: hier ist das gut beschrieben:
http://www.linuxwave.info/2007/11/mount ... ivecd.html

[jph]

Sofern die Verschlüsselung nur dem Schutz deiner Privatsphäre bei Diebstahl der Platten dient, kannst du das Vollschreiben mit Zufallszahlen m. E. sparen.

Falls du gerade unsicher bist, wie du weiter vorgehen sollst: bastle dir doch in VirtualBox flink eine VM mit dem gleichen Setup zum experimentieren. Vorteil: eine VM kennt Snapshots.

[mclien]

Guter Hinweis mit der VM, aber flink ist da ein dehnbarer Begriff.

VM mit 4Platten, 4xmd, wovon 2ein LV bilden,installiern mit Daten füllen, 2 weite platten, die VM live bootenund dann alle durchspielen...
Flink ist was anderes, oder?

Mein Plan war eher das alte System komplett ro zu mounten, dann habe ich das immernoch zur Verfügung. backup der Daten habe ich zusätzlich.

Zu den Zufallszahlen. es geht (leider) möglicherweise auch darum, dass die Platten bis zu 6 Monate legal in dem Besitz anderer sind.

[jph]

Du musst die VM ja nicht mit Nutzdaten füllen. Es reicht ja, wenn du dein Setup damit bootfähig konfigurieren lernst. Die virtuellen Platten müssen nur ein, zwei GB groß sein.

[mclien]

Stand der Dinge:
/boot (ohne Verschlüsselung) auf /dev/md127 gesynct
/ läuft gerade der rsync (/dev/mapper/cryptroot auf /dev/md128)

Plan ist dann erstmal das neue System bootfähig zu bekommen und danach erst die Daten Partition anzugehen.

Anpassen auf dem neuen System muss ich dann:
/etc/fstab
/etc/crypttab (die muss ich wahrscheinlich anlegen)
(ist crypsetup installiert? kein cryptsetup ind /old/sbin. Mist also nicht -> altes System booten und nachinstallieren.)
EDIT (zumindest weiß ich jetzt schonmal, dass mein altes System noch bootet, cryptsetup ist installiert)

Muss ich dann noch initramfs neu erstellen?

[mclien]

OK, jetzt stehe ich doch auf der Leitung.

/boot und / sind auf die neuen Platten gesynct
fstab cryptab und mdadm.conf sind angelegt.

Bin jetzt aber (wieder, da ich es so selten mahe) unschlüssig.
initramfs und grub2 installation: muss ich die mit chroot machen? (als in das neue root verz.)

[jph]

Ja. /dev etc. zuvor mit -o bind mounten.

[mclien]

das mit dem initramfs macht mich jedes mal fertig...
nehmen wir mal an /dev /proc /sys sind gemountet (on der live cd), das neue / und /boot sind auch gemountet und ich bin mit chroot in das passende root gewechselt.

Dann sichere ich mein aktuelles initramf:

Code: Alles auswählen

cp -p /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r).img_2017_03_05

EDIT:offenbar nicht richtig, denn "uname -r" liefert den kernel des laufenden live-systems (wahrscheinlich trivial, musste ich mir aber erst beweisen)
Blos ist mir jetzt (mal wieder) nicht klar:
neu erstellen "mkinitrmfs" oder updaten "update-initramfs"?
das hier habe ich imcentOS wiki gefunden:

Code: Alles auswählen

mkinitrd -f -v /boot/initrd-$(uname -r).img $(uname -r)

verstehe ich das richtig,dass durch das chroot uname-rden passenden kernel (aus der chroot Umgebung) zurück gibt?
EDIT:offenbar nicht richtig, denn "uname -r" liefert den kernel des laufenden live-systems (wahrscheinlich trivial, musste ich mir aber erst beweisen)

[jph]

Code: Alles auswählen

# update-initramfs -u -k all

Das erzeugt das initramfs für alle installierten Kernel neu.

[mclien]

Code: Alles auswählen

root@sysresccd:/# update-initramfs -u -k all
update-initramfs: /boot/initrd.img-3.2.0-4-amd64 has been altered.
update-initramfs: Cannot update. Override with -t option.
update-initramfs: Generating /boot/initrd.img-3.2.0-2-amd64
[ hier folgen dann Meldungen über aktive RAID Verbünde die aktiv aber nicht in mdadm.conf sind ]

die Warnings über die RAID Verbünde sind OK,da es sich um die alten handelt.

Das image "initrd.img-3.2.0-4-amd64" mache ich dann mit der vorgeschlagenen -t Option nochmal?

Code: Alles auswählen

update-initramfs -t -k vmlinuz-3.2.0-4-amd64

EDIT:
Moment. Ich habe ja cryptsetup noch nachinstallieren müssen, also muss ich /boot nochmal syncen?
EDIT2: altes /boot nochmal zu neuem /boot gesynct. Jetzt passt alles.
Ausser die zu erwartenen Fehler für mdadm bzgl. der Alten Platten (RAID Verbünde)

[mclien]

Grub install klemmt noch:
innerhalb von chroot:

Code: Alles auswählen

root@sysresccd:/# grub-install /dev/sdc
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/md127 failed.

sdc1 und sdd1 bilden md127 (unverschlüsselt).
/dev/md127 ist in das neue chroot gemounted und auch lesbar.

Da ist was mit meinem Partitiontablenicht in Ordnung, denke ich:

Code: Alles auswählen

Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdd: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  524MB   523MB   ext2         1     raid
 2      524MB   4744MB  4219MB               2
 3      4744MB  75.2GB  70.4GB               3     raid
 4      75.2GB  3001GB  2925GB               4     raid

ich hatte das boot-flag zwar gesetzt, aber offenbar ist die Information "primary" nicht angekommen? (aber wie setze ich denn das? Interaktiv wurde es nicht abgefragt oder heißt "type" bei parted jetzt "Name"?)
Und wo ist das boot-flag hin dass ich mit:

Code: Alles auswählen

(parted) set 1 boot on

gesetzt hatte?
Oder war es ein fehler ext2 zu nehmen für /boot?

Code: Alles auswählen

mount
/dev/md127 on /boot type ext2 (rw,relatime,errors=continue,user_xattr,acl)

[mclien]

Code: Alles auswählen

root@sysresccd:/# mdadm -D /dev/md127
/dev/md127:
        Version : 0.90
  Creation Time : Sat Mar  4 17:18:26 2017
     Raid Level : raid1
     Array Size : 510912 (499.02 MiB 523.17 MB)
  Used Dev Size : 510912 (499.02 MiB 523.17 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 127
    Persistence : Superblock is persistent

    Update Time : Sun Mar  5 13:06:52 2017
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 3de7d48a:7c67c842:c44c77eb:7ee19756 (local to host sysresccd)
         Events : 0.18

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1

Allerdings finde ich diesen teil von /etc/mdadm/mdadm.conf merkwürdig:

Code: Alles auswählen

ARRAY /dev/md/127_0 metadata=0.90 UUID=3de7d48a:7c67c842:c44c77eb:7ee19756
ARRAY /dev/md/128 metadata=1.2 name=sysresccd:128 UUID=883b5984:310045c3:94bb2809:4d46bc9e
ARRAY /dev/md129 metadata=1.2 name=sysresccd:129 UUID=b360b8e5:b30a047e:dd887155:2a75262f

EDIT:
grub.cfg wird ja auch nicht mehr correct sein, oder? (Ich habe ja metadata jetzt auf 0.9 orher war es auf 1.2) Also erstmal:

Code: Alles auswählen

grub-mkconfig -o /boot/grub/grub.cfg

?

[jph]

Poste bitte mal die Ausgabe von blkid, damit ich die Geräte zuordnen kann.

[mclien]

Code: Alles auswählen

root@sysresccd:/# blkid
/dev/sdb1: UUID="99c72451-42f1-5e69-ea6a-81201c982299" UUID_SUB="346fc220-9028-5b45-6dc3-ee58cf94d94a" LABEL="moya:0" TYPE="linux_raid_member" 
/dev/md1: UUID="5f85e5ee-80b2-440c-97fb-f93cb0b995c6" TYPE="ext4" 
/dev/sda3: UUID="8e0a2dea-a435-4a11-a351-ea4a9619c4b2" TYPE="swap" 
/dev/md0: UUID="1a5636d9-1e8e-4583-8fb6-e5e97749044e" SEC_TYPE="ext2" TYPE="ext3" 
/dev/md2: UUID="TJkjf2-IPZF-xwzU-AxPg-51aU-RZNv-CkiPPG" TYPE="LVM2_member" 
/dev/mapper/vg0-data_lv0: UUID="f2f6795d-e200-4c80-af9d-7bfb7d1ae7fc" TYPE="ext4" 
/dev/sdb2: UUID="03ddb35a-f90e-e32a-a86a-8fb8f1346590" UUID_SUB="0b4c7a68-7f16-6777-80d1-a76996b0acd3" LABEL="moya:1" TYPE="linux_raid_member" 
/dev/sdb4: UUID="6efe12c9-4da7-1cbc-cf08-68e20d1b5304" UUID_SUB="fda14d42-c85b-c6c3-e0a4-a34b339de259" LABEL="moya:2" TYPE="linux_raid_member" 
/dev/sda1: UUID="99c72451-42f1-5e69-ea6a-81201c982299" UUID_SUB="ec1039d0-34d5-f27b-fa28-99cf1a829f98" LABEL="moya:0" TYPE="linux_raid_member" 
/dev/sda2: UUID="03ddb35a-f90e-e32a-a86a-8fb8f1346590" UUID_SUB="884b5048-c62a-0763-8dcd-f282ed1bedc8" LABEL="moya:1" TYPE="linux_raid_member" 
/dev/sda4: UUID="6efe12c9-4da7-1cbc-cf08-68e20d1b5304" UUID_SUB="b80dfabd-1e9c-958c-4c06-e677de5b31d9" LABEL="moya:2" TYPE="linux_raid_member" 
/dev/sdd1: UUID="3de7d48a-7c67-c842-c44c-77eb7ee19756" UUID_SUB="f8753be8-6c08-951a-3732-13138003a439" LABEL="moya:3" TYPE="linux_raid_member" 
/dev/sdb3: UUID="6ad85707-5036-440e-8433-3c4bb81d2de2" TYPE="swap" 
/dev/md3: UUID="WyTRHF-bPBb-JPYS-WUR6-ynfL-bTim-2YrQ5a" TYPE="LVM2_member" 
/dev/sdc1: UUID="3de7d48a-7c67-c842-c44c-77eb7ee19756" TYPE="linux_raid_member" UUID_SUB="af960874-e0e0-d45a-4962-1dad1ebbba34" LABEL="moya:3" 
/dev/loop0: TYPE="squashfs" 
/dev/sdc3: UUID="883b5984-3100-45c3-94bb-28094d46bc9e" UUID_SUB="2c0b2e1a-99e0-2f0e-31fa-4605e136cb85" LABEL="sysresccd:128" TYPE="linux_raid_member" 
/dev/sdc4: UUID="b360b8e5-b30a-047e-dd88-71552a75262f" UUID_SUB="ecbe289a-5e27-39dc-c14d-f8a80d8d16b7" LABEL="sysresccd:129" TYPE="linux_raid_member" 
/dev/sdd3: UUID="883b5984-3100-45c3-94bb-28094d46bc9e" UUID_SUB="c71c6277-806a-9200-498a-70742e6217ec" LABEL="sysresccd:128" TYPE="linux_raid_member" 
/dev/sdd4: UUID="b360b8e5-b30a-047e-dd88-71552a75262f" UUID_SUB="11fc60c9-1bba-044a-e8b2-5fe3f858e657" LABEL="sysresccd:129" TYPE="linux_raid_member" 
/dev/sde1: UUID="f6de1d94-d82a-5755-2c93-4fe167a1e035" UUID_SUB="af960874-e0e0-d45a-4962-1dad1ebbba34" LABEL="moya:3" TYPE="linux_raid_member" 
/dev/sdf1: UUID="f6de1d94-d82a-5755-2c93-4fe167a1e035" UUID_SUB="f8753be8-6c08-951a-3732-13138003a439" LABEL="moya:3" TYPE="linux_raid_member" 
/dev/sdg1: LABEL="SYSRESC" UUID="CFB2-6677" TYPE="vfat" 
/dev/md127: UUID="a9349ca2-6a9e-4640-923c-3dbd7c028aa1" TYPE="ext2" 
/dev/md128: UUID="e8ba3f74-ffff-45ab-8965-bbd0a254af3c" TYPE="crypto_LUKS" 
/dev/mapper/cryptroot: UUID="74346974-7871-4f4a-b0c3-33630b8a2dcd" TYPE="ext4" 
/dev/md129: UUID="f7a87547-117c-492d-ac05-8637663a6416" TYPE="crypto_LUKS" 
/dev/mapper/cryptdata: UUID="734b1b32-438a-4756-8e0a-7c8ebf11679f" TYPE="ext4" 

Die LABEL zuordnungen scheinen irgendwie nicht ganz zu passen. moya:3 steht bei dem Pärchen sdc1/sdd1 und bei sde1/sdf1
EDIT:
Innerhalb der chroot umgebung:

Code: Alles auswählen

root@sysresccd:/# mdadm --detail --scan
ARRAY /dev/md/0 metadata=1.2 name=moya:0 UUID=99c72451:42f15e69:ea6a8120:1c982299
ARRAY /dev/md/1 metadata=1.2 name=moya:1 UUID=03ddb35a:f90ee32a:a86a8fb8:f1346590
ARRAY /dev/md/2 metadata=1.2 name=moya:2 UUID=6efe12c9:4da71cbc:cf0868e2:0d1b5304
ARRAY /dev/md/127_0 metadata=0.90 UUID=3de7d48a:7c67c842:c44c77eb:7ee19756
ARRAY /dev/md/128 metadata=1.2 name=sysresccd:128 UUID=883b5984:310045c3:94bb2809:4d46bc9e
ARRAY /dev/md/3 metadata=1.2 name=moya:3 UUID=f6de1d94:d82a5755:2c934fe1:67a1e035
ARRAY /dev/md129 metadata=1.2 name=sysresccd:129 UUID=b360b8e5:b30a047e:dd887155:2a75262f

Ich verstehe gerade gar nicht warum es die Abweichung md127 und md127_0 gibt und warum die UUIDsverschieden sind.
denn hiersieht es so aus als ob sdc1 und sdd1 md127 bilden (wie es sein soll:

Code: Alles auswählen

root@sysresccd:/# cat /proc/mdstat
md127 : active raid1 sdc1[0] sdd1[1]
      510912 blocks [2/2] [UU]

Allerdings habe ich das alte System zwischendrin nochmal starten müssen, um cryptsetup zu installiern.evtl.hat das live system dann nochmal eine andere UUID für das RAID vergeben?