Raspberry Pi OS Lite 64Bit + Nextcloud Hub + Nextcloud Office (Collabora Online)

[Outi]

History:
26.12.2023 - Modul php8.2-bz2 hinzugefügt (für Nextcloud 28 benötigt) und Speichergrenze erhöht (in php.ini)
01.12.2023 - Anleitung und Bilder auf aktuelles Image (Bookworm) angepasst
28.05.2022 - Erste Veröffentlichung

Hinweis:
Diese Anleitung/Information erhebt keinen Anspruch auf Vollständigkeit und kann Fehler enthalten und die Benutzung erfolgt auf eigene Gefahr.
Es wird keinerlei Haftung für Schäden und/oder Datenverluste übernommen.

Info:
Die Installation der 64Bit Version vom Raspberry Pi OS läuft nur mit folgenden Pis:
3B, 3B+, 3A+, 4B, 400, 5, CM3, CM3+, CM4, Zero 2 W

Auf Grund der Komplexität der eingesetzten Software empfehle ich aber nur diese RasPis: Pi 4B ab 4GB, Pi 400 oder Pi 5
(mit dem CM4 habe ich keine Erfahrung)

Alle vorherigen RasPis laufen nur mit 32Bit !!
Nextcloud Office läuft allerdings nur mit einem 64Bit System !!
(Alle Angaben ohne Gewähr und von der Raspberry Pi Foundation.)

Für diese Anleitung benutzte Hardware & Software:
PC mit Windows 11 mit USB 3 Port (MAC OS und Linux ebenso möglich)
Putty für Windows als Fernzugriff per SSH => Download
Raspberry Pi 5 / 8GB (empfohlen ab Pi 4B 4GB / Pi 400)
SanDisk 240GB SSD mit SATA/USB 3.0 Adapter (keine SD Karte !! Es wird direkt auf die SSD installiert)
Raspberry Pi Imager => Download
Raspberry Pi OS Lite 64Bit (über den Raspberry Pi Imager)
Nextcloud Hub (nicht NextcloudPi !!) => Info
Nextcloud Office (Collabora Online) => Info
Midnight Commander (für schnellere Navigation unter Debian)
Apache 2.4
PHP 8.2 im FPM/FastCGI Modus
MariaDB 10.x
phpMyAdmin (für kleinere Datenbankzugriffe, falls irgendwann mal notwendig)
APCu und Redis als Cache

Info:
Der Raspberry Pi wird "headless" installiert und konfiguriert, also ohne Maus, Tastatur und Monitor.
Wer will, kann natürlich Maus, Taststur und Monitor verwenden, ich gehe hier aber nur auf den reinen SSH Zugriff per Putty ein.
Das liegt einfach auch daran, dass dieses System später rein als Webanwendung läuft.

Image von Raspberry Pi OS Lite 64Bit auf SSD flashen
Als erstes wird die SSD am PC/MAC/Linux Rechner per SATA/USB 3.0 Adapter angeklemmt.
Wichtig zu wissen: Die SSD sollte leer sein, spätestens bem Flashen sind alle darauf befindlichen Daten gelöscht !!
Ich habe bei mir alle zurvor darauf befindlichen Partitionen über die Datenträgerverwaltung entfernt.
Achtung !! Genau aufpassen, dass man nicht die falsche Platte löscht !!

Da man eine SSD nicht über einen SD Karten Utility löschen kann, muss das über die PC Bordmittel/Betriebssystem geschehen.
Diese vorhergehende Löschung ist allerdings normal nicht nötig, da beim Flashen die ganze Platte neu beschrieben wird.

Anschließend wird der bereits installierte Imager gestartet:



Als erstes wählen wir das Pi Modell aus, welches wir verwenden.
Das ist zwar prinzipiell nicht erforderlich (gab es früher auch nicht) aber somit werden schon OS Images ausgeblendet, die nicht zum Gerät passen oder auf jenem nicht laufen.



Hier wähle ich den neuen Pi 5 aus, Ihr wählt das Modell, welches Ihr nutzen möchtet.



Nach der Auswahl des Modells klicken wir auf der Startseite - wie mit dem gelben Pfeil markiert - auf den Button OS WÄHLEN, um das passende Image einzustellen:



Wie auf dem Bild zu sehen, geht es auf den Menüpunkt Raspberry Pi OS (other).

Danach scrollen wir runter und klicken auf das gewünschte OS Raspberry Pi OS Lite (64-bit):



Nach dem Klick auf das gezeigte OS befinden wir uns wieder auf der Hauptseite und klicken auf SD-KARTE WÄHLEN:



Sollte der SATA/USB 3.0 Adapter und vom Imager korrekt erkannt worden sein, ist dieser - wie hier auf dem Bild - auswählbar:



Oben sieht man den Namen meines SATA/USB 3.0 Adapter und dahinter die Größe der angeschlossenen SSD.
Wer hier mehrere Laufwerke zur Auswahl hat, muss unbedingt aufpassen, dass das richtige Laufwerk ausgewählt wird !!



Nach der Auswahl des Laufwerks springt der Imager wieder zurück auf die Hauptansicht und damit ist das Modell des Pi, das OS und das Ziel des Ganzen (hier 240GB SSD) eingestellt.

Bevor nun der eigentliche Flashvorgang gestartet wird, erhalten wir beim Klick auf WEITER die Chance der Vorkonfiguration einiger Einstellungen, damit wir diese später nicht manuell auf der SSD vornehmen müssen.
(Früher musste man SSH und WLan noch in diversen Dateien anlegen.)

Nach dem Klick auf WEITER erscheint eine Abfrage:



Wie auf dem Bild zu sehen, können wir nur zwischen EINSTELLUNGEN BEARBEITEN und NEIN auswählen.
Hat man bereits mit dem Imager irgendwann mal davor einen Pi vorkonfiguriert oder hat das später vor, erhält später auch die hier ausgegrauten Möglichkeiten, die Einstellungen auch zu löschen oder unverändert zu übernehmen.

Hier in dem Fall klicken wir auf EINSTELLUNGEN BEARBEITEN, um weitere Konfigurationen vorzunehmen.
Andernfalls würde bei der Ablehnung SSH und wer WLan braucht, alles wieder manuell einrichten müssen.

Es erscheint das Fenster für die OS Anpassungen mit drei Bereichen (früher alles auf einer Seite):



Ich habe hier sinnbildlich Eintragungen angepasst, wie man sie früher oft genutzt hat.
Bei Hostname: habe ich nextcloud eingetragen, damit sich der Pi im Router besser finden lässt und generell von anderen Pis unterscheidet.
Hier sollte jeder seine eigenen gewünschten Eintragungen machen, wichtig ist nur, dass Wifi-Land und Spracheinstellungen festlegen richtig zum Land und der Sprache passen.

Im mittleren Bereich folgt die Konfiguration von SSH, was die Kommunikation mit dem Raspberry Pi auf Kommandozeilenebene ermöglicht, auch Terminal genannt.



Dabei handelt es sich um eine einfache textbasierte Oberfläche.
Um diese zu aktivieren, einfach SSH aktivieren ankreuzen.
Bei der Anmeldung per SSH werden die Daten der vorherigen Seite benutzt (Benutzer / Passwort).

Die andere Option mit der passwortlosen Authentifizierung (Authentifizierung via Public-Key) würde ich als Neuling erst später nachkonfigurieren, wenn das System läuft.

Hier befindet sich nochmal die Anleitung von Putty mit anschließender Konfiguration des Public-Keys:
Login per SSH per Key mit oder ohne Passphrase mit Putty

Der letzte und damit dritte Bereich behandelt noch einige weitere Einstellmöglichkeiten:



Dort kann man den flashenden PC ein Tonsignal abspielen lassen, wenn der Flashvorgang beendet wurde.
Auch das Auswerfen der Medien (hier die SSD am USB Adapter) kann hier eingestellt werden, womit man nach dem Flashen die SSD nicht mehr manuell vom System abmelden muss.
Der letzte Punkt mit der Telemetrie überträgt an eine Webseite den groben Standort des Raspberry Pis und dient nur statistischen Zwecken.
Dies habe ich bei mir immer deaktiviert.

Zum Abschluss speichern wir die Einstellungen mit einem Klick auf den unteren Button SPEICHERN und gelangen zurück auf die Bearbeitungsauswahl von vorhin und klicken bei der zu sehenden Frage auf JA.

Es erfolgt vor dem eigentlichen Flashen noch eine Sicherheitsabfrage:



Nach der Bestätigung wird der Download und Flashvorgang gestartet:



Mit SCHREIBEN ABBRECHEN kann der Vorgang abgebrochen werden.

Nach dem Download und Flashen des Images wird noch eine Verifizierung durchgeführt, um zu testen, ob der Vorgang fehlerfrei durchgelaufen ist:



Auch dieser Vorgang kann mit VERIFIZIERUNG ABBRECHEN abgebrochen werden.

Ist die Überprüfung erfolgreich, meldet sich der Imager mit einer entsprechenden Meldung:



Nach einem Klick auf WEITER landet man wieder auf dem Hauptbildschirm und kann den Imager beenden.
Nun wird das Medium (SD Karte, HDD, SSD oder USB Stick) vom PC entfernt und in/an den Pi gesteckt/angeklemmt und das Netzteil am Pi angeschlossen.

Hinweis:
Sollte z.B. der Dateimanager von Windows meckern, dass er eine Partition formatieren will (weil er sie z.B. nicht erkannt hat oder nix damit anfangen kann), müssen wir unbedingt auf Abbrechen klicken, da uns sonst der Linuxteil gelöscht wird.
Das passiert unter Windows z.B. oft oder fast immer, wenn wir später die SSD nochmal an den PC anklemmen, um z.B. etwas in der Konfiguration im Bootbereich ändern wollen.

Alles Weitere passiert nun headless und bei Windows mit dem SSH Programm Putty (Downloadlink siehe oben).


SSH Zugriff per Putty
Wenn Putty installiert wurde, starten wir es und erhalten folgende Ansicht:



Auch wenn es evtl. schon voreingestellt ist, kontrollieren wir, ob als Dateispeichercodierung UTF-8 eingestellt ist, da im Internet auf Webseiten faktisch nichts anderes mehr verwendet wird.
Somit beugen wir auch diversen Falschdarstellungen bei Texten vor, die später nur schwerlich umzukonvertieren sind.
Auch Datenbankabfragen verwenden so gut wie nur noch UTF-8 in bestimmten Versionen.

Diese Einstellung finden wir in Putty links im Menüpunkt Window => Translation:



Nun wechseln wir wieder links im Menü zurück auf die Hauptseite über den Punkt Session:



Hier nun die folgende weitere Vorgehensweise in 6 Punkten:

1. mit diesem Menüpunkt geht es auf die gezeigte Hauptseite
2. hier den Namen des RasPis eingeben, so wie oben in der Vorabkonfiguration (hier: nextcloud)
3. hier den Namen der zu speichernden Konfiguration eingeben (frei wählbar)
4. das Ganze hier speichern, um nicht jedes Mal alles neu eingeben zu müssen
5. sobald gespeichert wurde, erscheint hier ein neuer Eintrag
6. nach dem Speichern hier die Konfiguration starten und die Verbindung herstellen

Wenn man später Putty neu startet, kann man über die Auswahl bei Punkt 5 die zuvor gespeicherte Konfiguration per Load laden und unten per Open einfach starten.

Bei der allerersten Verbindung erscheint ein Sicherheitshinweis in Putty:



Da Putty den Server und dessen Sicherheitsschlüssel noch nicht kennt und wir diese Konfiguration gerade erst erstellt haben, teilen wir Putty per Accept mit, sich diese Kombination aus Konfiguration und Verschlüsselung zu merken.

