Ubuntu Server 20.04.1 LTS 64Bit (oder 21.10) + Nextcloud + Collabora Online

[Outi]

History:
17.12.2021 - Upgrade Erfahrung 21.04 auf 21.10 (Impish Indri) ergänzt
19.07.2021 - Anleitung mit Ubuntu Server 21.04 (Hirsute Hippo) 64Bit getestet / Upgrade Erfahrung ergänzt
10.11.2020 - Anleitung mit Ubuntu Server 20.10 (Groovy) 64Bit getestet / Erfahrung ergänzt
31.10.2020 - Weitere kleinere Korrekturen vorgenommen und Anleitung auf Nextcloud 20.x.x aktualisiert
22.10.2020 - Abgeschnittene Optionen korrigiert und Konfigurationsablauf (Redis in Collabora Konfig) in richtige Reihenfolge gebracht
16.10.2020 - Nextcloud über interne Updatefunktion auf 19.0.4 aktualisiert und Collabora Online hinzugefügt
03.10.2020 - Erste Veröffentlichung

Info:
Ziel des Ganzen:

Ubuntu Server 20.04.1 LTS 64Bit (21.10 ist inzw. verfügbar, LTS wird jedoch länger supportet)
Nextcloud (nicht NextcloudPi)
Collabora Online
Collabora Document Server ARM64 <= noch im Beta Stadium !!*
Apache 2.4 als Webserver
APCu und Redis als Cache
phpMyAdmin für kleinere Datenbankzugriffe
PHP 7.4
MariaDB 10.x als Datenbank
FPM/FastCGI Modus
Verschlüsselung per SSL mit Let´s Encrypt Zertifikat
MC (Midnight Commander) für schnelle Shellzugriffe als Dateimanager in der Shell

*Built-in Collabora Online Development Edition (CODE) server for local testing and non-production use.

Das Ganze ist also als Test zu sehen und sollte noch nicht produktiv eingesetzt werden.

Wer möchte, kann diese Anleitung natürlich auch nur zur Installation vom Ubuntu Server 64Bit nutzen.

Hinweis:
Diese Anleitung beruht auf einem 64Bit System, welches nicht auf Raspberry Pi OS basiert (aktuell in 64Bit nur als Beta), sondern auf Ubuntu 20.04.1 LTS Server 64Bit.
Sobald es das Raspberry Pi OS ebenfalls fertig als 64Bit Version gibt, kann natürlich auch das benutzt werden und ich werde es ggf. hier berücksichtigen oder eine Anleitung dazu erstellen.

Dann wäre noch wichtig zu wissen:
Collabora benötigt auf dem Raspberry Pi einen externen Dokumentenserver, der normalerweise entweder nur für Intel/AMD existiert und damit extern laufen muss oder neuerdings gibt es für Nextcloud auch einen internen Server, der momentan auch auf ARM64 läuft und damit ein 64Bit System auf dem Raspberry Pi erfordert.

Wichtig:
Dieser Collabora Online - Built-in CODE Server (ARM64) läuft selbst noch als Beta und ich warne hier deutlich:
Auf eigene Gefahr, auf eigenes Risiko, besser nur auf Testumgebungen installieren und nicht auf Produktivsystemen, keine Haftung durch diese Anleitung oder durch mich !!

Meine Erfahrung:
Die ganze Collabora Konfiguration läuft inzwischen recht "passabel" (aber eben immer noch nicht schnell).
Sobald jedoch mehrere Leute gleichzeitig arbeiten oder die Dokumente größer werden, sollte man sich evtl. doch nach einem externen Server umsehen.
Ob hier ein zweiter Raspberry Pi 4B Sinn macht, habe ich nicht getestet.
Hoffen wir, das die finale Version noch etwas performanter wird.

Zwar läuft das System auch mit Ubuntu Server 20.10 64Bit recht gut, jedoch habe ich festgestellt, das manchmal die Zugriffszeiten in der Shell etwas stocken.
Dafür ist die Weboberfläche von Nextcloud erstaunlich "flott".
Meine letzte Installation habe ich auf eine 500GB USB Platte gemacht.
Hierbei muss das Booten von USB aktiviert werden (am besten 1x Raspbian drauf und im raspi-config entsprechend checken/umstellen) und das Ubuntu Server Image 2010 64Bit ließ sich bei mir nur mit dem Balena Etcher auf die 500er Platte flashen.
Der originale Imager streikte bei mir nach einigen % und der Win32DiskImager erkannte bei mir keine Festplatten.
Der Balena Etcher motzte zwar wegen der Größe aber flashte trotzdem bei mir einwandfrei.
So erspart man sich das SD Flashen und überspielen auf die Festplatte aber wenns nicht anders geht, könnte man auch den Umweg über die SD machen.

Für einen externen Zugriff per DynDNS wird eine funktionierende DynDNS Weiterleitung benötigt, dessen Erstellung hier NICHT beschrieben wird.
Hier wird lediglich die Einbindung und der Betrieb von Let´s Encrypt gezeigt.

Die Forumsoftware hier wandelt in den Codezeilen TABs oft in Leerzeichen um.
Daher bitte im Editor unter Linux am Besten die Leerzeichen wieder durch TABs ersetzen (nicht alle, nur so viele, dass die Einrückung wieder passt).

Info:
Ich habe mich für das oben genannte System entschieden, da es über den Raspberry Pi Imager direkt eine Auswahl zum Flashen gibt.
Damit will ich auch für mich selbst schauen und testen, ob es Sinn macht, in Zukunft auf einem Raspberry Pi 4B (hier die 4GB Variante) sowohl Nextcloud als auch Collabora Online inkl. Dokument Server zu betreiben.
Daher sehe ich diese Anleitung eher als Studie an und weniger als Sofortproduktivsystem, zumal Teile davon eben noch Beta sind.

Diese Anleitung benötigt keine Maus, keine Taststur und keinen Monitor, lediglich für den ersten Boot nach der WLan Konfiguration wird ein Netzwerkkabel zwischen Raspberry Pi und Router benötigt.

Verwendet habe ich einen Raspberry Pi 4B mit 4GB RAM, der headless (also rein übers Netzwerk per SSH) konfiguriert wurde.

