In diesem Artikel halte ich kurz fest, wie man die Festplatte eines Linux-Systems im laufenden Betrieb erweitert. Zunächst muss der zur Verfügung stehende Speicher erweitert werden, das funktioniert natürlich nur bei virtuellen Systemen, eine physische Festplatte lässt sich leider nicht einfach aufblasen ;) Eine weitere Existiert noch: Das ganze funktioniert nur für die letzte Partition auf der Festplatte.
Die folgende Anleitung bezieht sich auf die Platte sda, bei Abweichender Platte muss das natürlich in allen Befehlen entsprechend angepasst werden.
Wenn jetzt also mehr Platz zur Verfügung steht als verwendet wird, kann mittels echo 1>/sys/class/block/sda/device/rescan ein Rescan der Platte angestoßen werden. Aufgrund der Ausgabeumleitung funktioniert der Befehl nicht mit vorangestelltem sudo, daher entweder vorher zum User Root wechseln (sudo su) oder eine der beiden Lösungen aus dem verlinkten Artikel verwenden und entweder die ganze Zeile in eine Subshell übergeben (sudo bash -c 'echo 1 > /sys/block/sda/device/rescan') oder die Umleitung mit tee vornehmen (echo 1 | sudo tee /sys/block/sda/device/rescan ).
Am Anschluss kann mittels fdisk -l /dev/sda geprüft werden, ob die neue Größe erkannt wurde, die Ausgabe sollte eine Warnung sowie die korrekte neue Größe beinhalten.
tokk@linux:~$sudo fdisk -l /dev/sda
GPT PMBR size mismatch (33554431 != 41943039) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Wenn das funktioniert hat mittels fdisk die alte Partition gelöscht und eine neue angelegt werden:
tokk@linux:~$sudo fdisk /dev/sda
[…]Command (m for help): d
Partition number (1,2, default 2):↵
Partition 2 has been deleted.
Command (m for help): n
Partition number (2-128, default 2):↵
First sector (4096-41943006, default 4096):↵
Last sector, +/-sectors or +/-size{K,M,G,T,P}(4096-41943006, default 41943006):↵
Created a new partition 2 of type 'Linux filesystem' and of size 20 GiB.
Partition #2 contains a ext4 signature.Do you want to remove the signature? [Y]es/[N]o: N
Command (m for help): w
The partition table has been altered.
Syncing disks.
Der erste Sektor der neuen Partition muss hierbei identisch zum ersten Sektor der gerade gelöschten Partition sein, der letzte Sektor muss größer oder mindestens gleich dem der alten Partition sein. Wenn man keinen Wert eingibt wählt fdisk automatisch den letzten nutzbaren Sektor aus und vergrößert die Partition somit auf den maximalen zur Verfügung stehenden Platz. Sehr wichtig ist es, die Frage nach dem Löschen der bestehenden Dateisystem-Signatur zu verneinen!
Abschließend muss das Dateisystem der Platte noch auf die neue Größe der Partition eingestellt werden:
tokk@linux:~$sudo resize2fs /dev/sda2
resize2fs 1.46.5 (30-Dec-2021)Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks =3The filesystem on /dev/sda2 is now 5242363(4k) blocks long.
Der Festplattenplatz steht jetzt zur Verfügung und kann verwendet werden. Vorher:
tokk@linux:~$df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 16G 8,1G 6,9G 54% /
Nachher:
tokk@linux:~$df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 20G 8,1G 11G 44% /
tl;dr
sudo su
echo 1>/sys/class/block/sda/device/rescan
fdisk /dev/sda
Command (m for help): d
Partition number (1,2, default 2):↵
Command (m for help): n
Partition number (2-128, default 2):↵
First sector (4096-41943006, default 4096):↵
Last sector, +/-sectors or +/-size{K,M,G,T,P}(4096-41943006, default 41943006):↵
Do you want to remove the signature? [Y]es/[N]o: N
Command (m for help): w
resize2fs /dev/sda2
Obligatorische Warnung
Dass die hier aufgeführten Befehle zu Datenverlust führen können, erwähne ich hier nur der Vollständigkeit halber, da es eigentlich klar sein sollte
Vielen Untersuchungen und Aufrufen kompetentem Personals zum Trotz geht seit Jahren das Gespenst der regelmäßigen Passwortänderungen in der IT-Welt herum. Millionen von Usern werden dank einer vor Jahrzehnten kurzzeitig herausgegebenen und inzwischen zurückgezogenen Empfehlung der US-Amerikanischen IT-Standardisierungsbehörde NIST (Vergleichbar mit einer Fußion aus PTB und BSI) regelmäßig vollkommen unnötig dazu genötigt, ihre Passwörter zu ändern. Für User, die einen Passwortmanager verwenden ist es einfach eine nervige Angelegenheit, die Anwender ohne Passwortmanager werden dadurch regelrecht zur Unsicherheit gedrängt, Passwörter entweder nach leicht zu merkenden Mustern zu wählen oder diese irgendwo aufzuschreiben.
Aufgrund all der Nachteile wurde die Empfehlung auch schon länger zurückgezogen, aber in Unternehmen gibt es ja leider immer die eine Etage, in der technisches Know-how leider Mangelware ist. Dies wird dann meist mit einem umso größeren Willen zur Entscheidung kompensiert und diese Praxis wird mit allen Mitteln am Leben erhalten. Daher sah sich das NIST wohl nun gezwungen, die Richtlinie explizit umzukehren und einen Passwortwechsel zu untersagen:
Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Mit anderen Worten: Eine Passwortänderung soll nicht erzwungen werden, es sei denn, es besteht der begründete Verdacht auf eine Kompromittierung.
Dies sollte in Diskussionen um die Abschaffung einer solchen Richtlinie einen guten Hebel liefern, dieses alte Relikt endlich ad Acta legen zu können.
Dies ist der erste Beitrag einer Blogreihe über meine Infrastruktur, die ich nutze, um so unabhängig wie möglich selbst zu hosten. Den Anfang möchte ich mit einem kleinen Beitrag über meine Server machen, da diese natürlich das Gerüst für alles Weitere bereitstellen. Für sich selbst genommen ist dieser Beitrag vermutlich nicht ganz so spannend, aber im Laufe der Serie wird natürlich immer mal wieder auf die Server verwiesen, daher dachte ich, eine kleine Vorstellung könne nicht schaden.
Seit meinem Einstieg in die Webhosting-Welt mittels eines kleinen Pakets bei dem 2016 eingestellten Hoster DomainGo habe ich viele Dienste probiert und Hardwareiterationen hinter mir. Inzwischen bin ich bei einem Setup angekommen, mit dem ich sehr zufrieden bin.
Domain-Registrar
Meine Domains habe ich inzwischen alle bei INWX, einem Dienstleister, der sich auf Domains spezialisiert hat. Es werden auch einige Hosting-Pakete angeboten, zu denen kann ich aber nichts sagen. Preislich bin ich sehr zufrieden, pro .de-Domain fallen jährlich 4,65 € an. Die Auswahl an TLDs ist auch beachtlich, Stand heute gibt es 2226 verschiedene zur Auswahl! >
INWX selbst bietet eigentlich alles, was man braucht, inklusive einer API, um alle Änderungen an Domains auch automatisiert durchführen zu können.
Virtueller privater Server
Als zentrales Standbein der Infrastruktur außerhalb meines privaten Netzwerkes nutze ich einen VPS bei Netcup. Netcup bietet neben einer großen Paketauswahl mit wirklich kleinen Preisen die Möglichkeit, ein Betriebssystem eigener Wahl aus einem hochgeladenen ISO auf dem eigenen Server zu installieren, so das man nicht von einer meist kleinen Distributionsliste abhängig ist und auch wechsel zwischen Distributionen oder gar Betriebssystemen einfach jederzeit selbst durchführen kann. Selbst Windows wäre möglich, um die Lizenz müsste man sich hier jedoch selbst kümmern. Ich nutze aktuell ein VPS 3000 aus der 9. Generation, hier habe ich 600 GB SSD-Festplattenspeicherplatz, 24 GB RAM und eine 6-Core-CPU. Leistungstechnisch hatte ich hier noch nie Probleme. Sollte ich in Zukunft das Paket wechseln wäre ggf. auch die neue ARM-Linie interessant - als ich das Paket buchte gab es diese noch nicht.
Angefangen mit einem Raspberry Pi hat sich mein Setup über ein Intel-Atom-Board zu einem Supermicro Server mit einem Intel Xeon E3-1515M v5, 64 GB RAM, einer 500 GB NVM Platte für System und Datenbanken. Zur Datenablage ist noch ein RAID 6 mit einer Nettokapazität von 8.2 TB verbaut.
Hier laufen die meisten Dienste und für Familienmitglieder gibt es Shares.
Als Betriebssystem kommt auch hier ArchLinux1 zum Einsatz.
Sicherungsspeicher
Die wichtigsten Daten auf den Servern werden auf dem jeweils anderen synchronisiert, bei 8.2 TB kann ich aber natürlich nicht alles irgendwo in die Cloud speichern, daher habe ich noch ein NAS mit knapp 10 TB Nettokapazität, auf das der Homeserver regelmäßig gesichert wird.
Fußnoten
Ich möchte an dieser Stelle keine Diskussion um das Für und Wider von Rolling-Release Distributionen starten, aber ich betreibe persönlich mehrere Systeme und hatte noch nie die angeblich dauernd auftretenden Probleme damit - dafür habe ich aber ein immer aktuelles System. ↩︎↩︎
wenn Paketsignaturen nicht validiert werden können
Tokk 131 Wörter ~1 Min.
Privat nutze ich auf meinem Laptop Arch Linux. Derzeit ist der Laptop allerdings nicht viel in Verwendung, da ich mich meist an den PC setze um zu arbeiten. Dies führt dazu, das Systemupdates, derer es bei einer Rolling-Release-Distribution ja nicht gereade wenige gibt, ein wenig mehr hinterherhängen als sie eigentlich sollten. Dies kann dann dazu führen, dass beim Update folgende Fehlermeldungen erscheinen:
Fehler: <Paketname>: signature from "Mr. Maintainer maintainer@archlinux.org" is unknown trust
:: Datei /var/cache/pacman/pkg/paket-version-x86_64.pkg.tar.zst ist beschädigt (Ungültiges oder beschädigtes Paket (PGP-Signatur)).
Soll die Datei entfernt werden? [J/n]
Dies liegt dann zumeist am veralteten archlinux-keyring, der zum verifizieren der Pakete verwendet wird und nicht alle aktuellen Schlüssel enthält. Die Lösung ist einfach, zunächst muss das Paket mittels
pacman -S archlinux-keyring
upgedatet werden, dann kann das Systemupdate wieder wie gewohnt durchgeführt werden.
Ein elementarer Teil der Betriebssicherheit eines IT-Systems ist die Datensicherung. Spätestens wenn man Dienste auch Freunden und Familie zur Verfügung stellt ist die Sicherung ein Muss. Wem seine eigenen Daten lieb sind, sollte sich natürlich auch schon vorher damit beschäftigen. Ein Mailserver ist hier ein Paradebeispiel, der Grundgedanke sollte aber auf alle anderen Dienste übertragen werden.
Die Mailcow-Dokumentation zur Datensicherung ist ein guter Einstiegspunkt, beschäftigt sich allerdings nur mit der periodischen Ausführung mittels cron. Auf meinem Server habe ich kein Cron installiert, da ich im laufe der Zeit die Vorteile von Systemd-Timern schätzen gelernt habe.
Einrichtung
Zunächst erstellen wir einen Systemd-Service, der beim Starten ein Backup von Mailcow erstellt und sich dann wieder beendet. Hierzu legen wir die Datei /etc/systemd/system/mailcowBackup.service mit folgendem Inhalt an:
[Unit]Description=Mailcow Backup[Service]Type=oneshotEnvironment="MAILCOW_BACKUP_LOCATION=/opt/backup"ExecStart=/opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 5[Install]WantedBy=multi-user.target
Type=oneshot bedeutet hierbei, dass es sich um einen Prozess handlet der gestartet wird und sich nach getaner Arbeit beendet - das ist wichtig, das Backup soll ja nicht direkt wieder gestartet werden. Die Environment-Variable MAILCOW_BACKUP_LOCATION steuert den Ausgabepfad des fertigen Backups, daher muss diese Variable natürlich gesetzt und entsprechend angepasst werden
Sobald diese Service-Unit existiert kann der Backup-Prozess mittels systemctl start mailcowBackup.service jederzeit manuell gestartet werden.
Die Ausgabe des Backup-Skriptes wird im Systemlog erfasst und kann daher über systemctl status mailcowBackup.service und journalctl -f -u mailcowBackup.service eingesehen werden.
[user@server]$ sudo systemctl status mailcowBackup.service
○ mailcowBackup.service - Mailcow Backup
Loaded: loaded (/etc/systemd/system/mailcowBackup.service; disabled; preset: disabled) Active: inactive (dead)Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/ib_buffer_pool
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/aria_log.00000001
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/aria_log_control
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_checkpoints
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/backup-my.cnf
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_info
Aug 07 07:32:16 mailcow.url backup_and_restore.sh[14066]: /backup_mariadb/xtrabackup_binlog_pos_innodb
Aug 07 07:32:16 mailcow.url systemd[1]: mailcowBackup.service: Deactivated successfully.
Aug 07 07:32:16 mailcow.url systemd[1]: Finished Mailcow Backup.
Aug 07 07:32:16 mailcow.url systemd[1]: mailcowBackup.service: Consumed 1.056s CPU time, 14.1M memory peak.sudo
Periodische Ausführung mittels Timer
Der nächste Schritt ist die Anlage eines Timers, der die neu angelegte Unit zu definierten Zeitpunkten startet. Hierzu legen wir die Datei /etc/systemd/system/mailcowBackup.timer wie folgt an:
[Unit]Description=Starts the Mailcow Backup every nightRequires=mailcowBackup.service[Timer]Unit=mailcowBackup.serviceOnCalendar=*-*-* 00:30:00[Install]WantedBy=timers.target
Wichtig ist hier neben der Angabe der entsprechenden Service-Unit die Zeile OnCalendar=*-*-* 00:30:00, die besagt, dass der Timer An jedem Tag jeden Monats jeden Jahres um 00:30 aktiv werden soll. Der Timer muss abschließend noch aktiviert und gestartet werden. Dies erfolgt analog zu Service Units: systemctl enable --now mailcowBackup.timer. Mittels systemctl list-timers können aktive Timer eingesehen werden. Der Befehl zeigt eine Auflistung aller Timer inklusive dem absoluten und relativen Zeitpunkt der nächsten sowie vorherigen Ausführung.
[tokk@mx-web backup]$ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
[...]Thu 2024-08-08 00:30:00 UTC 16h - - mailcowBackup.timer mailcowBackup.service
Wed 2024-08-14 07:05:57 UTC 6 days Wed 2024-08-07 07:05:57 UTC 33min ago certbot-renewal.timer certbot-renewal.service
[...]
Auch hier landet die Ausgabe des Backups im System-Log und kann via journalctl eingesehen werden. Die komplette Ausgabe der tagesaktuellen Sicherung lasen sich zum Beispiel mittels journalctl -S today -u mailcowBackup.service anzeigen.
Weiterführende Gedanken
Nach der Einrichtung des Timers wird jede Nacht ein Backup unter dem spezifizierten Pfad angelegt. Sollte die Festplatte des Servers oder der ganze Server jedoch ausfallen ist dadurch jedoch nicht nur Mailcow betroffen, sondern auch das Backup. Daher ist es dringend notwendig, die Backups automatisiert noch anderweitig abzulegen.