Nextcloud - Data Verzeichnis verlegen und Apache Config

Hallo zusammen,

freudig habe ich festgestellt, dass Nextcloud nun im Appcenter von UCS verfügbar ist. Ich habe auf dem gleichen Server parallel Owncloud 8.2 im Einsatz zusammen mit Kopano Webapp.
Dazu folgende Fragen und Feedback von meiner Seite:

  1. Bei Owncloud lies sich das Data-Verzeichnis per UCS Variable “owncloud/directory/data” einfach anpassen. Dies fehlt analog für nextcloud und sollte unbedingt nachgezogen werden.
  2. Nextcloud wird als Dockercontainer ausgeliefert … Gibt es dazu ein Tutorial von UCS auch im Hinblick auf zukünftige Container ? Aktuell verstehe ich nicht wie ich z.B. die Apache Config zur Nextcloud Webpage editieren kann bzw. wo diese überhaupt zu finden ist ?

Ansonsten funktioniert die Installation tadellos.

Grüße,
Ludwig

Hallo,

es ist möglich, dass von Nextcloud hier niemand regelmässig vorbeischaut. Ich würde daher empfehlen, Community-Feedback im Github-Repository abzugeben.

Beim Thema Datenverzeichnis sieht man, dass bei den Docker-Integrationen wesentlich mehr Aufwand nötig ist , eine funktional mit einer nativen Integration vergleichbare Lösung zu erhalten.Fürs erste wird man wohl damit leben müssen, dass /var/lib/univention-appcenter/apps/nextcloud/data/nextcloud-data bei Bedarf als ein Mountpoint oder Symlink einzurichten ist. Ansonsten landet halt alles in / auf dem Wirt.

UCS-spezifische Tutorials zum Thema Docker gibt m.E. zunächst nur für Entwickler und als Einstiegsinfo in der Wiki.

Den Rest kann man sich ableiten.
Kleiner Exkurs:
Wir wissen, dass wir auf Nextcloud via http/https zugreifen können.

root@ucs-9843:~# netstat -tulpen | egrep ":443|:80 " tcp6 0 0 :::80 :::* LISTEN 0 14303 3859/apache2 tcp6 0 0 :::443 :::* LISTEN 0 14299 3859/apache2
Da ist nur der Apache selbst. Also muß irgendwo in dessen Konfiguration ein “/nextcloud” vergraben sein.

root@ucs-9843:/etc/apache2/sites-enabled# grep -R nextcloud * 000-default: ProxyPass /nextcloud http://127.0.0.1:40001/nextcloud retry=0 000-default: ProxyPassReverse /nextcloud http://127.0.0.1:40001/nextcloud default-ssl: ProxyPass /nextcloud http://127.0.0.1:40001/nextcloud retry=0 default-ssl: ProxyPassReverse /nextcloud http://127.0.0.1:40001/nextcloud
Also suchen wir heraus, wer da auf 40001 lauscht:

root@ucs-9843:~# netstat -tlpn | grep 40001 tcp6 0 0 :::40001 :::* LISTEN 18699/docker-proxy root@ucs-9843:~# ps -ef | grep docker-proxy | grep -v grep root 18699 3312 0 01:09 ? 00:00:01 docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 40001 -container-ip 172.17.0.1 -container-port 80
Der Proxy verbindet somit Port 80 vom Container mit Port 40001 vom Wirt. Auf den ersten Blick finde ich es nicht ganz so toll, dass man sich nicht auf 127.0.0.1 beschränkt. Bei Nextcloud kommt man aber bei direkter Ansprache des Proxyports wegen “‘overwriteprotocol’ => ‘https’” nicht weit. Aber das nur am Rande.

Den Rest muß man sich im Container ansehen.

root@ucs-9843:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3053791b58f7 nextcloud/univention-app-image:11.0.1-70 "/bin/sh -c /usr/sbi 11 hours ago Up 11 hours 0.0.0.0:40001->80/tcp sharp_pasteur root@ucs-9843:~# docker exec -it sharp_pasteur /bin/bash root@nextc-56421814:/# df Filesystem 1K-blocks Used Available Use% Mounted on overlay 44977968 3568976 39064240 9% / tmpfs 1026900 0 1026900 0% /dev shm 65536 0 65536 0% /dev/shm /dev/mapper/vg_ucs-root 44977968 3568976 39064240 9% /var/lib/univention-appcenter/apps/nextcloud/conf root@nextc-56421814:/# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 00:09 ? 00:00:00 /bin/sh -c /usr/sbin/entrypoint.sh /usr/sbin/entrypoint.sh root 13 1 0 00:09 ? 00:00:00 bash /usr/sbin/entrypoint.sh root 25 1 0 00:09 ? 00:00:00 /usr/sbin/cron root 26 13 0 00:09 ? 00:00:00 /bin/sh /usr/sbin/apache2ctl -D FOREGROUND root 28 26 0 00:09 ? 00:00:02 /usr/sbin/apache2 -D FOREGROUND www-data 29 28 0 00:09 ? 00:00:02 /usr/sbin/apache2 -D FOREGROUND www-data 171 28 0 00:10 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 174 28 0 00:10 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 176 28 0 00:10 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 312 28 0 09:41 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 326 28 0 09:44 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 335 28 0 09:45 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 342 28 0 09:45 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 343 28 0 09:45 ? 00:00:01 /usr/sbin/apache2 -D FOREGROUND www-data 365 28 0 09:56 ? 00:00:00 /usr/sbin/apache2 -D FOREGROUND root 388 0 0 11:19 ? 00:00:00 /bin/bash root 399 388 0 11:19 ? 00:00:00 ps -ef root@nextc-56421814:/# cat /usr/sbin/entrypoint.sh #!/usr/bin/env bash service cron start && /usr/sbin/apache2ctl -D FOREGROUND

