Neuinstallation Nextcloud - Script im Status "Pending" - EXITCODE=0

german
nextcloud

#1

Ich habe unseren Nextcloud Container deinstalliert, neu installiert.und anschließend die trusted_domains in der config.php angepasst. Ich kann Nextcloud über die entsprechende URL aufrufen, aber eine Anmeldung ist mit keinem User möglich. Weder als Dom-Admin, noch als User mit gesetztem LDAP NextCloud Flag.

Im Modul “Domänenbeitritt” hängt das Nextcloud Script im Status “ausstehend”.
50nextcloud ausstehend

Das Join-Log sieht für mich sauber aus. “EXITCODE=0”
Die Schemaerweiterungen und Serviceregistrierungen waren von der Vorinstallation bereits vorhanden und werden entsprechend angemeckert.

univention-run-join-scripts started
Di 26. Jun 15:01:06 CEST 2018

RUNNING 50nextcloud.inst
2018-06-26 15:01:09.928497867+02:00 (in joinscript_init)
Object exists: cn=services,cn=univention,dc=xx,dc=xx,dc=de
Object exists: cn=Nextcloud,cn=services,cn=univention,dc=xx,dc=xx,dc=de
WARNING: cannot append Nextcloud to service, value exists
No modification: cn=xx,cn=dc,cn=computers,dc=xx,dc=xx,dc=de
Not updating nextcloud/ucs/modifyUsersFilter
Not updating nextcloud/ucs/userEnabled
Not updating nextcloud/ucs/userQuota
Not updating nextcloud/ucs/debug
Not updating nextcloud/ldap/cacheTTL
Not updating nextcloud/ldap/homeFolderAttribute
Not updating nextcloud/ldap/userSearchAttributes
Not updating nextcloud/ldap/userDisplayName
Not updating nextcloud/ldap/groupDisplayName
Not updating nextcloud/ldap/base
Not updating nextcloud/ldap/baseUsers
Not updating nextcloud/ldap/baseGroups
Not updating nextcloud/ldap/filterLogin
Not updating nextcloud/ldap/filterUsers
Not updating nextcloud/ldap/filterGroups
Object exists: cn=ldapschema,cn=univention,dc=xx,dc=xx,dc=de
INFO: No change of core data of object nextcloud.
No modification: cn=nextcloud,cn=ldapschema,cn=univention,dc=xx,dc=xx,dc=de

Waiting for activation of the extension object nextcloud: OK
Object exists: cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
E: Object exists: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
No modification: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
E: Object exists: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
No modification: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
E: Object exists: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
No modification: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=xx,dc=xx,dc=de
EXITCODE=0

Di 26. Jun 15:01:14 CEST 2018
univention-run-join-scripts finished

PS:
Versessen … Sorry.

Im Apache2 unseres UCS Servers ist ein offizielles Wildcard Zertifikat hinterlegt. Ich hatte gelesen, dass die Nextcloud Installation manchmal damit Probleme hat.

Mit den offiziellen Zertifikaten bekomme ich beim Ausführen des Nextcloud Scripts diese Meldung:

curl failed with error 51
EXITCODE=51

Di 26. Jun 15:39:53 CEST 2018
univention-run-join-scripts finished

Daher hatte ich unsere Apache “default_ssl.conf” gesichert und in der aktiven Konfigurationsdatei das ursprüngliche selbstsignierte Zertifiat mit dem entsprechenden Key und der passenden CA hinterlegt.
Anschließend den Apache2 Service neu gestartet und das Nextcloud Script lief fehlerfrei durch (aber verbleibt im Status “ausstehend”, wie oben beschrieben).

Verwende ich wieder unsere default_ssl.conf mit dem Globalsign Zertifikat kommt wieder der Curl Fehler 51.

LG
Jens


#2

Ich hab derartiges kürzlich in einer ähnlichen Konstellation beim Versuch, Nextcloud neu zu installieren, auch gesehen. Leider musste ich den Versuch aus Zeitgründen abbrechen und habe daher noch keine komplette Lösung.
Wie es aussieht, betriift es aber mehrere Anwender und wir versuchen mal gemeinsam, uns dem Problem zu nähern.

Zum einen verwendet die aktuelle Integration einen lokalen Nutzer mit dem Namen “ncadmin” dessen Kennwort in "/var/lib/univention-appcenter/apps/nextcloud/conf/admin.secret" steht (oder stehen sollte).
Wenn die LDAP-Anmeldung nicht geht, kann sich im Normalfall immer noch mit diesem Konto am Nextcloud anmelden und die Konfiguration prüfen. Sollten diese Anmeldedaten auch nicht funktionieren, wird das Joinskript vermutlich auch nichts zu Stande bringen. In diesem Fall kann man aber mit dem occ-Tool (hier im Container, was noch etwas mehr “Spaß” macht) das Kennwort ändern.

Was mich sonst noch etwas wundert, ist der curl Fehler 51. Laut https://curl.haxx.se/libcurl/c/libcurl-errors.html bedeutet der "The remote server’s SSL certificate or SSH md5 fingerprint was deemed not OK. ", was insofern verwunderlich ist, da das Zertifikat in der default-ssl.conf gerade bei kommerziellen Zertifikaten ok sein sollte. Kann aber sein, dass hier durch die vorherige Installation der Reverseproxy noch nicht korrekt definiert ist.


#3

Huhu,

Ganz allgemein gesprochen: das allerhäufigste Problem mit offiziellen Zertifikaten ist, dass die ein Intermediate Certificate benötigen und dieses Intermediate curl (bzw. dem System) nicht als vertrauenswürdiges CA-Zertifikat bekannt ist. Hat man normalerweise zwei Möglichkeiten: Intermediate mit ausliefern (das wäre serverseitig zu konfigurieren), oder das Intermediate auf dem Clientsystem installieren (wie letzteres bei Debian-basierenden Systemen geht, steht u.a. hier).

Gruß
mosu