Fast keine Apps in Nextcloud nach (Neu-) Installation von UCS 5.0-2

Apps & App Center
,
#1

Ich habe mehrmals UCS 5.0-2 auf einem root-Server installiert und habe dann immer das gleiche Problem wenn ich Nextcloud hinzufüge. Aktuell ist das sie Version Nextcloud 24.0.7.
Nextcloud hat nur eine minimale Ausstattung mit Nextcloud-Apps wie in dem Screenshot unten zu sehen ist. Wenn ich die gleiche Installation auf einem anderen System durchführe dann habe ich den vollen Umfang an Nextcloud-Apps.
Bisher ist es mir nicht gelungen einen Grund dafür zu finden warum sich genau dieser root-Server sich anders verhält als alle bisherigen Systeme. Kann mir jemand auf die Sprünge helfen?

Nextcloud-missing-apps

#2

Moin,

meine erste Vermutung wäre, dass Nextcloud die Appinformationen nicht erfolgreich abrufen kann. Was sagen denn die App-Logs? (univention-app logs nextcloud).
Ein Tipp: Ich hatte selbst mal ein Problem mit der MTU-Config - Das war unter OpenStack, da war der MTU Wert für die UCS VM bzw. deren Docker und damit den Nextcloud Container höher als beim Host. Als Folge funktionierte HTTP, aber HTTPS Pakete waren zu groß und Nextcloud konnte die App-Infos nicht (sicher) abrufen.

Gruß
Jan-Luca

#3

Danke für die Rückmeldung Jan-Luca. Ich war schon im Nextcloud-docker container und habe versucht dort das Log zu lesen, aber mit dem Kommando kommt etwas wesentlich interessanteres:

~# univention-app status nextcloud
● docker-app-nextcloud.service - LSB: Start the Container for nextcloud
   Loaded: loaded (/etc/init.d/docker-app-nextcloud; generated)
   Active: active (exited) since Sun 2023-01-15 14:21:15 CET; 4 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 7962 ExecStart=/etc/init.d/docker-app-nextcloud start (code=exited, status=0/SUCCESS)

Jan 15 14:21:13 u1 systemd[1]: Starting LSB: Start the Container for nextcloud...
Jan 15 14:21:15 u1 docker-app-nextcloud[7962]: Starting nextcloud Container 02864f679a52d903f705f69a098e7dda0bc4f11f313176c987cd52cfcff928eb ....
Jan 15 14:21:15 u1 systemd[1]: Started LSB: Start the Container for nextcloud.
~# 
~# univention-app nfo
UCS: 5.0-2 errata541
Installed: letsencrypt=2.0.0-2 4.4/nextcloud=24.0.7-1
Upgradable: 
~# univention-app status nextcloud
● docker-app-nextcloud.service - LSB: Start the Container for nextcloud
   Loaded: loaded (/etc/init.d/docker-app-nextcloud; generated)
   Active: active (exited) since Sun 2023-01-15 14:21:15 CET; 4 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 7962 ExecStart=/etc/init.d/docker-app-nextcloud start (code=exited, status=0/SUCCESS)

Jan 15 14:21:13 u1 systemd[1]: Starting LSB: Start the Container for nextcloud...
Jan 15 14:21:15 u1 docker-app-nextcloud[7962]: Starting nextcloud Container 02864f679a52d903f705f69a098e7dda0bc4f11f313176c987cd52cfcff928eb ....
Jan 15 14:21:15 u1 systemd[1]: Started LSB: Start the Container for nextcloud.
~# univention-app logs nextcloud
#### 'docker logs 02864f679a52d903f705f69a098e7dda0bc4f11f313176c987cd52cfcff928eb' output:
Nextcloud is not installed - only a limited number of commands are available

                                                                   
  There are no commands defined in the "config:system" namespace.  
                                                                   

Nextcloud is not installed - only a limited number of commands are available

                                                                   
  There are no commands defined in the "config:system" namespace.  
                                                                   

Nextcloud is not installed - only a limited number of commands are available

                                                                   
  There are no commands defined in the "config:system" namespace.  
                                                                   

Nextcloud is not installed - only a limited number of commands are available

                                                                                
 Command "app:enable" is not defined.                                           
                                                                                

 Do you want to run "app:check-code" instead?  (yes/no) [no]:
 >  * Starting periodic command scheduler cron
   ...done.
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.1. Set the 'ServerName' directive globally to suppress this message
~#

Was sucht apache2 da genau für Informationen und wo?

#4

