staging.inyokaproject.org

Hallo Ubuntuusers,

Ziel war, Kubuntu als verschlüsselte Installation auf meinem System mit SSD (sda) und HDD (sdb) zu bringen, wobei klassisch die Systemdateien, also /, (neben unverschlüsseltem Uefi und /boot) auf der SSD und Home auf der HDD liegen sollten. Auch Swap wollte ich auf die HDD legen (Schreibvorgänge auf SSD gering halten). Die entsprechenden Anleitungen, die ich erfolgreich auf einem Laptop mit einer Platte umsetzen konnte (und dabei auch erfolgreich Home umziehen konnte), decken diesen spezielleren Fall klarerweise nicht ab. Ich habe die LVM-Infos zur Initialisierung der physical volumes, Verwaltung von VolGroups und Logical Volumes mit einbezogen, hab's aber erst einmal so nicht hingekriegt, eine VolGroup, welche Partitionen auf beiden Platten zusammenfasst, zu erstellen.

Deswegen hab ich zunächst einmal eine geführte vollverschlüsselte Installation auf der SSD gemacht, um erst mal mögliche Bootprobleme in den Griff zu kriegen (Uefi-Modus). Das ist soweit in Ordnung und das neue System Jammy funktioniert.

Über die nun folgenden Schritte zur Integration des alten Home bin ich mir nicht recht im Klaren. Gibt es mehrere Wege zum Ziel, also die A1) freie Partition sdb2 mit Luks zu verschlüsseln, A2) das aktuelle Home dorthin umziehen, A3) die alten Homedaten dorthin zu kopieren und A4) mit pam-mount das Einbinden konfigurieren (das sehe ich eher als eine Notlösung, die ich im Übrigen mit Rumprobieren auch noch nicht erreicht habe, weil Befehl cryptsetup luksOpen Probleme macht), oder wäre es besser/möglich, B1) die neue leere sdb2 in die verschlüsselte VolGroup zu holen und B2,3) diese als neues Home einzubinden?

Aktueller Stand: sdb2 ist in die VolGroup eingehängt, aber noch unformatiert.

Bevor es an die Details geht, die hier ja noch fehlen, möchte ich erst einmal wissen, ob ich die grundsätzlichen Möglichkeiten und event. Alternativen überhaupt richtig einschätze.

/home gehört unbedingt mit auf SSD.

Die HDD kannst du für alles verwenden wo Geschwindigkeit keine Rolle spielt (Filme usw.)

Ich nutze LUKS & LVM sowohl auf SSD als auch HDD, aber das sind getrennte Volume Groups. Es macht keinen Sinn, SSD und HDD zu kombinieren. Es sei denn du nimmst die SSD komplett nur als Cache, aber das kommt für mich so nicht in Frage.

Montyfrisian schrieb:

[…] sdb2 ist in die VolGroup eingehängt

Das ist schlecht. Zwar ist es technisch möglich, Datenträger mit unterschiedlichem Zeitverhalten in einer gemeinsamer Volumegroup zusammen zu fassen, jedoch ist das keine gute Entscheidung. Richte besser für SSD und HDD jeweils eine eigene Volumegroup ein.

Danke für eure bisherigen Anworten ...!

@kB betr. Verschiebung des Themas:

Sorry, habe die Leitlinien nicht ignoriert oder fahrlässig behandelt. Letztlich geht es ja um sinnvolle Verschlüsselung des Systems bei gegebener Hardwarekonstellation und nicht um Installationsprobleme.

Betr.: unterschiedliche Zugriffsgeschwindigkeiten bei HDD und SDD Als ich mir den Rechner anschaffte, wollte ich ein System, dass einfach schnell betriebsbereit ist. Die Zugriffsgeschwindigkeit auf unterschiedliche Datenarten war und ist immer noch eher zweitrangig. Ihr schreibt, "es mache keinen Sinn" bzw. es sei "schlecht". Also, ich verstehe das so, dass ich mit der Kombination das Geschwindigkeitspotential der SSD ausbremse. Ist das richtig oder ergeben sich möglicherweise andere gravierende Konsequenzen?

Ok, ich hab mich inzwischen noch anderswo über LVM informiert und mich jetzt entschlossen, einfach ein wenig zu experimentieren. Learning by doing. 2 VG, eine auf SSD für Ubuntu mit separatem Home inkl. Bilderarchiv, die andere VG, separat verschlüsselt, mit allen anderen Datenbeständen auf die HDD. Wäre das sinnvoll?

Eine weitere konkrete Frage: Hatte irgendwo gelesen (und finde es nicht wieder), dass /boot ungefähr 120MB groß sein sollte. Stimmt das? Der Partitionsmanager hat es bei mir 260M groß gemacht - ist das nötig? Hier laufen bis zum nächsten Upgrade die Kernel auf, ja? (Sorry wegen dummer Fragen ...)