Beim der nächsten Verbindung über Putty erscheint dann diese Warnung nicht mehr.

Sollte diese Meldung nicht erscheinen und stattdessen eine Fehlermeldung, dass der Host nicht gefunden wurde, sollte man den Namen des Pi und das Passwort nochmals kontrollieren.

Ist alles ok, dann erscheint das Login auf den RasPi im Terminalfenster:



Hier wurde im Bild bereits pi als Benutzer eingegeben.
Das Passwort wird nun blind eingegeben, so wie es zuvor in der Vorabkonfiguration festgelegt wurde.

Hinweis:
Es kann oder es wird oft vorkommen, dass diese Eingabeabfrage beim ersten Login sehr lange braucht, bis sie angezeigt wird.
Das liegt daran, dass der RasPi beim ersten Booten länger braucht, um erste Einstellungen umzusetzen.
Z.B. wird im Hintergrund automatisch die Partition auf das Maximum vergrößert, was gerade auch bei größeren Laufwerken länger dauern kann.
Sollte z.B. ein Timeout in Putty erscheinen, was anzeigt, dass in einer bestimmten Zeit keine Reaktion des RasPis erfolgte, wird Putty einfach geschlossen und neu gestartet und der ganze Vorgang etwas später einfach wiederholt.

Nach dem erfolgreichen Login sehen wir die folgende Ausgabe:



Bei späteren Logins wird uns auch noch die IP des letzten Gerätes angezeigt, mit dem wir uns zum RasPi verbunden haben.
Die grüne Farbe und der Name pi in der Eingabezeile zeigt, dass wir als normaler Nutzer eingeloggt sind.
Um mit Rootrechten zu arbeiten (eher nicht empfohlen), gibt man sudo su ein und der Name pi ändert sich in root und die grüne Farbe wechselt zu grau (wie der Rest).
Zurück in den reinen Benutzermodus kommt man wieder mit der Eingabe exit.
Ein weiteres exit beendet die Verbindung und schließt Putty ebenfalls.

Da das Image des Downloads nun auch schon ein paar Tage alt ist, aktualisieren wir das gesamte System auf den neusten Stand.
Dafür geben wir den folgenden Kombinationsbefehl ein:

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Der Befehl bedeutet Folgendes:

sudo führt den Befehl als Benutzer root aus, auch wenn wir nur im reinen Benutzermodus sind.
apt sagt dem System, dass wir etwas "holen" wollen; was genau, sagt der nachfolgende Befehl.
update definiert, dass wir die Liste der verfügbaren Installationspakete aktualisieren möchten.
&& addiert einen weiteren Befehl hinten dran, der danach auch ausgeführt werden soll.
sudo wie oben, auch der nachfolgende Befehl benötigt Rootrechte
apt wie oben, wir wollen wieder was "holen".
full-upgrade diesmal aktualisieren wir alle Pakete inkl. Abhängigkeiten der gesamten Distribution.
-y spart uns das Bestätigen mit y (yes) bei der Abfrage, ob wir das wirklich wollen.

Hinweis:
Egal was wir mit apt anstellen, das sudo apt update ist immer der allererste Befehl, da es sonst zu Problemen kommt, wenn die Paketliste (also alles was irgendwie per Paket zur Verfügung gestellt wird) auf dem RasPi von der Paketliste online abweicht.
Dieser Befehl passt die Paketliste auf dem RasPi so an, dass sie mit der Onlineliste übereinstimmt.
Warum ist diese Abgleichung/Aktualisierung nötig ??
Antwort: Pakete werden immer Online heruntergeladen und ändern sich dauernd und wenn die Liste auf dem Pi veraltet ist, kann es schlicht sein, dass eine Installation nicht funktioniert oder nicht gestartet werden kann.
Das betrifft aber nur fertige Pakete, manuelle Installationen per Kompilierung gehen andere Wege.

Die Ausgabe kann beim ersten Mal etwas länger dauern (je nachdem, wie lange das letzte Update her ist) und sieht in der Regel etwa so aus:



Sollte es nichts Neues geben, wird das auch angezeigt.

Dieser Befehl sollte von Zeit zu Zeit auch unabhängig durchgeführt werden, da es oft sicherheitsrelevante Updates gibt.

Hinweis:
Sollte das oben durchgeführte Upgrade länger gedauert haben (und könnte evtl. sogar Firmware Updates beinhalten), booten wir den Pi neu und loggen uns dann wie weiter oben mit Putty wieder ein.

Der Reboot erfolgt mit dem Befehl

Code: Alles auswählen

sudo reboot

Dann etwas warten, bis der Pi wieder "oben" ist und nach dem Einloggen kann man zur Sicherheit den Upgrade Befehl wiederholen.
Danach sollten keine weiteren Pakete gefunden werden.

In meinem Fall wurden keine neuen Pakete mehr gefunden, dafür aber ein überflüssiges.
Dies wurde nach dem zweiten Upgrade am Ende der Ausgabe angezeigt:

Code: Alles auswählen

The following packages were automatically installed and are no longer required:
  libcamera-apps-lite libpisp0.0.1
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Mir wurde also empfohlen, das gezeigte Paket zu entfernen.
Dies geschieht (wie gezeigt) mit folgendem Befehl:

Code: Alles auswählen

sudo apt autoremove -y

Nach kurzer Zeit ist auch das erledigt.

Um schneller im Raspberry Pi OS zu navigieren und z.B. mal eben schnell einige Dateien zu bearbeiten, installiere ich mir bei allen RasPis den Midnight Commander (mc).
Ältere Semester kennen sicherlich ein ähnlich aussehendes/klingendes Tool aus der frühen DOS Zeit.

Installiert wird er ganz einfach:

Code: Alles auswählen

sudo apt install mc -y

Um ihn zu starten und um auch alle Dateien und Verzeichnisse zu erreichen/bearbeiten, starten wir ihn wieder mit dem Befehl sudo:

Code: Alles auswählen

sudo mc

Und eine den älteren Semestern bekannte "Oberfläche" erscheint:



Beendet wird der mc per <F10>.

Über den beim Raspberry Pi OS bekannten Befehl können weitere Einstellungen vorgenommen werden:

Code: Alles auswählen

sudo raspi-config

Dabei erscheint auch in der Lite Version die bekannte Konfigurationsoberfläche:



Hier habe ich allerdings nur Kleinigkeiten angepasst, z.B. Punkt 5 Localisation Options:



Zuerst habe ich L1 Locale angepasst:



Dabei habe ich zusätzlich de_DE.UTF-8 UTF-8 aktiviert und



en_GB.UTF-8 UTF-8 deaktiviert.

Direkt danach wird das Standardenviroment angegeben, hier de_DE.UTF-8, wodurch man wesentlich öfter die deutsche Sprache erhält, wenn auch nicht überall:



Nach wenigen Sekunden der Umkonfiguration erscheint das Hauptmenü mit seltsamen Zeichen im Rahmen:



Das gibt sich aber durch einen Reboot des RasPis, nachdem wir raspi-config mit Finish beendet haben:

Code: Alles auswählen

sudo reboot

Putty bekommt die Unterbrechung mit und meldet den Verbindungsverlust.
Sollte sich Putty nicht mit dieser Meldung melden, dann einfach beenden und neu starten.

Nun kann man entweder Putty beenden oder mit einem Rechtsklick auf die Titelleiste die Sitzung per Klick auf Restart Session wieder herstellen, sobald der RasPi nach einigen Sekunden wieder bereit ist.
Gebt dem RasPi ein wenig Zeit und versucht es ggf. mehrmals.
Danach erscheint wieder das bekannte Login, in dem Ihr Euch wieder anmeldet.

Da jetzt noch einige deutsche Texte fehlen könnten durch die Umstellung, empfehle ich den folgenden bekannten Befehl:

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Damit werden auch die letzten vorhandenen deutschen Texte nachgeladen.
Zumindest kam bei mir bei einigen früheren Installationen noch teilweise etwas nach, jedenfalls kaputt machen kann man damit nichts.

Mehr muss eigentlich nicht in raspi-config eingestellt werden und selbst das oben Gezeigte kann man eigentlich ignorieren.
Ich mache das halt eben bei jedem RasPi, da ich es gerne - so weit wie möglich - auf Deutsch übersetzt haben möchte.


Login Benutzer Root deaktivieren
Ein Sicherheitspunkt ist das Deaktivieren des Benutzers "Root", der systemweit alle Rechte hat. Damit hier niemand eine Angriffsfläche hat, wird dieser Benutzer deaktiviert. Man loggt sich in Zukunft also als normaler User ein (hier z.B. als "pi") und wechselt bei Bedarf auf Rootrechte z.B. mit sudo (daher auch zuvor immer sudo vor den Befehlen).

Info:
Generell kann man auch das komplette Passwortlogin deaktivieren, wenn man vorher die Schlüsseldateiauthentifizierung aktiviert.
Hierzu kann man sich z.B. mit dem Programm PuttyGen ein Schlüsselpaar erzeugen und einen Schlüssel auf den Raspberry Pi einbinden und den anderen in Putty zuweisen und wer will, kann auch dafür noch eine Passphrase (also ein Kennwort) dafür erzeugen.
Da dies hier aber einer extra Anleitung bedarf und eher in die Kategorie Allgemein gehört (da auch für alle anderen headless Anwendungen gilt), würde dieser Part diese Anleutung unnötig aufblasen.
Man hat dadurch eine höhere Sicherheit, kann sich aber nur einloggen, wenn man den passenden Schlüssel dabei hat.
Wer dies trotzdem hier auch schon nutzen möchte, googelt am besten nach Wörtern wie ssh login per key.

Hinweis:
Bitte darauf achten, dass ein anderer Benutzer vorhanden ist, der Rootrechte übernehmen kann, damit man sich nicht komplett aussperrt.

Um diesen Schritt durchzuführen, muss die Datei /etc/ssh/sshd_config bearbeitet werden:

Code: Alles auswählen

sudo nano /etc/ssh/sshd_config

Dort wird der Parameter

Code: Alles auswählen

#PermitRootLogin prohibit-password

in

Code: Alles auswählen

PermitRootLogin no

geändert.

Dabei ist zu beachten, dass das # Zeichen vor der Zeile zu entfernen ist, da die Zeile sonst keine Funktion hat.

Wer gleich noch ein ganz wenig mehr Sicherheit einbauen möchte, ändert in dieser Datei auch gleich den Port von 22 auf was anderes (am Besten irgendwas 5stelliges).

Dabei in der Zeile #Port 22 das "#" davor entfernen und den gewünschten Port eintragen.
Der neue Port mus dann natürlich auch in Putty angepasst werden, da wir sonst nicht mehr per SSH drauf kommen, da ja der Standard Port 22 in Putty immer vorgegeben ist.

Gespeichert und verlassen wird die Datei mit der Tastenkombination <STRG><X>.

Die Frage nach der Speicherung bitte per <J> für "Ja" und <ENTER> für den Dateipfad bestätigen.
Nun sind wir wieder auf der Eingabeaufforderung zurück.

Damit die Einstellung auch vom System übernommen und der Root Zugang gesperrt wird, muss der SSH Dienst neu gestartet werden:

Code: Alles auswählen

sudo /etc/init.d/ssh restart

Abschließend noch ausloggen und einen Test durchführen, ob der Zugang wirklich gesperrt ist.


Installation von Apache2, PHP, MySQL (MariaDB) und phpMyAdmin
Zuerst installieren wir den Webserver Apache 2:

Code: Alles auswählen

sudo apt install apache2 -y

Man könnte hier auch den leichteren Webserver nginx nehmen aber ich denke, der RasPi 4B, 400 oder 5 sind schnell genug, so dass man eigentlich keinen Unterschied bemerken sollte.
Ich habe mich für den Apache 2 entschieden, da hier mehr Anleitungen existieren und ich mich mit diesem ein wenig besser auskenne.
Das Teil will ja schließlich auch gepflegt werden.

