Um auf einem System mit mehreren Gateways die Route für eine bestimmte IP zu ermitteln kann ip route show to match verwendet werden:
user@system:~$ ip route show to match 10.190.10.6
default via 192.168.2.1 dev ens160 proto static
10.0.0.0/8 via 192.168.2.250 dev ens160 proto static src 192.168.2.10
In diesem Artikel halte ich kurz fest, wie man die Festplatte eines Linux-Systems im laufenden Betrieb erweitert. Diese Anleitung bezeiht sich auch auf direkt formatierte Platten, eine Verwenung von LVM o.Ä. führt natürlich zu einem anderen Vorgehen, aber da es eh nur um virtuelle Systeme geht, gibt es ja keinen Grund eine weitere Abstraktionsschicht für die Platten einzuführen.
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 Einschränkung 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 = 3
The 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% /
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
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:
Aus der Richtlinie:
- 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.
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.
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.
Als Betriebssystem kommt ArchLinux1 zum Einsatz.
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.
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.
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.