Und noch ne konkrete Frage LVM betreffend:

Die Seite "System verschlüsseln" enthält beim Befehl pvcreate im Pfad den Begriff "mapper". Der taucht auf der Seite "Logical Volume Manager" nicht auf. Kapiere ich nicht richtig, die Sache mit dem Mapper device ... Spielt das nur eine Rolle, wenn man eine verschlüsselte VG erzeugen möchte?

So, jetzt hab' ich ein bisschen studiert und probiert und, dem Rat von "Frostschutz" und "kB" folgend, die eine SSD und HDD zusammenfassende Volume Group wieder weggenommen und /home auf der schnellen Platte belassen. Allerdings soll /home nach bewährter Manier eine eigene vom System getrennte Partition erhalten, die dann per libpam-mount beim Anmelden eingebunden werden soll. Ich hab nicht rausfinden können bzw. nicht verstanden, ob man dafür ein PV/VG/LV braucht oder ob man das LV als Homeverzeichnis auch ohne VG haben kann.

Jedenfalls, wie unten zu sehen ist, ist das als Home gedachte LV in einer eigenen verschlüsselten VG angelegt.

Probleme bereitet das automatische Mounten per libpam-mount. Ich habe dazu die UUs-Anleitung befolgt (fehlt da im Abschnitt pam-mount konfigurieren nicht etwas?) und die xml in /etc/security ediert und, als das nicht funktionierte, einige andere Infos zum Thema herangezogen, doch ich finde den Fehler nicht. Der fürs separate Home erzeugte Lukscontainer lässt sich auch in Dolphin nicht entschlüsseln; Fehlermeldung:

"Beim Zugriff auf „Persönlicher Ordner“ ist ein Fehler aufgetreten, die Meldung lautet: Ein nicht genauer angegebener Fehler ist aufgetreten: No such interface “org.freedesktop.UDisks2.Filesystem” on object at path /org/freedesktop/UDisks2/block_devices/dm_2d3"

Die in der Anleitung genannte Zeile fürs Konfigurieren von pam-mount sieht so aus (Z. 41-46):

<mkmountpoint enable="1" remove="true" />

<volume user="maxac" fstype="crypt" path="/dev/disk/by-uuid/ed90e5cd-069c-485e-b4a3-75f96b907328" mountpoint="~/mnt/home" options="fsck,relatime" />

</pam_mount>