Um zu prüfen, ob der Apache korrekt installiert wurde und läuft, rufen wir die Webseite des Webservers auf:

http://nextcloud

Die passende Webseite sollte also so aussehen:



Weiter geht es mit der Installation von PHP 8.2:

Code: Alles auswählen

sudo apt install php8.2 php8.2-curl php8.2-gd php8.2-fpm php8.2-cli php8.2-opcache php8.2-mbstring php8.2-xml php8.2-zip php8.2-mysql php8.2-intl php8.2-bcmath php8.2-gmp php8.2-bz2 php8.2-imagick -y

Dieser Vorgang dauert nun ein wenig, da hier einiges an PHP Modulen eingerichtet wird, die wir später brauchen.

Am Ende erscheinen folgende Zeilen:

Code: Alles auswählen

NOTICE: Not enabling PHP 8.2 FPM by default.
NOTICE: To enable PHP 8.2 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php8.2-fpm
NOTICE: You are seeing this message because you have apache2 package installed.

Die beiden genannten Hinweise für die Aktivierung von FPM/FastCGI führen wir also noch so aus:

Code: Alles auswählen

sudo a2enmod proxy_fcgi setenvif && sudo a2enconf php8.2-fpm

Auch wenn danach ausgegeben wird, dass eines der beiden Module bereits aktiviert war, ist es sicherer, wir geben trotzdem beide Befehle ein.

Da wir später auch das Rewrite Modul und das Actions Modul benötigen, binden wir diese auch gleich noch mit ein:

Code: Alles auswählen

sudo a2enmod rewrite && sudo a2enmod actions

Danach muss der Apache 2 Webserver neu gestartet werden (ein reload reicht aus):

Code: Alles auswählen

sudo systemctl reload apache2

Somit sollte PHP im Webserver laufen.

Um die PHP Version abzufragen, geben wir folgenden Befehl ein:

Code: Alles auswählen

php --version

und erhalten eine Ausgabe so ähnlich wie hier:

Code: Alles auswählen

PHP 8.2.7 (cli) (built: Jun  9 2023 19:37:27) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies

Damit der Apache 2 auch mit PHP was anfangen kann, installieren wir folgendes Modul nach:

Code: Alles auswählen

sudo apt-get install libapache2-mod-php8.2 -y

Und auch hier folgt wieder ein Reload der Apache 2 Konfiguration:

Code: Alles auswählen

sudo systemctl reload apache2

Da wir nun bereits einige systeminterne Änderungen vorgenommen haben, empfehle ich das Upgrade per

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Bei mir gab es nun bereits mehrere Neuerungen, die damit aktualisiert wurden.
Ob es nun Zufall war oder nicht, ist egal, denn dieser Befehl schadet nicht, denn er gibt entweder aus, dass nichts zu aktualisieren sei oder es wird eben aktualisiert, falls nötig.

Jetzt erstellen wir eine Webseite, um die PHP Konfiguration zu prüfen.
Die dafür benötigte Datei legen wir wie folgt an:

Code: Alles auswählen

sudo nano /var/www/html/info.php

Sollte danach gefragt werden, welcher editor duaewrhaft benutzt werden soll, bitte nano wählen.

In das darauf erscheinende leere Fenster geben wir folgenden Inhalt ein:

Code: Alles auswählen

<?php
  phpinfo();
?>

Fertig sieht das dann so aus:



Gespeichert wird diese Datei per Tastendruck: <STRG><X>

Diese Webseite rufen wir nun auf:

http://nextcloud/info.php

Dabei sollte etwas wie dieses hier erscheinen:



Wird dagegen ein Download im Browser angeboten, sollte man alle PHP Schritte nochmal prüfen.

Bei früheren PHP Versionen vor 8.x.x musste man den FPM/FastCGI Modus noch manuell konfigurieren, seit einiger Zeit wird dies unter PHP 8.x.x bereits automatisch eingerichtet, wie man auch auf dem Bild sehen kann.

Nun installieren wir die benötigte Datenbank MariaDB, die kompatibel zu MySQL und quasi der neue Standard ist:

Code: Alles auswählen

sudo apt install mariadb-client mariadb-server -y

Danach sichern wir die Datenbankkonfiguration etwas ab:

Code: Alles auswählen

sudo mysql_secure_installation

Folgende Fragen werden gestellt und beantwortet:

Enter current password for root (enter for none): hier einfach <ENTER> drücken
Switch to unix_socket authentication [Y/n] hier <ENTER> für Yes drücken
Change the root password? [Y/n] hier <ENTER> für Yes drücken
New password: hier ein gewünschtes Passwort für den Root Account (der Datenbank) eingeben + <ENTER>
Re-enter new password: Passwort erneut eingeben + <ENTER>
Remove anonymous users? [Y/n] hier <ENTER> für Yes drücken
Disallow root login remotely? [Y/n] hier <ENTER> für Yes drücken
Remove test database and access to it? [Y/n] hier <ENTER> für Yes drücken
Reload privilege tables now? [Y/n] hier <ENTER> für Yes drücken

Damit wäre die Absicherung der Datenbank abgeschlossen.

Um auch mal einfach so in die Datenbank zu gehen und ein paar Werte zu prüfen und/oder zu ändern, ohne Befehle auswendig eintippen zu müssen, installieren wir das Skript phpMyAdmin.

Um die aktuelle phpMyAdmin Version 5.x.x zu installieren, erledigen wir das auf dem manuellen Weg, da die bisherigen Pakete nur bis 4.x.x gehen, welche für PHP 8.x nicht geeignet sind.

Dies funktioniert folgendermaßen:

Code: Alles auswählen

cd /usr/local/src

Code: Alles auswählen

sudo mkdir phpmyadmin

Code: Alles auswählen

cd phpmyadmin

Hier die phpMyAdmin Version 5.2.1:

Code: Alles auswählen

sudo wget https://files.phpmyadmin.net/phpMyAdmin/5.2.1/phpMyAdmin-5.2.1-all-languages.zip && sudo unzip phpMyAdmin-5.2.1-all-languages.zip && cd phpMyAdmin-5.2.1-all-languages

Nach dem Download und Entpacken wird ein Passwortgenerator installiert:

Code: Alles auswählen

sudo apt-get install pwgen -y

Und anschließend ein Passwort generiert:

Code: Alles auswählen

pwgen -s 32 1

Dieses generierte Passwort ist recht komplex und sollte in der Zwischenablage zwischengespeichert werden.

Als Nächstes kopieren wir die Beispiel Konfigdatei in eine brauchbare Datei um:

Code: Alles auswählen

sudo cp config.sample.inc.php config.inc.php

Jetzt öffnen wir die Datei:

Code: Alles auswählen

sudo nano config.inc.php

und tragen das zwischengespeicherte Passwort hier an dieser Stelle ein:

Code: Alles auswählen

$cfg['blowfish_secret'] = 'Hier das zuvor generierte und zwischengespeicherte komplexe PW eintragen'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

Wenn wir gerade drin sind, fügen wir gleich noch folgende Zeile ans Ende der Datei ein:

Code: Alles auswählen

$cfg['TempDir'] = 'tmp';

Die Datei wird nun per Tastenkombination <STRG><X> gespeichert und beendet.

Nun erzeugen wir die phpMyAdmin Konfigurationsdatei:

Code: Alles auswählen

sudo nano /etc/apache2/conf-available/phpmyadmin-custom.conf

und füllen sie mit folgendem Inhalt:

Code: Alles auswählen

Alias /phpmyadmin /usr/local/src/phpmyadmin/phpMyAdmin-5.2.1-all-languages
<Directory "/usr/local/src/phpmyadmin/phpMyAdmin-5.2.1-all-languages">
        Options SymLinksIfOwnerMatch
        DirectoryIndex index.php
        Require all granted
</Directory>

Nach dem Speichern und Beenden der Konfig müssen wir diese noch in Apache2 aktivieren:

Code: Alles auswählen

sudo a2enconf phpmyadmin-custom

Und der obligatorische Apache 2 Reload:

Code: Alles auswählen

sudo systemctl reload apache2

Jetzt noch das Temp Verzeichnis anlegen:

Code: Alles auswählen

sudo mkdir tmp

Damit es beim Anlegen von temporären Dateien in phpMyAdmin zu keinen Fehlern kommt, müssen wir hier noch den Eigentümer des TMP Verzeichnisses von Root auf den Webserver ändern:

Code: Alles auswählen

sudo chown -R www-data:www-data tmp

Nun können wir auch wieder ins Home Verzeichnis zurückspringen:

Code: Alles auswählen

cd ~

phpMyAdmin läuft nun unter folgendem Link:

http://nextcloud/phpmyadmin

Nach dem Aufruf im Browser erscheint die Loginmaske von phpMyAdmin:



Da bei dieser manuellen Installation keine phpMyAdmin Datenbank für phpMyAdmin selbst angelegt wird, könnte man später die in phpMyAdmin auftretende Fehlermeldung anklicken und den Anweisungen folgen.
Wir können aber dieses Problem bereits vorher beheben, indem wir die Datenbank selbst erstellen und mit die gewünschten Daten einlesen.

Zuerst loggen wir uns im Terminalfenster (Putty) in die Datenbank ein:

Code: Alles auswählen

mysql -u root -p

Dann geben wir das Passwort ein, welches wir bei der Installation der Datenbanksoftware vergeben haben.

Nun erscheint ein neuer Eingabeprompt:

Code: Alles auswählen

MariaDB [(none)]>

Mit dem Befehl CREATE DATABASE dahinter legen wir zuerst die Datenbank an:

Code: Alles auswählen

CREATE DATABASE phpmyadmin;

Nun verlassen wir die Datenbanksoftware wieder mit exit, um wieder in die normale Terminaleingabemaske zu kommen:

Code: Alles auswählen

exit

Es folgt das Einlesen der fehlenden Tabellen:

Code: Alles auswählen

sudo mysql -u root -p phpmyadmin < /usr/local/src/phpmyadmin/phpMyAdmin-5.2.1-all-languages/sql/create_tables.sql

Hier wieder das Datenbankpasswort eingeben und die Daten sind schnell importiert.

Nun kann man sich auf der phpMyAdmin Webseite als root mit dem passenden Passwort einloggen.

Es wird empfohlen, nicht den root Account für Zugriffe und Skripts zu verwenden, daher empfiehlt es sich einen neuen Benutzer anlegen und diesem alle Rechte zu geben (auch hier die Sicherheit bedenken).

Um einen komplett anderen Benutzer anzulegen, den man statt dem root Account nutzt, loggen wir uns wieder im Terminal in die Datenbank ein:

Code: Alles auswählen

sudo mysql --user=root mysql

Der neue Benutzer wird wie folgt angelegt:

Code: Alles auswählen

CREATE USER 'benutzername'@'localhost' IDENTIFIED BY 'passwort';

Die Wörter benutzername und passwort sind durch eigene Kreationen auszutauschen.

Die Rechtevergabe sieht dann so aus:

Code: Alles auswählen

GRANT ALL PRIVILEGES ON *.* TO 'benutzer'@'localhost' WITH GRANT OPTION;

Auch hier ist das Wort benutzer wie im oberen Befehl gleich zu setzen.

Und zum Abschluss wieder die sofortige Rechteübernahme:

Code: Alles auswählen

FLUSH PRIVILEGES;

Der Befehl exit beendet die Datenbankkonsole wieder und führt in die Terminaleingabe zurück.

Zur Sicherheit lesen wir die Apache 2-, PHP- und Datenbankkonfiguration nochmals neu ein:

Code: Alles auswählen