usw.

Viele Grüße,
Dirk Ahrnke

Hallo Herr Ahrnke,

vielen Dank für die ausführliche Beschreibung und die Links zu den Entwicklerseiten.

Das ist genau der Einstieg den ich gesucht habe, auch ist aus dem App Tutorial die Verwendung von mod-proxy genau beschrieben so dass sich nachvollziehen lässt wie die Docker Websites an das Host System angebunden werden.

Die Lösung über Symlink hatte ich bereits umgesetzt; Ich hatte mich nur parallel gefragt ob ggf. die Einführung eines konfigurierebaren Parameters angedacht war analog Owncloud.

Beste Grüße,
Ludwig

Ich muss mich korrigieren:

Weder mit Symbolic Link noch mit mount --bind funktioniert es /nextcloud-data auf ein anderes Verzeichnis außerhalb des Containers zu verlegen.
Beim Aufruf der Nextcloud Seite werden die Daten nicht gefunden. (“Data directory (/var/lib/univention-appcenter/apps/nextcloud/data/nextcloud-data) is invalid”). Ownership und Verzeichnisrechte wurden natürlich angepasst auf www-data:www-data.
Kopiere ich die Daten mit mv wieder an den alten Ort zurück funktioniert es sofort wieder. Kann es das ein Zugriff auf Verzeichnis außerhalb des Containers nicht ohne weiteres Möglich ist ?

Grüße,
Ludwig

Der Dockercontainer kommt nur an die Verzeichnisse des Wirtes, die ihm explizit erlaubt werden. Die Doku für die App-Anbieter sagt dazu:

[quote]DockerVolumes
Apart from /var/lib/univention-appcenter/apps/$APPID/{data,conf}/, one may choose further directories that shall be mounted into the Docker Container. This is a good idea if it makes storing / restoring data easy and also provides the benefit of increased I/O performance. The syntax is DockerVolumes=/path/on/host/:/path/in/container/,… [/quote]
Man muss also garnicht erst versuchen, irgendwas im Container selbst zu verbiegen.

Das einzige, was ich bei meinen heutigen Tests geschafft habe, war, das gesamte Verzeichnis /var/lib/univention-appcenter auf dem Wirt auf eine andere Platte zu legen. Alles andere war dann doch eher frustrierend oder nicht von Dauer.

Der Weg über das ini file des Docker Containers ist aber kein gangbarer für die Praxis. Das ini File soweit ich das verstanden habe ist Bestandteil des App Pakets welches im UCS Appstore bereitgestellt wird. Dort Speicherorte zu inkludieren außerhalb des Containers auf dem Wirt System macht für die Masse keinen Sinn.

Auf der anderen Seite ist auch des Verlegen des kompletten Verzeichnisses /var/lib/univention-appcenter nicht zweckmäßig, denn damit würde ich dann alle Dockeranwendungen samt deren Config Daten auf einen anderen Speicherort verweisen.

Ich will jedoch dediziert den Nextcloud Data Store an einem anderen Speicherort haben da hier mit größeren Datenmengen zu rechnen ist und ansonsten meine SSD in Kürze voll ist. Nichts desto trotz möchte ich für andere Docker Anwendungen diese Performance natürlich weiter nutzen.

Kurzes Update:

Ich habe eben nextcloud nochmal deinstalliert, anschließend einen Symlink für “data” von “/var/lib/univention-appcenter/apps/nextcloud/data” nach “/mnt/filestore/nextcloud” angelegt und Nextcloud wieder installiert.
Siehe da … hat auf direkt funktioniert.

Warum dem so ist kann ich mir aktuell nicht erklären…

Hallo nochmal,

nachdem Nextcloud ein paar Tage problemlos lief, bekomme ich seit gestern folgende Fehlermeldung beim Loginversuch:


Es wurde am UCS Server nichts verändert, er ist seit dem Nextcloud funktioniert hat noch nicht einmal neugestartet worden. In den Log files auf dem Host finden sich keine Fehler.

Nun stehe ich vor dem nächsten Docker Problem: Wo finde ich die Logfiles von Nextcloud um dem Thema auf die Spur zu kommen ?
Diesem Wiki Eintrag folgend: http://wiki.univention.com/index.php?title=Debugging bin ich bereits mit “univention-app shell nextcloud” in den Nextcloud container vorgedrungen. /var/log/nextcloud.log existiert allerdings nicht und auch kein anderes Logfile was etwas mit nextcloud zutun hätte. Interessanter ist sogar noch der Umstand, dass auch alle anderen Logfiles im Container leer zu sein scheinen.

