wiki.archlinux.de - Benutzerbeiträge [de]

LVM

2016-03-31T07:41:58Z

Smoneck: /* Logical Volume */ typo

= Übersicht =
Der Logical Volume Manager, kurz LVM, ist eine Alternative zu den klassischen Partitionen um Massenspeicher wie Festplatten logisch zu unterteilen. LVM bietet dabei gegenüber normalen Partitionen viele Vorteile, aber auch Nachteile.

== Vorteile ==
=== Flexibilität im Layout ===
Während eine Partitionstabelle immer fix ist und nur unter bestimmten Bedingungen geändert werden kann, ist LVM immer vollständig flexibel. Gehen wir bei Partitionen von folgender Situation aus:
sda1 - 20GB - /
sda2 - 20GB - /usr
sda3 - 20GB - /home
Jetzt fällt einem auf dass man sda1 viel zu großzügig dimensioniert hat, man wird auf diesem Dateisystem niemals an die 20GB Grenze kommen. Also wäre es sinnvoll sda1 auf 10GB zu verkleinern und diesen Platz sda3 zu überlassen, da hier zu erwarten ist dass dort mit der Zeit immer mehr Daten anfallen. Mit Partitionen ist das nicht möglich. Zwar kann man sda1 verkleinern, der freie Platz liegt dann aber zwischen sda1 und sda2. Partitionen müssen immer an einem Stück sein, weswegen es nun nicht möglich ist den übrigen Platz sda3 zuzuweisen. Man könnte ihn nur sda2 überlassen. Es wäre höchstens möglich durch zeitaufwendige und nicht ganz ungefährliche Verschieboperationen das Problem lösen.

LVM hingegen ist egal wo die Bereiche liegen. Ob das nun an einem Stück ist oder nicht ist völlig egal, es kann sogar auf einem völlig anderem Gerät(z.B. einer anderen Festplatte) liegen. Den Benutzer kümmert es meistens auch nicht wo was genau liegt, er kann das System einfach benutzen.

=== Vergrößern und Verkleinern ===
Zwar kann man auch Partitionen vergrößern und verkleinern, allerdings beschreibt das obige Beispiel die Restriktionen ganz gut.
LVM unterstützt vergrößern und verkleinern im Betrieb, das Ganze dauert keine 5 Sekunden. Es sei allerdings dazu gesagt dass die allermeisten Dateisysteme zwar vergrößern im Betrieb erlauben, verkleinern aber nicht. Ext3 und 4 gehören dazu.

=== Snapshots ===
LVM unterstützt sogenannte Snapshots. Dabei wird ein neues Blockdevice angelegt, welches den Zustand des jeweiligen Volumes zu dem Zeitpunkt des Snapshots repräsentiert. Dieses Blockdevice ist auch beschreibbar.
So ergeben sich verschiedene Vorteile:

- Es können auf schnellste Art und Weise Backups angelegt werden. Müsste das System für ein konsistentes Backup normalerweise für die gesamte Zeit offline sein, reicht es kurz alles nötige abzuschalten, den Snapshot anzulegen und dann wieder alles zu aktivieren. Man kann dann in aller Ruhe von dem Snapshot ein Backup anlegen, während das System unberührt weiterläuft. Gerade für Server ein unschlagbarer Vorteil.

- Dadurch dass die Snapshots auch beschreibbar sind ist es auch möglich von ihnen ''zu booten'', es sind ja ganz normale Blockdevices. Das ist perfekt falls es sich bei dem betreffenden System um ein Produktivsystem handelt, gerade bei Arch Linux. Arch Linux ist eine "bleeding edge" Distribution, in der immer das Neueste zu finden ist. Daher kann und wird es passieren dass irgendwelche Updates das System in Teilen oder im Ganzen unbenutzbar machen. Ohne Snapshots müsste man sich nun mit dem Problem beschäftigen, wofür im Zweifelsfall keine Zeit ist. Mit Snapshots rebootet man einfach auf sein garantiert funktionierendes System und kann sich mit den Problemen beschäftigen wenn Zeit dafür ist.

Mit den Snapshots von LVM ist allerdings, im Gegensatz zu denen von ZFS, kein Rollback möglich. Man kann LVM also nicht sagen "Vergiss alles was passiert ist und spring zu dem Stand des Snapshots zurück". Benötigt man einen solchen Mechanismus muss man alle Änderungen auf dem Snapshot selbst machen, denn den Snapshot kann man wieder löschen.

== Nachteile ==
=== Linux exklusiv (nahezu) ===
LVM gibt es fast ausschließlich für Linux. HP-UX verwendet ihn zwar auch, spielt aber im Privatbereich nahezu keine Rolle. Zwar hat *BSD mit GEOM einen ähnlichen Mechanismus, allerdings ist GEOM nicht mit LVM kompatibel. Für andere Betriebssysteme wie Mac OSX oder Microsoft Windows gilt das gleiche.
Daher lohnt es sich nur dann LVM einzusetzen wenn auf dem System exklusiv Linux läuft, man kann von anderen Betriebssystemen die Daten im LVM nicht lesen. Eine Notlösung wäre die Einrichtung einer Ext2/3 oder FAT Austauschpartition, wobei für diese dann wieder die Einschränkungen der Partitionen gelten.