sudo service apache2 reload && sudo service php8.2-fpm reload && sudo service mysql restart

Ob die erweiterte Rechtevergabe geklappt hat, erkennt man im eingeloggten phpMyAdmin links an der Anzahl der Datenbanken (mehr als 2).
Zum Test sollte eine neue Datenbank angelegt und wieder gelöscht werden.

Generell lässt sich noch empfehlen, dass ggf. für diverse Datenbanken auch unterschiedliche Benutzer mit verschiedenen Rechten konfiguriert werden können. Hierzu ist z.B. die recht ausführliche Anleitung per man mysql aufrufbar oder auch diverse Webseiten zu MySQL und MariaDB geben umfangreiche Infos.

Nun loggen wir uns entweder mit dem Account root oder wer einen neuen Account angelegt hat, mit diesem und dem entsprechenden Passwort über den bekannten Link ein:

http://nextcloud/phpmyadmin

Nach der Eingabe der Zugangsdaten sehen wir die Hauptseite von phpMyAdmin:



Damit ist die Grundlage für Datenbankanwendungen und Bearbeitung geschaffen.

Nun löschen wir noch die oben angelegte Datei info.php und das Archiv von phpMyAdmin, welche wir nicht mehr benötigen, sofern alles korrekt läuft:

Code: Alles auswählen

sudo rm /usr/local/src/phpmyadmin/*.zip

Code: Alles auswählen

sudo rm /var/www/html/info.php

Da in der momentanen PHP Konfiguration einige Speichereinstellungen etwas ungünstig/zu niedrig eingestellt sind, passen wir das gleich noch an.
Dazu öffnen wir die Datei php.ini:

Code: Alles auswählen

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

und scrollen runter zu memory_limit = 128M und ändern den Wert auf den gewünschten neuen Wert (hier 6G für Pi mit 8GB RAM):



3G sollten bei einem Raspberry Pi 4B 4GB / Pi 400 reichen, bei den 8GB Pis nehme ich immer 6G, dann bleibt noch was für den Rest außenrum.
Evtl. sollte/darf man mit den Werten spielen und testen.
Bei einem Wert unter 512M bekommt man später eine Warnmeldung in Nextcloud, jedoch empfiehlt es sich bei einem Raspberry Pi 3B(+), hier mit den 512M zu verfahren, da dieser nur 1GB RAM hat. Ein Raspberry Pi 2B kommt hier nicht in Frage, da dieser kein 64Bit kann, genauso wenig wie ein Zero oder die ganz alten Pis. Aber auch einen Pi 3B(+) kann ich wegen der mangelnden Ressourcen nicht mehr empfehlen.

Wenn wir eh schon in der php.ini sind, passen wir gleich noch den Dateiuploadwert an:

An dieser Stelle

Code: Alles auswählen

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 2M

ändern wir die unterste Zeile in

Code: Alles auswählen

upload_max_filesize = 1G

was für die meisten Sachen reichen sollt, ggf. diesen Wert anpassen.
Bitte aber bedenken, dass größere Uploads länger dauern und es ggf. zu Timeouts kommen kann.

Dann noch folgenden Wert auf 100 erhöhen:

Code: Alles auswählen

max_file_uploads = 100

Und dann passen wir auch gleich noch die Option post_max_size an:

Code: Alles auswählen

post_max_size = 1G

Zudem habe ich bei mir noch die Ausführungszeiten angepasst:

Code: Alles auswählen

max_execution_time = 240

und

Code: Alles auswählen

max_input_time = 240

und die Anzahl der Eingabevariablen:

Code: Alles auswählen

max_input_vars = 2000

Nun speichern und schließen wir die php.ini wieder.

Jetzt sollte das Gröbste für einen (unverschlüsselten Betrieb, die Verschlüsselung folgt später, wenn alles läuft) konfiguriert sein.

Zum Abschluss booten wir am besten neu:

Code: Alles auswählen

sudo reboot

Danach wieder über Putty an der Kommandozeile einloggen.


Caching mit APCu und Redis
Bevor es nun an die Nextcloud Installation geht, richten wir noch eben einen Cache ein, der die Bereitstellung der Webseiten beschleunigen soll.
Die originale Anleitung von Nextcloud listet drei verschiedene Varianten, nennt dabei APCu mit Redis als die modernste Version.
In der "normalen" 32 Bit Installation von NextcloudPi über Curl wird m.W.n. auch Redis implementiert.

Da dies aber in der hier gezeigten PHP Installation nicht der Fall ist, holen wir das nach:

Code: Alles auswählen

sudo apt install redis-server php8.2-redis php8.2-apcu -y

Damit der Webserver auch in den Redis Cache schreiben und davon lesen kann, muss der Webserver User www-data in die Redis Gruppe:

Code: Alles auswählen

sudo usermod -a -G redis www-data

Damit Redis aber auch nach einem Sytsem Start/Neustart geladen und gestartet wird, fürgen wir den Autostart noch hinzu:

Code: Alles auswählen

sudo systemctl enable redis-server

Redis wird mit

Code: Alles auswählen

sudo service redis-server start

gestartet, mit restart neu gestartet und mit stop gestoppt.

Es folgt der übliche Neustart, am besten wieder von Apache und Co.:

Code: Alles auswählen

sudo service apache2 reload && sudo service php8.2-fpm reload && sudo service mysql restart

Hinweis:
Ich hatte in einer meiner früheren Installationen von Redis folgenden Warnhinweis in der dazugehörigen Logdatei /var/log/redis/redis-server.log:

Code: Alles auswählen

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.
To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the
command 'sysctl vm.overcommit_memory=1' for this to take effect.

Wer diesen Hinweis nicht im Log stehen hat, kann diesen Kasten überspringen !!

Eine weitere Fehlermeldung im Log bez. TimeOut kann ignoriert werden, da der Fehler bei der weiteren Konfiguration mit behoben wird.

Diesem Rat bin ich gefolgt und dazu öffnen wir die oben genannte Datei

Code: Alles auswählen

sudo nano /etc/sysctl.conf

und hängen folgenden Eintrag ganz an den Schluss:

Code: Alles auswählen

vm.overcommit_memory = 1

Damit war die Warnmeldung weg und Redis ließ sich ohne weitere Warnmeldungen oder Fehler in der Logdatei starten.
Wer also mit Redis diverse Probleme hat, es könnte evtl. auch damit zu tun haben.

Als nächstes generieren wir ein sicheres Passwort.
Man kann entweder ein eigenes, langes und kompliziertes Passwort ausdenken oder wir lassen uns eins generieren und verschlüsseln:

Code: Alles auswählen

echo "IchbinnureinBeispiel" | sha256sum

Heraus kommt etwas in der Art (bitte natürlich was Eigenes erstellen):

Code: Alles auswählen

c03d914786edf0161b5bad0180d789634acc39cd310cc1dee1cc395e3dbc76ee

Wer will, kann natürlich darin noch Großbuchstaben und Sonderzeichen einfügen, aber ich denke, das sollte komplex genug sein.

Diese Zeichenkollonne speichern wir uns nun irgendwo hin (Notepad oder Ähnliches) und fügen ihn in die Konfigdatei von Redis ein:

Code: Alles auswählen

sudo nano /etc/redis/redis.conf

Dort scrollen wir zum Absatz SECURITY und bearbeiten die Zeile requirepass:



Die oben markierte Zeile aktivieren wir durch das Entfernen der Raute (#) und dem Einsetzen des Passworts:

Code: Alles auswählen

requirepass c03d914786edf0161b5bad0180d789634acc39cd310cc1dee1cc395e3dbc76ee

Diesen Cache Mechanismus müssen wir später in Nextcloud in der Konfiguration nachtragen, daher speichern wir das Passwort irgendwo hin.
Ich mache das immer per Copy/Paste in den Notepad++ Editor, der im Hintergrund weitere Daten aufnehmen kann, falls wir die Zwischenablage öfter nutzen.

Jetzt müssen noch die Sockets für Nextcloud aktiviert und die Rechte angepasst werden.
Dafür scrollen wir in der noch geöffneten Datei an die Stelle Unix socket.

Dieser Bereich muss so abgeändert werden, dass es fertig so aussieht:

Code: Alles auswählen

# Unix socket.
#
# Specify the path for the Unix socket that will be used to listen for
# incoming connections. There is no default, so Redis will not listen
# on a unix socket when not specified.
#
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 775

In den letzten beiden hier gezeigten Zeilen müssen die '#' davor entfernt werden und in der letzten Zeile ist die 700 durch die 775 zu ersetzen.

Und wenn wir schon in der Konfigurationsdatei sind, aktivieren wir (wie in der Datei empfohlen) die supervision interaction Option, indem wir das # vor der entsprechenden Zeile entfernen und es dann also so aussieht:

Code: Alles auswählen

supervised auto

Viele andere Anleitungen empfehlen die Einstellung u.U. auf einen anderen Wert statt auto.
Generell sollte diese Option aktiviert werden, mit auto passt sich Redis automatisch an die eigene Konfiguration an.
Das Ganze soll die interne Kommunikation erweitern, siehe auch die Erklärungen rund um diese Option.

Nun speichern wir die Datei und schließen sie, gefolgt von einem Redis Restart:

Code: Alles auswählen

sudo service redis-server restart

Nun geht es direkt zur Installation von Nextcloud.


Nextcloud Installation (Nextcloud HUB / nicht NextCloudPi !!)
Zuerst legen wir das Datenverzeichnis außerhalb des öffentlichen Webserverzugriffs ab und vergeben die passenden Rechte.
Dies geschieht jetzt schon, damit nachher keine Probleme nach der Installation auftreten.
Die Nextcloud Installation selbst generiert das Verzeichnis im öffentlichen Bereich und wenn wir dann einen anderen Pfad wählen, fehlen die Rechte.

Das Verzeichnis erstellen wir ein Unterverzeichnis unter dem Hauptwebverzeichnis /var/www/data:

Code: Alles auswählen

sudo mkdir /var/www/data

Dann noch die Rechteanpassung:

Code: Alles auswählen

sudo chown -R www-data:www-data /var/www/data

Damit es später keine Rechteprobleme mit dem html Verzeichnis gibt, geben wir ihm (www-data) gleich die Eigentümerschaft:

Code: Alles auswählen

sudo chown -R www-data:www-data /var/www/html

Damit gehört dem Webserver das Verzeichnis und nur er (außer Root) hat die Rechte, darin zu schreiben.

Da wir die PHP Installation von Nextcloud wählen (wie von der originalen Anleitung empfohlen), wechseln wir dazu in unser Webspace Verzeichnis:

Code: Alles auswählen

cd /var/www/html

Wenn wir schon drin sind, löschen wir gleich die Beispieldatei für die Anzeige des installierten Apache 2 Webserver index.html:

Code: Alles auswählen

sudo rm index.html

Als nächstes laden wir dafür hier die Installationsdatei für Nextcloud rein:

Code: Alles auswählen

sudo wget https://download.nextcloud.com/server/installer/setup-nextcloud.php

Damit es keine Rechteprobleme gibt, müssen wir dieser Datei noch den Richtigen User (Webserver) und die passenden Rechte geben:

Code: Alles auswählen

sudo chown www-data:www-data setup-nextcloud.php

und

Code: Alles auswählen

sudo chmod 0755 setup-nextcloud.php

Nun rufen wie diese Installationsdatei in unserem Browser auf:

http://nextcloud/setup-nextcloud.php

Es wird der Installationswizzard angezeigt, den wir mit Next starten:



Auf der folgenden Seite wird nach dem Installationsverzeichnis gefragt:



Hier wurde von der Installationsroutine Nextcloud vorgegeben aber ich habe hier einen Punkt eingetragen, damit - wie im Hilfstext zu lesen - Nextcloud in unserem Hauptverzeichnis vom Webserer installiert wird.

Wer Nextcloud in einem Unterverzeichnis installieren möchte, weil er im Hauptverzeichnis andere Sachen haben möchte und Nextcloud nur als Teil, kann hier ein gewünschtes Unterverzeichnis angeben.
Ich habe mich eben für den Punkt, also das Hauptverzeichnis, entschieden, da Nextcloud die Hauptanwendung sein wird.

Weiter geht es also mit Next.

Ein paar Sekunden passiert scheinbar nichts aber das täuscht, da der Wizzard einiges herunterläd und entsprechend anpasst.
Lediglich am Browser kann man sehen, dass sich etwas tut (beim MS Edge z.B. dreht sich links oben der kleine Kreis).

Dann erscheint die Meldung, dass Nextcloud installiert ist:



Als nächstes fordert der Wizzard weitere Daten:



Somit geben wir also die benötigten Daten ein.

Als erstes wird nach dem Administratoraccount gefragt.
Als Name sollte man nicht unbedingt "Admin" oder "Administrator" eingeben, denn danach wird bei einem Hackingversuch meist zuerst gesucht.
Da wir hier freie Namenswahl haben, denken wir uns irgendwas aus, was wir uns gut merken können.
Dazu folgt direkt darunter ein komplexes Passwort, notfalls bitte aufschreiben.
Komplex ist deshalb wichtig, da Ihr sicherlich das Ganze später auch vom Internet aus erreichbar machen wollt.
Hier empfehlen sich - wie immer - Groß/Kleinschreibung, Zahlen und Sonderzeichen.
Ich habe hier in der Tat für die Anleitung den Benutzernamen Admin genommen, den man sicherlich später des öfteren noch sehen wird aber wie gesagt, das dient nur der Anleitung und sollte von Euch nicht verwendet werden.

Sind die Daten des Administrators eingegeben worden, folgt darunter der Pfad, wo später alle unsere Daten von Nextcloud abgelegt werden sollen.

Hier eine wichtige Info dazu:

Hinweis:
Der vorgegebene Standardpfad liegt im öffentlichen Webseitenbereich, was Nextcloud später auch u.U. als Warnung ausgibt.
Man kann zwar später auch das Verzeichnis der Daten und der Datenbank ändern, das ist aber mit einem größeren Aufwand verbunden.
Daher empfehle ich hier gleich das endgültige Verzeichnis anzugeben.
Das Ganze dient einer erhöhten Sicherheit.

Ich habe hier also /var/www/data genommen, denn dieses Verzeichnis liegt eine Ebene unter dem öffentlichen Webseitenbereich.
Aber das ist nur ein Beispiel.

Das dazu nötige Verzeichnis haben wir bereits weiter oben schon angelegt und angepasst.

Wer hier einen anderen Pfad oder gar ein anderes Gerät (USB Stick oder SSD Platte) nutzen möchte, muss das vorab erst anmelden, konfigurieren und den neuen Pfad erstellen und freigeben.

Jetzt kommen wir zur Datenbank.
Als Datenbankbenutzer können wir entweder den bereits zuvor angelegten Datenbankadministrator mit dem vergebenen Passwort eingeben oder es muss vorab ein entsprechender Benutzer mit allen passenden Rechten in phpMyAdmin erstellen, wenn man diesen Nutzer extra haben möchte.
Ich habe mich für den bereits bestehenden Datenbankadministrator entschieden, wobei hier aber gesagt sei, dass dieser Rechte auf alle Datenbanken hat.
Wer sicher gehen möchte, legt vorab einen eigenen Benutzer an, der nur Rechte auf die Nextcloud Datenbank hat.
Unter dem Benutzernamen ist dann entsprechend das zugehörige Passwort einzugeben.

Unter dem Datenbankbenutzer für Nextcloud folgt die Eingabe des Namens der Datenbank.
Hier kann man frei eingeben, was man möchte.
Die Datenbank muss vorab nicht erstellt worden sein, sondern wird automatisch vom Wizzard angelegt.
Dann wird der Datenbankserver (hier localhost) angegeben.
Wer den Raspberry Pi auch als Datenbankserver nutzt (sehr zu empfehlen), übernimmt hier die Vorgabe localhost und gibt direkt dahinter noch den Port an, den der Server nutzen soll.
Da ich den Standardport nutze, lautet bei mir der Eintrag also localhost:3306, da 3306 in der Regel der Datenbankport ist.
Natürlich kann man hier auch wieder frei wählen, muss das dann aber immer berücksichtigen und darf keine bereits belegte Ports überschreiben.

Zu guter Letzt klicken wir auf Installieren.

Nun dreht unten eine Weile ein Kreis, der die zuvor empfohlenen Apps installiert, danach schaltet die Anzeige um auf folgendes Bild:

Info:
Warum empfehle ich die empfohlenen Apps zu überspringen ??

Früher habe ich immer die empfohlenen Apps immer übernommen und die (nicht funktionierende, da für andere Prozessoren gedachte) Version von Nextcloud Office deinstalliert und die passende Version (für ARM64 wie z.B. Raspberry Pi) installiert.

Auch die in den anderen Kreisen markierte Apps Mail und Talk habe ich früher dann wieder entfernen müssen.

Mail bringt mir nichts, da der Pi dann auch noch als Mailserver konfiguriert werden müsste, was prinzipiell auch gehen würde, jedoch ist das nicht überall sinnvoll oder möglich.
Wer seinen Pi schon für Mail nutzt oder zukünftig nutzen möchte, kann diese App jederzeit nachinstallieren.
Diese Mailapp ersetzt aber nicht normales Mailing auf einem Pi.

Talk ist eine Kommunikationssoftware wie z.B. Teams oder Zoom von den entsprechenden Firmen.
Beim Raspberry Pi 4B habe ich jedoch keine so guten Erfahrungen gemacht.
Waren z.B. mehr als 2 bis 3 Nutzer gleichzeitig in einer Videokonferenz, stoppte das ganze System.
Das könnte natürlich auch an anderen Faktoren gelegen haben (Internetbandbreite, RAM, ....) und evtl. mit dem Pi 5 besser sein, jedoch habe ich das nicht mehr getestet und nutze für solche Anwendungen etablierte Anbieter direkt und ohne den Pi.

Hier wird also nichts weiter installiert und man kann sich später die gewünschten Apps selbst raussuchen.

Auch hier ist etwas Geduld gefragt und danach erscheint dann endlich die Startseite von Nextcloud:



Dort klicken wir uns dann über das X oben rechts im vorderen Fenster oder den Pfeil ganz rechts am Fensterrand in der Mitte durch einige Informationen, am Ende auf Beginne mit der Nutzung von Nextcloud, bis wir die Hauptansicht erreicht haben:



In der aktuellen Installation ist nun ein sogenanntes Dashboard integriert mit einer einstellbaren Übersicht.
Wenn man auf das Ordnersymbol oben links klickt, erscheint wieder die bekannte Verzeichnisübersicht:



Jetzt müssen wir noch die ganz oben konfigurierte Cache Funktion (Redis & Co.) in die Nextcloud Konfiguration eintragen.
Das wird wieder in der Kommandozeile gemacht.
Dabei benötigen wir wieder das oben generierte Passwort, welches ich - wie oben genannt - im Notepad++ in Windows abgelegt habe:

Code: Alles auswählen

sudo nano /var/www/html/config/config.php

Dort scrollen wir ans Ende zu den letzten beiden Zeilen

Code: Alles auswählen

  'installed' => true,
);

und fügen folgenden Code dazwischen ein:

Code: Alles auswählen

....
  'memcache.local' => '\OC\Memcache\APCu',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array(
     'host'     => '/var/run/redis/redis-server.sock',
     'port'     => 0,
     'password' => 'c03d914786edf0161b5bad0180d789634acc39cd310cc1dee1cc395e3dbc76ee',
     'timeout'  => 0.0,
  ),

Und wenn wir schon dabei und in dieser Datei sind, kommen noch folgende Zeilen direkt darunter:

Code: Alles auswählen

  'default_language' => 'de',
  'default_locale' => 'de_DE',
  'default_phone_region' => 'DE',

Die ersten beiden Zeilen stellen Deutsch als Standardsprache ein.
Ansonsten würden auch alle neuen Benutzer Englisch als Sprache voreingestellt bekommen.
Die letzte Zeile Stellt die Telefonregion auf Deutsch ein, was sonst bei Fehlen dieser Zeile später zu einer Fehlermeldung führt.

Das Ganze sieht fertig dann so aus:

Code: Alles auswählen

....
  'installed' => true,
  'memcache.local' => '\OC\Memcache\APCu',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array(
     'host'     => '/var/run/redis/redis-server.sock',
     'port'     => 0,
     'password' => 'c03d914786edf0161b5bad0180d789634acc39cd310cc1dee1cc395e3dbc76ee',
     'timeout'  => 0.0,
  ),
  'default_language' => 'de',
  'default_locale' => 'de_DE',
  'default_phone_region' => 'DE',
);

Das .... bedeutet nur, dass darüber weitere Zeilen sind.

Dann speichern und verlassen die Datei wieder.

Damit ist erst einmal die generelle Installation abgeschlossen.

Da wir die Installation auf einem Raspberry Pi durchgeführt haben, haben wir natürlich auch die Kontrolle über das gesamte System (anders als bei manchem Webspaceprovier) und stellen zuerst die Hintergrundaufgaben auf Cron um, da hier dann in vordefinierten Zeiträumen das Sytsem Aufgaben erledigen kann, die sonst immer erst bei Aufruf der Webseite durchgeführt würden.
Dies wäre dahingehend nachteilig, da sich bei einigen Änderungen und Aufgaben einiges bei der Anzeige der Webseite verzögert würde.
Wer Hintergrundaufgaben per Cron ausführen kann, sollte diese Chance nutzen.

Hierfür legen wir einen Cron Eintrag an, damit (wie empfohlen) die Aufgaben alle 5 Minuten ausgeführt werden.
Dazu muss ein Eintrag angelegt werden:

Code: Alles auswählen

sudo crontab -u www-data -e

Es öffnet sich unser Standard Editor nano mit einigem Text als Inhalt.

Dort scrollen wir ganz nach unten und fügen folgende Zeile ans Ende ein:

Code: Alles auswählen

*/5 * * * * php -f /var/www/html/cron.php > /dev/null 2>&1