Info:
Meine Update Erfahrung von Ubuntu Server 20.10 auf 21.04 (Distrubutionsupgrade):
Generell sind solche großen Updates immer mit Vorsicht zu genießen, da hier mit großer Wahrscheinlichkeit Probleme auftauchen können.
Bereits bei meiner Raspberry Pi OS Anleitung habe ich darauf hingewiesen, dass das u.U. im Desaster enden kann (nicht muss) und man evtl. mehr an den Problemen herrumdoktert als an einer Neuinstallation an Zeit investiert.

Auf alle Fälle gilt wie immer:
BACKUP machen (am besten komplett (Image), damit man im Problemfall das System einfach wieder zurückspielen kann) !!
Wer es also wagen will, sollte dieses Backup unbedingt durchführen !!

Und:
Alles auf eigene Gefahr, eigenes Risiko und keinerlei Haftung durch mich und durch diese Anleitung !!

Ich habe es nun gewagt, bei einer komplett gesicherten und etwas länger bestehenden Installation dieses Upgrade durchzuführen.

Upgrade von Ubuntu Server 20.10 auf 21.04

Der Installationsprozess von Ubuntu wird mit dem folgenden Befehl gestartet:

Code: Alles auswählen

sudo do-release-upgrade

oder

Code: Alles auswählen

sudo do-release-upgrade -d

Unterer Befehl installiert die neuste Developerversion.
Ich habe bei mir zum Test die obere Version getestet.

Die Routine empfiehlt das Upgrade direkt am System (also nicht per SSH), öffnet aber für den Fall, dass man es doch per SSH (fernkonfiguriert) machen möchte, einen weiteren Port, den man alternativ aufrufen können soll, falls die Sitzung mit dem normalen Port nicht mehr funktioniert.
Dieser Port muss selbstverständlich im Router (wo der Pi angeklemmt ist) freigegeben werden.

Wenn man diese Meldung bestätigt hat, startet der Upgradeprozess, der eine Weile dauert (auch von der eigenen Internetgeschwindigkeit abhängig).
Bei mir hatte ich 100/40 MBit auf beiden Seiten (am PC und dort, wo sich der Pi befand).
Daher ging es eigentlich recht gut und hat sich nicht soooo ewig in die Länge gezogen.
Man sollte aber unbedingt bei dem Upgradeprozess dabei bleiben, da man öfter nach Entscheidungen gefragt wird.

Es kam, wie es kommen musste und nach dem kompletten und angeblich erfolgreichen Upgrade lief zuerst einmal gar nix mehr, also das auf dem System installierte Nextcloud quittierte die ganze Aktion mit einem Serverfehler.
Da PHP & Apache aber problemlos liefen, war etwas Suche nötig.
Durch Tests habe ich dann aber herausgefunden, dass MariaDB nicht aktualisiert wurde oder besser gesagt, komplett fehlte.
Keine Log Datei wies auf diesen Umstand hin, ich sah es nur, weil ich mir die Datenbank anschauen wollte und jegliche Zugriffe mit Fehlermeldungen endeten, die aber ebenfalls wenig aussagten, dass MariaDB gar nicht im System lief.

Lösung bei mir: Den Teil der Anleitung mit der Installation der Datenbank MariaDB durchgeführt und alles lief wieder einwandfrei.
Es mussten sogar nicht mal die Datenbankeinträge zurückgespielt werden, da diese von Nextcloud eh separat gesichert wurden.
Aber auch die anderen Anwendungen liefen wieder.

Dies sei also meine Erfahrung mit diesem Upgrade und es sei jedem selbst überlassen, ob er sich das zutraut oder nicht.
Wer eben ein Image der gesamten Installation angelegt hat, kann zumindest auf den Backupstand wieder zurück, falls alles schief gehen sollte.

Upgrade von Ubuntu Server 21.04 auf 21.10

Dieses Upgrade wird genauso installiert, wie im Update drüber.
Diesmal waren die Erfahrungen Folgende:

Da bei diesem Upgrade PHP 7.4 durch PHP 8.0 ersetzt wird, muss hier auf jeden Fall Hand angelegt werden.
Dafür war bei mir keine Reparatur der MySQL Datenbank notwendig.

Wer das Ganze bereits von vorne herein mit PHP 8.0 installiert hat, dürfte wenig anzupassen haben.
Der ganze Vorgang dauerte sehr lang und man sollte dabei bleiben, da hin und wieder nach Optionen gefragt wurde.

Außerdem wird automatisch die Deinstallation von phpMyAdmin angeboten, die man auch durchführen sollte, da die installierte Paketversion unter PHP 8.0 nicht mehr läuft.
Hier muss man dann auf die manuelle Installation zurückgreifen (siehe meine anderen Anleitungen).

Es mussten die restlichen PHP 7.4 Pakete deinstalliert und die entsprechenden PHP 8.0 Pakete installiert werden.
Auch die vHost Einträge für die PHP 7.4 Sockets mussten an die PHP 8.0 Version angepasst werden, sonst erhält man beim Webseitenaufruf nur Fehlerseiten.

Auch Collabora bemängelt nach dem Upgrade ggf. fehlende Pakete, die man aber nachinstallieren kann.

Kurzes Fazit: Auch hier gab es wieder die Notwendigkeit für Eingriffe, die man evtl. nur mit Linux Erfahrung meistert.
Daher: Backup, Backup und nochmals Backup !!
(am besten vorab die Karte oder SSD per Imager sichern)
Wer sich dran wagt, kann sich daran versuchen und spielt beim Schiefgehen sein Backup zurück.

Von mir gibts dafür aber keine Hilfe !!

Image von Ubuntu 20.04.1 LTS Server 64 Bit auf SD flashen
Wer den Raspberry Pi Imager noch nicht benutzt/installiert hat, kann diesen hier downloaden:

Raspberry Pi Imager Download

Dort kann zwischen 3 verschiedenen Systemen gewählt werden (Windows, macOS, Ubuntu).
Wer generell mehr Infos zum Flashen von Systemen (auch Raspberry Pi OS), findet weitere Infos dazu in meiner Anleitung:

Raspberry Pi installieren: Raspberry Pi OS (ehemals Raspbian)

Ist der Imager installiert und gestartet, sehen wir folgendes Startbild:



In diesem Startbild klicken wir auf CHOOSE OS und erhalten folgende Auswahl,



bei der wir das oben im Kreis markierte Ubuntu auswählen und eine weitere Auswahl erhalten:



Nachdem man dann auch eine leere SD Karte in das SD Laufwerk eingelegt und im Imager ausgewählt hat, befindet man sich wieder in der Hauptansicht und klickt auf WRITE:



Es folgt noch eine Sicherheitsabfrage, bei der nochmals darauf hingewiesen wird, das alle Daten dieser SD Karte gelöscht werden.
Nach Bestätigung wird das Imager geschrieben und anschließend verifiziert.

Nach dem Flashen wird die SD Karte sofort vom Hauptsystem abgemeldet.
Da wir aber gleich noch WLan vorab konfigurieren wollen, wird die SD Karte kurz herausgezogen und gleich wieder eingesteckt.


WLan vorab konfigurieren
Jetzt öffnen wir die kleine Partition von der SD Karte, die in Windows lesbar ist und die Bootpartition darstellt.
In diesem Verzeichnis öffnen wir die Datei network-config mit einem Texteditor.

Im unteren Teil sehen wir die WLan Beispielkonfiguration:

Code: Alles auswählen

#wifis:
#  wlan0:
#    dhcp4: true
#    optional: true
#    access-points:
#      myhomewifi:
#        password: "S3kr1t"
#      myworkwifi:
#        password: "correct battery horse staple"
#      workssid:
#        auth:
#          key-management: eap
#          method: peap
#          identity: "me@example.com"
#          password: "passw0rd"
#          ca-certificate: /etc/my_ca.pem

Diese ist mit der Raute "#" deaktiviert und mit Beispielwerten gefüllt.

Hier entfernen wir die Raute "#" und ersetzen die Werte durch eigene:

Code: Alles auswählen

wifis:
  wlan0:
    dhcp4: true
    optional: true
    access-points:
      "hier die eigene SSID eintragen":
        password: "hier das zugehörige Passwort eintragen"
#      myworkwifi:
#        password: "correct battery horse staple"
#      workssid:
#        auth:
#          key-management: eap
#          method: peap
#          identity: "me@example.com"
#          password: "passw0rd"
#          ca-certificate: /etc/my_ca.pem

Das sollte anfangs reichen.

Anders als im Beispiel vorgegeben, schreibt die originale Installationsanleitung, dass man den Networknamen (also die SSID) in Anführungsstriche setzen muss, was ich oben getan habe.

Das sollte reichen und nun wird die Datei gespeichert, die SD Karte am PC abgemeldet und in den Raspberry Pi eingesteckt und gebootet.

Hinweis:
Das erste Booten startet die WLan Verbindung noch nicht, sondern konfiguriert diese nur (mehrmals getestet).
Daher bitte den Raspberry Pi zuerst per Lankabel mit dem Router verbinden und hochfahren lassen und eine Weile warten, da einige Sachen erst fertig gestellt werden müssen, wie z.B. das automatische Vergrößern der Arbeitspartition.

Hierbei baut der Raspberry Pi automatisch eine Verbindung ins eigene Netzwerk auf und wir können per SSH Zugriff über Putty den Pi erreichen.

Dann fährt man den Pi wieder herunter und zieht das Lankabel ab und startet den Pi neu mit WLan (Strom kurz weg und wieder dran).

Wer den Pi gleich beim ersten Mal ohne Lankabel gestartet hat, kann das Lankabel auch nachträglich anstecken, das funktioniert genauso.
Das Lankabel muss 1x dran, um den Pi nach der Erstkonfiguration vom Wlan wieder herunterfahren zu können.

Dieses "Phänomen" wird auf der Ubuntu Server Webseite auch erwähnt, daher gehe ich davon aus, dass dies momentan nicht anders geht.
Das ist aber kein wirkliches Problem.

Wie das funktioniert, folgt unter diesem Kasten.

SSH Zugriff per Putty
Um nun auf den Raspberry Pi zugreifen zu können, damit wir ihn herunterfahren und das Netzwerkkabel abziehen können, benötigen wir das unter Windows beliebte Programm Putty, welches verschiedene Arten des Zugriffs auf Geräte im Netzwerk ermöglicht.

Putty kann man hier herunterladen:

Download PuTTY latest release

Ich habe hier die 64Bit Version der direkt ausführbaren Datei (ohne es installieren zu müssen) entschieden.

Wer ein anderes Host System nutzt (z.B. macOS oder Ubuntu), kann sicherlich auch direkt in der Kommandozeile per SSH Befehl darauf zugreifen.

Ist Putty in den gewünschten Ordner auf der Festplatte des PCs heruntergeladen, reicht ein Doppelklick zum Starten und trägt die auf dem folgenden Bild gezeigte Daten ein:



Bei Hostname (or IP Adress) kommt der Netzwerkname des Raspberry Pis rein, der hier vordefiniert ubuntu lautet.
Wer möchte, kann hier auch die IP Adresse eintragen, die man im Router auslesen kann.
Ich habe mich eben für den Hostnamen entschieden.

Im Feld Saved Sessions kann man frei einen Namen für die Speicherung dieser Konfiguration eintragen, damit man den Hostnamen nicht immer neu eintippen muss.
Ich habe mich einfach für Ubuntu entschieden, was man sich auch leicht merken kann.
U.U. kann/sollte man den Hostnamen später ändern, wenn Nextcloud im Netzwerk oder extern erreicht werden kann/soll.

Nach dem Klick auf Save wird ein gleichnamiger Eintrag für spätere Nutzung abgelegt und ein Klick auf Open startet den Verbindungsaufbau.
Dabei wird eine Meldung ausgegeben, die abfragt, ob man dem gefundenen Zertifikat vertrauen möchte.
Dies mit einem bestätigt, öffnet die Kommandozeile des Ubuntu Servers, der nun nach den Login Daten fragt.

Die Login Daten sind vorgegeben mit

Code: Alles auswählen

Benutzer: ubuntu
Passwort: ubuntu

Das Passwort muss auch direkt nach dem Einloggen geändert werden und Ubuntu ruft die Passwortänderung auch gleich nach dem Login auf.
Man ist quasi gezwungen, nach dem ersten Login das Passwort zu ändern.

Hinweis:
Direkt nach der Passwortänderung wird die SSH Verbindung getrennt und Putty schließt automatisch.
Das ist so gewollt und völlig normal, daher nicht wundern, sondern Putty erneut starten, die Verbindung herstellen und mit dem neuen Passwort einloggen.

Nach dem neuen Login sehen wir folgendes Bild:



Oben im Bild sieht man die Lankabelverbindung von IP4 und IP6 per eth0:.

Jetzt fahren wir den Raspberry Pi herunter, um das Netzwerkkabel abzuziehen.
Einen Reboot müssten wir sowieso durchführen, daher bietet sich ein Herunterfahren an, um in aller Ruhe das Netzwerkkabel abzuziehen.

Der Befehl zum Herunterfahren lautet:

Code: Alles auswählen

sudo poweroff

Nach kurzer Zeit meldet Putty dien Verbindungsverlust und wir warten, bis die grüne LED nach kurzem Blinken ganz aus bleibt und nur noch die rote LED leuchtet.

Jetzt können wir das Netzwerkkabel abziehen und den Raspberry Pi an gewünschter Stelle plazieren, wo wir aber noch ausreichend WLan Signal haben.

Nach erneuter Stromzufuhr und ohne Netzwerkkabel öffnen wir wieder die Verbindung über Putty und loggen uns ein.
Jetzt ist folgendes Bild zu sehen:



Nun hat sich eth0: zu wlan0: geändert und dahinter stehen die entsprechenden IP Adressen.

Auf dem Bild wird auch darauf hingewiesen, dass einige Updates vorliegen, die installiert werden sollten.

Dies erledigen wir mit folgendem Befehl:

Code: Alles auswählen

sudo apt-get update && sudo apt-get dist-upgrade -y

Obigen Befehl kennen wir auch von Debian / Raspberry Pi OS und dieser funktioniert hier ebenso.
Damit werden auch alle Abhängigkeiten auf den aktuellen Stand gebracht.

Für zeitnahe kleinere Updates reicht in der Regel auch folgender Befehl:

Code: Alles auswählen

sudo apt-get update && sudo apt-get upgrade -y

Aber beim ersten Update nutze ich immer den Befehl weiter oben.

Nach dem Start des Updates dauert es eine Weile, weil sich doch einiges angesammelt hat, was aktualisiert werden muss.
Manchmal sieht es auch so aus, als wenn gar nichts mehr geht aber trotzdem bitte Geduld üben, denn in der Regel ist alles ok.

Hinweis:
Die übliche Konfigurationsoberfläche vom Raspberry Pi OS (raspi-config) existiert hier nicht, daher müssen diverse Änderungen manuell durchgeführt werden.

Um im System einfacher zu navigieren, empfehle ich die Nutzung vom Midnight Commander, der vieles vereinfacht.
Alte Hasen kennen diesen Norton Commander Klon.

Installationsbefehl:

Code: Alles auswählen

sudo apt-get install mc -y

Gestartet wird der MC mit diesem Befehl:

Code: Alles auswählen

sudo mc

Damit ist die Grundkonfiguration erst einmal erledigt.
Wer möchte, kann noch eine grafische Oberfläche installieren aber ich denke, auf einem Server ist das nicht unbedingt nötig.

Aber zum Abschluss stellen wir die Zeitzone noch um:

Code: Alles auswählen

sudo dpkg-reconfigure tzdata

Dies ruft folgende Eingabemaske auf:



Nach der Auswahl Europe fehlt nur noch die dazu gehörige Stadt:



Nach der Auswahl und Bestätigung von Berlin schließt das Fenster wieder und die angezeigte lokale Zeit sollte jetzt stimmen, solange der Raspberry Pi Internetzugang hat.

Als nächstes stellen wir noch die Sprache (locales) auf Deutsch um.
Hierzu schauen wir, ob locales installiert ist oder installieren es einfach:

Code: Alles auswählen

sudo apt-get install locales -y

Ubuntu merkt, dass locales bereits installiert ist und teilt mit, dass es nun auf "manuell installiert" umgestellt wurde.

Mit dem Befehl

Code: Alles auswählen

locale -a

lassen wir uns anzeigen, was momentan installiert/eingestellt ist.

Bei mir sah das dann so aus:

Code: Alles auswählen

ubuntu@ubuntu:~$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
ubuntu@ubuntu:~$

Deutsch fehlt also und muss nachinstalliert werden:

Code: Alles auswählen

sudo locale-gen de_DE.UTF-8

Jetzt ist Deutsch zwar installiert, muss aber noch umgestellt werden:

Code: Alles auswählen

sudo dpkg-reconfigure locales

Hier scrollen wir zu den deutschen Einstellungen



und schauen, dass die mit dem roten Pfeil gezeigte Option angesternt ist.
Falls nicht, einfach markieren.

Dann scrollen wir zu der englischen Einstellung runter



und nehmen die (us) englische Option raus und bestätigen mit Ok.

Nun fragt das Konfigmenü nach der Standardsprache:



Hier habe ich die neu hinzugefügte deutsche Sprache ausgewählt.
Sollten mal Übersetzungen fehlen, wird das System diese trotzdem noch in Englisch anzeigen.

Nach der Bestätigung mit Ok wird das Ganze fertig eingerichtet und die meisten Meldungen sollten jetzt in Deutsch erscheinen.

Ein Test mit

Code: Alles auswählen

locale -a

zeigt dann

Code: Alles auswählen

ubuntu@ubuntu:~$ locale -a
C
C.UTF-8
POSIX
de_DE.utf8
ubuntu@ubuntu:~$

Wer will, kann natürlich auch andere Sprachen aktivieren oder alles einfach auf Englisch lassen.
Ich mag Deutsch halt ganz gerne, zumal es ja auch zur Verfügung gestellt wird.

Um bereits jetzt mit deutscher Sprache zu arbeiten, empfehle ich einen Reboot:

Code: Alles auswählen

sudo reboot now

Danach einfach wieder anmelden.


Vorbereitung: Apache2, PHP, MySQL (MariaDB) und phpMyAdmin
Für Nextcloud existiert zwar auch von Ubuntu ein fertiges Image inkl. Nextcloud, jedoch ist dort eine alte Version enthalten (18.x.x).
Ich möchte aber unabhängig vom Grundsystem eine aktuelle Version installieren und zeitgleich bin ich flexibel, was das Betriebssystem angeht.
Das spätere Update der Nextcloud Versionen ist dann auch kein Hexenwerk mehr, da Nextcloud einen Updater mitbringt.

