Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
invis_server_wiki:installation:basesetup-160 [2026/05/11 11:10] flacco [Festplatten-Management] |
invis_server_wiki:installation:basesetup-160 [2026/05/20 11:13] (aktuell) flacco [Umsetzung] |
||
|---|---|---|---|
| Zeile 20: | Zeile 20: | ||
| Dem Festplattenmanagement sollten Sie besondere Aufmerksamkeit widmen, schließlich geht es um sinnvolle Nutzung Ihres Plattenplatzes, der Sicherheit Ihrer Daten und der Wartbarkeit des Servers. Wir erläutern das Management beispielhaft anhand eines von uns in der Praxis meist genutzten Setups. | Dem Festplattenmanagement sollten Sie besondere Aufmerksamkeit widmen, schließlich geht es um sinnvolle Nutzung Ihres Plattenplatzes, der Sicherheit Ihrer Daten und der Wartbarkeit des Servers. Wir erläutern das Management beispielhaft anhand eines von uns in der Praxis meist genutzten Setups. | ||
| + | ==== Rahmenbedingungen ==== | ||
| Wir gehen hier davon aus, dass Sie keinen Hardware-RAID-Controller im Einsatz haben, sondern statt dessen auf ein Linux-Sowftware-RAID setzen. Vorteil dieser Methode ist auf jeden Fall, die Hardware-Unabhängigkeit sowie der Preisvorteil. Die Investition in einen Hardware-RAID-Controller macht sich hinsichtlich der höheren Performance bemerkbar. | Wir gehen hier davon aus, dass Sie keinen Hardware-RAID-Controller im Einsatz haben, sondern statt dessen auf ein Linux-Sowftware-RAID setzen. Vorteil dieser Methode ist auf jeden Fall, die Hardware-Unabhängigkeit sowie der Preisvorteil. Die Investition in einen Hardware-RAID-Controller macht sich hinsichtlich der höheren Performance bemerkbar. | ||
| Zeile 27: | Zeile 28: | ||
| Unabhängig von der Größe der eingesetzten Festplatten bevorzugen wir eine GPT-basierte Partitionierung. Es hat sich gezeigt, dass dies im Falle eines Festplattendefekts weitaus weniger Probleme bereitet, als eine MBR basierte Partitionierung. Die Verwendung von GPT Partitionstabellen ist ab openSUSE Leap die Vorgabe, Sie müssen also nichts anpassen. | Unabhängig von der Größe der eingesetzten Festplatten bevorzugen wir eine GPT-basierte Partitionierung. Es hat sich gezeigt, dass dies im Falle eines Festplattendefekts weitaus weniger Probleme bereitet, als eine MBR basierte Partitionierung. Die Verwendung von GPT Partitionstabellen ist ab openSUSE Leap die Vorgabe, Sie müssen also nichts anpassen. | ||
| - | Ziel des Setups ist also eine GPT-basierte Partitionierung. Je nach BIOS/UEFI muss am Anfang jeder Platte entweder eine 8MB große Partition vom Typ "BIOS Boot" (Legacy Boot) oder eine min. 100MB große EFI-Boot-Partition (UEFI-Boot) angelegt werden, in die Grub seine Boot-Records speichert. Der verbleibende Platz wird mit zwei Partitionen des Typs "Linux RAID" belegt, die zu einem RAID1-Verbund kombiniert werden. Darauf aufbauend wird die Verteilung des zur Verfügung stehenden Platzes mittels Logical-Volume-Management (LVM) erledigt. Partitionen für Swap sind nicht erforderlich, dies wird in Form von LVM-Logical-Volumes umgesetzt. Wenn auch etwas gewöhnungsbedürftig, Agama beherrscht den Umgang mit LVM. | + | ==== Umsetzung ==== |
| + | |||
| + | Ziel des Setups ist also eine GPT-basierte Partitionierung. Je nach BIOS/UEFI muss am Anfang jeder Platte entweder eine 8MB große Partition vom Typ "BIOS Boot" (Legacy Boot) oder eine min. 100MB große EFI-Boot-Partition (UEFI-Boot) angelegt werden, in die Grub seine Boot-Records speichert. Der verbleibende Platz wird für eine Partition des Typs "Linux RAID" belegt, die zu einem RAID1-Verbund kombiniert werden. Darauf aufbauend wird die Verteilung des zur Verfügung stehenden Platzes mittels Logical-Volume-Management (LVM) erledigt. Partitionen für Swap sind nicht erforderlich, dies wird in Form von LVM-Logical-Volumes umgesetzt. Wenn auch etwas gewöhnungsbedürftig, **agama** beherrscht den Umgang mit LVM. | ||
| //**Hinweis:** Wer sich statt dessen an einem vollständig manuellen Setup versuchen möchten findet **[[:invis_server_wiki:installation:diskprep|hier]]** eine nicht ganz aktuelle Anleitung.// | //**Hinweis:** Wer sich statt dessen an einem vollständig manuellen Setup versuchen möchten findet **[[:invis_server_wiki:installation:diskprep|hier]]** eine nicht ganz aktuelle Anleitung.// | ||
| Zeile 39: | Zeile 42: | ||
| //**Hinweis:** Lesen Sie für Systeme mit Festplatten größer 2TB und/oder aktiviertem UEFI-Boot bitte die entsprechenden Hinweise [[http://wiki.invis-server.org/doku.php/invis_server_wiki:installation:diskprep#festplatten_groesser_2tb_uefi_boot_secure_boot|hier]].// | //**Hinweis:** Lesen Sie für Systeme mit Festplatten größer 2TB und/oder aktiviertem UEFI-Boot bitte die entsprechenden Hinweise [[http://wiki.invis-server.org/doku.php/invis_server_wiki:installation:diskprep#festplatten_groesser_2tb_uefi_boot_secure_boot|hier]].// | ||
| - | Hier noch einmal die Befehle die Sie zur Partitionierung und zum Anlegen des RAID1 Verbundes benötigen: | + | === Setup mit agama === |
| - | **Festplatte partitioniern:** | + | **[[ :invis_server_wiki:installation:basesetup-160:agama|Leap-Setup mit agama]]** |
| - | <code> | + | === SSH Zugang === |
| - | linux:~ # fdisk /dev/sdX | + | |
| - | </code> | + | |
| - | Es werden wie gesagt auf jeder Platte 2 Partitionen benötigt, eine Boot-Partition (BIOS Boot oder UEFI Boot) und eine Partition vom Typ "LINUX RAID". | + | Nach der Installation des Systems mit **agama** ist der SSH-Dienst zunächst inaktiv. Das lässt sich leicht ändern: |
| - | + | ||
| - | **RAID-Verbund anlegen:** | + | |
| <code> | <code> | ||
| - | linux:~ # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2 | + | invis:~ # systemctl start sshd.service |
| </code> | </code> | ||
| - | Leider geht **agama** mit festen Größenangaben zu erstellender LVM-Volumes nicht korrekt um. Um sicher zu sein muss ein bereits angelegtes Volume noch ein mal editiert werden. Es zeigt sich, dass die Checkbox für "Größenzuwachs erlauben" wieder aktiviert ist. Wird das übersehen nutzt **agama** den gesamten Platz des physical Volumes aus und vergrößert alle anzulegenden Volumes im Verhältnis der getätigten Größenangabe, was ziemlicher Schwachsinn ist. | + | Weiter muss dafür gesorgt werden, dass der SSH-Dienst auch nach einem Neustart des Servers automatisch startet: |
| - | + | ||
| - | Wird dieser Umstand nicht übersehen, ärgert **agama** mit dem nächsten Unfug. Er legt auf dem RAID-Volume eine Partition an, die genau so groß ist wie die Summe der logical Volumes. Den daraus resultierenden freien Platz nachträglich der angelegten Partition zuzuordnen ist so gut wie unmöglich. In diesem Fall ist der einfachste Workaround auf dem freien Platz mit **fdisk** eine zweite Partition anzulegen und diese dann als physical Volume der zuvor angelegten Volumegroup zuzuordnen. | + | |
| - | + | ||
| - | Im Falle zu großer Volumes können diese, so sie mit Dateisystem **ext4** formatiert wurden, nachträglich verkleinert werden. Das funktioniert nur wenn die Dateisysteme **nicht** eingehängt sind, also im Falle eines var-Volumes nur aus einem Rescue-System heraus. Das ganze funktioniert wie folgt. Zunächst erfolgt der umount: | + | |
| <code> | <code> | ||
| - | invis:~ # umount /dev/system/srv | + | invis:~ # systemctl enable sshd.service |
| </code> | </code> | ||
| - | Danach muss das Dateisystem zwingend überprüft werden: | + | Zu bedenken ist, dass ein SSH-Login des Benutzers root unter Verwendung von Benutzername und Passwort nicht möglich ist. Sie können sich mit dem Benutzer anmelden. den Sie während des Setups eingerichtet haben und dann mit //**su -**// oder //**sudo -i**// arbeiten. Möglich ist auch, dass Sie sich direkt als root via SSH mit der Public-Key-Methode anmelden. Dazu müssen Sie sich ein SSH-Schlüsselpaar erzeugen und den Public-Key in die Datei: <file>/root/.ssh/authorized_keys</file> schreiben. |
| - | + | ||
| - | <code> | + | |
| - | invis:~# e2fsck -f /dev/system/srv | + | |
| - | </code> | + | |
| - | + | ||
| - | Jetzt kann zunächst das Dateisystem verkleinert werden, im Beispiel auf 100GiB: | + | |
| - | + | ||
| - | <code> | + | |
| - | invis:~# resize2fs /dev/system/srv 100G | + | |
| - | </code> | + | |
| - | + | ||
| - | Anschließend wird das Volume passend dazu verkleinert: | + | |
| - | + | ||
| - | <code> | + | |
| - | invis:~# lvresize -L 100G /dev/system/srv | + | |
| - | </code> | + | |
| - | + | ||
| - | Danach kann das Volume wieder eingehängt werden. Am einfachsten mit: | + | |
| - | + | ||
| - | <code> | + | |
| - | invis:~# mount -a | + | |
| - | </code> | + | |
| - | + | ||
| - | //**Achtung:** Das Dateisystem **XFS** lässt sich nicht verkleinern.// | + | |
| - | + | ||
| - | Wird das Verkleinern in einem Rescue-System vorgenommen sind zunächst MD-RAID-Verbünde und auch darauf befindliche Logical-Volumes inaktiv. Beides muss erst aktiviert werden. Zunächst der RAID-Verbund mit: | + | |
| - | + | ||
| - | <code> | + | |
| - | invis:~ # mdadm --assemle --scan | + | |
| - | </code> | + | |
| - | + | ||
| - | Dann sind die betreffenden Volumes zu aktivieren, hier am Beispiel des var-Volumes: | + | |
| - | + | ||
| - | <code> | + | |
| - | invis:~ # lvchange -ay /dev/system/var | + | |
| - | </code> | + | |
| - | + | ||
| - | Danach wird verfahren wie zuvor gezeigt. | + | |
| - | + | ||
| - | Hoffen wir mal, dass **agama** irgendwann erwachsen wird! | + | |
| ===== Letzte Vorbereitungen ===== | ===== Letzte Vorbereitungen ===== | ||