Das sieht dann in etwa so aus:

Hinweis:
Damit Cron in der aktuellen Version funktioniert, muss eine Datei angepasst werden, da sonst die Ausführung mit einer Fehlermeldung verhindert wird.

Getestet werden kann das, indem man folgenden Befehl eingibt:

Code: Alles auswählen

sudo -u www-data php /var/www/html/cron.php

Unter Umständen (oder eigentlich ziemlich sicher) erfolgt folgende Fehlermeldung:

Code: Alles auswählen

pi@raspberrypi:/ $ sudo -u www-data php /var/www/html/cron.php
OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

Dies beheben wir durch eine Bearbeitung einer Datei:

Code: Alles auswählen

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

Darin tragen wir die Zeile apc.enable_cli=1 am Ende ein und die ganze Datei sieht dann so aus:

Code: Alles auswählen

extension=apcu.so
apc.enable_cli=1

Wenn wir nun erneut obigen Cron Befehl eingeben, sollte die Fehlermeldung weg sein.

Sollte der erneute Cron Befehl "hängen", per <STRG><C> abbrechen und erneut starten, dann sollte er wieder funktionieren.

Nun prüfen wir in der Konfiguration und Funktion von Cron um, indem wir rechts oben auf die Einstellungen klicken:



Dann im erscheinenden Menü rechts auf Grundeinstellungen:



Im folgenden Fenster sollte nun Folgendes zu sehen sein:



Über den Croneinstellungen sollte ein grüner Hinweis stehen, der die letzte Ausführung innerhalb der letzten 5 Min. bestätigt.
Ist der Hinweis rot und die Zeit ist über 5 Min., stimmt irgend etwas nicht und man sollte die Croneinstellungen nochmal prüfen.

Info:
Wer nicht vor hat, Nextcloud mit einer eigenen (Sub)Domain im Internet zugänglich zu machen und dies nur Zuhause im eigenen Netz nutzen möchte, kann den folgenden Punkt mit der Verschlüsselung überspringen und weiter mit Punkt
Konfiguration auf Warnhinweise und Probleme prüfen und ggf. beheben
fortfahren.

Zu beachten ist dann, dass später bei den Warnungen die fehlende Verschlüsselung bemängelt wird, was aber dann ignoriert werden kann, wenn Nextcloud tatsächlich nur rein intern benutzt wird und keinen Zugriff auf das Internet bekommt.


Verschlüsselung mit Let´s Encrypt Zertifikaten
Als Nächstes kümmern wir uns um die Verschlüsselung, da wir sicherlich auch aus dem Internet darauf zugreifen möchten.

Damit der Apache Webserver auch Verschlüsselung per SSL anbieten kann, muss dieses erst aktiviert werden:

Code: Alles auswählen

sudo a2enmod ssl

Nach der kurzen Konfiguration müssen wir den Apachen diese Änderung neu einlesen lassen:

Code: Alles auswählen

sudo service apache2 reload

Im Prinzip könnten wir jetzt unser Nextcloud per https, also verschlüsselt, aufrufen aber sämtliche moderne Browser verweigern die Anzeige fehlerhafter und/oder selbstsignierter Verschlüsselungen.

Da es von Let´s Encrypt (LE) kostenlose Zertifikate gibt, die so gut wie von allen modernen Browsern akzeptiert werden, empfehle ich diesen Service zu nutzen, was wir hier im Folgenden auch tun.

Hinweis:
Folgendes muss beachtet/mit einbezogen werden:

Um im Internet (per DSL/Kabel/....) von außen auf den Raspberry Pi zugreifen zu können,

- sollte man einen DynDNS Service nutzen
- eine Portweiterleitung im Router einrichten
- möglichst eine eigene Domain nutzen
- einen Zugriff auf den Port 80 und 443 für Let´s Encrypt ermöglichen

Gerade bei Subdomains von sehr verbreiteten DynDNS Anbietern kann es sein, dass Let´s Encrypt die Ausgabe von Zertifikaten verweigert, da immer nur eine begrenzte Anzahl von Subdomains einer Domain erlaubt sind.

Sollte man keinen kostenlosen DynDNS Anbieter finden, der von LE akzeptiert wird, wäre es eine Möglichkeit, bei einigen Domainanbietern zu schauen, ob diese DynDNS bei ihren Domains anbieten.
Interessant wären da z.B. Strato oder Serverprofis, die bei einigen günstigen Paketen bereits die Konfiguration von DynDNS anbieten.
Sicherlich gibt es noch weitere, jedoch habe ich nur mit diesen beiden Erfahrung, da ich sie selbst genutzt habe oder noch nutze.

Wer Kabelinternet und/oder einen Internetzugang mit DS-Light-Anschluß hat, wird nicht so ohne weiteres von extern auf seinen Raspberry Pi zugreifen können.
Hier sollte man seinen Provider fragen, ob die Möglichkeit zum Freischalten von DualStack besteht.

Zugriffe vom Mobilfunknetz misslingen in den meisten Fällen ebenfalls, da die Anbieter (auch sogenannte LTE Provider) ihren Kunden nur IP Adressen aus dem privaten Adressraum (z.B. 169.x.x.x oder 10.x.x.x) zuweisen, die dann auch noch mit anderen Usern geteilt werden müssen.
Hier ist mir bisher nur ein Weg bekannt, der funktioniert.
Und zwar bietet O2 auf Anfrage an, für einmalig ~50€ Einrichtungsgebühr eine öffentliche IP4 Adresse zu bekommen.
D1 soll angeblich in einigen Tarifen die Möglichkeit des Wechsels per anderer APN auf eine öffentliche IPv4 bieten, jedoch kann ich dazu nichts sagen, da ich keinen Zugrif auf D1 habe.
Bei D2 ist mir nichts bekannt aber D2 Nutzer könnten mal bei Vodafone nachfragen.
Wie es bei IPv6 aussieht, kann ich auch nicht sagen, da die Fritzboxen DynDNS scheinbar nur mit einer öffentlichen IPv4 bedienen können.
Wie es bei anderen Routern aussieht, sorry, keine Ahnung, da bitte selbst recherchieren.

Wie man eine DynDNS Umleitung beim Domainanbieter erstellt und im Router hinterlegt, bitte ich beim jeweiligen Domainanbieter und Routerhersteller zu evaluieren, da dies hier zu weit führen würde.
Im Prinzip ist das kein Hexenwerk und recht einfach zu meistern aber die Vielzahl an Möglichkeiten würde hier den Rahmen sprengen.
Evtl. gehe ich da irgendwann mal getrennt darauf ein.
Es müssen auf jeden Fall die Ports 80 und 443 auf den Raspberry Pi umgeleitet werden, da sonst die Erstellung des Zertifikats nicht funktioniert.
Wichtig ist mir, falls DynDNS korrekt läuft, die Weiterbearbeitung in unserem Raspberry Pi.

certbot ist der Service, der sich um die LE Zertifikate kümmert.

Da certbot-auto (aus einigen Anleitungen) scheinbar Probleme mit diversen Linux Distributionen macht, wird diese Vorgehensweise der Installation empfohlen:

Code: Alles auswählen

sudo apt install certbot python3-certbot-apache -y

Da wir weiter oben für den Apachen SSL aktiviert haben, befindet sich auch für den verschlüsselten Bereich ein VirtualHost in der Konfiguration, welchen wir noch aktivieren müssen, da bis jetzt nur der unverschlüsselte Teil als aktiv eingetragen wurde.

Bevor wir diesen VHost aktivieren, tragen wir noch die endgültige Domain als Servernamen ein, damit LE nachher die richtige Domain erkennt und übernimmt.

Hinweis:
Alle in der Anleitung als sub.domain.tld genannten Domains sind durch die eigene (Sub)Domain zu ersetzen !!
sub.domain.tld ist hier nur ein Platzhalter.

Dazu öffnen wir die entsprechende VHost datei:

Code: Alles auswählen

sudo nano /etc/apache2/sites-available/default-ssl.conf

Der Anfang sieht in etwa dann so aus:

Code: Alles auswählen

<VirtualHost *:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html
....

Über den ServerAdmin tragen wir nun die endgültige (Sub)Domain ein und darunter etwaige Aliase:

Code: Alles auswählen

<VirtualHost *:443>
        ServerName sub.domain.tld
        ServerAlias nextcloud
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html
....

Die gleichen Änderungen machen wir der Vollständigkeit halber auch in der Port 80 VHost (also den unverschlüsselten Teil):

Code: Alles auswählen

sudo nano /etc/apache2/sites-available/000-default.conf

Auch hier den Servernamen und Aliase nachtragen.

Nun aktivieren wir den VHost default-ssl.conf.
Dafür wechseln wir in das Verzeichnis, welche die ganzen vordefinierten VHosts beinhaltet:

Code: Alles auswählen

cd /etc/apache2/sites-available

Es gibt zwei Verzeichnise:
Eins für die eigentlichen VHosts (sites-available) und
eins, welches die Links beinhaltet (sites-enabled), welche auch wirklich aktiv sind.

Aktiviert wird diese SSL Version mit folgendem Befehl:

Code: Alles auswählen

sudo a2ensite default-ssl.conf

Damit wird im Verzeichnis sites-enabled der Link erstellt, damit diese Konfiguration auch geladen wird.

Danach wird die Apachekonfiguration neu eingelesen:

Code: Alles auswählen

sudo systemctl reload apache2

Jetzt starten wir die Erstellung eines LE Zertifikats:

Code: Alles auswählen

sudo certbot --apache

Zuerst werden wir nach der Mailadresse gefragt, die korrekt eingegeben werden muss und natürlich aktiv sein sollte, da LE dort hin weitere Hinweise mailt.

Dann akzeptieren wir die TOS (Nutzungsbedingungen) mit Y für Ja.

Die dann folgende Frage für die Teilung unserer Mailadresse mit der Electronic Frontier Foundation beantworten wir mit N für Nein.

Da wir oben im VHost die (Sub)Domain eingetragen haben, erkennt LE diese und bietet sie als Auswahl an, was wir mit der Nummer davor bestätigen.
Sind mehrere (Sub)Domains eingetragen, kann man diese per Nummern oder alle auf einmal übernehmen lassen.
Ich drücke hier einfach <ENTER>, dann übernimmt er mir automatisch diese eine angezeigte (Sub)Domain.

Nun wird das Zertifikat erstellt.

Es folgt die restliche Konfiguration, bei der die Zertifikate und die Umleitung auf https angepasst werden.

Doch bevor wir nun unsere verschlüsselte Nextcloud Seite abrufen können, muss noch in der Konfigurationsdatei die (Sub)Domain als vertrauenswürdige Domain nachgetragen werden:

Code: Alles auswählen

sudo nano /var/www/html/config/config.php

In diesem Block

Code: Alles auswählen

  'trusted_domains' =>
  array (
    0 => 'nextcloud',
  ),

fügen wir unten einfach folgende Zeile unter Punkt 1 ein:

Code: Alles auswählen

    1 => 'sub.domain.tld',

Das Ganze sieht dann fertig so aus:

Code: Alles auswählen

  'trusted_domains' =>
  array (
    0 => 'nextcloud',
    1 => 'sub.domain.tld',
  ),

Man kann sich nun per https://sub.domain.tld einloggen und die Seite wird einwandfrei mit gültigem Zitat ohne jegliche Warnhinweise angezeigt.

In der ersten Version dieser Anleitung hat LE noch eine eigene Datei angelegt, um die Umleitung von HTTP zu HTTPS zu ermöglichen.
Diese Umleitung wurde nun direkt in den passenden VHost unten eingetragen und weitere Konfigs befinden sich per Verweis im Verzeichnis /etc/letsencrypt.
Daher muss nun normalerweise keine Verknüpfung mehr geprüft oder angelegt werden.
Die Umleitung hat bei mir jetzt auf Anhieb geklappt.

Test im Browser:

http://sub.domain.tld

muss jetzt automatisch auf

https://sub.domain.tld

umgeleitet werden.
Funktioniert das, geht es weiter in der Konfiguration.

Da das LE Zertifikat nur 90 Tage gültig ist, sollte es rechtzeitig erneuert werden.
Darum kümmert sich aber unser installierter Certbot automatisch, indem er 2x am Tag auf Zertifikate prüft, die in den nächsten 30 Tagen ablaufen.
Diese werden dann ohne unser Zutun erneuert.

Um das zu überprüfen, geben wir Folgendes ein:

Code: Alles auswählen

sudo systemctl status certbot.timer

Herauskommen sollte dies in der Art hier:

Code: Alles auswählen

pi@nextcloud:/ $ sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2023-12-04 16:40:58 CET; 24min ago
    Trigger: Tue 2023-12-05 06:52:30 CET; 13h left
   Triggers: ● certbot.service

Dez 04 16:40:58 nextcloud systemd[1]: Started certbot.timer - Run certbot twice daily.

Kleiner Test, in dem wir eine Erneuerung manuell anstoßen:

Code: Alles auswählen

sudo certbot renew --dry-run