Ich konnte auf die Schnelle nur herausfinden, dass anscheinend die 32Bit Version von Ubuntu Server verwendet wird.
Auf jeden Fall muss 64Bit installiert werden, da sonst der Dokumentserver von Collabora Online nicht läuft, da dieser momentan nur für 64Bit Arm Systeme vorliegt.

Die normale Variante von NextcloudPi über Curl funktioniert hier leider nicht, daher muss eine andere Version des Installers benutzt werden (Fehler bei Curl: ERROR: distro not supported).

Ich verwende daher die normale Nextcloud Version, die über PHP installiert wird.

Zuallererst installieren wir aber den benötigten Apache Webserver:

Code: Alles auswählen

sudo apt-get install apache2 -y

Ob die Installation geklappt hat und auch funktioniert, erfahren wir durch den Aufruf im Browser mit folgender Adresse:

http://ubuntu

Und angezeigt werden sollte das:



Wenn das passt, installieren wir PHP 7.4:

Code: Alles auswählen

sudo apt-get install php7.4 php7.4-curl php7.4-gd php7.4-fpm php7.4-cli php7.4-opcache php7.4-json php7.4-mbstring php7.4-xml php7.4-zip php7.4-mysql php7.4-intl php7.4-bcmath php7.4-gmp php7.4-imagic -y

Wir erhalten folgenden Hinweis am Ende:

Code: Alles auswählen

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

Ergo ist noch Folgendes zu tun:

Code: Alles auswählen

sudo a2enmod proxy_fcgi setenvif

Code: Alles auswählen

sudo a2enconf php7.4-fpm

Damit auch später das Rewrite Modul für die Umleitungen funktioniert, wird dies gleich mit aktiviert:

Code: Alles auswählen

sudo a2enmod rewrite

War es bereits aktiv, wird dies gleich mitgeteilt, ansonsten ist es ab jetzt aktiv.

Dann starten wir den Apache neu:

Code: Alles auswählen

sudo systemctl restart apache2

Weiter geht es mit dem Apache Modul für PHP:

Code: Alles auswählen

sudo apt-get install libapache2-mod-php7.4 -y

Und ein erneuter Restart vom Apachen:

Code: Alles auswählen

sudo systemctl restart apache2

Nun prüfen wir, ob und mit welcher Konfiguration PHP läuft.
Dazu erstellen wir eine Info Datei:

Code: Alles auswählen

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

Und füllen diese mit folgendem Inhalt:

Code: Alles auswählen

<?php
  phpinfo();
?>

Beendet wird der Editor mit der Tastenkombination <STRG><X>.

Test im Browser:

http://ubuntu/info.php

Wie wir sehen, läuft PHP:



Aber wir wollen ja den sichereren FPG/FastCGI Modus.

Hierfür ist ein weiterer Befehl notwendig:

Code: Alles auswählen

sudo a2enmod actions

gefolgt vom empfohlenen Neustart des Apachen:

Code: Alles auswählen

sudo systemctl restart apache2

Damit dieser Modus auch berücksichtigt wird, ändern wir den VirtualHost der Webseite durch diese Datei:

Code: Alles auswählen

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

Den nun folgenden Inhalt ergänzen wir mit diesem Code:

Code: Alles auswählen

<VirtualHost *:80>
….
        ServerName ubuntu
….

        <Directory /var/www/html>
                Options -Indexes +FollowSymLinks +MultiViews
                AllowOverride All
                Require all granted
        </Directory>
    
        <FilesMatch \.php$>
                SetHandler "proxy:unix:/var/run/php/php7.4-fpm.sock|fcgi://localhost"
        </FilesMatch>

….

Die …. deuten darauf hin, dass noch weitere Einträge vorhanden sind und das oben Gezeigte zusätzlich mit eingefügt werden muss.

Wurde die obige Datei ergänzt und gespeichert, starten wir den Apachen und PHP Teil neu:

Code: Alles auswählen

sudo service apache2 restart && sudo service php7.4-fpm restart

Wenn kein Fehler auftritt, erscheint einfach nur wieder der Eingabeprompt.

Nun gilt es zu prüfen, dass der Apache auch wirklich im FPM/FastCGI Modus läuft.
Dafür rufen wir unsere zuvor angelegte Info Datei wieder auf:

http://ubuntu/info.php

Dabei sollte das angezeigt werden:



Somit haben wir die Apache2 und PHP Installation erledigt und kümmern uns um die Datenbank, die Nextcloud benötigt.

Als Datenbank nutze ich MariaDB, welche kompatibel zu MySQL ist und moderner sein soll.
Installation von Client und Server erfolgt hiermit:

Code: Alles auswählen

sudo apt-get install mariadb-client mariadb-server -y

Diese Installation nimmt einiges an Zeit in Anspruch, daher bitte Geduld haben.

Danach folgt die Absicherung der Datenbank mit folgendem Befehl:

Code: Alles auswählen

sudo mysql_secure_installation

Hier ist zuerst das aktuelle Passwort des Datenbankadministrators (root) eingegeben.
Wurde die Datenbank erst gerade installiert und noch kein Passwort eingegeben, ist einfach die Entertaste für kein Passwort einzugeben.

Es folgt daraufhin die Frage, ob man ein Passwort setzen möchte.
Dies sollte unbedingt mit Y für Yes bestätigt werden.

Nun ist das neue Administratorpasswort einzugeben, danach ein zweites Mal zur Bestätigung (und um Tippfehler zu vermeiden).

Auf die Frage, ob anonyme Benutzer gelöscht werden sollen, ist ebenfalls mit Y für Yes zu bestätigen.

Ebenso ist die nachfolgende Frage nach dem Verbot für das entfernte Einloggen des Benutzers "Root" mit Y zu bestätigen.
Somit kann sich der Benutzer "Root" nur lokal in die Datenbank einloggen und niemand sonst aus dem Netzwerk mit diesem Account.

Bei der Frage nach dem Löschen der Datenbank "Test" ist auch wieder eine Bestätigung mit Y einzugeben, da diese für eine produktive Umgebung nicht benötigt wird.
Ebenso werden auch die Zugänge darauf gelöscht.

Zum Schluss folgt noch die erneute Bestätigung mit Y für das Neuladen der Datenbankprivilegien, damit die Änderungen sofort übernommen werden.

Die Installation ist hiermit beendet und die zu dem früheren MySQL kompatible Datenbank kann sofort eingesetzt werden.

