Maschinenraum-Log 2025-07-09
Die heißen Tage sind vorbei, um so heißer ging es im Maschinenraum zu. Diesmal auch organisatorisches enthalten.
Die heißen Tage sind vorbei, um so heißer ging es im Maschinenraum zu. Diesmal auch organisatorisches enthalten.
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.
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
web=ip4.dnshome.de
wird das Problem behoben.
Der Beitrag dnsHome bevorzugt IPv6 erschien zuerst auf intux.de.
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 […]
Der Beitrag AlmaLinux 10 „Purple Lion“ veröffentlicht: Stabil, sicher und zukunftsbereit erschien zuerst auf fosstopia.
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 Beitrag Ubuntu 25.10 „Questing Quokka“: GNOME 49, Microsoft-Integration und mehr erschien zuerst auf fosstopia.
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:
Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:
/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/*.conf
/etc/crypto-policies/back-ends/opensshserver.config (nur RHEL)
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:
systemctl reload sshd # RHEL
systemctl reload ssh # Debian, Ubuntu
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.
dnf install google-authenticator qrencode # RHEL + EPEL
apt install libpam-google-authenticator # Debian, Ubuntu
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)
...
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
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
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.
sshd -T # Syntaxtest
systemctl reload sshd # RHEL
systemctl reload ssh # Debian + Ubuntu
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!
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.
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 […]
Der Beitrag Ubuntu 25.10 (Questing Quokka): Erste Testversionen verfügbar erschien zuerst auf fosstopia.
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 […]
Der Beitrag Ubuntu 20.04 LTS: Support endet bald – jetzt besteht Handlungsbedarf erschien zuerst auf fosstopia.
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…
Die Application-Plattform NethServer macht einen kleinen Versionssprung.
Die Application-Plattform NethServer macht einen kleinen Versionssprung.
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.
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.
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
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.
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
Alternativ könnte ein RAID 0 eingerichtet werden, um beide SSDs hintereinander zu verknüpfen. Dabei würde sich die Speicherkapazität verdoppeln.
Eine letzte Überprüfung zeigt nun den aktuellen Zustand.
lsblk
Nun kann das Dateisystem für das RAID eingerichtet werden.
sudo mkfs -t ext4 /dev/md0
Der Fortschritt wird mit den folgenden Befehlen überprüft (siehe Screenshots).
cat /proc/mdstat
sudo mdadm --detail /dev/md0
Das Mountverzeichnis wird erstellt und der Datenspeicher darauf gemountet.
sudo mkdir /media/ssd
sudo mount /dev/md0 /media/ssd
Nun wird die Datei /etc/fstab bearbeitet, damit der Datenträger nach einem Neustart weiterhin mit unserer Nextcloud verbunden bleibt.
sudo nano /etc/fstab/
Dort fügt man folgende Zeile hinzu und speichert die Datei ab:
/dev/md0 /media/raid ext4 4,nofail 0 0
Die Bearbeitung der crontab sorgt dafür, dass das RAID-System beim Neustart korrekt eingebunden wird.
sudo crontab -e
Dort wird folgender Eintrag hinzugefügt:
@reboot sleep 5; sudo mount /dev/md0 /media/raid
Das vorhandene Datenverzeichnis wird von der MicroSD auf das RAID-System verschoben.
sudo mv /var/www/html/nextcloud/data /media/ssd
Anschließend muss der Nextcloud noch mitgeteilt werden, wo sich das Datenverzeichnis befindet. Dazu wird die Konfigurationsdatei geöffnet.
sudo nano /var/www/html/nextcloud/config/config.php
Der folgende Eintrag wird angepasst und von
'datadirectory' => '/var/www/html/nextcloud/data',
in
'datadirectory' => '/media/ssd/data',
geändert.
Damit ist die Einrichtung des RAID-Systems für die Nextcloud auf dem Raspberry Pi abgeschlossen!
Der Beitrag Raspberry Pi Raid erschien zuerst auf intux.de.
In der monatlichen Auswertung der Firma Netcraft zur Verbreitung von Webservern liegt der Nginx-Server im Januar 2025 weiter vorne.
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.
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.
sudo nano /etc/turnserver.conf
listening-port=5349 fingerprint lt-cred-mech use-auth-secret static-auth-secret=geheimespasswort realm=cloud.domain.tld total-quota=100 bps-capacity=0 stale-nonce no-loopback-peers no-multicast-peers
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.
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.
Damit endet die Artikelserie Nextcloud auf dem RasPi. Viel Spaß beim Nachbauen!
Die Proxmox Server Solutions GmbH hat Version 3.3 von Proxmox Backup Server veröffentlicht.
Innerhalb weniger Tage nach der Veröffentlichung von RHEL 9.5 stehen nun auch Rocky Linux 9.5 und AlmaLinux 9.5 als neue stabile Versionen bereit. Beide Distributionen bringen zahlreiche Verbesserungen und neue Funktionen mit, die Entwickler, Administratoren und Unternehmen gleichermaßen ansprechen. Rocky Linux 9.5 „Blue Onyx“ Rocky Linux 9.5 führt zahlreiche Neuerungen ein, darunter: Zudem wurden die […]
Der Beitrag Rocky Linux 9.5 und AlmaLinux 9.5 veröffentlicht: Wichtige Updates für die Linux-Community erschien zuerst auf fosstopia.
Als ich mit der Artikelserie zur Nextcloud auf dem Raspberry Pi begann, war mein Ziel, ein Tutorial zu erstellen, das es ermöglicht, eine Nextcloud auf dem Einplatinencomputer so zu installieren und zu konfigurieren, dass diese produktiv genutzt werden kann. Nextcloud ist mittlerweile mehr als nur eine Cloud. Nextcloud hat sich zu einem professionellen Büroprodukt entwickelt, das ich selbst täglich nutze.
In diesem Artikel zeige ich, wie man den Datenspeicher von der MicroSD auf eine SSD auslagert, um die Speicherkapazität der Nextcloud zu erweitern. Ich verwende dafür eine SanDisk Extreme mit einer Kapazität von 2TB.
Die Leser, die dieser Artikelreihe bisher gefolgt sind und alles auf dem Raspberry Pi nachgebaut haben, sollten die Version 29 installiert haben. Diejenigen, die etwas mutiger waren, haben bereits ein Upgrade auf Version 30 in den Verwaltungseinstellungen durchgeführt.
Bevor wir starten, sollte unbedingt ein Backup des gesamten Systems durchgeführt werden, um Datenverlust zu vermeiden, falls etwas schief geht.
Zuerst wird die externe SSD mit dem Raspberry Pi über den USB 3.0-Anschluss verbunden. Anschließend wird die SSD mithilfe des folgenden Befehls identifiziert.
sudo fdisk -l
Das System zeigt nun an, dass die SSD als /dev/sda1 eingehängt wurde. Durch die Eingabe von
sudo mkfs.ext4 /dev/sda1
kann die SSD in Ext4 formatiert werden. Auf meinem System erschien eine Fehlermeldung, dass die SSD bereits eingehängt ist und daher nicht formatiert werden kann.
Daher muss die SSD zuerst wieder ausgehängt werden.
sudo umount -fl /dev/sda1
Anschließend wird die SSD, gemäß der bereits erwähnten Methode im Artikel, Ext4-formatiert. Die Abfrage wird durch die Eingabe von „y“ bestätigt.
sudo mkfs.ext4 /dev/sda1
Nun wird das Verzeichnis /media/ssd erstellt, in dem später das Datenverzeichnis auf der externen SSD liegen wird.
sudo mkdir /media/ssd
Danach wird das Verzeichnis mit dem Inhalt der SSD gemountet.
sudo mount /dev/sda1 /media/ssd
Damit die SSD auch nach einem Neustart korrekt eingebunden wird, trägt man sie mit der richtigen UUID in die /etc/fstab ein. Die benötigte UUID findet man über den Befehl:
sudo blkid /dev/sda1
Nun kann die fstab mit der entsprechenden Zeile ergänzt werden. Dieser Eintrag erfolgt direkt unter den beiden Hauptpartitionen (siehe Screenshot).
sudo nano /etc/fstab
Die hier von mir angegebene UUID ist natürlich durch die UUID der eigenen Festplatte zu ersetzen.
UUID=4866c0d5-3ab8-4746-8aaf-c772a60444e9 /media/ssd ext4 defaults 0 0
Dabei muss man mit größter Sorgfalt vorgehen, da das System bei einer falschen Eingabe möglicherweise nicht mehr starten wird. Ein vorheriges Backup bietet (wie oben schon erwähnt) Sicherheit. Nachdem alles korrekt eingegeben wurde, kann der Raspberry Pi neu gestartet werden.
sudo reboot
Wenn das System fehlerfrei neu gestartet ist, wird das Datenverzeichnis von der MicroSD-Karte auf die SSD verschoben. Dieser Vorgang kann je nach Größe einige Minuten dauern.
sudo mv /var/www/html/nextcloud/data /media/ssd
Nun muss der Nextcloud noch mitgeteilt werden, wo sich das Datenverzeichnis befindet. Dazu gehen wir in die config.php.
sudo nano /var/www/html/nextcloud/config/config.php
Hier wird nun das Datenverzeichnis an die neue Situation angepasst. Dazu sucht man den Eintrag
'datadirectory' => '/var/www/html/nextcloud/data',
und ändert diesen in:
'datadirectory' => '/media/ssd/data',
Das Data-Verzeichnis befindet sich jetzt auf der externen SSD. Falls ein Upgrade ansteht, kann dieses gleich durchgeführt werden.
Im nächsten und letzten Artikel dieser Reihe möchte ich zeigen, wie man Nextcloud mit einem TURN-Server erweitert, um Videokonferenzen mit Nextcloud Talk nutzen zu können.
Heute geht es um das Fein-Tuning unserer Nextcloud-Installation, genauer gesagt, um die Umstellung des Systems von PHP auf PHP-FPM. Hierzu wird der Webserver Apache2 konfiguriert und auf HTTP/2 umgestellt.
Auf dem aktuellen System, Raspberry Pi OS Bookworm, läuft derzeit standardmäßig PHP 8.2. Diese Version werden wir mit den folgenden Schritten umstellen: Zunächst installieren wir PHP-FPM 8.2. Anschließend deaktivieren wir PHP 8.2, aktivieren PHP-FPM 8.2 und HTTP/2. Die erforderlichen Befehle werden nacheinander in der angegebenen Reihenfolge ausgeführt.
sudo apt install php-fpm -y sudo a2dismod php8.2 sudo a2enconf php8.2-fpm sudo a2enmod proxy_fcgi sudo a2dismod mpm_prefork sudo a2enmod mpm_event sudo a2enmod http2
Anschließend fügen wir im VirtualHost die folgende Zeile über den Editor Nano
sudo nano /etc/apache2/sites-available/raspi.conf
unter VirtualHost *:443>
Protocols h2 http/1.1
hinzu (siehe Screenshot).
Mit einem Neustart des Webservers aktivieren wir nun PHP-FPM 8.2.
sudo service apache2 restart
In der Nextcloud treten nun, nach der Umstellung, allerdings wieder einige bekannte Fehler auf. Diese beheben wir indem wir, mit
sudo nano /etc/php/8.2/fpm/php.ini
folgenden Eintrag
memory_limit = 128M
in
memory_limit = 512M
ändern. Am Ende der Datei wird zudem ein weiterer Block mit den spezifischen Einstellungen zu OPcache eingefügt.
opcache.enable=1 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1
Zum Abschluss muss dann der PHP-FPM 8.2-Dienst neu gestartet werden.
sudo service php8.2-fpm restart
Für eine zusätzliche Optimierung können die FPM-Einstellungen angepasst werden. Dazu werden die folgenden Parameter mit dem Editor auf die spezifischen Anforderungen des Systems eingestellt:
sudo nano /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic pm.max_children = 120 pm.start_servers = 12 pm.min_spare_servers = 6 pm.max_spare_servers = 18
Diese Werte sind auf ein System mit 4 GB RAM abgestimmt (siehe Link).
Zum Abschluss wird der Dienst ein letztes Mal gestartet, damit die Änderungen wirksam werden.
sudo service php8.2-fpm restart
Der nächste Artikel dieser Reihe wird sich damit befassen, das Datenverzeichnis von der MicroSD auf eine externe SSD auszulagern, um so den Speicher der Nextcloud zu erweitern.
Ein neuer adminForge Service kann ab sofort genutzt werden. Eine geographische Nähe zu einem Zeitserver ist wichtig um die höchstmögliche Genauigkeit der Zeitsynchronisation zu bekommen. Du kannst jeden unserer Server in deiner NTP-Konfiguration verwenden....
by adminForge.
Wer meiner Artikelreihe „Nextcloud auf dem RasPi“ gefolgt ist und alle Schritte nacheinander umgesetzt hat, sollte erfolgreich eine Nextcloud 29 auf dem Raspberry Pi installiert haben, die über ein SSL-Zertifikat von Let’s Encrypt aus dem Internet erreichbar ist. Obwohl inzwischen Version 30 am 14.09.2024 veröffentlicht wurde, wird diese noch nicht im Stable-Zweig bereitgestellt. Daher werde ich nun auf die Behebung der verbleibenden Fehler in Nextcloud 29 eingehen.
Es fällt sicherlich auf, dass im installierten System in den Verwaltungseinstellungen zahlreiche Fehlermeldungen aufgelaufen sind. Diese müssen nun behoben und beseitigt werden.
Ihr Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, Ihren Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass Sie es aus dem Document-Root-Verzeichnis des Webservers herausverschieben.
Das PHP-Speicherlimit liegt unterhalb des empfohlenen Wertes von 512 MB.
Die PHP-Konfigurationsoption „output_buffering“ muss deaktiviert sein
Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von „/ocm-provider/“ eingerichtet. Dies hängt höchstwahrscheinlich mit einer Webserver-Konfiguration zusammen, die nicht dahingehend aktualisiert wurde, diesen Ordner direkt zu auszuliefern. Bitte vergleichen Sie Ihre Konfiguration mit den mitgelieferten Rewrite-Regeln in „.htaccess“ für Apache oder den in der Nginx-Dokumentation mitgelieferten. Auf Nginx sind das typischerweise die Zeilen, die mit „location ~“ beginnen und ein Update benötigen. Weitere Informationen finden Sie in der Dokumentation
.
Ihr Webserver ist nicht ordnungsgemäß für die Auflösung von .well-known-URLs eingerichtet. Fehler bei: /.well-known/webfinger Weitere Informationen finden Sie in der Dokumentation
.
4 Fehler in den Protokollen seit 20. September 2024, 10:15:53
Der Server hat keine konfigurierte Startzeit für das Wartungsfenster. Das bedeutet, dass ressourcenintensive tägliche Hintergrundaufgaben auch während Ihrer Hauptnutzungszeit ausgeführt werden. Wir empfehlen, das Wartungsfenster auf eine Zeit mit geringer Nutzung festzulegen, damit Benutzer weniger von der Belastung durch diese umfangreichen Aufgaben beeinträchtigt werden. Weitere Informationen finden Sie in der Dokumentation
.
Einige Header sind in Ihrer Instanz nicht richtig eingestellt – Der Strict-Transport-Security-HTTP-Header ist nicht gesetzt (er sollte mindestens 15552000 Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen finden Sie in der Dokumentation
.
In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das Hinzufügen von Indizes in großen Tabellen einige Zeit in Anspruch nehmen kann, wurden diese nicht automatisch erzeugt. Durch das Ausführen von „occ db:add-missing-indices“ können die fehlenden Indizes manuell hinzugefügt werden, während die Instanz weiter läuft. Nachdem die Indizes hinzugefügt wurden, sind Anfragen auf die Tabellen normalerweise schneller. Fehlende optionaler Index „mail_messages_strucanalyz_idx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_class_creat_idx“ in der Tabelle „mail_classifiers“. Fehlende optionaler Index „mail_acc_prov_idx“ in der Tabelle „mail_accounts“. Fehlende optionaler Index „mail_alias_accid_idx“ in der Tabelle „mail_aliases“. Fehlende optionaler Index „systag_by_objectid“ in der Tabelle „systemtag_object_mapping“. Fehlende optionaler Index „mail_messages_mb_id_uid_uidx“ in der Tabelle „mail_messages“. Fehlende optionaler Index „mail_smime_certs_uid_email_idx“ in der Tabelle „mail_smime_certificates“. Fehlende optionaler Index „mail_trusted_senders_idx“ in der Tabelle „mail_trusted_senders“. Fehlende optionaler Index „mail_coll_idx“ in der Tabelle „mail_coll_addresses“.
Das PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert. Der „OPcache interned strings“-Puffer ist fast voll. Um sicherzustellen, dass sich wiederholende Strings effektiv zwischengespeichert werden können, wird empfohlen, „opcache.interned_strings_buffer“ mit einem Wert größer als „8“ in der PHP-Konfiguration zu setzen.. Weitere Informationen finden Sie in der Dokumentation
.
Die Datenbank wird für transaktionale Dateisperren verwendet. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, falls verfügbar. Weitere Informationen finden Sie in der Dokumentation
.
Es wurde kein Speichercache konfiguriert. Um die Leistung zu verbessern, konfigurieren Sie bitte Memcache, sofern verfügbar. Weitere Informationen finden Sie in der Dokumentation
.
Für Ihre Installation ist keine Standard-Telefonregion festgelegt. Dies ist erforderlich, um Telefonnummern in den Profileinstellungen ohne Ländervorwahl zu überprüfen. Um Nummern ohne Ländervorwahl zuzulassen, fügen Sie bitte „default_phone_region“ mit dem entsprechenden ISO 3166-1-Code der Region zu Ihrer Konfigurationsdatei hinzu. Weitere Informationen finden Sie in der Dokumentation
.
Sie haben Ihre E-Mail-Serverkonfiguration noch nicht festgelegt oder überprüft. Gehen Sie bitte zu den „Grundeinstellungen“, um diese festzulegen. Benutzen Sie anschließend den Button „E-Mail senden“ unterhalb des Formulars, um Ihre Einstellungen zu überprüfen. Weitere Informationen finden Sie in der Dokumentation
.
Dieser Instanz fehlen einige empfohlene PHP-Module. Für eine verbesserte Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren: – gmp für WebAuthn passwortlose Anmeldung und SFTP-Speicher Weitere Informationen finden Sie in der Dokumentation
.
Der erste Fehler in der Liste (… Datenverzeichnis und Ihre Dateien sind wahrscheinlich vom Internet aus erreichbar …) wird behoben, indem man die Konfigurationsdatei des Webservers mit
sudo nano /etc/apache2/apache2.conf
öffnet und den folgenden Eintrag
<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>
sucht. Hier wird „None“ durch „All“ ersetzt. Anschließend wird der Webserver neu gestartet und überprüft, ob die Fehlermeldung tatsächlich verschwunden ist. Diese Vorgehensweise wird nun bei jedem der zu beseitigenden Fehler wiederholt. Auf diese Weise lässt sich gut nachvollziehen, wie die Liste nach und nach abgebaut wird.
sudo service apache2 restart
Beim zweiten Fehler gilt es, das Memory Limit in der php.ini von 128MB auf 512MB anzuheben. Hierzu öffnet man diese mit
sudo nano /etc/php/8.2/apache2/php.ini
und ändert den Wert von
memory_limit = 128M
auf.
memory_limit = 512M
Anschließend wird der Webserver erneut gestartet.
sudo service apache2 restart
Eine weitere Fehlermeldung (… Einige Header sind in Ihrer Instanz nicht richtig eingestellt …) wird behoben, indem wir den Header HSTS aktivieren.
sudo a2enmod headers
Im Anschluss geht man in den VirtualHost, wie im Artikel „Nextcloud auf dem RasPi – Teil 5“ beschrieben,
sudo nano /etc/apache2/sites-available/raspi.conf
und entfernt das Rautezeichen vor der Zeile. Die Zeile wird also auskommentiert
Header always set Strict-Transport-Security "max-age=31536000"
und der Webserver neu gestartet.
sudo service apache2 restart
Danach wird ein weiterer Fehler (… E-Mail-Serverkonfiguration noch nicht festgelegt …) wie folgt behoben: Hierzu navigiert man in die Verwaltungseinstellungen → Verwaltung → Grundeinstellungen und ermöglicht Nextcloud, eMails zu senden. Dies ist wichtig, damit man bei einem vergessenen Passwort als Nutzer dieses zurücksetzen kann.
Diese Daten sind natürlich an die eigene E-Mail-Adresse anzupassen. Die meisten E-Mail-Anbieter geben hier entsprechende Anleitungen.
Die nächste Fehlermeldung (… keine Standard-Telefonregion festgelegt …) verschwindet, indem die Konfigurationsdatei der Nextcloud mit
sudo nano /var/www/html/nextcloud/config/config.php
um folgende Zeile am Ende der Auflistung erweitert wird.
'default_phone_region' => 'DE',
Die Fehlermeldung zum OPcache-Modul (… PHP OPcache-Modul ist nicht ordnungsgemäß konfiguriert …) lässt sich beseitigen, indem das Paket php-apcu installiert und die Erweiterung entsprechend konfiguriert wird.
sudo apt install php-apcu -y
Danach wird die Konfiguration der Nextcloud mit
sudo nano /var/www/html/nextcloud/config/config.php
erneut aufgerufen und
'memcache.local' => '\\OC\\Memcache\\APCu',
vor ’trusted_domains … eingefügt. Um das Ganze wirksam umzusetzen, öffnet man noch einmal die php.ini mit
sudo nano /etc/php/8.2/apache2/php.ini
und fügt diesen Block am Ende der Datei ein.
opcache.enable=1 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=10000 opcache.memory_consumption=128 opcache.save_comments=1 opcache.revalidate_freq=1
Abschließend wird der Apache2 wieder neu gestartet.
sudo service apache2 restart
Die Problematik zum Thema (… konfigurieren Sie bitte Memcache …) lässt sich lösen, indem man einen Redis-Server installiert, konfiguriert und diesen einbindet. Dazu werden die Pakete redis-server und php-redis installiert.
sudo apt install redis-server php-redis -y
In der redis.conf werden danach mit
sudo nano /etc/redis/redis.conf
die Zeilen
unixsocket /run/redis/redis-server.sock unixsocketperm 770
gesucht, auskommentiert und der Redis-Server gestartet.
sudo service redis start
Nun muss der Benutzer www-data noch zur Gruppe redis hinzugefügt werden.
sudo usermod -aG redis www-data
Um das Ganze nun abschließend umzusetzen, wird erneut die Konfiguration der Nextcloud geöffnet,
sudo nano /var/www/html/nextcloud/config/config.php
um folgenden Block unter der Zeile ’memcache.local … einzufügen.
'filelocking.enabled' => true, 'memcache.locking' => '\OC\Memcache\Redis', 'redis' => array( 'host' => 'localhost', 'port' => 6379, 'timeout' => 0.0, ),
Nach einem erneuten Neustart des Webservers sollte nun auch diese Fehlermeldung verschwunden sein.
sudo service apache2 restart
Nun wird noch dafür gesorgt, dass HTTPS bei einer Webserveranfrage erzwungen wird. Dazu wird das Apache2-Modul rewrite installiert
sudo a2enmod rewrite
und via
sudo nano /etc/apache2/sites-available/raspi.conf
ein weiteres Mal der VirtualHost aufgerufen und dieser Block unter der Zeile <VirtualHost *:80> eingefügt.
RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Wieder wird der Webserver gestartet.
sudo service apache2 restart
Die Fehlermeldung zu fehlenden Modulen (… fehlen einige empfohlene PHP-Module …) wird durch die Installation des Pakets php-gmp beseitigt.
sudo apt install php-gmp -y
Nach der Installation wird der Apache2 ein weiteres Mal neu gestartet.
sudo service apache2 restart
Ein anderer Fehler (… Server hat keine konfigurierte Startzeit für das Wartungsfenster …) lässt sich beheben, indem man die Nextcloud-Konfiguration mit
sudo nano /var/www/html/nextcloud/config/config.php
um diese zwei Zeilen
'maintenance' => false, 'maintenance_window_start' => 1,
unter dem letzten Block erweitert.
Um OCC-Befehle auszuführen, ist es notwendig, den Alternative PHP Cache (APC) für das Command Line Interface (CLI) zu aktivieren. Dies ist wichtig, um den nächsten Fehler zu beheben. Dazu wird die entsprechende Konfigurationsdatei geöffnet
sudo nano /etc/php/8.2/mods-available/apcu.ini
und folgender Eintrag
apc.enable_cli=1
ans Ende gesetzt und der Webserver neu gestartet.
sudo service apache2 restart
Jetzt kann die Fehlermeldung (… In der Datenbank fehlen einige Indizes …) behoben werden, nachdem das Verzeichnis /var/www/html/nextcloud/ zuvor betreten wurde.
cd /var/www/html/nextcloud/
Hier führt man den entsprechenden OCC-Befehl aus, der fehlende Indizes der Nextcloud-Datenbank hinzufügt.
sudo -u www-data php occ db:add-missing-indices
Abschließend wird die Log-Datei der Nextcloud gelöscht. Danach sollte sich ein grünes Häkchen mit dem Hinweis „Alle Überprüfungen bestanden“ zeigen.
sudo -u www-data truncate /var/www/html/nextcloud/data/nextcloud.log --size 0
Selbstverständlich ist es von entscheidender Bedeutung, dass die Nextcloud optimal funktioniert. Dieser Artikel soll dazu beitragen. Anfangs mag man durch die Vielzahl der Fehlermeldungen etwas überwältigt sein. Doch wenn alle Schritte nach und nach abgearbeitet werden, wird man am Ende mit dem grünen Häkchen belohnt. Ein regelmäßiger Blick in die Verwaltungseinstellungen gibt Aufschluss über den Fortschritt und erleichtert das Verständnis der durchgeführten Maßnahmen.
Nach der Veröffentlichung des ersten Point Releases von Nextcloud 30 wird automatisch ein Upgrade auf diese Version vorgeschlagen. Es wird empfohlen, über den grafischen Updater auf die neuere Version umzusteigen.
Der nächste Artikel dieser Reihe wird sich damit befassen, das System mit „PHP-FPM“ weiter zu optimieren und die Ladezeiten zu verkürzen.
Im vorherigen Artikel habe ich beschrieben, wie man den Raspberry Pi und den Router konfiguriert, um auf die Nextcloud aus dem Internet zuzugreifen. Da die Verbindung derzeit unverschlüsselt ist, werde ich nun erläutern, wie man eine SSL-Verschlüsselung implementieren und erzwingen kann.
Zu Beginn installieren wir Certbot, um ein Let’s-Encrypt-Zertifikat zu erstellen.
sudo apt install python3-certbot-apache -y
Der Vorgang wird wie folgt gestartet. Dabei ist es wichtig, die korrekte DynDNS-Adresse (dnsHome.de) anzugeben. Zudem muss eine eMail-Adresse hinterlegt werden.
sudo certbot --apache
Nachdem das Zertifikat ausgestellt wurde, folgt die Konfiguration des VirtualHost. Diesen erstellt man mit dem folgenden Befehl und fügt den unten aufgeführten Block in die Datei /etc/apache2/sites-available/raspi.conf ein.
Dabei müssen die Pfade für das Zertifikat und der Servername an die eigene DynDNS angepasst werden.
sudo nano /etc/apache2/sites-available/raspi.conf
<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html/nextcloud ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> <IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html/nextcloud # Header always set Strict-Transport-Security "max-age=31536000" # Header append X-FRAME-OPTIONS "SAMEORIGIN" ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLCertificateFile /etc/letsencrypt/live/meinecloud.dnshome.de/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/meinecloud.dnshome.de/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf ServerName meinecloud.dnshome.de </VirtualHost> </IfModule>
Nun werden die nicht mehr benötigten Vorgaben der VirtualHosts deaktiviert, der neue VirtualHost aktiviert und das SSL-Modul des Apache2 eingeschaltet.
sudo a2dissite 000-default.conf sudo a2dissite 000-default-le-ssl.conf sudo a2ensite raspi.conf sudo a2enmod ssl
Danach wird der Webserver neu gestartet.
sudo service apache2 restart
Um Verbindungen über HTTPS zu erzwingen, muss das Apache2-Modul „rewrite“ aktiviert werden.
sudo a2enmod rewrite
Danach öffnen wir den VirtualHost erneut
sudo nano /etc/apache2/sites-available/raspi.conf
und fügen die folgenden drei Rewrite-Zeilen hinzu.
<VirtualHost *:80> RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ...
Anschließend wird der Webserver erneut neu gestartet.
sudo service apache2 restart
Ein Let’s Encrypt-Zertifikat sollte monatlich erneuert werden, um sicherzustellen, dass die verschlüsselte Kommunikation auf Ihrer Website
kontinuierlich geschützt ist. Die regelmäßige Erneuerung gewährleistet, dass das Zertifikat gültig bleibt und Ihre Websitebesucher vor potenziellen Sicherheitsrisiken wie Man-in-the-Middle-Angriffen geschützt werden.
Dafür navigieren wir zum Home-Verzeichnis
cd ~/
und erstellen die Datei zertifikat.sh.
nano zertifikat.sh
Dort wird der folgende Inhalt eingetragen.
#!/bin/bash certbot certonly --renew-by-default --apache --rsa-key-size 4096 -d meinecloud.dnshome.de /etc/init.d/apache2 restart
Auch hier ist der Servername an die eigene DynDNS anzupassen.
Nun wird das erstellte Skript ausführbar gemacht
sudo chmod +x zertifikat.sh
und ein Cronjob erstellt,
sudo nano /etc/crontab
der das Script jeweils am 1. jeden Monats um 2:30 Uhr ausführt. Dabei ist folgende Zeile am Ende hinzuzufügen
30 2 1 * * root /home/radiouser/zertifikat.sh >/home/radiouser/zertifikat.log 2>&1
und der Cronjob neu zu starten.
sudo /etc/init.d/cron restart
Im nächsten Teil zeige ich, wie man die aufgelaufenen Fehler nach der Erstinstallation der Nextcloud beheben kann.