DragonflyBSD unterstützt seit Mitte 2010 LVM (siehe [http://leaf.dragonflybsd.org/mailarchive/users/2010-07/msg00036.html]).

=== Schwerer Umstieg ===
Man kann Partitionen nicht in LVM Volumes konvertieren, wodurch sich der Umstieg auf einem bereits eingerichteten System als schwer erweist. Man müsste ein neues Volume anlegen und alle Daten dort hin kopieren, was dadurch erschwert wird dass man in einem klassischem System mit Partitionen üblicherweise bereits den gesamten zur Verfügung stehenden Platz durch Partitionen reserviert hat. Entweder man besorgt sich einen weiteren Datenträger mit ausreichender Größe, oder man verkleinert bereits bestehende Partitionen so dass genug Platz vorhanden ist.
Man fährt am besten wenn man bereits zur Installation LVM benutzt.

=== Kompliziertere Benutzung ===
Durch die vielen Features von LVM muss man sich auch Zeit nehmen um mit LVM umgehen zu können. Der alltägliche und vorallem sinnvolle Umgang mit LVM will gelernt sein.

=== Keine LVM Unterstützung in GRUB ===
Dadurch dass in GRUB selbst keine LVM Unterstützung vorhanden ist muss man mindestens eine normale /boot Partition haben auf der GRUB, der Linux Kernel und eine Initrd(falls benötigt) vorhanden sind. Eine Alternative wäre GRUB 2, welches bereits LVM Unterstützung bietet. Allerdings ist GRUB 2 nach wie vor in Entwicklung.

= Die Theorie =
LVM repräsentiert die Daten ziemlich abstrakt.
== Physical Volume ==
Auf der untersten Ebene sind die sog. Physical Volumes. Das können beliebige Blockdevices sein. Festplatten, Partitionen, Ramdisks und so weiter. Physical Volumes werden weiterhin mit ihren normalen Namen, beispielsweise /dev/sda2, angesprochen.

== Volume Group ==
Physical Volumes werden dann zu Volume Groups zusammengefasst. Diese Volume Groups stellen quasi einen Speicherplatz Pool dar, ähnlich wie eine Festplatte. Allerdings ohne die Begrenzung, dass dieser Pool auf einem bestimmten physikalischen Gerät vorhanden sein muss.
Volume Groups werden mit ihrem Namen angesprochen, welchen man selbst wählen kann. Volume Groups dürfen über beliebig viele Physical Volumes verteilt sein und können im Betrieb vergrößert und verkleinert werden. Das Entfernen von Physical Volumes aus einer Volume Group ist logischerweise nur dann möglich wenn sie redundant sind, also die gleichen Daten bereits auf einem anderen Physical Volume vorhanden sind oder sich auf dem zu entfernenden Physical Volume keine Daten befinden.

== Logical Volume ==
In der Volume Group werden wiederum Logical Volumes angelegt, sie sind ähnlich wie Partitionen. Das sind dann auch die tatsächlich ansprechbaren Blockdevices auf denen sich ein Dateisystem erstellen lässt.

Für ein Logical Volume ist die einzige Begrenzung dass es in einer bestimmten Volume Group sein muss, es kann nicht über 2 verschiedene Volume Groups gehen. Logical Volumes können im Betrieb vergrößert oder verkleinert werden. Logical Volumes können immer angelegt werden solange in der entsprechenden Volume Group genügend Platz vorhanden ist. Sie können weder umbenannt noch entfernt werden, sollten sie in Benutzung sein.
Logical Volumes werden durch die Volume Group in der sie sich befinden und einen frei wählbaren Logical Volume Namen angesprochen. Ist ein Logical Volume in der Volume Group "tank" und heisst selbst "lvol-root", dann ist der Pfad zum Blockdevice:
/dev/tank/lvol-root
Es gibt noch einen weiteren Pfad, da der erstgenannte in frühen Bootphasen eventuell noch nicht existiert. Er lautet:
/dev/mapper/tank-lvol-root
Snaphots zählen ebenfalls als Logical Volume, für sie gelten die gleichen Begrenzungen. Zusätzlich müssen sie sich in der selben Volume Group befinden wie ihr Original.

= Die Einrichtung =
Ich gehe hier von einer frischen Installation mittels einer Arch Linux CD aus, ob x86_64 oder i686 spielt hierbei keine Rolle.
Das Arch Linux Setup verfügt zwar über LVM Kompatibilität, allerdings nur so weit dass sich LVM benutzen lässt. Die Einrichtung von LVM muss manuell geschehen.
Nachdem man auf eine Konsole gewechselt ist, partitioniert man erstmal normal. Dabei ist nur zu beachten, dass es zwingend eine separate /boot Partition geben muss. Ich empfehle eine Größe von 128-256 MB, damit auch mal ein paar mehr Snapshot Kernel drauf passen. Der Rest kann zu einer Partition allokiert werden und wird dann später in das LVM übernommen.
Im Beispiel wird davon ausgegangen, dass {{ic|/dev/sda1}} für {{ic|/boot}} verwendet wird, {{ic|/dev/sda2}} und {{ic|/dev/sdb}} sollen in das LVM übernommen werden.
Nachdem man das Device-Mapper Modul "dm-mod" geladen hat, kann man mittels pvcreate Physical Volumes anlegen:
pvcreate /dev/sda2 /dev/sdb
Nun fügt man diese beiden Physical Volumes mittels vgcreate zu einer Volume Group zusammen:
vgcreate tank /dev/sda2 /dev/sdb
Dabei wird eine Volume Group mit dem Namen "tank" angelegt, welche die beiden Physical Volumes {{ic|/dev/sda2}} und {{ic|/dev/sdb}} beinhaltet.
In der Volume Group werden jetzt Logical Volumes für die verschiedenen Mountpunkte mittels lvcreate eingerichtet:
lvcreate --name lvol-root -L10G tank
Dies würde das Logical Volume "lvol-root" mit einer Größe von 10 GB in der Volume Group "tank" erstellen. Man möchte natürlich auch Logical Volumes für Swap und /home:
lvcreate --name lvol-swap -L2G tank
lvcreate --name lvol-home -l50%FREE tank
Das erste Kommando arbeitet nach dem selben Prinzip. Im zweiten verwenden wir -l anstatt -L, damit kann man Extents als Größe angeben. 50%FREE gibt an, dass die Hälfte des restlichen Speichers in der Volume Group für lvol-home genutzt werden soll. Ob das schlau ist oder nicht, muss man für sich selbst entscheiden - die Volume Group könnte ja auch 5TB groß sein. Dieses Beispiel soll nur den Syntax zeigen.

Ist das alles geschehen, kann man das Arch Linux Setup starten. Hier überspringt man die Partitionierung und geht direkt zum Festlegen der Mountpunkte. Es sollte sichergestellt sein, dass {{ic|/dev/sda1}} als /boot eingetragen wird, andernfalls wird das System nicht booten.
Am Ende der Installation muss man {{ic|/etc/mkinitcpio.conf}} bearbeiten, um sicherzustellen, dass "lvm2" in dem HOOKS Array eingetragen ist und vor "filesystems" steht. Es ist zu empfehlen, in {{ic|/etc/mkinitcpio.conf}} "dm-snapshot" in das MODULES Array mit einzutragen, da sonst auf '''kein Volume mehr zugegriffen werden kann''' sollten Snapshots verwendet werden.
Man sollte vor dem Reboot noch sicherstellen, dass Bootloaderkonfiguration und {{ic|/etc/fstab}} richtig ausgefüllt wurden, was aber in der Regel der Fall ist.

= Der Alltag =
Das System läuft zwar jetzt, allerdings haben sich bisher keine Vorteile gegenüber dem klassischen Partitionssystem ergeben. Im Gegenteil, dadurch dass die Einrichtung komplexer war musste man bisher ausschließlich mit Nachteilen leben. Zeit für die Feature Keule.

== Mount Punkte setzen ==
Wie schon erwähnt werden die Mountpunkte mit dem Mapper erstellt. Also ist anstatt {{ic|/dev/sda2}} {{ic|/dev/mapper/tank-home}} zu verwenden.

Desweiteren ist unbedingt zu beachten, dass in {{ic|/etc/mkinitpio.conf}} die Hooks {{ic|udev}} und {{ic|lvm2}} im Hooksarray eingetragen sind und sich {{ic|lvm2}} vor dem {{ic|filesystems}} Eintrag befindet.
{{hc|/etc/mkinitcpio.conf|
HOOKS{{=}}"base udev ... block lvm2 filesystems" }}

== Partition Hinzufügen==
Um eine Partition in die Volume Group aufzunehmen muß diese erst ins 'Linux LVM' Format formatiert werden. Danach wird auf der Platte ein Volumen erstellt und der Volume Group hinzugefügt.
pvcreate /dev/sdb1
vgextend tank /dev/sdb1

==Partitionen Entfernen==
Bevor eine Partition aus der Volume Group entfernt wird, sollten vorher alle Daten auf die restlichen Datenträger der Volume Group geschoben werden, um Datenverlust zu vermeiden.
pvmove /dev/sdb1
Sollen die daten auf eine bestimmte Festplatte verschoben werden
pvmove /dev/sdb1 /dev/sda1
Nun kann die Festplatte aus der Volume Group entfernt werden.
vgreduce tank /dev/sdb1
Weiterhin können alle unbenutzten Festplatten entfernt werden mit
vgreduce --all vg0
Abschliesend muß nun noch folgender Befehl benutzt werden
pvremove /dev/sdb1

== Vergrößern ==
Da das Vergrößern von Logical Volumes immer mit ein bisschen Aufwand verbunden ist empfiehlt es sich für alle größeren Sachen ein eigenes Logical Volume anzulegen. Was aber wenn das viel zu klein geraten ist?
Mit lvextend können Logical Volumes vergrößert werden, wenn es das Dateisystem erlaubt auch im Betrieb.
lvextend -L15G tank/lvol-home
Würde lvol-home auf 15GB vergrößern. Man kann die Angaben auch relativ machen:
lvextend -L+5G tank/lvol-home
Dies vergrößert lvol-home um 5GB. Man kann ebenfalls -l benutzen um Angaben mit Hilfe von Extents zu machen.
Bisher ist nur das Logical Volume vergrößert, das Dateisystem weiß es noch nicht. Im Falle von ext2/3/4 kann man das Dateisystem mit Hilfe von
resize2fs /dev/tank/lvol-home
auf die maximale Größe bringen. Zu beachten ist das hier mit /dev Pfaden gearbeitet werden '''muss''', da resize2fs ja nichts von LVM weiß. Man kann auch in LVM Kommandos mit /dev Pfaden arbeiten.

== Verkleinern ==
Verkleinern funktioniert im Prinzip gleich, allerdings muss hier auf das Dateisystem geachtet werden. Nur die wenigsten unterstützen das Verkleinern im Betrieb, ext2/3/4 gehören nicht dazu. Falls das Dateisystem das Verkleinern im Betrieb nicht unterstützt muss es vorher ausgehangen werden, andernfalls kommt es von Datenverlust bis hin zur Zerstörung des gesamtem Dateisystems.
Bevor man das Logical Volume verkleinert muss das Dateisystem verkleinert werden, sonst würde man am Ende Daten abschneiden. Bei ext2/3/4 geht das ebenfalls mit resize2fs:
resize2fs /dev/tank/lvol-home 10000
Würde das Dateisystem auf lvol-home auf etwa 9.8GB verkleinern. Man sollte zuerst das Dateisystem etwas kleiner als die endgültige Größe machen und nachher auf die maximale bringen, damit auch sichergestellt ist dass keine Daten abgeschnitten werden.
Nun wird das Logical Volume selbst mittels lvreduce verkleinert:
lvreduce -L10G tank/lvol-home
Auch hier kann wieder mit relativen Angaben und Extents gearbeitet werden.
Zum Schluss wird noch das Dateisystem auf die endgültige Größe gebracht:
resize2fs /dev/tank/lvol-home

== Snapshots ==
Snapshots anzulegen ist nicht viel Aufwand. Es muss nur sichergestellt sein dass in der Volume Group genug unreservierter Platz vorhanden ist, da die Änderungen vom Snapshot zum Original und umgekehrt in die Volume Group geschrieben werden. Ein Snapshot kann man mit dem Parameter -s oder --snapshot bei lvcreate anlegen:
lvcreate -s --name lvol-root-testing -L5G tank/lvol-root
Sollten mehr als 5GB Änderungen auf dem Snapshot oder dem Original seit Anlegen des Snapshots geschrieben worden sein springt der Snapshot raus und das dort vorhanden Dateisystem ist aller Wahrscheinlichkeit nach defekt. Das Original ist davon nicht betroffen.
Der Snapshot ist jetzt unter /dev/tank/lvol-root-testing ansprechbar. Er lässt sich ganz normal mounten und so weiter.
Mit lvremove lässt sich der Snapshot auch wieder entfernen:
lvremove tank/lvol-root-testing

== Ein testing System ==
Eingangs wurde erwähnt dass sich LVM Snapshots eignen um Updates zu testen. Allerdings kommt keine schwarze Magie ins Spiel – wir können nicht sofort vom Snapshot booten wenn er angelegt wurde. Es sind ein paar Vorbereitungen nötig.

Als erstes wird ein Snapshot angelegt und gemountet, ich gehe von /mnt/lvol-root-testing aus. Dort wird ein neuer Ordner namens "boot-real" angelegt und die Datei etc/fstab mittels eines Editors geöffnet.
Die Gerätedatei des Wurzelverzeichnisses / wird von /dev/mapper/tank-lvol--root auf /dev/mapper/tank-lvol--root--testig geändert. Der Mountpunkt von /dev/sda1 von /boot auf /boot-real. Zusätzlich wird folgender Eintrag hinzugefügt:
/boot-real/testing /boot none bind,rw,noatime 0 0
Dieser bewirkt dass der Ordner /boot-real/testing, welcher erst noch angelegt wird, nach /boot gemountet wird. Das hat den Hintergrund dass ein Kernel Update auf dem Testsystem auch den Kernel von dem normalen System überschreiben würde, da sich beide Systeme dieselbe /boot Partition teilen. Mit diesem Eintrag wird das getrennt.
Falls man noch mehr Volumes hat auf denen auf Änderungen auftreten könnten die man im normalen System nicht haben möchte(z.B. /usr, /home, ...) muss von diesen auch ein Snapshot angelegt werden. Die Einträge dieser werden wie die von / in etc/fstab abgeändert.
Der Snapshot kann jetzt wieder ausgehangen werden. In /boot wird nun der Ordner testing erstellt, in welchen die Dateien vmlinuz26(der Kernel), kernel26.img(die Initrd) und System.map26 kopiert werden.
Nun wird jegedlich ein Eintrag im GRUB benötigt um vom neuen Snapshot auch starten zu können. In /boot/grub/menu.lst sollte sich ein Eintrag befinden, der so ähnlich aussieht:
title Arch Linux
root (hd0,0)
kernel /vmlinuz26 root=/dev/mapper/tank-lvol--root ro
initrd /kernel26.img
Da weder /dev/tank/lvol-root als /, noch /boot/vmlinuz26 als Kernel und /boot/kernel26.img als Initrd benutzt werden soll wird ein neuer Eintrag mit folgenden Inhalt erstellt:
title Arch Linux testing
root (hd0,0)
kernel /testing/vmlinuz26 root=/dev/mapper/tank-lvol--root--testing ro
initrd /testing/kernel26.img
Einmal gespeichert kann man jetzt in GRUB das neue System auswählen und es booten. Im System sollten alle Mountpunkte überprüft werden bevor die Updates letztendlich eingespielt werden. Auch sollte man die bisher geschehenen Änderungen, einsehbar mit lvdisplay unter "Allocated to snapshot" im Auge behalten und rechtzeitig vergrößern falls benötigt. Steht der Wert bei 100% springt der Snapshot raus und das Dateisystem auf dem Snapshot ist wahrscheinlich defekt.

== Tipps für den Alltag ==
Eine komplette Dokumentation über alle Befehle und Möglichkeiten von LVM würde den Rahmen eines Wiki Artikels sprengen, doch ein paar gute Tipps sind nie fehl am Platz.

=== Alles in Logical Volumes auslagern ===
Stellt man fest dass etwas größeres nicht mehr in das aktuelle Logical Volume passt(zum Beispiel ein Spiel o.ä.) sollte man dafür ein neues Logical Volume anlegen anstatt das bestehende zu vergrößern. Das hat den großen Vorteil dass man ein Logical Volume viel leichter wieder entfernen kann als ein bestehendes zu verkleinern. Ausserdem trifft dann die zwar minimale, aber trotzdem vorhanden Fragmentierung des neuen Volumes nicht auf das alte zu.

[[Kategorie:Konfiguration]]
[[en:LVM]]

Dm-crypt

2015-03-25T07:52:02Z

Smoneck: /* Arch Linux installieren und konfigurieren */ Fehlende root Angabe in Kernelparameter --> bleibt beim Booten bei UUIDs stecken

[[en:System_Encryption_with_LUKS_for_dm-crypt]]
{{achtung|Nach der Verschlüsselung der Festplatte sind etwaige vorherige Daten nicht mehr zu rekonstruieren! In jedem Fall sollte also ein Backup alter Daten erstellt werden}}

Eine komplett verschlüsselte Festplatte kann in vielen Fällen sinnvoll sein. Zum Beispiel kann es sehr schnell passieren, dass der private Laptop mit den privaten Daten irgendwo liegen gelassen oder geklaut wird. In solchen Fällen ist es immer besser, wenn niemand auf die Daten zugreifen kann. In diesem Beitrag werden zwei Varianten vorgestellt wie sich Festplatten bereits während der Installation von Arch Linux verschlüsseln lassen. Beide Varianten sind gleich sicher, erstere Variante verlangt allerdings weniger Konfigurationsaufwand.

==Festplatte Verschlüsseln==
Das Ver- und Entschlüsseln wird über das Kryptographie-Modul des Devicemappers des Kernels abgewickelt. Dieser stellt uns ein virtuelles Device zu Verfügung, über das auf die verschlüsselten Partitionen zugegriffen werden kann.
Der Verschlüsselungsalgorithmus, die Größe des Schlüssels und viele weitere Dinge die die Verschlüsselung beeinflussen, können selber festgelegt werden. Nähere Informationen zu den verfügbaren Parametern gibt es hier auf der [http://www.saout.de/misc/dm-crypt/ Seite von dm-crypt].
Informationen über die Geschwindigkeit der einzelnen Algorithmen gibt es [http://web.archive.org/web/20070519171434/http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio hier] übersichtlich dargestellt.

===Verschlüsselte LVM Partition(Variante 1)===
Dies ist die meist verbreitete Variante zumal viele andere Distributionen solch eine Verschlüsselung automatisch bei der Installation anbieten. Man kann den normalen [[Arch Install Scripts]] bzw. der [[Anleitung für Einsteiger]] folgen und muss nur an einigen Punkten abweichen.

====Partitionslayout====
Man folge den Anleitungen bis zur Partitionierung, danach folge man dieser Anleitung bis auf weiteres.

Das Grundlayout solch einer Festplatte sieht vor, dass bis auf eine kleine Bootpartition die gesamte Platte verschlüsselt wird. Innerhalb des verschlüsselten Bereichs wird eine [[LVM]] angelegt. In dieser können wiederum eine unbegrenzte Anzahl von Logical Volumes angelegt werden. D.h. man partitioniert die Festplatte wie in der Anleitung mit dem Unterschied, dass man nur zwei Partitionen benötigt, einmal die besagte Bootpartition und einmal eine, die verschlüsselt wird und in der später logische Partitionen für z.B. die Root- oder Homepartition angelegt werden. Ein beispielhaftes Layout auf einem reinen Linuxsystem könnte also so aussehen:

/dev/sda1 - ca. 100MB(Bootpartition)
/dev/sda2 - Rest der Festplatte

====Verschlüsselung anlegen====
Nun sollte man die zu verschlüsselnde Partition mit zufälligen Daten überschreiben:
# shred -v /dev/sda2
shred überschreibt die Festplatte dreimal mit Zufallswerten. Eine schnelle Alternative wäre die Partition nur mit Nullen zu überschreiben.
# shred -vn 0 -z /dev/sda2
Ob einem das reicht, muss man selber entscheiden. Laut einem Artikel von 2009 bei [http://www.heise.de/newsticker/meldung/Sicheres-Loeschen-Einmal-ueberschreiben-genuegt-198816.html Heise] reicht dies bei modernen Festplatten.

Dann müssen die benötigten Kernelmodule geladen werden:
# modprobe dm-crypt
Danach verschlüsselt man sda2 mit folgendem Befehl:
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2
{{Hinweis|Für Volumes größer als 2TiB sollte '''aes-xts-plain64''' verwendet werden. Kernelunterstützung hierfür gibt es seit Kernel 2.6.33.}}
Den Befehl bestätigen und das gewünschte Passwort eingeben, wobei man beachte, dass das Passwort [https://de.wikipedia.org/wiki/Passwort#Wahl_sicherer_Passw.C3.B6rter sicher] ist. Beim AES-Algorithmus bringen Passwörter, die länger als 32 Zeichen sind, keinen Sicherheitsgewinn.

Zur Auswahl alternativer Algorithmen konsultiere man die Manpage von Cryptsetup:
# man cryptsetup

Für die weiteren Schritte muss man die eben verschlüsselte Partition gleich einbinden:
# cryptsetup luksOpen /dev/sda2 lvm

In dem Ordner /dev/mapper erscheint jetzt die neue Gerätedatei lvm.

====LVM einrichten====
Mit
# pvcreate /dev/mapper/lvm
# vgcreate main /dev/mapper/lvm
richtet man jetzt die LVM und eine Volume Group (hier im Beispiel mit dem Namen main) ein. Jetzt muss man noch die jeweiligen Logical Volumes einrichten. Logical Volumes sind so etwas wie virtuelle Partitionen, die von Linux wie richtige Partitionen gemountet und verwendet werden können. Zuallererst sollte man sich über das gewünschte Layout im klaren sein.

/ → etwa 10GB (evtl. mehr, einige Pakete wie urbanterror (>1GB) oder auch texlive-full (=1GB) füllen schnell 10GB)
/swap → abhängig von der Größe des verbauten RAM (siehe [[Swap]])
/home → restlicher Festplattenplatz
Das Layout ist nur eine Empfehlung und kann beliebig verändert werden.

Um obiges Layout im LVM anzulegen muss man folgende Befehle verwenden:
# lvcreate -L 10GB -n root main
# lvcreate -L 2GB -n swap main
# lvcreate -l 100%FREE -n home main

Möchte man statt GB mit MB-Größen arbeiten, lässt sich auch Folgendes anwenden:

# lvcreate -L 3072M -n swap main

====Arch Linux installieren und konfigurieren====
Nun folgt man der gewöhnlichen Installationsanleitung. Wenn man während der Installation die Mountpoints festlegt, muss man jedoch natürlich die eben erstellten Partitionen wählen. In unserem Beispiel muss {{ic|/boot}} auf {{ic|/dev/sda1}} angelegt werden, {{ic|/home}} auf {{ic|/dev/mapper/main-home}}, {{ic|/ }}auf {{ic|/dev/mapper/main-root}} und {{ic|swap}} ist in diesem Fall {{ic|/dev/mapper/main-swap}}. {{ic|/dev/sda2}} und {{ic|/dev/mapper/lvm}} bleiben indes unangetastet.

Im Vergleich zur normalen Installation müssen ab der Erstellung des Linux-Kernels Änderungen beachtet werden. Man editiert in {{ic|/etc/mkinitcpio.conf}} die ''HOOKS''-Zeile, dabei ist darauf zu achten, dass ''encrypt'' '''vor''' ''lvm2'' und beide in dieser Reihenfolge vor ''filesystems'' eingetragen werden! Wünscht man bei der Abfrage der Passworts ein z.B. deutsches Tastaturlayout, muss man noch ''keymap'' vor ''encrypt'' einfügen. Benutzt man eine USB-Tastatur (oder hat man vor, dies irgendwann zu tun), so muss zusätzlich noch ''keyboard'' vor ''encrypt'' eingetragen werden.
HOOKS="base udev autodetect modconf block ''keyboard keymap encrypt lvm2 filesystems'' fsck shutdown"

Nachdem ''grub'' installiert wurde, muss man vor der Erstellung der Konfigurationsdatei mit {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} noch die Kernelparameter anpassen. Dazu ändert man in {{ic|/etc/default/grub}} den Eintrag '''GRUB_CMDLINE_LINUX''' wie folgt:

{{hc|nano /etc/default/grub|
GRUB_CMDLINE_LINUX{{=}}"cryptdevice{{=}}/dev/sda2:main root{{=}}/dev/mapper/main-root"}}

Sollte ''keymap'' in die mkinitcpio.conf eingetragen worden sein und man wünscht beispielsweise ein deutsches Tataturlayout, so müssen entsprechend noch "lang=de" und "locale=de_DE.UTF-8" in die Kernelzeile eingetragen werden. Danach kann man nach der normalen Anleitung weitermachen. Grub selbst sollte auf {{ic|/dev/sda}} installiert werden.

Wird [[syslinux]] als Bootloader verwendet, editiert man die {{ic|APPEND}}-Zeile in {{ic|/boot/syslinux/syslinux.cfg}}:
APPEND cryptdevice=/dev/sda2:main root=/dev/mapper/main-root rw
unter Verwendung der UUID ist die Zeile nach folgendem Muster zu gestalten:
APPEND cryptdevice=UUID="i23ac042-fac8-3cf4-acac3-8295c5a525be":main root=/dev/mapper/root-main rw
{{achtung|Es ist darauf zu achten, die UUID des crypto_LUKS devices zu verwenden.}}

====LVM manuell mounten====

Möchte man ein mit LVM eingerichtetes und verschlüsseltes System manuell mounten, beispielsweise beim Start von einer Live-CD, so ist wie im Folgenden zu verfahren.

Verschlüsselte Partition einbinden:

# cryptsetup luksOpen /dev/sda2 lvm

Unter {{ic|/dev/mapper/}} erscheint nun die Gerätedatei lvm. Im nächsten Schritt ist mitunter der folgende Befehl nötig, um die Volume-Group - in diesem Fall lautet sie ''main'' - zu aktivieren.

# vgchange -ay

Nun sollte es möglich sein, einzelne Partitionen aus dieser Volume-Group ins System einzubinden.

# mount -t ext4 /dev/main/root /mnt

===Partitionen einzeln verschlüsseln(Variante 2)===
Eine weitere Variante verfährt ohne LVM. Diese Anleitung ähnelt trotzdem stark der ersten, daher wird auf die einzelnen Punkte nur rudimentär eingegangen.

====Partitionslayout festlegen====
Wieder verfährt man nach Anleitung bis zur Partitionierung. Diesmal partitioniert man jedoch die Festplatte schon von vornherein so, wie man sie später haben will. Ein beispielhaftes Layout:

/dev/sda1 → /boot (100MB)
/dev/sda2 → swap abhängig von der Größe des verbauten RAM (siehe [[Swap]])
/dev/sda3 → / (10-15GB)
/dev/sda4 → /home (restliche Festplatte)

Die Größe der einzelnen Partitionen kann natürlich variieren.

====Crypto-Devices anlegen====
Laden der benötigten Kernelmodule:

modprobe dm-crypt

Anlegen des Crypto-Devices:

# cryptsetup luksFormat /dev/sda3 --cipher aes-xts-plain -y -s 512

Öffnen des eben erstellten Crypto-Devices:

# cryptsetup luksOpen /dev/sda3 root

Formatieren und mounten der Partition:

# mkfs.ext4 -j /dev/mapper/root
# mount /dev/mapper/root /mnt

Für die Homepartition soll kein extra Passwort verwenden, sondern ein Keyfile, damit nicht bei jedem Start des Systems zwei Passwörter eingeben werden müssen. Das Keyfile für die Partition wird in /crypto/home.key abgelegt. Allerdings ist es sehr wichtig dieses Keyfile zu sichern. Sollte die Root-Partition einmal beschädigt und nicht wiederherstellbar sein, ist die Home-Partition mit allen Daten ebenfalls verloren.

{{Hinweis|Eine andere Möglichkeit wäre es auch hier ein Passwort zu benutzen und dieses dann in der /etc/crypttab anzugeben. So muss das Passwort nicht auf einem physikalischen Datenträger abgelegt werden.}}

Das Keyfile wird zufällig erstellt, indem man einen 2048 Byte großen Block aus /dev/urandom kopiert.

# mkdir /mnt/crypto
# dd if=/dev/urandom of=/mnt/crypto/home.key bs=1k count=2

Anlegen des nächsten Crypto-Devices:

# cryptsetup luksFormat /dev/sda4 /mnt/crypto/home.key --cipher aes-xts-plain -s 512
# cryptsetup luksOpen /dev/sda4 home --key-file /mnt/root/crypto/home.key

Formatieren und mounten der Partition:

# mkfs.ext4 -j /dev/mapper/home
# mkdir /mnt/home
# mount /dev/mapper/home /mnt/home

====Arch Linux installieren und konfigurieren====
Man verfährt nun nach der normalen Installationsanleitung.

Die Konfigurationsdateien für Grub und mkinitcpio müssen analog zur ersten Anleitung angepasst werden.

Damit das System die Home-Partition korrekt einbindet und die Swap-Partition bei jedem Start mit einem neuen zufälligen Schlüssel verschlüsselt, muss noch folgendes gemacht werden:

Zuerst wird {{ic|/etc/crypttab}} geöffnet und die Home-Partition samt Schlüssel, der auf der Root-Partition in /crypto/home.key liegt, eingetragen.

# NAME SOURCE DEVICE PASSWORD OPTIONS
home /dev/sda4 /crypto/home.key
....

Um die Partitionen über die UUID einzubinden, wird die aus folgendem Befehl resultierende UUID benutzt
$ cryptsetup luksDump /dev/sda4 | grep UUID:

Damit wird bei jedem Systemstart die Home-Partition automatisch geöffnet. Jetzt wird {{ic|/dev/mapper/home}} ganz normal in {{ic|/etc/fstab}} eingetragen, damit {{ic|/home}} korrekt gemountet wird.

# <file system> <dir> <type> <options> <dump> <pass>
/dev/mapper/home /home ext4 defaults 0 0

Auch die Swap Partition wird in die {{ic|/etc/crypttab}} eingetragen.

'''Achtung:''' unbedingt darauf achten, dass hier das richtige Device angegeben wird, da sonst Datenverlust droht!

# NAME SOURCE DEVICE PASSWORD OPTIONS
swap /dev/sda2 SWAP -c aes-xts-plain -s 512

Jetzt muss nur noch {{ic|/dev/mapper/swap}} in die fstab Datei eintragen werden.

# <file system> <dir> <type> <options> <dump> <pass>
/dev/mapper/swap swap swap defaults 0 0

*ANMERKUNG: ''Falls nach dem Neustart die Swap-Partition nicht richtig eingebunden wird, kann folgender Befehl Abhilfe schaffen:''

dd if=/dev/zero of=/dev/sda2

Achtung: Dies überschreibt die Partition mit Nullen - hierbei ist unbedingt darauf zu achten, dass es sich bei sda2 auch tatsächlich um die besagte SWAP-Partition handelt, da man sonst eine andere Partition überschreibt!

==System per USB-Stick entschlüsseln==
Wer nicht jedesmal beim Booten das LUKS Passwort für die root Partition eingeben will kann auch ein Keyfile auf einem USB-Stick speichern.
Wenn der Stick beim Booten eingesteckt ist wird das System automatisch aufgeschlossen. Es gibt zwei Möglichkeiten den Key auf dem Stick zu speichern.
Als einfache (sichtbare) Klartextdatei, oder zwischen dem MBR und der ersten Partition des Sticks.

===Vorbereitungen===
Bei beiden Methoden muss zunächst erstmal eine Udev Regel für den Stick erstellt werden. Wie das geht wird [[Einbindung_von_USB-Geräten#Udev-Regel_erstellen|hier]] beschrieben. Ab jetzt wird angenommen, dass die Udev Regel den Stick ''usbstick'' nennt und die erste Partition des Sticks ''usbstick1''.

Jetzt erstellt man ein Keyfile und speichert es auf dem USB-Stick. Soll das Keyfile als Klartextdatei gespeichert werden, darf der Name keine Sonderzeichen, Punkte (versteckte Dateien) etc. enthalten, da der ''encrypt'' HOOK die Datei sonst beim Booten nicht findet.

USB-Stick mounten

mkdir /mnt/usb-stick
mount /dev/usbstick1 /mnt/usb-stick

Keyfile erstellen und auf dem Stick speichern.

dd if=/dev/urandom of=/mnt/usb-stick/archkey bs=512 count=4

Jetzt kann das Keyfile zu den Schlüsseln für die root Partition (hier {{ic|/dev/sda3}}) hinzugefügt werden. Das alte LUKS Passwort sollte man nicht löschen. Falls das Keyfile mal verloren geht, oder das Entschlüsseln per USB-Stick nicht auf Anhieb funktioniert, kommt man immer noch ins System.

cryptsetup luksAddKey /dev/sda3 /mnt/usb-stick/archkey

''/dev/sda3'' gegebenenfalls anpassen...

Als nächstes wird die {{ic|/etc/mkinitcpio.conf}} angepasst. Die Udev-Regel wird in die FILES="" Zeile eingetragen und zu den HOOKS ''block'' hinzugefügt (vor encrypt).

FILES="/etc/udev/rules.d/50-myusb.rules"
HOOKS="... block encrypt filesystems ..."

Soll das Keyfile als Klartextdatei gespeichert werden, müssen noch zwei Module zur MODULES="" Zeile hinzugefügt werden. Eins für das Dateisystem des Sticks (hier vfat) und eins für die Codepage

MODULES="ata_generic ata_piix '''nls_cp437''' '''vfat'''"

Die Module für das Dateisystem und die Codepage müssen durch die passenden ersetzt werden, falls der USB-Stick ein anderes Dateisystem hat (z.B. ext2). Benutzer des Arch-stock Kernels sollten die hier genannte Codepage verwenden.

Jetzt kann das neue initrd-image erstellt werden. (evtl. das alte vorher sichern)

mkinitcpio -p linux

===Schlüssel als Klartextdatei speichern===
Da das Keyfile bereits auf dem Stick existiert, muss nur noch die Kernelzeile in der ''/boot/grub/menu.lst'' angepasst werden.

kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro vga=771 cryptkey=/dev/usbstick1:vfat:/archkey

''/dev/usbstick1'' ist dabei die FAT-Partition mit dem Keyfile.

Wenn alles geklappt hat, sollte das System beim nächsten Booten automatisch "aufgeschlossen" werden, vorausgesetzt der USB-Stick ist eingesteckt.

===Schlüssel zwischen MBR und erster Partition speichern===
'''ACHTUNG:''' Man sollte das hier nur machen, wenn man weiß, was man tut. Es kann zu Datenverlust kommen und die Partitionen oder der MBR des Sticks beschädigt werden.

Sollte auf dem Stick ein Bootloader installiert sein, müssen einige Werte angepasst werden. GRUB braucht z. B. die ersten 16 Sektoren. Man müsste also ''seek=4'' durch ''seek=16'' ersetzen. Andernfalls würden Teile von GRUB überschrieben werden. Im Zweifelsfall kann man sich die ersten 64 Sektoren anschauen und nach einem genügend großen freien Bereich suchen.

dd if=/dev/usbstick of=64sectors bs=512 count=64 # kopiert die ersten 64 Sektoren
hexcurse 64sectors # freien Platz suchen

Den Schlüssel auf den Stick schreiben:

dd if=/mnt/usb-stick/archkey of=/dev/usbstick bs=512 seek=4

Wenn das geklappt hat kann das (Klartext-) Keyfile vom Stick gelöscht werden:

shred --remove --zero /mnt/usb-stick/archkey

Jetzt muss noch die Kernelzeile in der ''menu.lst'' (GRUB) Datei angepasst werden:

kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro vga=771 cryptkey=/dev/usbstick:2048:2048

Das Format für die ''cryptkey'' Option sieht so aus:

cryptkey=BLOCKDEVICE:OFFSET:SIZE

Die Werte für OFFSET und SIZE passen für dieses Beispiel, da das Keyfile die Länge 2048 hat (bs=512 count=4) und ab OFFSET 2048 (bs=512 seek=4) auf dem Stick gespeichert ist. Gegebenenfalls müssen die Werte angepasst werden.

Das System wird nun beim nächsten Booten automatisch "aufgeschlossen" werden,
vorausgesetzt der USB-Stick ist eingesteckt.

==Padlock Fehlermeldung==
FATAL: Error inserting padlock_aes (/lib/modules/2.6.24-ARCH/kernel/drivers/crypto/padlock-aes.ko): No such device
Wenn diese Fehlermeldung beim Booten erscheint, ist das nicht weiter schlimm.
Die padlock-Module können nur mit speziellen Mini-ITX-Mainboards von VIA mit C7- oder Eden-CPU benutzt werden. Diese Mainboards enthalten eine Verschlüsselungseinheit namens Padlock, die unter anderem einen Hardware-Zufallsgenerator bereitstellt sowie hardwarebeschleunigte AES-Ver-/Entschlüsselung ermöglicht.

Die Module werden an zwei Stellen versucht zu Laden:

* in der initrd
* durch udev

Um die Meldung weg zu bekommen kan mann folgendes machen:

'''a)'''<br>
Der encrypt-Hook bewirkt beim Erstellen des initrd-Images das alle Module die in Verzeichnissen namens crypto liegen eingebunden und versucht zu laden werden. Das kann man steuern durch den Parameter CRYPTO_MODULES in der /etc/mkinitcpio.conf ähnlich des MODULES Parameters dort. D.h., man muss alle Crypto-Module, die zum Aufschließen der verschlüsselten Root-Partition nötig sind, dort explizit aufführen da der encrypt-Hook diese nicht mehr automatisch einfügt. Die benötigten Module kann man durch lsmod im laufenden System finden. Wer seine crypto-Module anhand des Namens nicht eindeutig identifizieren kann findet sie auf diesen Weg:

cd /lib/modules/$(uname -r)
source /lib/initcpio/functions
m="$(all_modules "/crypto/") "
echo $m

Diese Module würde der encrypt-Hook automatisch einbinden (darunter auch die padlock).
Zum Abgleich mit den eigenen Modulen jetzt einfach lsmod mit dieser Liste vergleichen.

Der nötige Eintrag in der /etc/mkinitcpio.conf kann z.B. so aussehen:

CRYPTO_MODULES="blowfish sha256_generic aes_i586 aes_generic"

Jetzt noch das initrd-Image erstellen(als root):

mkinitcpio -g /boot/initramfs-linux.img

'''b)'''<br>
Damit das Modul durch udev nicht versucht wird zu laden. Es reicht nicht (bzw. hat keine Auswirkung) die Module in der rc.conf mit ! vom Laden ausschließen zu wollen. Erst das explizite Blacklisten bei udev führte bei mir zum Erfolg. Also Datei /etc/modprobe.d/modprobe.conf editieren

blacklist padlock-aes
blacklist padlock-sha

'''Nachtrag:'''<br>Durch das Update auf 2.6.27 hat sich bei den notwendigen CRYPTO_MODULES wieder einiges geändert. Ich konnte meinen Laptop erstmal nicht normal starten, da in meinen vorgegebenen Modulen welche fehlten. Um das (und das padlock-Problem zu umgehen) habe ich nun die CRYPTO_MODULES Zeile wieder rausgenommen und habe einfach die Module selbst in lib/modules/2.6.27-ARCH/kernel/drivers/crypto/padlock-* gelöscht. Dann das initrd neu erstellt. Somit taucht diese Meldung ebenfalls nicht mehr auf (ich verwende nie eine Hardware für das ich dieses padlock brauchen würde).

==lrw-benbi==
Wer wie im [http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Mapping_partitions US-Arch-Wiki] mit lrw-benbi verschlüsseln will, muss ebenso die /etc/mkinitcpio.conf anpassen:

CRYPTO_MODULES="blowfish '''lrw''' sha256_generic aes_i586 aes_generic"

==Bei einem Dateisystem-Prüffehler==
Sollte der seltene Fall eintreten, dass die Dateisystem-Überprüfung einer entschlüsselten Partition fehlschlägt (etwa nach einem Crash des Betriebssystems mit anschließendem Kaltstart) und man dieses mit [https://wiki.archlinux.org/index.php/Fsck fsck] händisch machen muss, ist unbedingt darauf zu achten, die betroffene Partition (wie üblich) vorher mit ''umount'' auszuhängen!

Bei folgendem Boot-Szenario hängt die Überprüfung bei ''/dev/mapper/root'', das mit ext3 formatiert ist:

...
:: Running Hook [keymap]
:: Loading keymap...done.
:: Running Hook [encrypt]
...
EXT3-fs: barriers not enabled
EXT3-fs (dm-0): mounted filesystem with writeback data mode
kjournald starting. Commit interval 5 seconds
INIT: version 2.88 booting

> Arch Linux
...
--------------------------- [DONE]
:: Starting UDev Daemon [DONE]
:: Triggering UDev uevents [DONE]
:: Loading Modules [DONE]
:: Waiting for EDev uevents to be processed [DONE]
:: Bringing up loopback interface [DONE]
:: Unlocking encrypted volumes: home..ok [DONE]
:: Mounting Root Read-only [BUSY]
:: Checking Filesystems
/dev/mapper/root contains a file system with errors, check forced.
...
Inode 90689 has imagic flag set.

/dev/mapper/root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
[FAIL]
**************** FILESYSTEM CHECK FAILED *****************
* *
* Please repair manually and reboot. Note that the root *
* file system is currently mounted read-only. To remount *
* it read-write write: mount -n -o remount,rw / *
* When you exit the maintenance shell the system will *
* reboot automatically. *
* *
**********************************************************

Give root password for maintenance
(or type Control-D to continue): _

Wie zu sehen, hängt die Überprüfung bei einer bestimmten Adresse (inode) -- es muss aber bei weitem nicht die einzige sein! Außerdem ist die entschlüsselte ''/dev/mapper/root''-Partition bereits als / (Root) "read-only" eingehängt.

Nachdem man sich nun in der Wartungsumgebung (maintenance shell) als ''root'' eingeloggt hat, hängt man die Root-Partition (oder eben eine andere betroffene Partition) also wieder aus:

# umount /
und repariert sie anschließend mit:
# fsck.ext3 /dev/mapper/root
(oder je nach Format mit einer anderen fsck-Variante.) Fsck gibt dann laufend Statusmeldungen aus, und je nachdem, ob es viele Fehler gibt (was man vorher nicht wissen, aber wovon ausgehen kann), muss man häufig bestätigen. Um dies zu vermeiden, gibt man alternativ ein:

# fsck.ext3 -y /dev/mapper/root

Die Reparatur kann einige Zeit in Anspruch nehmen, ''man darf sie aber auf keinen Fall abbrechen, sonst wird die Partition zerstört!'' -- Schließlich startet man das System neu, und das Problem ist behoben.

== Siehe auch ==
* [[Verschlüsseltes Verzeichnis]]
* [[TrueCrypt]]

== Weblinks ==
* [https://wiki.koeln.ccc.de/index.php/Suspend_to_Cryptodisk "Suspend to Cryptodisk"-How-To auf wiki.koeln.ccc.de] {{sprache|de}}
* [http://www.marcstraube.de/linux/2012/08/installation-von-archlinux-mit-verschlusseltem-lvm-und-systemd/ Blog-Artikel zur Komplettverschlüsselung von Arch Linux] {{sprache|de}}

[[Kategorie: Sicherheit]]