--dry-run bedeutet, dass nicht wirklich das Zertifikat erneuert wird, sondern LE lediglich einen Test durchführt, ob dieser manuelle Updateprozess funktioniert.
Nach der Ausgabe einiger Infos von LE sollte der Erfolg dieses simulierten Updates bestätigt werden, ansonsten hat man ein Problem und sollte danach auf die Suche gehen.
Ein Restart vom Apachen nach dem Update wird automatisch vom Certbot ausgeführt.
Man muss ich also nicht selbst darum kümmern.

Die Erfolgsmeldung sieht in der Regel so aus:

Code: Alles auswählen

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/sub.domainn.tld.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Account registered.
Simulating renewal of an existing certificate for sub.domain.tld

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/sub.domain.tld/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Damit können wir die Verschlüsselung per LE abhaken und weiter an den Feinheiten von Nextcloud arbeiten.

Da wir nun die Konfiguration für verschlüsselten Zugriff eingerichtet haben und nutzen, müssen hier auch die Änderungen eingepflegt werden, die wir im unverschlüsselten Status gemacht haben, z.B. den sichereren FPM/FastCGI Modus, womit auch wieder unsere zuvor konfigurierte Datei php.ini berücksichtigt wird.

Dazu öffnen wir wieder unsere Verschlüsselungs-VHost-Datei:

Code: Alles auswählen

sudo nano /etc/apache2/sites-available/default-ssl.conf

Diese Konfiguration beginnt mit:

Code: Alles auswählen

<VirtualHost *:443>
        ServerName sub.domain.tld
        ServerAlias nextcloud
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html
....

Darin scrollen wir herunter bis zu diesem Abschnitt:

Code: Alles auswählen

        <FilesMatch "\.(?:cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

Direkt darunter fügen wir Folgendes ein:

Code: Alles auswählen

        <Directory /var/www/html>
                Options -Indexes +FollowSymLinks +MultiViews
                AllowOverride All
                Require all granted

                <IfModule mod_dav.c>
                        Dav off
                </IfModule>
        </Directory>
        <FilesMatch \.php$>
                SetHandler "proxy:unix:/var/run/php/php8.2-fpm.sock|fcgi://localhost"
        </FilesMatch>
        <IfModule mod_headers.c>
                Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
        </IfModule>

Damit der mod_headers auch funktioniert, müssen wir diesen auch im Apachen aktivieren:

Code: Alles auswählen

sudo a2enmod headers

Der Teil mit <IfModule mod_dav.c> könnte im Prinzip weggelassen werden, da in der Regel nach dieser Installation das DAV Modul vom Apachen nicht aktiv ist.
Zur Sicherheit wird es aber immer empfohlen, falls man in weiteren Konfigurationen auf dem Raspberry Pi mit anderer Software doch Apache DAV benötigt und deshalb DAV aktiviert wurde.
Nextcloud bringt ein eigenes DAV mit, daher muss es genau für diesen Zweck und nur dafür deaktiviert werden.

Dann starten wir alle wichtigen Services neu:

Code: Alles auswählen

sudo service apache2 reload && sudo service php8.2-fpm reload && sudo service mysql restart

Soweit so gut, kümmern wir uns im nächsten Abschnitt um evtl. vorhandene Probleme und Warnhinweise.


Konfiguration auf Warnhinweise und Probleme prüfen und ggf. beheben
Als Nächstes sehen wir uns die Übersicht der Nextcloud Installation/Konfiguration an, um zu prüfen, ob noch weitere Schritte notwendig sind:



Auf der darauf folgenden Seite waren bei mir noch folgende Fehler noch zu sehen:



Zu Punkt 1:
Um diese Fehler kümmern wir uns gleich.

Zu Punkt 2: (kein Fehler)
Hier sehen wir die aktuell installierte Version.
Der Satz unter der Versionsangabe sagt aus, dass wir bereits die aktuelle Version installiert haben.
Andernfalls wird uns hier ein Update angezeigt.
Bei der letzten Bearbeitung dieser Anleitung war diese Version aktuell und kann später durchaus höher sein.

Nun aber zu den auf dem Bild angezeigten Hinweise:

• Du hast deine E-Mail-Serverkonfiguration noch nicht festgelegt oder überprüft. Bitte gehe zu den Grundeinstellungen , um sie einzustellen. Verwende anschließend die Schaltfläche "E-Mail senden" unterhalb des Formulars, um deine Einstellungen zu überprüfen.
• Dem Modul php-imagick fehlt die SVG-Unterstützung. Für eine bessere Kompatibilität wird empfohlen, es zu installieren.

Gehen wir nun nach und nach die beiden Punkte durch und daher zuerst diesen:

Du hast Deine E-Mail-Serverkonfiguration noch nicht festgelegt oder überprüft. Bitte ....

Hier weißt das System darauf hin, dass noch keine Mailkonfiguration eingerichtet wurde.
Wer Nextcloud ohne Mailing nutzen möchte, kann diesen Punkt selbstverständlich ignorieren.
Da Mailing aber u.U. doch sehr hilfreich sein kann, habe ich das bei mir eingerichtet.

Info:
Wer auf Nextcloud kein Mailing nutzt, kann diese Meldung ignorieren und mit der nächsten Meldung weiter machen.

Für diese Mailkonfiguration rufen wir wieder die Grundeinstellungen auf:



Auf der folgenden Seite scrollen wir weiter runter bis zu den Mailservereinstellungen:



Dort geben wir die Daten ein, die unser Mailprovider (oder wer einen eigenen Server betreibt, die Daten des eigenen Servers) ein und klicken anschließend auf E-Mail senden.

Für die Änderung der Einstellungen werden wir nach unserem Adminpasswort gefragt, welches wir dann eingeben und Bestätigen.

Bevor wir aber eine Testmail absenden können, erscheint nach dem Sendeversuch folgender Hinweis:

Du musst Deine Benutzer-E-Mail-Adresse festlegen, bevor Du Test-E-Mails senden kannst. Gehe dazu zu https://sub.domain.tld/index.php/settings/user.

Da der angezeigte Link auf Eurer Seite nicht anklickbar ist, gehen wir im linken Menü auf Persönliche Informationen:



Dort sehen wir in der rechten Hälfte das Maileingabefeld, in das wir unsere Mailadresse eintragen.
Natürlich können hier auch gleich alle anderen Profilfelder ausgefüllt werden.



Jetzt gehen wir wieder zurück zu den Grundeinstellungen zur Mailserverkonfiguration und klicken erneut auf den Button E-Mail senden.

Hat alles geklappt, sollten wir in unserem Postfach unseres Mail-Clients eine Testmail vorfinden.

Und Nun zur nächsten Meldung in der obigen Liste:

Dem Modul php-imagick fehlt die SVG-Unterstützung. Für eine bessere Kompatibilität wird empfohlen, es zu installieren.

Durch etwas Recherche im Internet kam immer wieder folgender Befehl als Lösungsvorschlag:

Code: Alles auswählen

sudo apt install libmagickcore-6.q16-6-extra -y

Dabei wurden neben SVG auch noch weitere andere Formate installiert.
Diesen Befehl habe ich laufen lassen und ein erneutes Drücken im Browser von <F5> beseitigte auch die letze Meldung.

Somit sollte Eure Übersicht in den Einstellungen nun so aussehen:

Hinweis:
Diese beiden oben gezeigten Fehler-/Warnungs-Bearbeitungen sollen nur als Beispiel dienen, wie man in etwa vorgeht.
Bei jeder Installation, Konfiguration und/oder Nextcloud Version können andere Meldungen erscheinen.
Sollte das bei Euch so sein, dann kann man vieles durch Googeln herausfinden, da oft viele andere auch schon den einen oder anderen Hinweis hatten.
Ihr könnt auch hier unter der Anleitung das eine oder andere Problem diskutieren aber ich bitte um Nachsicht, wenn nicht alles sofort und/oder überhaupt gelöst werden kann, da wir hier nicht alle Möglichkeiten kennen oder behandeln können.
Trotzdem wäre es schön, wenn Euch diese Anleitung hilft und/oder Anreize vermittelt.
Ich bitte auch um Hinweise, falls Ihr Fehler findet und/oder was ergänzt haben möchtet.

Damit ist die Nextcloud Installation soweit im Wesentlichen konfiguriert.
Sollten Probleme oder Fehler in der Anleitung vorhanden sein, würde ich mich für Infos freuen, am Besten als Beiträge unter dieser Anleitung.

Auf weitere Einstellungen in der Nextcloud Webkonfiguration gehe ich erstmal nicht weiter ein, denn ich denke, jeder stellt sich jetzt Nextcloud auf seine Bedürfnisse ein, legt Verzeichnisse an, usw ....


Nextcloud Office / Collabora Online installieren
Die beliebte Online-Office-Anwendung nennt sich in der aktuellen Nextcloud Version Nextcloud Office.
Dabei handelt es sich um das bekannte Collabora Online, welches im Prinzip das Libre Office als Server Version darstellt.

Hinweis:
Zur Erinnerung:
Da Nextcloud Office / Collabora Online in der ARM Version nur als 64Bit Version existiert, muss auch das Raspberry OS unbedingt in der 64Bit Version installiert sein, alles andere Funktioniert nicht !!

Wir rufen nun wieder oben rechts das Menü auf und klicken den Punkt Apps an



und installieren wir den korrekten Server (ARM64).
Dafür klicken wir links im Menü zuerst auf Büro & Text:



Rechts werden diverse Apps eingeblendet, wobei wir hier weiter runter scrollen, bis wir zum passenden Document Server kommen.
Ganz wichtig dabei ist, dass wir diesen installieren: Collabora Online - Built-in CODE Server (ARM64)
Hinten am Namen muss ARM64 stehen, denn die anderen Server funktionieren auf dem Raspberry Pi nicht.

Installiert wird nun mit einem Klick auf Herunterladen und aktivieren.

Nun vergeht eine Weile, bis die App installiert ist aber wenn der drehende Kreis weg ist, ist der Server installiert.
Auf jeden Fall taucht der Server in der installierten Appliste auf.

Hinweis:
Solltet Ihr in eine TimeOut Fehlermeldung laufen, probiert das Herunterladen und Aktiviren einfach nochmal.
Bei mir hat es beim 3. Mal funktioniert, verm. weil der bereits heruntergeladene Teil übersprungen wurde.
Bei der Suche nach Lösungen gab es viele Hinwise aber letztendlich habe ich es so hinbekommen.

Nun benötigen wir noch die Schnittstelle, die die Verbindung vom CODE Server zum Browser herstellt.
Scrollt dazu weiter runter und installiert noch das Paket Nextcloud Office:



Wenn wir nun in die Verwaltungs-Einstellungen oben rechts gehen und anschließend im linken Menü auf Nextcloud Office klicken,



erscheint folgende Seite:

Hinweis:
Bitte unbedingt beachten !!
Auch wenn (wie auf dem Bild über diesem Textkasten zu sehen) die mit dem Pfeil markierte Option bereits aktiviert ist und der Server mit einem grünen Symbol als erreichbar angezeigt wird,
BITTE GENAU DIESE OPTION NOCHMALS ANKLICKEN !!

Hier scheint es seit langem irgendwie ein Problem mit der korrekten Zuweisung des internen Servers zu geben, denn es wird zwar angezeigt, dass diese Option aktiv wäre aber scheinbar nur in der Anzeige.

Dies kann man auch ganz gut kontrollieren, denn wenn man eben auf diese bereits aktivierte Option klickt, passiert Folgendes, wie im nachfolgenden Bild zu sehen ist:



Wie man in der rot markierten Ellipse sieht, dreht sich der Kreis in dieser Option bei Neuen Server einrichten eine Weile und alle Optionen erscheinen solange grau.
Erst nach dieser ein paar Sekunden dauernden Rekonfiguration funktioniert der Server erst !!
Klickt man erneut auf diese Option, geht es ruckzuck und daran erkennt man, dass der Server auch richtig zugewiesen wurde.

