Canonical hat die neue Version Ubuntu 25.10 mit dem Codenamen „Questing Quokka“ veröffentlicht. Die Ausgabe ist eine Kurzzeitversion mit neun Monaten Support und erhält Updates bis Juli 2026. Sie richtet sich vor allem an Nutzer, die gerne auf dem neuesten Stand bleiben und aktuelle Technologien im Ubuntu Kosmos testen möchten. Die Distribution basiert auf dem […]
Der Suse Multi-Linux Manager 5.1, ehemals als Suse Manager bekannt, soll das Linux-Management über komplexe, heterogene IT-Landschaften hinweg vereinfachen, sichern und skalieren.
Der Proxmox Backup Server unterstützt ab Version 4, welche sich aktuell in der Beta-Phase befindet, als Technologievorschau das Einbinden von S3-kompatiblen Objektspeichern als Backupspeicher. Hetzner bietet günstig (ab 5,94 EUR/Monat für 1 TB) S3-kompatiblen...
Der Vorschlag, XLibre, den Fork für die X.Org X-Server-Implementierung von X11 in Fedora 43 aufzunehmen, wurde wegen fehlender Zustimmung der Community zurückgezogen.
Fedora nimmt oft die Pole-Position bei der Einführung neuer und der Entfernung alter Technologien ein. Das führt derzeit wieder zu kontroversen Diskussionen.
Wenn es um den Raspberry Pi und DynDNS geht, empfehle ich gerne, wie im Artikel „Nextcloud auf dem RasPi – Teil 4“ beschrieben, als DynDNS-Anbieter den Dienst dnsHome.de. Privatanwender kommen hier in den Genuss, eine kostenlose DynDNS für kleinere Projekte nutzen zu können. Dieser Dienst arbeitet einwandfrei und sorgt dafür, dass u. a. eigene Cloud-Server nach der Zwangstrennung des Internetanbieters stets erreichbar bleiben. Durch den ständigen Abruf der öffentlichen IP und der Übermittlung bei Änderung dieser an den DynDNS-Anbieter wird sichergestellt, dass der Server über eine Subdomain immer erreichbar bleibt.
Darstellung DynDNS. Quelle: Wikipedia
Nun kam es aber bei einer von mir aufgesetzten Installation in einem Telekom-Netz vor, dass die von dnsHome empfohlene Konfiguration
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
protocol=dyndns2
ssl=yes # Erst ab ddclient Version 3.7 möglich, bitte prüfen
daemon=3600
use=web, web=ip.dnshome.de
server=www.dnshome.de
login=SUBDOMAIN.DOMAIN.TLD
password=PASSWORT
SUBDOMAIN.DOMAIN.TLD
des ddclients nicht funktionierte. Wo lag das Problem? Der Eintrag
web=ip.dnshome.de
ermittelt in diesem Netz nicht wie gewünscht die IPv4-, sondern die IPv6-Adresse und leitet diese an dnsHome weiter. Somit wurde die Verbindung der Subdomain zum Server gestört. Natürlich gibt es auch hierfür eine einfache Lösung. Durch den Austausch des zuvor erwähnten Eintrags durch
Mit einer Woche Abstand zur RHEL-10-Veröffentlichung bringt AlmaLinux OS 10 frischen Wind in die Enterprise-Linux-Welt. Die neue Version mit dem Spitznamen „Purple Lion“ setzt auf Kernel 6.12 und verspricht vollständige Kompatibilität mit Red Hat Enterprise Linux. Ein Highlight: Frame Pointers sind nun standardmäßig aktiviert. Das erlaubt bessere Systemanalyse in Echtzeit. Auch ältere Hardware profitiert, denn […]
Canonical hat die Entwicklungsphase für Ubuntu 25.10 eingeläutet. Unter dem Codenamen Questing Quokka nimmt die nächste reguläre Ubuntu-Version Gestalt an. Als letzte Ausgabe vor dem kommenden LTS-Release (Ubuntu 26.04) bekommt sie eine besondere Rolle im Entwicklungszyklus. Und so sie bringt einige wegweisende Neuerungen mit. Im Mittelpunkt steht der Sprung auf GNOME 49, das eine rundum […]
Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).
Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:
mit SSH-Schlüssel (ohne 2FA)
mit Passwort und One-time Password (also mit 2FA)
Links die App »Google Authenticator«, rechts »Authy«
Grundlagen: sshd-Konfiguration
Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:
Verwechseln Sie sshd_config nicht mit ssh_config (ohne d) für die Konfiguration des SSH-Clients, also für die Programme ssh und scp! opensshserver.config legt fest, welche Verschlüsselungsalgorithmen erlaubt sind.
Beachten Sie, dass bei Optionen, die in den sshd-Konfigurationsdateien mehrfach eingestellt sind, der erste Eintrag gilt (nicht der letzte)! Das gilt auch für Einstellungen, die am Beginn von sshd_config mit Include aus dem Unterverzeichnis /etc/ssh/sshd_config.d/ gelesen werden und die somit Vorrang gegenüber sshd_config haben.
Werfen Sie bei Konfigurationsproblemen unbedingt auch einen Blick in das oft übersehene sshd_config.d-Verzeichnis und vermeiden Sie Mehrfacheinträge für ein Schlüsselwort!
Weil die Dateien aus /etc/ssh/sshd_config.d/ Vorrang gegenüber sshd_config haben, besteht eine Konfigurationsstrategie darin, sshd_config gar nicht anzurühren und stattdessen alle eigenen Einstellungen in einer eigenen Datei (z.B. sshd_config.d/00-myown.conf) zu speichern. 00 am Beginn des Dateinamens stellt sicher, dass die Datei vor allen anderen Konfigurationsdateien gelesen wird.
Überprüfen Sie bei Konfigurationsproblemen mit sshd -T, ob die Konfiguration Fehler enthält. Wenn es keine Konflikte gibt, liefert sshd -T eine Auflistung aller aktuell gültigen Einstellungen. Die Optionen werden dabei in Kleinbuchstaben angezeigt. Mit grep -i können Sie die für Sie relevante Einstellung suchen:
sshd -T | grep -i permitro
permitrootlogin yes
Änderungen an sshd_config werden erst wirksam, wenn der SSH-Server die Konfiguration neu einliest. Dazu führen Sie das folgende Kommando aus:
Google Authenticator bezeichnet zwei unterschiedliche Programme: einerseits die App, die sowohl für iOS als auch für Android verfügbar ist, andererseits ein Linux-Kommando, um die 2FA auf einem Linux-Server einzurichten. Während der Code für die Smartphone-Apps nicht öffentlich ist, handelt es sich bei dem Linux-Kommando um Open-Source-Code. Das resultierende Paket steht für RHEL-Distributionen in der EPEL-Paketquelle zur Verfügung, bei Ubuntu in universe.
Nach der Installation führen Sie für den Account, als der Sie sich später via SSH anmelden möchten (also nicht für root), das Programm google-authenticator aus. Nachdem Sie den im Terminal angezeigten QR-Code gescannt haben, sollten Sie zur Kontrolle sofort das erste OTP eingeben. Sämtliche Rückfragen können Sie mit y beantworten. Die Rückfragen entfallen, wenn Sie das Kommando mit den Optionen -t -d -f -r 3 -R 30 -W ausführen. Das Programm richtet die Datei .google-authenticator im Heimatverzeichnis ein.
user$ google-authenticator
Do you want authentication tokens to be time-based (y/n)
Enter code from app (-1 to skip): nnnnnn
Do you want me to update your .google_authenticator file? (y/n)
Do you want to disallow multiple uses of the same
authentication token? (y/n)
...
Zum Einrichten wird das Kommando »google-authenticator« im Terminal ausgeführt. Den QR-Code scannen Sie dann mit der OTP-App Ihrer Wahl ein. (Keine Angst, der hier sichtbare QR-Code stammt nicht von einem öffentlich zugänglichen Server. Er wurde vielmehr testweise in einer virtuellen Maschine erzeugt.)
SSH-Server-Konfiguration
Das nächste Listing zeigt die erforderlichen sshd-Einstellungen. Mit der Methode keyboard-interactive wird PAM für die Authentifizierung verwendet, wobei auch eine mehrstufige Kommunikation erlaubt ist. Die ebenfalls erforderliche Einstellung UsePAM yes gilt bei den meisten Linux-Distributionen standardmäßig. Am besten speichern Sie die folgenden Zeilen in der neuen Datei /etc/ssh/sshd_config.d/00-2fa.conf. Diese wird am Beginn der sshd-Konfiguration gelesen und hat damit Vorrang gegenüber anderen Einstellungen.
# Datei /etc/ssh/sshd_config.d/00-2fa.conf
UsePAM yes
PasswordAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
# Authentifizierung wahlweise nur per SSH-Key oder
# mit Passwort + OTP
AuthenticationMethods publickey keyboard-interactive
PAM-Konfiguration
Der zweite Teil der Konfiguration erfolgt in /etc/pam.d/sshd. Am Ende dieser Datei fügen Sie eine Zeile hinzu, die zusätzlich zu allen anderen Regeln, also zusätzlich zur korrekten Angabe des Account-Passworts, die erfolgreiche Authentifizierung durch das Google-Authenticator-Modul verlangt:
# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode zwingend erforderlich
auth required pam_google_authenticator.so
Alternativ ist auch die folgende Einstellung mit dem zusätzlichen Schlüsselwort nullok denkbar. Damit akzeptieren Sie einen Login ohne 2FA für Accounts, bei denen Google Authenticator noch nicht eingerichtet wurde. Sicherheitstechnisch ist das natürlich nicht optimal — aber es vereinfacht das Einrichten neuer Accounts ganz wesentlich.
# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode nur erforderlich, wenn
# Google Authenticator für den Account eingerichtet wurde
auth required pam_google_authenticator.so nullok
Wenn Sie RHEL oder einen Klon verwenden, sieht die PAM-Konfiguration ein wenig anders aus. SELinux verbietet dem SSH-Server Zugriff auf Dateien außerhalb des .ssh-Verzeichnisses. Deswegen müssen Sie die Datei .google-authenticator vom Home-Verzeichnis in das Unterverzeichnis .ssh verschieben. restorecon stellt sicher, dass der SELinux-Kontext für alle Dateien im .ssh-Verzeichnis korrekt ist.
user$ mv .google-authenticator .ssh/ (nur unter RHEL!)
user$ restorecon .ssh
In der Zeile auth required übergeben Sie nun als zusätzliche Option den geänderten Ort von .google-authenticator. Falls Sie die nullok-Option verwenden möchten, fügen Sie dieses Schlüsselwort ganz am Ende hinzu.
# am Ende von /etc/pam.d/sshd (RHEL & Co.)
...
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator
Test und Fehlersuche
Passen Sie auf, dass Sie sich nicht aus Ihrem Server aussperren! Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server!
Vergessen Sie nicht, die durchgeführten Änderungen zu aktivieren. Vor ersten Tests ist es zweckmäßig, eine SSH-Verbindung offen zu lassen, damit Sie bei Problemen die Einstellungen korrigieren können.
Bei meinen Tests hat sich die Google-Authenticator-Konfiguration speziell unter RHEL als ziemlich zickig erwiesen. Beim Debugging können Sie client-seitig mit ssh -v, server-seitig mit journalctl -u sshd nach Fehlermeldungen suchen.
Die Anwendung von Google Authenticator setzt voraus, dass die Uhrzeit auf dem Server korrekt eingestellt ist. Die One-Time-Passwords gelten nur in einem 90-Sekunden-Fenster! Das sollten Sie insbesondere bei Tests in virtuellen Maschinen beachten, wo diese Bedingung mitunter nicht erfüllt ist (z.B. wenn die virtuelle Maschine pausiert wurde). Stellen Sie die Zeit anschließend neu ein, oder starten Sie die virtuelle Maschine neu!
Was ist, wenn das Smartphone verlorengeht?
Für den Fall, dass das Smartphone und damit die zweite Authentifizierungsquelle verlorengeht, zeigt das Kommando google-authenticator bei der Ausführung fünf Ziffernfolgen an, die Sie einmalig für einen Login verwendet können. Diese Codes müssen Sie notieren und an einem sicheren Ort aufbewahren — dann gibt es im Notfall einen »Plan B«. (Die Codes sind auch in der Datei .google_authenticator enthalten. Auf diese Datei können Sie aber natürlich nicht mehr zugreifen, wenn Sie keine Login-Möglichkeit mehr haben.)
Die App Google Authenticator synchronisiert die 2FA-Konfiguration automatisch mit Ihrem Google-Konto. Die 2FA-Konfiguration kann daher auf einem neuen Smartphone rasch wieder hergestellt werden. Schon eher bereitet Sorge, dass nur die Kenntnis der Google-Kontodaten ausreichen, um Zugang zur 2FA-Konfiguration zu erhalten. Die Cloud-Synchronisation kann in den Einstellungen gestoppt werden.
Auch Authy kann die 2FA-Konfiguration auf einem Server der Firma Twilio speichern und mit einem weiteren Gerät synchronisieren. Anders als bei Google werden Ihre 2FA-Daten immerhin mit einem von Ihnen zu wählenden Passwort verschlüsselt. Mangels Quellcode lässt sich aber nicht kontrollieren, wie sicher das Verfahren ist und ob es den Authy-Betreibern Zugriff auf Ihre Daten gewährt oder nicht. 2024 gab es eine Sicherheitspanne bei Twilio, bei der zwar anscheinend keine 2FA-Daten kompromittiert wurden, wohl aber die Telefonnummern von 35 Millionen Authy-Benutzern.
Sicherheits- und Privacy-Bedenken
Authenticator-Apps funktionieren prinzipiell rein lokal. Weder der beim Einrichten erforderliche Schlüssel bzw. QR-Code noch die ständig generierten Einmalcodes müssen auf einen Server übertragen werden. Die Apps implementieren den öffentlich standardisierten HMAC-based One-Time Password Algorithmus (OATH-HOTP).
Allerdings bieten einige OTP-Apps die Möglichkeit, die Account-Einträge über ein Cloud-Service zu sichern (siehe oben). Diese Cloud-Speicherung ist eine mögliche Sicherheitsschwachstelle.
Davon losgelöst gilt wie bei jeder App: Sie müssen der Firma vertrauen, die die App entwickelt hat. Der Code der App Google Authenticator war ursprünglich als Open-Source verfügbar, seit 2020 ist das leider nicht mehr der Fall. Wenn Sie weder Google Authenticator noch Authy vertrauen, finden Sie im Arch Linux Wiki Links zu Apps, deren Code frei verfügbar ist.
Ubuntu Fans und Entwickler können sich freuen, denn die ersten täglichen Testversionen von Ubuntu 25.10 stehen ab sofort zum Download bereit. Die finale Version des kommenden Releases soll planmäßig am 7. Oktober 2025 erscheinen. Änderungen am Termin sind jedoch noch möglich. Der Entwicklungsstart begann Anfang Mai, nun gibt es erste ISO-Images. Diese sogenannten Daily Builds […]
Netcraft kann in seinen Messungen zur Verteilung von Webservern weltweit im Monat April Nginx den größten Zuwachs von 8,0 Millionen Websites zusprechen.
Am 31. Mai 2025 endet der reguläre Support für Ubuntu 20.04 LTS. Unternehmen, die weiterhin auf diese Version setzen, sollten dringend handeln. Mit Expanded Security Maintenance (ESM) erhalten Ubuntu Instnazen auch nach dem offiziellen Ende wichtige Sicherheitsupdates. So bleiben Server und Anwendungen zuverlässig geschützt. Doch reine Sicherheitsupdates decken nicht alle Risiken ab. Wenn ein Paket […]
Die neue Version des Proxmox Backup Servers bietet eine flottere Garbage Collection, einen teilweise höheren Datendurchsatz bei der Bandsicherung, einen statisch gelinkten Client und weitere…
Die neue Version des Proxmox Backup Servers bietet eine flottere Garbage Collection, einen teilweise höheren Datendurchsatz bei der Bandsicherung, einen statisch gelinkten Client und weitere…
Unraid hat im letzten Jahr nicht nur die Preise angezogen, sondern liefert seitdem auch Updates mit vielen wichtigen Neuerungen aus. Dieses Mal ist der Import fremder ZFS-Pools mit dabei.
Heute möchte ich über ein Thema schreiben, das sicher den einen oder anderen Leser meines Blogs beschäftigt. Es geht um die Frage, wie man auf einer auf einem Raspberry Pi installierten Nextcloud ein RAID-System aufbaut, um Daten redundant auf dem Massenspeicher abzulegen.
Als Vorlage diente mir hierbei eine Anleitung von Daniel von der Firma apfelcast, die ich in Teilen etwas abgeändert habe.
Installation
Zuerst wird die Software mdadm auf dem Raspberry Pi installiert.
sudo apt-get install mdadm
Um diese zu aktivieren, muss der Raspberry Pi nach der Installation von mdadm neu gestartet werden.
sudo reboot
Danach schaut man nach den angeschlossenen Datenträgern. Ich setze voraus, dass man sich zuvor ausreichend mit dieser Materie auseinandergesetzt hat. Ein RAID-Level 1 erfüllt in unserem Fall alle Voraussetzungen für dieses Unterfangen.
Wenn zwei baugleiche SSDs mit identischer Speicherkapazität (z. B. 1 TB) angeschlossen sind, können diese mit folgendem Befehl identifiziert werden:
sudo lsblk
Beide Laufwerke werden als /dev/sda und /dev/sdb ausgegeben.
RAID-System
Raid-System
Nun werden alle Daten und Partitionen der SSDs gelöscht. Hierzu werden beide Befehle nacheinander ausgeführt:
sudo parted /dev/sda "rm 1"
sudo parted /dev/sdb "rm 1"
Ein abschließender Check gibt Gewissheit.
sudo lsblk
Bei Festplatten < 2 TB werden nun die MSDOS-Partitionstabellen erstellt.
sudo parted /dev/sda "mklabel msdos"
sudo parted /dev/sdb "mklabel msdos"
Bei Festplatten > 2 TB verwendet man hingegen folgende Befehle für GPT-Partitionstabellen.
sudo parted /dev/sda "mklabel gpt"
sudo parted /dev/sdb "mklabel gpt"
Anschließend werden die ext4-Partitionen auf beiden Datenträgern erstellt.
sudo parted /dev/sda "mkpart primary ext4 1M -1"
sudo parted /dev/sdb "mkpart primary ext4 1M -1"
Nun wird RAID auf beiden Partitionen aktiviert.
sudo parted /dev/sda "set 1 raid on"
sudo parted /dev/sdb "set 1 raid on"
Anschließend kann der Status überprüft werden (siehe Screenshot).
sudo parted -s /dev/sda print
sudo parted -s /dev/sdb print
Check des Status nach Aktivierung der einzelnen Raid-Partitionen
Jetzt wird ein RAID-Level 1 erstellt, sodass beide Laufwerke zu einem zusammengeführt und so die Daten redundant gespeichert werden können. Falls eine SSD ausfällt, sollten somit keine Daten verloren gehen.
Mit diesem Artikel möchte ich meine Nextcloud-Serie schließen. Um die installierte Cloud nun noch mit einer Videokonferenz-Funktion zu erweitern, möchte ich heute zeigen, wie man einen TURN-Server auf das bestehende System aufsetzt. Dies hatte ich im Mai diesen Jahres im Artikel „Coturn TURN-Server für Nextcloud Talk“ zwar schon erklärt, aber es gehört aus meiner Sicht einfach in diese Artikelserie hinein.
Installation
Ein TURN-Server wird von Nextcloud Talk benötigt, um Videokonferenzen zu ermöglichen. Der TURN-Server bringt die Teilnehmer, welche sich in verschiedenen Netzwerken befinden, zusammen. Nur so ist eine reibungslose Verbindung unter den Gesprächspartnern in Nextcloud Talk möglich.
Wer bisher meinen Anleitungen zur Installation von Nextcloud auf dem Raspberry Pi gefolgt ist, kann nun die eigene Cloud für Videokonferenzen fit machen. Zu bedenken gilt aber, dass ein eigener TURN-Server nur bis maximal 6 Teilnehmer Sinn macht. Wer Konferenzen mit mehr Teilnehmern plant, muss zusätzlich einen Signaling-Server integrieren.
Nun zur Installation des TURN-Servers. Zuerst installiert man den Server mit
sudo apt install coturn
und kommentiert folgende Zeile, wie nachfolgend zu sehen in /etc/default/coturn aus.
sudo nano /etc/default/coturn
Dabei wird der Server im System aktiviert.
#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1
Nun legt man die Konfigurationsdatei zum TURN-Server mit folgendem Inhalt an.
Hier werden u.a. der Port und das Passwort des Servers sowie die Domain der Cloud eingetragen. Natürlich muss hier noch der Port im Router freigegeben werden. Ein starkes Passwort wird nach belieben vergeben.
Hierbei kann das Terminal hilfreich sein. Der folgende Befehl generiert z.B. ein Passwort mit 24 Zeichen.
gpg --gen-random --armor 1 24
Jetzt wird der Server in den Verwaltungseinstellungen als STUN- und TURN-Server inkl. Listening-Port sowie Passwort eingetragen.
Nextcloud – Verwaltungseinstellungen – TalkEintrag der Domain für STUN- und TURN-Server (sowie Passwort)
Damit der TURN-Server nach einem Reboot auch zuverlässig startet, müssen ein paar Einstellungen am Service vorgenommen werden. Mit
sudo systemctl edit coturn.service
wird der Service des Servers editiert. Folgender Eintrag wird zwischen die Kommentare gesetzt:
### Editing /etc/systemd/system/coturn.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file
[Service]
ExecStartPre=/bin/sleep 30
### Lines below this comment will be discarded
### /lib/systemd/system/coturn.service
Dies ermöglicht den TURN-Server (auch nach einem Upgrade) mit einer Verzögerung von 30 Sekunden zu starten.
Zum Schluss wird der Service neu gestartet.
sudo service coturn restart
Ein Check zeigt, ob der TURN-Server funktioniert. Hierzu klickt man auf das Symbol neben dem Papierkorb in der Rubrik TURN-Server der Nextcloud. Wenn alles perfekt läuft ist, wird im Screenshot, ein grünes Häkchen sichtbar.
Check TURN-ServerCheck bestanden
Damit endet die Artikelserie Nextcloud auf dem RasPi. Viel Spaß beim Nachbauen!
Anmelden
Canonical hat die neue Version Ubuntu 25.10 mit dem Codenamen „Questing Quokka“ veröffentlicht. Die Ausgabe ist eine Kurzzeitversion mit neun Monaten Support und erhält Updates bis Juli 2026. Sie richtet sich vor allem an Nutzer, die gerne auf dem neuesten Stand bleiben und aktuelle Technologien im Ubuntu Kosmos testen möchten. Die Distribution basiert auf dem […]
Mit einer Woche Abstand zur RHEL-10-Veröffentlichung bringt AlmaLinux OS 10 frischen Wind in die Enterprise-Linux-Welt. Die neue Version mit dem Spitznamen „Purple Lion“ setzt auf Kernel 6.12 und verspricht vollständige Kompatibilität mit Red Hat Enterprise Linux. Ein Highlight: Frame Pointers sind nun standardmäßig aktiviert. Das erlaubt bessere Systemanalyse in Echtzeit. Auch ältere Hardware profitiert, denn […]