Da wir evtl. ab und zu auch mal direkt in die Datenbank schauen möchten, folgt hier die Installation von phpMyAdmin:

Code: Alles auswählen

sudo apt-get install phpmyadmin -y

Nach kurzer Zeit der Installation folgt das Konfigurationsfenster:



Hier ist apache2 auszuwählen und mit Ok zu bestätigen.

Nun folgen weitere Konfigurationen in der Kommandozeile, bis folgende Abfrage erscheint:



Da phpMyAdmin eine eigene Datenbank benötigt, bestätigen wir hier mit Ja oder Yes.

Nun benötigt phpMyAdmin ein MySQL Kennwort.
Wird hier nichts eingegeben, wird ein zufälliges erzeugt:



Hier ein Passwort eingeben und danach nochmals bestätigen.
Nach kurzer Fertigstellung der Konfiguration landen wir wieder in der Konfigurationszeile.

Es folgt ein erster Test mit dem Browser:

http://ubuntu/phpmyadmin

Hat alles funktioniert, erscheint folgende Login Maske:



Hier ist nun ein Login mit dem Datenbankbenutzer "phpmyadmin" und dem weiter oben definierten Passwort möglich und man erhält die folgende Startseite:



Greift man von extern auf phpMyAdmin zu, sollte eine Verschlüsselung aktiviert werden, denn sonst gehen die Abfragen im Klartext durchs Internet. Daher entweder verschlüsseln oder den Zugriff von extern blockieren.

Da aber nach der Standardkonfiguration (wie oben ausgeführt) der Benutzer phpmyadmin keine Rechte zum Anlegen und/oder bearbeiten anderer Datenbanken hat, wenn man nicht lokal am Raspberry Pi (sondern über das Netz) zugreift, gibt es zwei Möglichkeiten, dieses einzurichten:

1. dem Benutzer phpmyadmin alle Rechte geben (sollte eigentlich vermieden werden, vor allem Remote)
2. einen neuen Benutzer anlegen und diesem alle Rechte geben (auch hier die Sicherheit bedenken)

Auf jeden Fall sollte man bei einem Fernzugriff über das Internet mindestens die SSL Verschlüsselung aktivieren.

1. Möglichkeit: dem Benutzer phpmyadmin alle Rechte für MariaDB einrichten.
Dies geschieht in der Datenbank selbst, die wie folgt per Root zu starten ist:

Code: Alles auswählen

sudo mysql --user=root mysql

Es erscheint der mysql Prompt, bei dem für die Rechtevergabe des vorhandenen Benutzers phpmyadmin Folgendes einzugeben ist:

Code: Alles auswählen

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

Damit diese Rechte sofort geändert und übernommen werden, ist folgender Befehl zum Abschluss einzugeben:

Code: Alles auswählen

FLUSH PRIVILEGES;

Danach wird mysql (MariaDB) mit exit verlassen.

Wenn jedoch einen gänzlich anderen Benutzernamen verwenden werden soll, ist die 1. Möglichkeit zu ignorieren und stattdessen die 2. Möglichkeit zu verwenden:

2. Möglichkeit: Einen neuen Benutzer anlegen und alle Rechte vergeben
Hierzu ist (wie bei Möglichkeit 1) die Kommandozeile von mysql zu starten:

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 starten wir den Apachen und PHP nochmals neu:

Code: Alles auswählen

sudo service apache2 restart && sudo service php7.4-fpm 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.

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-get install redis-server php-redis php-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 PHP:

Code: Alles auswählen

sudo service apache2 restart && sudo service php7.4-fpm restart

Ich hatte in meiner Installation 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.

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

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.

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

Code: Alles auswählen

sudo service redis-server restart

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.

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/7.4/fpm/php.ini

und scrollen runter zu memory_limit = 128M und ändern den Wert auf den gewünschten neuen Wert (hier 2G):



Dieser Wert sollte bei einem Raspberry Pi 4B 4GB locker reichen, ggf. kann 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.

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.

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 now

Danach wieder über Putty an der Kommandozeile einloggen.


Nextcloud installieren
Nun geht es direkt zur Installation von Nextcloud.

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 www-data:www-data /var/www/data

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

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

Code: Alles auswählen

sudo chown 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.

Wenn wir schon drin sind, löschen wir gleich die Beispieldatei für die Anzeige des installierten Apache2 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://ubuntu/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.

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 übernehmen wir noch die Option Empfohlene Apps installieren und klicken auf Installation abschließen.

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



U.U. erscheint im blauen Bereich folgende Meldung:

Code: Alles auswählen

Collabora Online - Built-in CODE Server
Lokales Dokumentenbearbeitungs-Backend, das von der Collabora Online-Anwendung verwendet wird.
Herunterladen oder Installieren der App fehlgeschlagen

Das kommt evtl. davon, dass in der Installation vom CODE Server die normale Intel/AMD Version versucht wird zu installieren.
Wir können das ignorieren und istallieren später die richtige Version (ARM64).

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



Dort klicken wir uns dann über den Pfeil rechts neben dem Titelfenster in der Mitte durch einige Informationen, bis wir die Hauptansicht erreicht haben:



In der aktuellen Installation ist nun ein sogenanntes Dashboard integriert, welches man sicherlich auch deaktivieren kann.
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 von Ubuntu 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.locking' => '\OC\Memcache\Redis',
  'filelocking.enabled' => 'true',
  'redis' =>
  array(
     'host'     => '/var/run/redis/redis-server.sock',
     'port'     => 0,
     'password' => 'c03d914786edf0161b5bad0180d789634acc39cd310cc1dee1cc395e3dbc76ee',
     'timeout'  => 0.0,
  ),

Das Ganze sieht fertig dann so aus:

Code: Alles auswählen

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

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:



Nun stellen wir in der Konfiguration auf die Verwendung auf Cron um, indem wir rechts oben auf die Einstellungen klicken:



Dann im erscheinenden Menü rechts auf Grundeinstellungen:



Im folgenden Fenster stellen wir einfach auf Cron um, falls noch nicht geschehen:



Prüfen wir im Konfigurationsbereich bei der Übersicht, ob alles weitere aktuell und korrekt installiert ist, werden wir noch diverse Kleinigkeiten sehen, die aber noch nach und nach angepasst werden.


