Vor der Umstellung empfiehlt es sich, ein Backup der Installation und der Datenbank anzulegen. Außerdem sollte geprüft werden, ob die eingesetzten Apps bereits mit Nextcloud 33 und PHP 8.4 kompatibel sind.

Installierte PHP-Version prüfen

Das System sollte zunächst auf den aktuellen Stand gebracht werden:

sudo apt update && sudo apt upgrade

Jetzt prüfen, welche PHP-Version aktuell aktiv ist:

php -v

Falls Apache mit PHP-FPM genutzt wird, lohnt sich auch ein Blick auf die aktiven Module und Konfigurationen.

PHP 8.4 und benötigte Module installieren

Wer von PHP 8.2 auf PHP 8.4 wechselt, installiert zunächst die neue Version samt der für Nextcloud üblichen Erweiterungen:

sudo apt update

sudo apt install php8.4 php8.4-mbstring php8.4-gd php8.4-curl php8.4-imagick php8.4-intl php8.4-bcmath php8.4-gmp php8.4-mysql php8.4-zip php8.4-xml php8.4-apcu libapache2-mod-php8.4 php8.4-bz2 php8.4-redis

PHP 8.2 deaktivieren und PHP 8.4 aktivieren

Nun wird PHP 8.2 deaktiviert und PHP 8.4 aktiviert:

sudo update-alternatives --config php

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
  6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Hier die entsprechende Nummer eingeben – in diesem Fall die 6 für PHP 8.4:

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
* 6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Die Abfrage der Version zeigt, ob die Umstellung auf PHP 8.4 angenommen wurde.

php -v

PHP 8.4 FPM starten und Apache neu laden

Anschließend wird der neue FPM-Dienst aktiviert und gestartet:

sudo a2disconf php8.2-fpm
sudo apt install php8.4-fpm
sudo a2enconf php8.4-fpm

Der Neustart des Webservers aktiviert nun die aktuelle PHP-Version:

sudo service apache2 restart

Nextcloud-Konfiguration

Sollten in Nextcloud anschließend wieder die bekannten Fehlermeldungen erscheinen, sind diese am besten Schritt für Schritt abzuarbeiten. Dazu werden zunächst die neue php.ini geöffnet:

sudo nano /etc/php/8.4/fpm/php.ini

und anschließend die Werte für memory_limit sowie session.gc_maxlifetime gemäß den Empfehlungen angepasst:

memory_limit = 512M
session.gc_maxlifetime = 3600

Am Ende der php.ini werden außerdem noch die Einstellungen für den Zwischenspeicher OPcache ergänzt:

opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1

Zur Optimierung von PHP 8.4 FPM können speziell auf einem Raspberry Pi 5 mit 8 GB RAM in der Datei www.conf

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

die folgenden Werte angepasst werden. Standardmäßig stehen dort in der Regel:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Diese werden dann auf folgende Werte geändert:

pm = dynamic
pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

Anschließend wird der Dienst neu gestartet:

sudo service php8.4-fpm restart

Danach muss in der apcu.ini noch das Command Line Interface (CLI) des PHP-Caches aktiviert werden. Dazu die Datei öffnen:

sudo nano /etc/php/8.4/mods-available/apcu.ini

und am Ende folgende Zeile ergänzen:

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet:

sudo service apache2 restart

Nextcloud prüfen

Danach sollte die Nextcloud-Instanz im Browser aufgerufen werden. Unter Administrationseinstellungen / System lässt sich kontrollieren, ob die neue PHP-Version erkannt wurde.

Zur Sicherheit zusätzlich die Logdateien von Apache, PHP-FPM und Nextcloud prüfen.

Fazit

Die Umstellung von PHP 8.2 auf PHP 8.4-fpm für Nextcloud 32 ist unter Raspberry Pi OS schnell erledigt. Wichtig ist vor allem, die benötigten PHP-Module zu installieren und anschließend die alte FPM-Konfiguration sauber durch die neue zu ersetzen.