Wieso folgt die Nextcloud App nicht dem Best-Practice, bindet var/log des Hosts in den Container mit ein und legt die log files der App dort ab ?

Grüße,
Ludwig

Hallo,

Die Logdatei wird im data Verzeichnis angelegt:

/var/lib/univention-appcenter/apps/nextcloud/data/nextcloud-data/nextcloud.log

Guter Punkt. Ich leite das mal als Feedback an Nextcloud und unser App Center Team weiter.

Schönen Gruß,
Michael Grandjean

Best Practice wäre für mich, syslog zu nehmen (Logging Configuration) und nicht das Log im Data-Verzeichnis abzulegen. Das wird im Container aber schwierig.

Da hat sich das log versteckt… Danke für den Hinweis.

Jetzt ist auch das Problem klar. Der LDAP Bind im Dockercontainer schlägt fehl aufgrund falscher credentials… Große Frage: Wie passiert so was von heute auf morgen ?

Grüße,
Ludwig

[quote=“lw3234”]Jetzt ist auch das Problem klar. Der LDAP Bind im Dockercontainer schlägt fehl aufgrund falscher credentials… Große Frage: Wie passiert so was von heute auf morgen ?
[/quote]
Nextcloud benutzt offensichtlich das Maschinenkonto des Docker-Wirtes. Während des Setups kann man das ja prima aus /etc/machine.secret auslesen. Das funktioniert allerdings nur bis zum nächsten Passwortwechsel. Dann muß es aktualisiert werden. UCS hat dafür eigentlich auch einen Mechanismus (Skript in /usr/lib/univention-server/server_password_change.d/ platzieren). Mich deucht, dass so etwas für Nextcloud fehlt.

EDIT: Ich habe dazu github.com/nextcloud/univention-app/issues/6 angelegt.

[quote=“ahrnke”][quote=“lw3234”]Jetzt ist auch das Problem klar. Der LDAP Bind im Dockercontainer schlägt fehl aufgrund falscher credentials… Große Frage: Wie passiert so was von heute auf morgen ?
[/quote]
Nextcloud benutzt offensichtlich das Maschinenkonto des Docker-Wirtes. Während des Setups kann man das ja prima aus /etc/machine.secret auslesen. Das funktioniert allerdings nur bis zum nächsten Passwortwechsel. Dann muß es aktualisiert werden. UCS hat dafür eigentlich auch einen Mechanismus (Skript in /usr/lib/univention-server/server_password_change.d/ platzieren). Mich deucht, dass so etwas für Nextcloud fehlt.
[/quote]

Das ist natürlich schon ärgerlich, wenn sich solche Schnitzer noch in der App befinden nachdem sie im UCS App Center veröffentlicht wurde…
Ich konnte den Verdacht zwischenzeitlich bestätigen und das Problem fürs erste wie folgt lösen:

  1. In den nextcloud Docker Container wechseln:
univention-app shell nextcloud
  1. Als www-data user über das bei nextcloud/owncloud mitgelieferte Admin tool occ die ldap config auslesen und die Nummer der Konfiguration merken (e.g. “s01”).
    Man sieht dann auch schön, dass als “ldapAgentName” der Docker Host verwendet wird.
sudo -u www-data php /var/www/html/occ ldap:show-config
  1. Setzen des neuen ldap Bind-Passworts (ausgelesen aus etc/machine.secret des Docker Wirts)
sudo -u www-data php /var/www/html/occ ldap:set-config s01 ldapAgentPassword AKTUELLESPASSWORD

Danach ging der Login sofort wieder. Die Konfiguration kann mit “sudo -u www-data php /var/www/html/occ ldap:testconfig” auch geprüft werden.

1 Like

Hallo,
da ich auch gerade Nextcloud installiert hatte und ich hinsichtlich des data-Verzeichnisses recht schnell bei diesem Thread gelandet hin, würde ich gerne kurz einhaken und nachfragen, ob einer der Beteiligten schonmal das nachfolgend geschilderte Problem hatte:
Nach der Installation und dem versymlinkten data-Verzeichnis sah zunächst alles gut aus, bis ich nc-Apps nachinstallieren wollte. Hier lädt sich nc zu Tode und im Logfile finde ich “curl_error 7”, es kann keine Verbindung aufgebaut werden.
Die Details dazu stehen in diesem Thread. Leider ist das meine erste Berührung mit Docker, daher weiß ich nicht, ob es an Docker selbst hängt (bzw. der Host-Config) oder dem Nextcloud-Container. Wäre dankbar für Hinweise.
Viele Grüße
Holle H.

Ich bin bisher nicht auf das Problem gestoßen und habe mehrere nc-Apps nachinstalliert sowie das Dataverzeichnis ebenfalls per Symlink verschoben.

Mastodon