Verschlüsselung mit Let´s Encrypt
Als Nächstes kümmern wir uns um die Verschlüsselung, da wir sicherlich auch aus dem Internet darauf zugreifen möchten.
Wer nur im lokalen Netz darauf zugreift oder von außen über VPN, der könnte diesen Schritt überspringen.
Alle anderen, die auf jeden Fall verschlüsseln möchten, machen hier einfach weiter, ohne diesen Teil zu überspringen.

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 neu starten:

Code: Alles auswählen

sudo service apache2 restart

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 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 Ubuntu Server 20.x.x macht, wird diese Vorgehensweise der Installation empfohlen:

Code: Alles auswählen

sudo apt-get 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

<IfModule mod_ssl.c>
        <VirtualHost _default_: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

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerName sub.domain.tld
                ServerAlias ubuntu
                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 der Apache neu gestartet:

Code: Alles auswählen

sudo systemctl restart 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 A für agree.

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.

Danach werden wir gefragt, ob wir eine Umleitung von http auf https möchten, was wir mit 2 bestätigen und damit erlauben.

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 => 'ubuntu',
    1 => 'localhost',
    2 => '192.168.178.68',
    3 => 'ubuntu.fritz.box',
  ),

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

Code: Alles auswählen

    4 => 'sub.domain.tld',

Das Ganze sieht dann fertig so aus:

Code: Alles auswählen

  'trusted_domains' =>
  array (
    0 => 'ubuntu',
    1 => 'localhost',
    2 => '192.168.178.68',
    3 => 'ubuntu.fritz.box',
    4 => '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

ubuntu@ubuntu:/$ sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Wed 2020-09-30 19:07:42 CEST; 21h ago
    Trigger: Fri 2020-10-02 05:13:08 CEST; 12h left
   Triggers: ● certbot.service

Sep 30 19:07:42 ubuntu systemd[1]: Started 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

....
Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/sub.domain.tld/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
....

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

Weitere notwendige Konfigurationen
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

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerName sub.domain.tld
                ServerAlias ubuntu
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html
.... usw ....

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/php7.4-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 den Apachen und PHP neu:

Code: Alles auswählen

sudo service apache2 restart && sudo service php7.4-fpm restart

Jetzt haben wir wieder den FPM/FastCGI Modus, den wir mit der weiter oben genannten info.php Datei überprüfen können:

https://sub.domain.tld/info.php

Dort sollte dann wie weiter oben an 3. Stelle diese Zeile erscheinen:

Code: Alles auswählen

Server API	FPM/FastCGI

Jetzt löschen wir noch die Datei info.php (aus Sicherheitsgründen)

Code: Alles auswählen

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

und rufen die Übersicht in den Einstellungen in Nextcloud auf:



Darin sollten wir im oberen Bereich keine Fehler sehen und unten die aktuelle Version:



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 ....


Collabora Online installieren
Hier folgt nun die Konfiguration von Collabora Online inkl. Server auf dem Raspberry Pi, weswegen ich den ganzen Aufwand hier betreibe.
Aktuell ist wohl Collabora Online mit seinem Server (im Betastadium !!) unter 64Bit scheinbar die einzige Lösung, Office Dokumente auf einem ARM System wie dem Raspberry Pi (ab 3B(+), besser Pi 4B ab 4GB) auszuführen.
Für Collabora ist also ein 64Bit ARM Server in Bearbeitung, was ich bei OnlyOffice, dem Konkurrenten zu Collabora Online, bisher noch nicht gefunden habe.
Für beide Systeme existieren zwar Server aber nur für Intel/AMD Systeme.
Einen Start als Beta für ARM64 konnte ich nur für Collabora Online ausmachen.
Für diesen 64Bit Betriebsmodus habe ich daher auch auf Ubuntu Server 64Bit zurückgegriffen, da dieses System im Gegensatz zum Raspberry Pi OS 64Bit nicht mehr Beta ist und gut funktioniert.

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



Dort sehen wir, dass die Schnittstelle für Collabora bereits installiert ist und wir diese nachher nur noch konfigurieren müssen, sobald wir den Document Server am Laufen haben:



Bei mir hat sich bei der Installation von Nextcloud und den empfohlenen Apps bereits ein nicht funktionierender CODE Server für Colloabora Online mitinstalliert, der aus berechtigten Gründen automatisch deaktiviert wurde (weil dieser eben nicht unter ARM64 läuft).

Diesen Server müssen wir zuerst deinstallieren, falls vorhanden.

Dazu gehen wir in der Apps Sektion auf Deaktivierte Apps:



Hier einfach auf Entfernen klicken und das Teil ist weg und sollte auch sonst nirgendwo mehr in der Apps Sektion auftauchen.
Evtl. wird hier wieder nach der Legimitierung gefragt, bei der einfach das bekannte Passwort eingegeben wird.

Nun installieren wir den korrekten Server.
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 wird vorab nach der Legitimierung gefragt:



Hier gebt Ihr das Passwort ein, dass Ihr bei der Installation für den User vergeben habt.

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.

Wenn wir nun in die Einstellungen oben rechts gehen und anschließend im linken Menü auf Eingebauter CODE-Server klicken,



erscheint folgende Meldung:



Das System teilt uns mit, dass der Server installiert wurde und zeigt uns einen Link, mit dem wir nun Collabora Online konfigurieren können, damit das mit unserem internen Server zusammen arbeitet.

Diesen angezeigten Link klicken wir jetzt an (man kann auch über das Menü links gehen und klickt dort auf Collabora Online einen Punkt höher).

Nun sollte der interne und gerade installierte Server bereits ausgewählt sein:



Weiter darunter folgende Optionen sollten nach eigenen Vorstellungen konfiguriert werden.

Ich habe nun 4 Dokumente mit MS Office 2019 erstellt, 2x Word (DOC + DOCX) und 2x Excel (XLS + XLSX) und in Nextcloud hochgeladen.
Alle 4 Dokumente habe ich auf die Schnelle vor dem Hochladen mit dem Text Dies ist ein Test. versehen.

Hier die 4 Dokumente in der Dateiübersicht:



Hier ein Beispiel mit einer der beiden Word Dateien:



Und hier eine der beiden Excel Dateien:



Damit ist die Installation mit Nextcloud und Collabora (mit internem Server) 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 © 2025 RasPiFun.de

[Outi]

Nextcloud über interne Updatefunktion auf 19.0.4 aktualisiert und Collabora Online hinzugefügt.

[bmortron]

Hallo.
Ich wollte mich für die tolle Anleitung bedanken. Ich habe erfolgreich Nextcloud mit CODE auf meinem Raspi4 8G an laufen.

Die Collabora Performace ist leider recht mies. Besonders aus dem Internet ist die Latenz sehr groß, so das Eingaben 1-2 Sekunden verzögert erscheinen. (400mbit Kabel 12mbit upload)
Ich habe PHP memory_limit auf 4 (GB) erhöht.
Hast du noch Tips hier die Geschwindigkeit zu verbessern?


Ich hatten an 2 Stellen etwas Problem bei der Anleitung:

1.

Nun wird diese Konfiguration (inkl. Passwort) in die Nextcloud Konfiguration eingetragen:

Code: Alles auswählen

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

die passiert in der Anleitung bevor Nextcloud installiert ist. geht zu dem Zeitpunkt also noch nicht.

2. bei der notwendigen Konfiguration von Apache nach SSL umstellung ist dein Code angschnitten

FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php7.4-fpm.>
</FilesMatch>

so das ich beim kopieren fehler hatte. konnte es dann fixen in dem ich die Code Zeile für die port 80 Einstellung kopiert habe.

[Outi]

Hallo bmortron,

herzlich willkommen im Forum und ganz lieben Dank für Deine Infos.
Ich habe meine Anleitung zwar nochmal gegengecheckt aber leider die von dir zu Recht bemängelten Punkte übersehen.
Das Problem war einfach, dass ich die Anleitung fast fertig hatte und Collabora dann aber - entgegen aller Behauptungen, die ich in Google gefunden habe - nicht lief.

Daher stoppte ich da erstmal und habe dann den Collabora Teil aus der Anleitung herausgenommen.
Dann kam kurz darauf das Update von Collabora, das dann funktioniert hat, wenn auch sehr träge, wie Du geschrieben hast.
Beim Einfügen muss ich dann die Redis Cache Geschichte falsch platziert haben aber jetzt sollte es stimmen.

Dein Hinweis mit der abgeschnittenen Position, die Du aus denm 80er VHost genommen hast, war übrigens auch dort abgeschnitten, wenn auch erst etwas später.
Dies habe ich nun auch bei beiden VHosts Dank Deines Hinweises korrigiert.
Leider hatte ich übersehen, dass Putty alles, was nicht ins Fenster passt, abschneidet.
Was mich halt wundert: Trotz der eigentlich unvollständigen Option hat es funktioniert ....

Danke nochmal und wenn noch irgendwas auffällt, bin ich für weitere Hinweise immer sehr dankbar.

[Outi]

Abgeschnittene Optionen korrigiert und Konfigurationsablauf (Redis in Collabora Konfig) in richtige Reihenfolge gebracht.

[bmortron]

Ich habe noch mal alles neu installiert auf ubuntu 20.10. Alles läuft, mit Redis hatte ich einige Probleme die ich bei der Installation davor schon gelöst hatte, aber vergessen zu dokumentieren.

1.
ich kann phpmyadmin erst erreichen nach dem ich diese befehle ausgeführt habe (das war bei 20.04 genauso):

sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf-available/phpmyadmin.conf
sudo a2enconf phpmyadmin.conf
sudo service apache2 reload

2.
Um nextcloud in das Verzeichnis unterhalb von /html zu installieren ist dieser Befehl nötigt nach dem das Verzeichnis angelegt wurde:
sudo chown www-data:www-data /var/www/data

3.
Redis hat den Socket nicht erzeugt und deshalb nicht funktioniert. Ich musst in /etc/redis/redis.conf
die Sockets auskommentieren und die bei Unixsocketperm die Berechtigung von 770 aud 775 ändern

# 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.sock
unixsocketperm 775 (hier stand bei dir

[Outi]

Hallo bmortron,

vielen Dank für Deine Hilfe.

Zu 1.:
Bei mir funktioniert phpMyAdmin einwandfrei über "sub.domain.tld/phpmyadmin" und ich habe den phpMyAdmin mit dem dazugehörigen Installer eingerichtet, der das normalerweise automatisch macht, wenn man am Anfang Apache 2 auswählt.

Zu 2.:
Ich habe nicht Nextcloud unter /html/ installiert, sondern nur das Datenverzeichnis aber ich denke, das meintest Du.
Da das erst später hinzukam, kann es sein, dass ich da was vergessen habe.

Zu 3.:
Redis hat bei mir funktioniert aber ich prüfe das nochmal.

Auf jeden Fall ganz herzlichen Dank für Deine Infos, ich werde alle 3 Punkte nochmal explizit durch eine Neuinstallation prüfen/korrigieren und die Punkte an der richtigen Stelle in der Anleitung einfügen/ändern.

.... befehle ausgeführt habe (das war bei 20.04 genauso): ....

Was hast Du denn jetzt für eine Version laufen ??

[bmortron]

Ich habe nicht Nextcloud unter /html/ installiert, sondern nur das Datenverzeichnis aber ich denke, das meintest Du.

ja ich meinte das Datenverzeichnis - unterhalb von dem /html/ Verzeichnis.

Was hast Du denn jetzt für eine Version laufen ??

Ubuntu Server 20.10 64bit

Collabora Performance:

Es hilft den standardmäßig aktivierten Spellchecker zu deaktivieren
Update auf 6.4.13 scheint auch noch mal minimal bessere Performance zu liefern.
Im lokalen Netzwerk fast nutzbar

grüße

[Outi]

So, ich bin etwas weiter und installiere gerade alles neu.
Dabei ist mir aufgefallen, dass Nextcloud jetzt bereits 20.x.x ist.

Status:

Zu 1.:
phpMyAdmin funktioniert bei mir immer noch ohne Änderungen - wie in der Anleitung beschrieben - ohne Deinen Befehl einzubauen ....

Zu 2.:
Hab ich jetzt vor die Installation von Nextcloud eingefügt und funzt prima.

Zu 3.:
Ich wusste doch, dass ich was vergessen hatte.
Die Sockets mussten natürlich erstmal aktiviert werden und auch ich erinnere mich an die Rechte 775.

Ich mach jetzt mal weiter aber das sieht alles (wieder) gut aus.

[bmortron]

Dabei ist mir aufgefallen, dass Nextcloud jetzt bereits 20.x.x ist.

Nextcloud 20.0.1 läuft bei mir