Der Beitrag PHP 8.4 FPM für Nextcloud 33 erschien zuerst auf intux.de.

Ich konnte somit alles 1:1 mit meinem System umsetzen. Hier nun alle Schritte mit den entsprechenden Erläuterungen.

Bevor es jedoch losgeht, noch ein wichtiger Hinweis:

Denkt bitte daran, vorher ein Backup zu erstellen! Das Upgrade birgt nicht zu unterschätzende Gefahren.

Upgrade auf Trixie

Zuerst sollte man dafür sorgen, das System inklusive Kernel und aller Abhängigkeiten auf den neuesten Stand zu bringen. Hierzu führt man folgenden Befehl aus:

sudo apt update && sudo apt full-upgrade

Vorbereitend wurde in meinem Fall die alte PHP-Fremd-Quelle deaktiviert.

Hierzu setzt man eine Raute (#) vor den Eintrag, öffnet dazu die php.list mit einem Editor

sudo nano /etc/apt/sources.list.d/php.list

und kommentiert die Zeile entsprechend aus:

#deb https://packages.sury.org/php/ bullseye main

Danach werden die hauseigenen Quellen des Raspberry Pi OS auf Trixie umgestellt:

sudo nano /etc/apt/sources.list

Hierzu wird in allen Quellen wie folgt bookworm durch trixie ersetzt:

deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

Das Gleiche führt man analog hier durch:

sudo nano /etc/apt/sources.list.d/raspi.list

deb http://archive.raspberrypi.org/debian/ trixie main

Da beim ersten Versuch des Upgrades noch einiges schieflief, möchte ich an dieser Stelle darauf hinweisen, dass das Entfernen folgender Pakete für das Gelingen extrem wichtig ist!

sudo apt purge -y raspberrypi-ui-mods
sudo apt purge -y lxplug-batt
sudo apt purge -y lxplug-cpu

Ist dies erledigt, startet man via

sudo apt update && sudo apt full-upgrade

das eigentliche Upgrade. Hierzu ist noch zu erwähnen, dass bei den Abfragen zu alten Konfigurationen diese erhalten bleiben sollen. An diesen Stellen also bitte immer die Vorgabe (N) während der Installation wählen.

Die Pakete rpd-wayland-all und rpd-x-all werden noch nachinstalliert:

sudo apt install rpd-wayland-all rpd-x-all

Aufgeräumt wird mit:

sudo apt autoremove
sudo apt clean

und das System wird neu gestartet:

sudo reboot now

Überprüfung

Nach dem Neustart sollte der Befehl

sudo cat /etc/os-release

nun Folgendes ausgeben:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Feintuning

Da der NetworkManager nach dem Neustart noch nicht arbeitet, sollte er mit

sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager

aktiviert und gestartet werden.

PHP-Quelle wieder einbinden

Am Anfang der Anleitung hatte ich die PHP-Quelle auskommentiert. Das machen wir nun wieder rückgängig. Erscheint nun nach einem Update der Hinweis, dass der zugehörige Schlüssel abgelaufen ist, löscht man diesen, lädt den aktuellen herunter und liest ihn neu ein.

sudo rm -f /usr/share/keyrings/deb.sury.org-php.gpg
sudo curl -sSLo /etc/apt/trusted.gpg.d/sury-php.gpg https://packages.sury.org/php/apt.gpg

Die Paketquellen werden nun abermals eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Da die PHP-Quelle allerdings noch nicht für Trixie optimiert ist, ersetzt man auch hier bookworm bzw. bullseye durch trixie:

sudo nano /etc/apt/sources.list.d/php.list

#deb https://packages.sury.org/php/ bullseye main

Ein weiteres Mal werden die Paketquellen eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Ist dies geschehen, ist das Upgrade von Raspberry Pi OS Version 12 auf 13 abgeschlossen.

Viel Erfolg bei der Umsetzung!

Der Beitrag Raspberry Pi OS Bookworm -> Trixie erschien zuerst auf intux.de.

Hierfür wird auf Linux-Systemen das Tool smartmontools benötigt. Die ausgelesenen Daten liefern wertvolle Hinweise auf mögliche Probleme mit dem Medium – bevor es zu einem Ausfall kommt.

Installation

Unter Debian-basierten Systemen ist smartmontools in den Paketquellen enthalten und schnell installiert:

sudo apt install smartmontools

S.M.A.R.T.-Werte abfragen

Um die aktuellen Werte eines Laufwerks auszulesen, genügt folgender Befehl:

sudo smartctl -a /dev/sdX

/dev/sdX steht dabei stellvertretend für das jeweilige Laufwerk, etwa /dev/sda oder /dev/nvme0n1 für NVMe-SSDs. Die Option -a sorgt dafür, dass alle verfügbaren Informationen ausgegeben werden.

Wichtig: sdX ist ein Platzhalter und muss durch die tatsächliche Bezeichnung des zu prüfenden Laufwerks ersetzt werden.

Was die Ausgabe verrät

Die Ausgabe von smartctl ist recht umfangreich und auf den ersten Blick etwas unübersichtlich. Neben allgemeinen Informationen wie Modell, Firmware-Version und Seriennummer finden sich dort auch die sogenannten S.M.A.R.T.-Attribute. Diese zeigen unter anderem wichtige Messwerte wie:

• den allgemeinen Gesundheitszustand (SMART overall-health self-assessment test result)
• die Temperatur des Laufwerks (Temperature)
• die Verfügbare Reserve (Available Spare)
• den Reserve-Schwellenwert (Available Spare Threshold)
• die verbrauchte Lebensdauer (Percentage Used)
• die gelesenen Dateneinheiten (Data Units Read)
• die geschriebenen Dateneinheiten (Data Units Written)

Ein Beispiel:

sudo smartctl -a /dev/nvme0n1

...
SMART overall-health self-assessment test result: PASSED
Temperature: 45 Celsius
Available Spare: 100%
Available Spare Threshold: 50%
Percentage Used: 4%
Data Units Read: 37.885.790 [19,3 TB]
Data Units Written: 28.019.142 [14,3 TB]
...

Für eine kurze Abfrage des Gesundheitszustands reicht hingegen:

sudo smartctl -H /dev/sdX

Ein Beispiel:

sudo smartctl -H /dev/nvme0

...
SMART overall-health self-assessment test result: PASSED
...

Fazit

Mit smartctl hat man unter Linux ein mächtiges Werkzeug zur Hand, um die Gesundheit von Laufwerken zu prüfen. Gerade bei älteren Festplatten lohnt sich ein regelmäßiger Blick auf die S.M.A.R.T.-Werte. Im Ernstfall können sie vor Datenverlust warnen – und geben den entscheidenden Anstoß, ein Backup nicht weiter aufzuschieben.

Der Beitrag Gesundheit der Festplatte überprüfen erschien zuerst auf intux.de.

Was sind Bad Sektoren?

Bad Sektoren sind physisch oder logisch beschädigte Bereiche auf einem Datenträger. Physische Defekte entstehen durch Abnutzung, mechanische Schäden oder Produktionsfehler. Logische Bad Sektoren hingegen resultieren meist aus Softwareproblemen oder Stromausfällen und lassen sich mitunter korrigieren.

Analysewerkzeuge unter Linux

Linux bietet verschiedene Werkzeuge zur Analyse und Erkennung defekter Sektoren. Eines der bekanntesten Tools ist badblocks.

Ein einfacher Check lässt sich wie folgt durchführen:

sudo badblocks -vsn /dev/sdX

Ersetzt man dabei /dev/sdX durch das entsprechende Gerät, erhält man einen Überblick über den Zustand der Sektoren. Hierbei sucht badblocks gezielt nach defekten Blöcken der Festplatte.

Dabei sollte beachtet werden, dass dieser Vorgang – je nach Größe des Datenträgers – einige Zeit in Anspruch nehmen kann.

Fazit

Die regelmäßige Analyse auf Bad Sektoren ist ein wichtiger Bestandteil der Systempflege. Frühzeitig erkannte Fehler ermöglichen rechtzeitige Backups und gegebenenfalls den Austausch der betroffenen Hardware. Open-Source-Werkzeuge wie badblocks bieten unter Linux zuverlässige Möglichkeiten zur Diagnose – ganz ohne proprietäre Software.

Der Beitrag Überprüfung auf fehlerhafte Sektoren erschien zuerst auf intux.de.

Neulich bin ich auf ein solches Verhalten gestoßen, als ich Bilder, die mir von einem Fotografen übergeben wurden, in WordPress zur Weiterverarbeitung hochladen wollte. Zuvor hatte ich die Größen der Dateien in einer Stapelverarbeitung über das Terminal angepasst. Danach habe ich die Dateinamen nach bestimmten Vorgaben umbenannt.

Nachdem das erledigt war, habe ich das Bildmaterial in die Mediathek der Webseite hochgeladen. Dabei fiel mir auf, dass die Bezeichnungen der Bilder nicht den neuen Dateinamen entsprachen. Stattdessen trugen sie die Bezeichnung der Veranstaltung, bei der sie aufgenommen wurden. Ein Löschen und erneutes Hochladen der Fotos konnte das Problem nicht beheben.

Schnell lag der Verdacht nahe, dass in den Bilddateien selbst noch Informationen gespeichert waren, die von WordPress beim Hochladen automatisch übernommen wurden. Im konkreten Fall handelte es sich um Metadaten in der IPTC-Kopfzeile. Bei knapp 100 Bildern wäre es sehr aufwendig gewesen, diese Angaben manuell zu entfernen. Eine Lösung über eine Stapelverarbeitung war daher naheliegend, am besten direkt über das Terminal unter Ubuntu.

Glücklicherweise gibt es eine einfache Möglichkeit, solche eingebetteten Informationen automatisch aus den Dateien zu entfernen.

Zuvor muss allerdings das Paket libimage-exiftool-perl installiert werden.

sudo apt install libimage-exiftool-perl

Danach wird folgender Befehl im Verzeichnis, in dem die zu bearbeitenden Bilder liegen, ausgeführt:

exiftool -all= *.jpg

Dieser sorgt dafür, dass die Dateiendungen der Originalbilder in .jpg_original geändert und die Metadaten aus den eigentlichen Bilddateien entfernt werden.

Beim anschließenden Upload in WordPress wurden die Bildbezeichnungen wie gewünscht angezeigt – also die neuen Dateinamen mit passender Nummerierung.

Der Beitrag Metadaten aus Fotos entfernen erschien zuerst auf intux.de.

Trotzdem habe ich nicht gezögert, das neue System mithilfe des Raspberry Pi Imager auf eine microSD-Karte zu schreiben. Ziel war es wie gewohnt, eine sogenannte headless-Installation vorzubereiten – also ohne Monitor und Tastatur. Die weitere Einrichtung sollte anschließend bequem per SSH (Secure Shell) erfolgen.

Der Vorgang wurde auf einem Notebook mit Ubuntu 24.04 LTS und dem über die Paketverwaltung installierten Raspberry Pi Imager (Version 1.8.5) durchgeführt. Nach dem Flashen wurden die Karte in den Raspberry Pi eingesetzt und das System gestartet. Doch eine Verbindung per SSH war danach nicht möglich.

Ursache und Lösung

Die Ursache für dieses Verhalten war schnell gefunden: Raspberry Pi OS 13 erfordert für die korrekte Vorkonfiguration den Raspberry Pi Imager in Version 2.0 oder höher. Und genau hier beginnt das Problem – zumindest für Linux-Nutzer.

Während Windows-Nutzer den neuen Imager bereits komfortabel nutzen können, hinkt die Linux-Unterstützung deutlich hinterher. Bislang steht weder ein aktuelles .deb-Paket noch eine Snap-Version zur Verfügung. Das sorgt in der Linux-Community verständlicherweise für Kopfschütteln – gerade bei einem Projekt wie dem Raspberry Pi, das tief in der Open-Source-Welt verwurzelt ist.

AppImage als Ausweg

Glücklicherweise bietet der Entwickler ein AppImage des neuen Imagers an. Dieses lässt sich unter Ubuntu und anderen Distributionen unkompliziert starten – ganz ohne Installation. Damit ist es wie gewohnt möglich, WLAN-Zugangsdaten und SSH vor dem ersten Start zu konfigurieren.

Fazit

Wer Raspberry Pi OS 13 „Trixie“ headless nutzen möchte, sollte sicherstellen, dass der Imager in Version 2.0 oder neuer verwendet wird. Für Linux-Nutzer führt der Weg aktuell nur über das bereitgestellte AppImage. Es bleibt zu hoffen, dass die offizielle Paketunterstützung für Linux bald nachgereicht wird.

Der Beitrag Trixie ohne SSH erschien zuerst auf intux.de.

Der Beitrag Frohes Fest! erschien zuerst auf intux.de.

Ein Buchtitel, der bereits im Namen zwei gegensätzliche Extreme vereint: Hacking und Security. Dieser Lesestoff richtet sich nicht an ein breites Publikum, wohl aber an all jene, die Wert auf digitale Sicherheit legen – sei es im Internet, auf Servern, PCs, Notebooks oder mobilen Endgeräten. Gleichzeitig kann dieses umfassende Nachschlagewerk auch als Einstieg in eine Karriere im Bereich Ethical Hacking dienen.

Das Buch ist in drei inhaltlich spannende und klar strukturierte Teile gegliedert.

TEIL I – Einführung und Tools erläutert, warum es unerlässlich ist, sich sowohl mit Hacking als auch mit Security auseinanderzusetzen. Nur wer versteht, wie Angreifer vorgehen, kann seine Systeme gezielt absichern und Sicherheitsmaßnahmen umsetzen, die potenzielle Angriffe wirksam abwehren.

Behandelt werden unter anderem praxisnahe Übungsmöglichkeiten sowie Penetrationstests auf speziell dafür eingerichteten Testsystemen. Ziel ist es, typische Angriffsabläufe nachzuvollziehen und daraus wirksame Schutzkonzepte abzuleiten. Einen zentralen Stellenwert nimmt dabei das speziell für Sicherheitsanalysen entwickelte Betriebssystem Kali Linux ein, das in diesem Zusammenhang ausführlich vorgestellt wird.

TEIL II – Hacking und Absicherung widmet sich intensiv den beiden zentralen Themenbereichen Hacking und Security. Es werden unterschiedliche Angriffsszenarien analysiert und typische Schwachstellen aufgezeigt. Besonders hervorgehoben wird dabei die Bedeutung der Festplattenverschlüsselung, um den unbefugten Zugriff auf sensible Daten zu verhindern.

Auch der Einsatz starker Passwörter in Kombination mit Zwei-Faktor-Authentifizierung (2FA) gehört heute zum Sicherheitsstandard. Dennoch lauern Gefahren im Alltag: Wird ein Rechner unbeaufsichtigt gelassen oder eine Sitzung nicht ordnungsgemäß beendet, kann etwa ein präparierter USB-Stick mit Schadsoftware gravierende Schäden verursachen.

Server-Betreiber stehen zudem unter permanentem Druck durch neue Bedrohungen aus dem Internet. Das Buch bietet praxisnahe Anleitungen zur Härtung von Windows- und Linux-Servern – beispielsweise durch den Einsatz von Tools wie Fail2Ban, das automatisiert Brute-Force-Angriffe erkennt und unterbindet.

Ein weiteres Kernthema ist die Verschlüsselung von Webverbindungen. Moderne Browser weisen inzwischen deutlich auf unsichere HTTP-Verbindungen hin. Die Übertragung sensibler Daten ohne HTTPS birgt erhebliche Risiken – etwa durch Man-in-the-Middle-Angriffe, bei denen Informationen abgefangen oder manipuliert werden können.

Abgerundet wird das Kapitel durch eine ausführliche Betrachtung von Angriffsmöglichkeiten auf weit verbreitete Content-Management-Systeme (CMS) wie WordPress, inklusive praxisnaher Hinweise zur Absicherung.

TEIL III – Cloud, Smartphones, IoT widmet sich der Sicherheit von Cloud-Systemen, mobilen Endgeräten und dem Internet of Things (IoT). Unter dem Leitsatz „Die Cloud ist der Computer eines anderen“ wird aufgezeigt, wie stark Nutzerinnen und Nutzer bei der Verwendung externer Dienste tatsächlich abhängig sind. Besonders bei Cloud-Angeboten amerikanischer Anbieter werden bestehende geopolitische Risiken oft unterschätzt – obwohl sie spätestens seit den Enthüllungen von Edward Snowden nicht mehr zu ignorieren sind.

Selbst wenn Rechenzentren innerhalb Europas genutzt werden, ist das kein Garant für Datenschutz. Der Zugriff durch Dritte – etwa durch Geheimdienste – bleibt unter bestimmten Umständen möglich. Als datenschutzfreundliche Alternative wird in diesem Kapitel Nextcloud vorgestellt: ein in Deutschland entwickeltes Cloud-System, das sich auf eigenen Servern betreiben lässt. Hinweise zur Installation und Konfiguration unterstützen den Einstieg in die selbstbestimmte Datenverwaltung.

Wer sich für mehr digitale Souveränität entscheidet, übernimmt zugleich Verantwortung – ein Aspekt, dem im Buch besondere Aufmerksamkeit gewidmet wird. Ergänzend werden praxisnahe Empfehlungen zur Absicherung durch Zwei- oder Multi-Faktor-Authentifizierung (2FA/MFA) gegeben.

Ein weiteres Thema sind Sicherheitsrisiken bei mobilen Geräten und IoT-Anwendungen. Besonders kritisch: schlecht gewartete IoT-Server, die oft im Ausland betrieben werden und ein hohes Angriffspotenzial aufweisen. Auch hier werden konkrete Gefahren und Schutzmaßnahmen anschaulich dargestellt.

Das Buch umfasst insgesamt 24 Kapitel.

• Einführung
• Kali Linux
• Hacking-Tools
• Hacking lernen
• Bug-Bounty-Programme
• Offline Hacking
• Passwörter
• IT-Forensik
• WLAN, Bluetooth und SDR
• Angriffsvektor USB-Schnittstelle
• Externe Sicherheitsüberprüfungen
• Penetration-Testing
• Windows Server absichern
• Active Directory
• Linux absichern
• Sicherheit bei Samba-Fileservern
• Sicherheit von Webanwendungen
• Intrusion-Detection-Systeme
• Software-Exploitation
• Sichere KI-Anwendungen
• Sicherheit in der Cloud
• Microsoft 365 sicher betreiben
• Mobile Security
• IoT-Sicherheit

Leseprobe

• Leseprobe

Fazit

Das Buch bietet einen fundierten und praxisnahen Einstieg in die Welt von IT-Sicherheit und Hacking. Es richtet sich gleichermaßen an interessierte Einsteiger als auch an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen möchten. Besonders gelungen ist die Verbindung technischer Grundlagen mit konkreten Anwendungsszenarien – vom Einsatz sicherer Tools über das Absichern von Servern bis hin zur datenschutzfreundlichen Cloud-Lösung.

Wer sich ernsthaft mit Sicherheitsaspekten in der digitalen Welt auseinandersetzen möchte, findet in diesem Werk einen gut strukturierten Leitfaden, der nicht nur Wissen vermittelt, sondern auch zum eigenständigen Handeln motiviert. Ein empfehlenswertes Nachschlagewerk für alle, die digitale Souveränität nicht dem Zufall überlassen wollen.

Der Beitrag Hacking & Security: Das umfassende Handbuch erschien zuerst auf intux.de.

KVM steht für Kernel-based Virtual Machine und ist eine Virtualisierungstechnologie für Linux auf x86-Hardware.

Temporäre Lösung

Abhängig vom verwendeten Prozessor kann das jeweilige KVM-Modul aus dem laufenden Kernel mit folgendem Befehl entfernt werden:

sudo modprobe -r kvm_intel

bei AMD-Systemen:

sudo modprobe -r kvm_amd

Diese Methode ist jedoch nicht dauerhaft, da das Modul nach einem Neustart wieder geladen wird.

Bei der Recherche zu diesem Thema bin ich auf zwei Lösungsansätze gestoßen, die das Problem dauerhaft beheben sollten. Zum einen geht es um das Hinzufügen einer Boot-Option in GRUB, zum anderen um die Erstellung einer Blacklist der entsprechenden KVM-Module für VirtualBox.

1. Ansatz – Eingriff in den Bootloader (GRUB)

In der Datei /etc/default/grub wird der Eintrag

GRUB_CMDLINE_LINUX=

um folgenden Parameter (siehe Screenshot) ergänzt:

"kvm.enable_virt_at_load=0"

Anschließend muss die GRUB-Konfiguration aktualisiert werden:

sudo update-grub

Wichtiger Hinweis:
Ein fehlerhafter Eintrag in der GRUB-Konfiguration kann dazu führen, dass das System nicht mehr startet. Unerfahrene Nutzer könnten in eine schwierige Situation geraten. Daher ist ein vollständiges System-Backup vor dem Eingriff unbedingt empfehlenswert.

2. Ansatz – Blacklisting des KVM-Moduls

Ein sichererer und eleganterer Weg ist das Blacklisting des Moduls. Dazu wird eine neue Konfigurationsdatei angelegt:

sudo nano /etc/modprobe.d/blacklist-kvm.conf

Dort fügt man folgende Zeilen hinzu:

blacklist kvm
blacklist kvm_intel

Nach einem Neustart des Systems wird das jeweilige KVM-Modul nicht mehr geladen und VirtualBox sollte wie gewohnt funktionieren.

Fazit

Die zweite Methode ist risikoärmer und benutzerfreundlicher. Dennoch empfiehlt es sich, vor jeder Änderung am System ein Backup anzulegen.

Viel Erfolg beim Virtualisieren!

Der Beitrag KVM-Konflikte mit VirtualBox unter Ubuntu 24.04 dauerhaft lösen erschien zuerst auf intux.de.

Solche Aufgaben können notwendig werden, wenn die Dateien aus unterschiedlichen Quellen stammen – so wie im folgenden Beispiel: Ich hatte vier verschiedene Zuarbeiten mit jeweils eigenen Benennungsregeln erhalten. Um die insgesamt 95 Dateien einheitlich in eine bestehende Webseite einzubinden, mussten sie alle nach einem gemeinsamen Schema umbenannt werden.

Umsetzung

Auf einem Ubuntu-System erfolgt die Mehrfachumbenennung ganz einfach: Zunächst wird das Verzeichnis geöffnet, in dem sich alle zu verarbeitenden Bilder befinden.

Im Dateimanager „Dateien“ (früher „Nautilus“) werden mit Strg + A alle Dateien markiert.

Mit einem Rechtsklick lässt sich nun die Option „Umbenennen“ auswählen. Hier wird „[Ursprünglicher Dateiname]“ durch den endgültigen Dateinamen ersetzt und über „+ Hinzufügen“ der neue Suffix ausgewählt.

In diesem Fall habe ich mich für „001, 002, 003, 004“ entschieden.

Der Vorgang wird durch Klicken auf „Umbenennen“ abgeschlossen.

Fazit

Die Mehrfachumbenennung unter GNOME ist ein einfaches, aber äußerst praktisches Werkzeug – besonders in Kombination mit einer automatischen Skalierung, wie im zuvor genannten Artikel beschrieben. So lässt sich die Verarbeitung großer Bildmengen deutlich effizienter gestalten und viel Zeit sparen.

Der Beitrag Mehrfachumbenennung von Dateien erschien zuerst auf intux.de.