Ich glaub, dieses Log führt für das Problem nicht zum Ziel. Das sieht bei mir für ein nachweislich funktionierendes Nextcloud fast genauso aus.
Evtl. hilft ein Blick /var/lib/univention-appcenter/apps/nextcloud/data/nextcloud-data/nextcloud.log mehr.
Oder man schaut, was univention-app shell nextcloud sudo -u www-data php /var/www/html/occ app:list ggf. korrepondierend mit o.g. Log so sagt. Die Syntax ab dem “occ” steht bei Nextcloud (Using the occ command — Nextcloud latest Administration Manual latest documentation)

hth,
Dirk

#5

Ich möchte das Problem noch einmal aufgreifen.
Ich habe inzwischen UCS 5.0-4 auf den gleichen vServer installiert. Alles scheint normal zu laufen bis auf die Installation von Nextcloud in der aktuellen Version.

Auch die Installation von Nextcloud läuft durch. Während der Installation über das Web-Interface erscheint kurz eine Meldung, die sich auch in appcenter.log und management-console-module-appcenter.log finden lässt.
Der entsprechende Ausschnitt aus appcenter.log ist:

 26893 actions.install.container.6525   23-07-20 22:28:50 [ WARNING]: Updating certificates in /etc/ssl/certs...
 26893 actions.install.container.6525   23-07-20 22:28:50 [ WARNING]: Nextcloud is not installed - only a limited number of commands are available
 26893 actions.install.container.6525   23-07-20 22:28:59 [ WARNING]: Nextcloud was successfully installed
 26893 actions.install.container.6525   23-07-20 22:29:00 [    INFO]:   - installed: true
 26893 actions.install.container.6525   23-07-20 22:29:00 [    INFO]:   - version: 25.0.8.2
 26893 actions.install.container.6525   23-07-20 22:29:00 [    INFO]:   - versionstring: 25.0.8

Wieder bietet die Nextcloud in der Menüleiste nur die Punkte Dashboard, Dateien, Fotos und Aktivitäten an. Das Menü zum Installieren weiterer Apps sieht aus wie im folgenden Bild dargestellt.
U1-Nextcloud-App

Bisher hatte ich nur bei diesem einen vServer diese Probleme. Was könnte an dem System so besonderes sein, dass die Univention Nextcloud-App sich in diesem Fall nicht korrekt installieren lässt?

Danke für alle Rückmeldungen.

#6

Moin,

ich würde nochmal auf meinen Hinweis aus der ersten Antwort verweisen:

Gerade bei einem virtualisierten System ist die Chance gegeben, dass dessen konfigurierte MTU kleiner ist als in UCS eingestellt - Dadurch war der HTTPS Verkehr der Nextcloud App beim Abrufen der Appcenterdaten einfach zu groß und ist auf dem Weg verloren gegangen. Mit Herabsetzen der MTU in UCS oder Heraufsetzen in der VM Konfiguration unter das Limit sollte das Problem behoben sein.

Gruß
Jan-Luca

#7

Interessanter Ansatz. Wenn ich mir das ansehe, dann bekomme ich:

root:~# ifconfig -a | grep mtu
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
veth0baf306: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ich gehe davon aus, dass ens3 das Interface in die Welt ist und docker0 das Interface für die Nextcloud Docker App.
Muss ich irgendwelche UCS-Eigenheiten berücksichtigen, denn ich an den MTU-Einstellungen drehe und diese Einstellungen gerne permanent hätte?

#8

In meinem Projekt haben wir das damals per Ansible gelöst, dazu wurde folgende Rolle entwickelt: GitHub - univention/ansible-roles: Ansible roles to setup, configure and deploy UCS

Konkret ist Workaround die Datei /etc/systemd/system/docker.service.d/fixmtu.conf mit folgendem Inhalt zu erstellen:

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --mtu=1400 --containerd=/run/containerd/containerd.sock

Danach noch den Service durchstarten mit systemctl restart docker und der neue Wert sollte gelten.
Der Vollständigkeit halber: Hier werden die Parameter zum Start des Docker-Daemon überschrieben, falls sich diese in UCS mal ändern gilt die Änderung nicht.
Alternativ könnte man schauen, ob sich die MTU der VM hochsetzen lässt.

#9

Ich habe folgendes ausprobiert:

Auf einem neu aufgesetzten Testsystem (VMware) habe ich manuell die MTU auf 1400 gesetzt und dann Nextcloud installiert. Während der Installation wird angezeigt, dass diverse Apps aktiviert werden, zum Beispiel Mail und in der Nextcloud sieht dann alles korrekt aus.

Auf dem Problemsystem habe ich Nextcloud deinstalliert (ohne die Reste zu entfernen, die bleiben), die MTU für docker0 manuell auf 1400 gesetzt und dann Nextcloud neu installiert. Das Problem bleibt bestehen.
Vorher hatte ich fixmtu.conf angelegt und das System neu gestartet, aber das docker0 Interface hatte immer noch eine MTU von 1500. Daher der manuelle Test.
Die fixmtu.conf sah dabei so aus:

root:/etc/systemd/system/docker.service.d# ls -al
insgesamt 16
drwxr-xr-x  2 root root 4096 Jul 21 14:55 .
drwxr-xr-x 16 root root 4096 Jul 20 22:00 ..
-rw-r--r--  1 root root  113 Jul 21 14:55 fixmtu.conf
-rw-r--r--  1 root root  630 Jul 20 21:35 http-proxy.conf
root:/etc/systemd/system/docker.service.d# cat fixmtu.conf 
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --mtu=1400 --containerd=/run/containerd/containerd.sock

Von welchem System kommen denn die Nextcloud-Apps, die auf meinem UCS fehlen? Ich könnte dann prüfen, ob es bei der Verbindung zu dem System ein grundsätzliches Problem gibt.

#10

Moin,

das klingt doch erst mal vielversprechend mit dem anderen System.
Ist denn die MTU vom docker interface tatsächlich angepasst? Meine Erwartung wäre, dass die Nextcloud App nach einem Neustart, zumindest aber bei Reinstallation die Apps laden kann.
Mir war noch eingefallen, dass man nach dem Anlegen der Fix-Datei vermutlich noch ein systemctl daemon-reload ausführen muss. Weiterhin kann es sein, dass sich die MTU auch auf anderen Wegen einstellen lässt, z.B. per /etc/docker/daemon.json oder per DOCKER_OPTS.

Was die Quelle angeht: Da kenne ich mich leider nicht aus, zum Nextcloud Troubleshooting macht es vielleicht Sinn, dort direkt zu suchen/fragen: https://help.nextcloud.com/

Gruß
Jan-Luca

#11

Hallo jlk.

Auf dem VMware System ist es mir nicht gelungen das Problem nachzustellen. Ich habe aber auf dem eigentlichen System leichte Fortschritte erzielt.

  1. Test:
    Ich habe /etc/docker/daemon.json ergänzt mit "mtu" : 1400 und dann das System neu gestartet. Danach waren docker0 und ein weiteres Interface auf mtu=1400 gesetzt. In der Nextcloud ist es mir dann gelungen Apps wie mail, calendar und contacts nachzuinstallieren.
    Ich habe dann die Nextcloud-App deinstalliert und wieder neu installiert. Leider haben viele der Standard-Apps wieder gefehlt. Irgendetwas scheint also noch zu fehlen.

  2. Test
    Ich habe den kompletten UCS noch mal neu installiert. Nachdem das Webinterface zum ersten Mal komplett gestartet war habe ich wieder die daemon.json angepasst und das System neu gestartet.
    Dieses mal war das Interface daemon0 NICHT auf mtu=1400 gesetzt. Ich habe das erst einmal manuell nachgeholt und die Apps, die ich normalerweise installiere, eingerichtet. Diese benutzen kein docker, soweit ich das sehen kann. Dann habe ich das System noch einmal neu gestartet.
    Wieder steht das Interface docker0 auf mtu=1500.
    Wie war das jetzt überschriebene System eingestellt? Ich kann fixmbr.conf erstellen und sehe mit systemctl status docker einen entsprechenden Aufruf des dockerd. Sobald ich das aber mit daemon.json kombinieren will startet der dockerd nicht mehr. Ich habe synapse zum Testen installiert. Alle Interfaces haben eine mtu von 1500 und wollen sich nicht ändern lassen.

Habe ich auf dem überschriebenen System etwas anders gemacht? Bis auf die Installation der Nextcloud fällt mir aktuell nichts mehr ein.

#12

Mir fehlt die Zeit mich da mehr einzuarbeiten und das Problem dann zu lösen. Daher habe den vServer bei einem anderen Hoster aufgesetzt.

Anregungen/Ideen:

  • Könnte in der Systemdiagnose auf solche Situationen hingewiesen werden? (Unterschiedliche MTU Interfaces)
  • Könnte bei der Installation auf so eine Situation hingewiesen werden und das System möglichst gleich passend konfiguriert werden?
#13

Moin, das kann ich gut nachvollziehen, per Ferndiagnose ist es leider auch nicht einfach, da einen guten Rat zu geben.
Basierend auf den Anregungen habe ich mal einen Feature Request bei uns erstellt: Bug 56404 – Detect non-default MTU settings and possible apply them to docker interface as needed

#14

Falls interessant und hilfreich:
Der vServer mit dem Problem steht mir noch bis zum 27.09.23 zur Verfügung bis der Vertrag ausläuft und das System komplett gelöscht wird.
Ich würde das System bis dahin zur Verfügung stellen für Untersuchungen und Tests. Meldet Euch dazu direkt bei mir …

Mastodon