Ohne diese erneute Zuweisung werden später keine Dokumente zur Bearbeitung geöffnet, sondern nur zum Download angeboten.
Daher ist dieser Textblock momentan unbedingt zu beachten !!

Weiter darunter folgende Optionen sollten nach eigenen Vorstellungen konfiguriert werden.

Ich habe nun zwei Dokumente mit MS Office 2021 erstellt, 1x Word (DOCX) und 1x Excel (XLSX) und in Nextcloud hochgeladen.
Beide Dokumente habe ich auf die Schnelle vor dem Hochladen mit dem Text Dies ist ein Test. versehen.

Hier die beiden Dokumente in der Dateiübersicht:



Klickt man nun auf eine der beiden Testdateien und der Server arbeitet korrekt, wird statt dem sonst üblichen Download in der Bildschirmmitte kurz das Laden der angeklickten Datei angezeigt.

Hier im Beispiel die Word Datei Dies ist ein Test.docx.

Und so sollte das Dokument geöffnet und bearbeitbar aussehen:

Text:


Tabelle:



Damit ist die Installation mit Nextcloud und Collabora (auch Nextcloud Office genannt) abgeschlossen und ich wünsche viel Erfolg mit diesem interessanten 64Bit System auf dem Raspberry Pi (4B mit min. 4GB empfohlen).

Dir hat die Anleitung geholfen und Du möchtest das Forum unterstützen ??
Dann hast Du hier die Möglichkeit, einen kleinen - von Dir frei wählbaren - Obolus zu spenden:

Die Abwicklung erfolgt über PayPal.
Vielen Dank und weiterhin viel Spaß im Forum.

Fortsetzungen, Korrekturen, Änderungen möglich ....

Copyright © 2024 by RasPiFun.de

[Outi]

Anleitung und Bilder auf aktuelles Image (Bookworm) angepasst.

[Outi]

Modul php8.2-bz2 hinzugefügt (für Nextcloud 28 benötigt) und Speichergrenze erhöht (in php.ini).

[lmsks]

Hallo,
wie sollte ich vorgehen wenn ich mariadb upgraden muß?
Ich bin dieser Anleitung erfolgreich im Februar 2023 gefolgt.
Habe dieses Jahr auf php 8.2 gewechselt
jetzt will Nextcloud Hub 9 (30.0.2)upgrade mariadb von 10.5.21 auf Version von Nextcloud wird MariaDB >= 10.6 und 11.4 <= empfohlen.

[Outi]

Hallo lmsks,

die Frage ist, welches Raspberry Pi OS Du auf dem Pi hast.
Bei der Bookworm Version ist das die aktuelle MariaDB Version: Ver 15.1 Distrib 10.11.6-MariaDB

Evtl. wäre ein kompletter Upgrade aller Komponenten interessant aber das ist natürlich mit einem hohen Aufwand verbunden.
Auf der MariaDB Webseite gibt es zwar einen Konfigeditor, jedoch wird armhf leider nicht unterstützt.

Ich habe im Moment auch keine alte Installation zum testen aber nachdem Du ein Backup Deiner Datenbanken gemacht hast, kannst Du mal folgenden Befehl ausführen, um evtl. eine neuere Version zu erhalten:

Code: Alles auswählen

sudo mariadb-upgrade

Gibt das Tool aus, das Du bereits die aktuellste Version installiert hast, bietet es Dir noch die Option -force an.
Jedoch hat das bei mir keinen Unterschied gemacht, es wurde lediglich die bereits installierte Version neu eingelesen.

Um auf höhere Versionen zu bekommen, gibt es Zwei Wege:

Aber zuerst Backup machen !!

- Raspberry Pi OS komplett upgraden (z.B. Bullseye auf Bookworm) / ziemlich gefährlich und ggf. sehr aufwändig
- Sourcen zu MariaDB ändern/hinzufügen und alte Version deinstallieren, neue Version installieren.

Hast Du schon ein Update des OS gemacht ??

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Evtl. reicht das ja schon.

[lmsks]

Hallo,
habe nicht mit einer Antwort gerechnet.Deshalb habe ich erst jetzt geschaut.
Auf mariadb habe ich mal diesen Befehl versucht.:
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version = "mariadb-10.6"
Hat mir aber bei jeder Version gesagt, das diese nicht zur verfügung steht.
# [info] Checking for script prerequisites.
# [warning] Found existing file at /etc/apt/sources.list.d/mariadb.list. Moving to /etc/apt/sources.list.d/mariadb.list.old_10
# [error] MariaDB Server version = is not valid.
# The latest MariaDB Server versions are:
# 10.5.27 10.6.20 10.11.10 11.2.6 11.4.4 11.6.2 11.7.1
#
# More information on MariaDB releases is available at:
# https://mariadb.com/kb/en/release-notes/
Dann diesen:
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash
der hat mir dann

https://dIm.mariadb.com/repo/mariadb-se ... epo/debian bullseys debian

in die mariadb.list geschrieben.

Habe es mal auf meine Testversion installiert.
Hatte auch dann funktioniert.

Bin mir aber nicht sicher ob das so sein sollte?

[Outi]

Hallo lmsks,

den hier ursprünglich stehenden Beitrag habe ich wieder gelöscht, da ich ihn auf einem VPS Server getestet hatte (ebenfalls Debian).
Im nächsten Beitrag habe ich das Ganze nochmal mit einem Pi 4B auf dem originalen Raspberry Pi OS (Legacy) 64Bit Lite / Bullseye getestet.

Bitte aber unbedingt beachten:
Bei solchen Aktionen immer vorher Backups anlegen, wie z.B. die Datenbanken und Konfigurationsdateien.
Auch die MariaDB Website weißt ausdrücklich darauf hin.

[Outi]

So, ich habe mal eben schnell einen Pi 4B mit Bullseye (Legacy OS 64Bit Lite) mit dem dort aktuellen MariaDB installiert:

Code: Alles auswählen

pi@pi4b:~ $ lsb_release -d
Description:    Debian GNU/Linux 11 (bullseye)

Hier noch die zu der Debian Version standardmäßig installierte MariaDB Version:

Code: Alles auswählen

pi@pi4b:~ $ mariadb --version
mariadb  Ver 15.1 Distrib 10.5.26-MariaDB, for debian-linux-gnu (aarch64) using  EditLine wrapper

Also zuerst MariaDB gestoppt:

Code: Alles auswählen

sudo service mysql stop

Curl nachinstalliert:

Code: Alles auswählen

sudo apt install curl -y

Zum Test MariaDB 10.6(.2) eingegeben:

Code: Alles auswählen

sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.6"

Hat scheinbar funktioniert, es kamen keine Fehler:

Code: Alles auswählen

pi@pi4b:~ $ sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.6"
# [info] Checking for script prerequisites.
# [info] MariaDB Server version 10.6 is valid
# [info] Repository file successfully written to /etc/apt/sources.list.d/mariadb.list
# [info] Adding trusted package signing keys...
# [info] Running apt-get update...
# [info] Done adding trusted package signing keys

Wieder die installierten Pakete aktualisiert:

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Dann läuft jede Menge Zeug durch.

Danach aufräumen:

Code: Alles auswählen

sudo apt autoremove -y

3 Pakete wurden entfernt, die wohl mit MariaDB nix zu tun haben.

Jetzt MariaDB wieder starten:

Code: Alles auswählen

sudo service mysql start

Und hier die Versionsabfrage:

Code: Alles auswählen

pi@pi4b:~ $ mariadb --version
mariadb  Ver 15.1 Distrib 10.6.20-MariaDB, for debian-linux-gnu (aarch64) using  EditLine wrapper

Die Sache hat also funktioniert.

Doch nun MariaDB für weitere Tests stoppen:

Code: Alles auswählen

sudo service mysql stop

Nun wollte ich herausfinden, was mir max. angeboten wird und ich habe eine nicht existente Version eingegeben:

Code: Alles auswählen

pi@pi4b:~ $ sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-88.8"
# [info] Checking for script prerequisites.
# [warning] Found existing file at /etc/apt/sources.list.d/mariadb.list. Moving to /etc/apt/sources.list.d/mariadb.list.old_2
# [error] MariaDB Server version 88.8 is not valid.
#         The latest MariaDB Server versions are:
#             10.5.27 10.6.20 10.11.10 11.2.6 11.4.4 11.6.2 11.7.1
#
#         More information on MariaDB releases is available at:
#             https://mariadb.com/kb/en/release-notes/

Also nehme ich jetzt auch hier die Version 11.7(.1):

Code: Alles auswählen

pi@pi4b:~ $ sudo curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-11.7"
# [info] Checking for script prerequisites.
# [warning] Found existing file at /etc/apt/sources.list.d/mariadb.list. Moving to /etc/apt/sources.list.d/mariadb.list.old_3
# [info] MariaDB Server version 11.7 is valid
# [info] Repository file successfully written to /etc/apt/sources.list.d/mariadb.list
# [info] Adding trusted package signing keys...
# [info] Running apt-get update...
# [info] Done adding trusted package signing keys

Lief also auch durch.

Nun wieder alles aktualisieren:

Code: Alles auswählen

sudo apt update && sudo apt full-upgrade -y

Dabei eine Meldung erhalten:

Code: Alles auswählen

Warning: The unit file, source configuration file or drop-ins of mariadb.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Dann machen wir das halt (aber nur, wenn wir auch - wie hier - dazu aufgefordert werden):

Code: Alles auswählen

sudo systemctl daemon-reload

Noch die unnötigen Backupdateien löschen (wegen der Meldungen in zukünftigen Backups):

Code: Alles auswählen

sudo rm /etc/apt/sources.list.d/*.old*

Ein Blick in die aktuelle Datei mariadb.list:

Code: Alles auswählen

# MariaDB Server
# To use a different major version of the server, or to pin to a specific minor version, change URI below.
deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/mariadb-server/11.7/repo/debian bullseye main

# MariaDB MaxScale
# To use the latest stable release of MaxScale, use "latest" as the version
# To use the latest beta (or stable if no current beta) release of MaxScale, use "beta" as the version
deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/maxscale/latest/apt bullseye main

Sieht gut aus.

Checken, ob MariaDB gestartet ist (war bei mir), andernfalls wieder starten:

Code: Alles auswählen

sudo service mysql start

Gegencheck:

Code: Alles auswählen

pi@pi4b:~ $ mariadb --version
mariadb from 11.7.1-MariaDB, client 15.2 for debian-linux-gnu (aarch64) using  EditLine wrapper
pi@pi4b:~ $

Ob es da einen Befehl generell für neuste Versionen gibt, habe ich nicht gefunden/getestet.
Sicherlich kann man irgendwie auch den Test per ungültiger Version vermeiden, am Besten einfach auf der MariaDB Website nachschauen.

[Outi]

Ach ja,
hier hatte ich 11.7.1 zum Test installiert.
Wenn Nextcloud eine niedrigere Version empfiehlt (laut Deinen Aussagen Version zwischen 10.6 und 11.4),
dann natürlich eine Version im empfohlenen Bereich installieren.

Da ich selbst auf einem anderen Pi 4B Bookworm installiert habe, nutze ich die dort Standard installierte Version 10.11.6.
Melde Dich mal bitte mit der Version, die bei Dir aktuell ausgegeben wird.

[lmsks]

Hallo,
danke für die schnelle und Ausführliche Antwort.
Meine Version ist 10.5.26-MariaDB-0+deb11u2 Debian 11

Werde aber momentan wegen Zeitmangel (Weihnachtszeit) nicht testen können.
Ich bin halt nur Leihe und sowas dauert bei mir immer ziemlich.
Melde mich aber

Grüße lmsks