parted -l:
{{{Model: ATA Corsair Force LS (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  11,5MB  10,5MB                                     bios_grub
 2      11,5MB  131MB   120MB   fat32        EFI System Partition  boot, esp
 3      131MB   10,1GB  9961MB  ext4
 4      10,1GB  62,5GB  52,4GB
 5      62,5GB  120GB   57,5GB


Model: ATA ST1000DM003-1CH1 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size   Type     File system  Flags
 1      1049kB  848GB   848GB  primary  ext4
 2      848GB   1000GB  152GB  primary


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vgmaxhome-home: 52,9GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0,00B  52,9GB  52,9GB  ext4


Error: /dev/mapper/luks-ed90e5cd-069c-485e-b4a3-75f96b907328: unrecognised disk
label
Model: Linux device-mapper (crypt) (dm)                                   
Disk /dev/mapper/luks-ed90e5cd-069c-485e-b4a3-75f96b907328: 57,5GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vgmaxkubuntu_vol_1-swap: 9664MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system     Flags
 1      0,00B  9664MB  9664MB  linux-swap(v1)


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vgmaxkubuntu_vol_1-root: 19,3GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End     Size    File system  Flags
 1      0,00B  19,3GB  19,3GB  ext4


Error: /dev/mapper/sda4_crypt: unrecognised disk label
Model: Linux device-mapper (crypt) (dm)                                   
Disk /dev/mapper/sda4_crypt: 52,4GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

sudo lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                                           7:0    0     4K  1 loop  /snap/bare/5
loop1                                           7:1    0    62M  1 loop  /snap/core20/1587
loop2                                           7:2    0  63,3M  1 loop  /snap/core20/1778
loop3                                           7:3    0 163,3M  1 loop  /snap/firefox/1635
loop4                                           7:4    0 400,8M  1 loop  /snap/gnome-3-38-2004/112
loop5                                           7:5    0 238,5M  1 loop  /snap/firefox/2263
loop6                                           7:6    0 346,3M  1 loop  /snap/gnome-3-38-2004/119
loop7                                           7:7    0  91,7M  1 loop  /snap/gtk-common-themes/1535
loop8                                           7:8    0  49,8M  1 loop  /snap/snapd/17950
sda                                             8:0    0 111,8G  0 disk  
├─sda1                                          8:1    0    10M  0 part  
├─sda2                                          8:2    0   114M  0 part  /boot/efi
├─sda3                                          8:3    0   9,3G  0 part  /boot
├─sda4                                          8:4    0  48,8G  0 part  
│ └─sda4_crypt                                253:0    0  48,8G  0 crypt 
│   ├─vgmaxkubuntu_vol_1-swap                 253:1    0     9G  0 lvm   [SWAP]
│   └─vgmaxkubuntu_vol_1-root                 253:2    0    18G  0 lvm   /var/snap/firefox/common/host-hunspell
│                                                                        /
└─sda5                                          8:5    0  53,6G  0 part  
  └─luks-ed90e5cd-069c-485e-b4a3-75f96b907328 253:3    0  53,6G  0 crypt 
    └─vgmaxhome-home                          253:4    0  49,3G  0 lvm   /media/maxac/99850d65-1eef-4056-aa02-232c94128453
sdb                                             8:16   0 931,5G  0 disk  
├─sdb1                                          8:17   0 789,7G  0 part  /media/maxac/TB1
└─sdb2                                          8:18   0 141,8G  0 part  
sr0                                            11:0    1  1024M  0 rom

fstab ist (noch?) unberührt:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vgmaxkubuntu_vol_1-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda3 during installation
UUID=cd5e9fb2-a0d8-44e7-9e15-a5f3db1fcd40 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/sda2 during installation
UUID=EC11-C2FC  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/vgmaxkubuntu_vol_1-swap none            swap    sw              0       0

crypttab:

sda4_crypt UUID=169c3d4c-a3c0-4f8c-9b92-904f35ad8e58 none luks

LVM-Angaben:

 PV                                                    VG                 Fmt  Attr PSize  PFree  
  /dev/mapper/luks-ed90e5cd-069c-485e-b4a3-75f96b907328 vgmaxhome          lvm2 a--  53,55g  <4,29g
  /dev/mapper/sda4_crypt                                vgmaxkubuntu_vol_1 lvm2 a--  27,79g 812,00m

VG                 #PV #LV #SN Attr   VSize  VFree  
  vgmaxhome            1   1   0 wz--n- 53,55g  <4,29g
  vgmaxkubuntu_vol_1   1   2   0 wz--n- 27,79g 812,00m

LV   VG                 Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home vgmaxhome          -wi-ao---- <49,27g                                                    
  root vgmaxkubuntu_vol_1 -wi-ao----  18,00g                                                    
  swap vgmaxkubuntu_vol_1 -wi-ao----   9,00g

Und, falls nötig, suche ich die relevanten Einträge in den Logs auch noch raus ...

Auch Swap wollte ich auf die HDD legen

Wird dadurch die Sicherheit nicht untergraben?

swap muss doch im PV liegen oder irren?

Das gewünschte System von erscheint doch etwas überkomplex.

Würde das ein "echter" Admin so gestalten?

@undine Die Sache mit Swap hat sich b.a.W. erledigt (also ist mit im System-PV). Ich dachte, es sei vielleicht eine gute Idee, häufiges Beschreiben auf einer SSD zu vermeiden. Sicherheit: Swap sollte ja mit in den Container ...

Anyway, ich bin ja am Üben und Kompetenzen ausweiten, und die admin. Fähigkeiten lassen sich halt nicht durch Theorie allein erwerben. Vielleicht stelle ich mich ja ein wenig ungeschickt an, wenn ich mich nicht systematisch von der Pike auf zu Linuxer autodidaktisch ausbilde, sondern nur mit einem vorhanden Zeitkontingent (das eh immer gesprengt wird, wenn was ansteht) die Dinge eher punktuell vornehme(n muss). Ich kann ja verstehen, dass die versierten User und besonders die Supporter oft ungeduldig ihre Köpfe schütteln müssen, aber ey, die rhetorische Frage ist nicht hilfreich ☺

Immerhin bin ich jetzt mit pam-mount einen Schritt weiter gekommen - die als neues Home vorgesehene Partition wird jetzt anscheinend beim Booten entschlüsselt. Aber das alte Home erscheint immer noch.

Nach der Anleitung zu pam-mount scheine ich keine Änderungen an fstab vornehmen zu müssen ebensowenig wie das Löschen des alten Home, aber ich hab in anderen Foren und Manuals (oft 10J alt) auch Hinweise entdeckt, die was anderes zu fstab sagen. Auch der Artikel MOUNT scheint da was anzudeuten, aber Explizites gibt's nicht zu pam-mount. Im Artikel HomeUmziehen gibt's nur was zur Verschlüsselung mit ecrypt.

Hier die kleine Änderung an /etc/security/pam-mount-conf.xml:

<volume user="maxac" fstype="crypt" path="/dev/disk/by-uuid/asd6aN-yODF-Djiu-knmd-g5Z1-YmHc-gN1TVu" mountpoint="/home" options="fsck,relatime" />