Univention nextcloud join

Habe ein Problem beim joinscript von nextcloud:

hier der Logauszug

nivention-run-join-scripts started
Mi 8. Mär 11:11:32 CET 2017

RUNNING 50nextcloud.inst
2017-03-08 11:11:36.309471468+01:00 (in joinscript_init)
Object exists: cn=services,cn=univention,dc=studenten,dc=hs-bremerhaven,dc=de
Permission denied.
Permission denied.
Not updating nextcloud/ucs/modifyUsersFilter
Not updating nextcloud/ucs/userEnabled
Not updating nextcloud/ucs/userQuota
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=studenten,dc=hs-bremerhaven,dc=de
ERROR: Failed to create settings/ldapschema object.
Permission denied.

Permission denied.
LDAP Error: No such object
E: object not found
LDAP Error: No such object
E: object not found
LDAP Error: No such object
E: object not found
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0curl: (51) SSL peer certificate or SSH remote key was not OK
EXITCODE=0

Mi 8. Mär 11:11:40 CET 2017
univention-run-join-scripts finished

ucs 4.1-3 errata360 und nextcloud 11.0.1 ist installiert.

Hat Jemand eine Idee wo ich suchen muss??

Gruß
Henry Otten

Hallo,

ich habe einen Verdacht, bräuchte aber Gewissheit: Welche Serverrolle hat der UCS?

ucr get server/role

Schönen Gruß,
Michael Grandjean

der owncloud/nextcloud server ist domaincontroller-slave

Hallo,

leider funktioniert das Joinscript aktuell nicht auf UCS Member oder Slave Systemen … :frowning:
Die Meldungen “Permission denied.” kommen daher, dass das Joinscript versucht Objekte im LDAP anzulegen, die Befehle dazu sich aber nicht authentifizieren. Auf UCS Slaves und Memberservern ist das aber Pflicht.
Wir können entweder versuchen hierüber das Joinskript zu patchen (gerne Bescheid sagen) und die Authentifizierung nachzurüsten oder man nimmt erstmal einen UCS Master oder Backup.

Weiter unten kommt es noch zu einem SSL-Fehler, dazu bitte mal hier schauen: nextCloud join Skript Fehler

Schönen Gruß,
Michael Grandjean

uns wäre an einem gepatchten Script sehr gelegen. Da der Server in der Tat als Slave an einem vorhandenen Domaincontroller laufen soll

Hallo,

vorneweg der Disclaimer: Das ist keine offiziell abgesegnete Lösung, sondern ein Workaround, der für mich funktioniert hat. Keine Garantie für irgendwas :slight_smile:

Bitte zunächst das originale Joinscript wegsichern:

cp /usr/lib/univention-install/50nextcloud.inst /var/univention-backup/

Dann das modifizierte Script im Anhang an die passende Stelle kopieren:

cp 50nextcloud_patched.inst.txt /usr/lib/univention-install/50nextcloud.inst

Nun noch den Marker für’s Update entfernen:

rm /var/lib/univention-appcenter/apps/nextcloud/conf/initial_config_done

Und nun das Joinscript nochmal forciert ausführen:

univention-run-join-scripts --force --run-scripts 50nextcloud

Das sollte nun zum gewünschten Ergebnis führen.
Auf jeden Fall sollte aber auch auf die aktuelle UCS Version 4.1-4 inkl. neuestem Errata-Stand aktualisiert werden :slight_smile:

Schönen Gruß,
Michael Grandjean

Hallo,

gestern gab es ein kleines Update der Nextcloud App und das hier beschriebene Problem ist dort behoben (ich habe das im vorangegangenen Post erwähnte gepatchte Joinscript daher auch entfernt).

Schönen Gruß,
Michael Grandjean

Nach der Ausführung des Join scripts für die nextcloud kann ich leider keinen User aus dem LDAP anmelden. Im Log steht dazu folgende Meldung:

{"reqId":"Zf9lJcm+nWZMiZUzEBAD","remoteAddr":"172.17.42.1","app":"user_ldap","message":"No LDAP Connection to server kopano.firma.de","level":3,"time":"2017-05-02T15:24:38+00:00","method":"POST","url":"\/nextcloud\/index.php\/login","user":"--","version":"11.0.2.7"}

Der nc_admin logon funktioniert ohne Probleme. Allerdings läd er sich ohne Fehlermeldung einfach tod beim Versuch die Userliste zu laden. Im Admin Menü von Nextcloud kann ich einen LDAP Server einstellen, wie finde ich die Daten raus die da rein gehören? Geht schon bei Server Adresse los, da das Teil ja in nem Docker Container läuft und hört beim User auf. Sonst wird das alles immer automatisch eingerichtet wenn ne neue App installiert wird, da ist dann wohl was schief gelaufen :frowning:

Hallo,

ich habe ein neues System mit Kopano und Nextcloud aufgesetzt (4.1-4 errata413) und hänge an der selben Stelle mit Nextcloud.

ucr get server/role --> domaincontroller_master

Unter join-status steht --> 50nextcloud ausstehend auch das Ausführen erzwingen ändern nicht:

univention-run-join-scripts started
Fr 5. Mai 15:41:58 CEST 2017

RUNNING 50nextcloud.inst
2017-05-05 15:41:59.479352830+02:00 (in joinscript_init)
Object exists: cn=services,cn=univention,dc=icemailer,dc=de
Object exists: cn=Nextcloud,cn=services,cn=univention,dc=icemailer,dc=de
WARNING: cannot append Nextcloud to service, value exists
No modification: cn=server,cn=dc,cn=computers,dc=icemailer,dc=de
Not updating nextcloud/ucs/modifyUsersFilter
Not updating nextcloud/ucs/userEnabled
Not updating nextcloud/ucs/userQuota
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=icemailer,dc=de
INFO: No change of core data of object nextcloud.
No modification: cn=nextcloud,cn=ldapschema,cn=univention,dc=icemailer,dc=de

Waiting for activation of the extension object nextcloud: OK
Object exists: cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
E: Object exists: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
No modification: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
E: Object exists: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
No modification: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
E: Object exists: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
Object modified: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=icemailer,dc=de
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or --insecure) option.
EXITCODE=0

Fr 5. Mai 15:42:02 CEST 2017
univention-run-join-scripts finished

Ich habe kein letsencrypt oder andere Zertifikate installiert.

Leider jetzt total ratlos.

Danke

Frank

@identt: Sorry, übersehen. Der Teil aus /var/log/univention/join.log für das Joinscript 50nextcloud.inst wäre interessant (jeweils ab “RUNNING 50nextcloud.inst”). Ich vermute dass das Skript “erfolgreich” beendet wurde, aber unterwegs doch die LDAP-Config nicht bei der Nextcloud-API angekommen ist.

@my_ucs_2017: Vielleicht hilft schon folgender Befehl: update-ca-certificates --fresh
Und dann nochmal univention-run-join-scripts.

Herzlichen Dank - das hat geholfen.

Jetzt mal sehen wie es aussieht, wenn ich

  • das Update auf 4.2 mache
  • letsencrypt einrichte

Oder gehst Du dann von Problemen aus?

RUNNING 50nextcloud.inst
Ignoring /var/cache/univention-appcenter/noctua-3.0_20170405092200.ini because of id: Invalid format
2017-05-02 16:41:00.022028480+02:00 (in joinscript_init)
Object exists: cn=services,cn=univention,dc=identt-gmbh,dc=intranet
Object exists: cn=Nextcloud,cn=services,cn=univention,dc=identt-gmbh,dc=intranet
WARNING: cannot append Nextcloud to service, value exists
No modification: cn=ucs-3348,cn=dc,cn=computers,dc=identt-gmbh,dc=intranet
Not updating nextcloud/ucs/modifyUsersFilter
Not updating nextcloud/ucs/userEnabled
Not updating nextcloud/ucs/userQuota
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=identt-gmbh,dc=intranet
INFO: No change of core data of object nextcloud.
No modification: cn=nextcloud,cn=ldapschema,cn=univention,dc=identt-gmbh,dc=intranet

Waiting for activation of the extension object nextcloud: OK
Object exists: cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (51) SSL peer certificate or SSH remote key was not OK
EXITCODE=0

Hm, wohl doch nicht ganz so reibungslos. Also die Felder für den LDAP sind nach dem admin Login in Nextcloud leer. Was muss denn dort manuell nachgetragen werden damit das Ganze wieder läuft? Meine Zertifikate sind von Let’s Encrypt und laufen auch im normalen Betrieb ohne Probleme.

Hallo,

ich bin eher dafür das SSL-Problem auszuräumen und dann das Joinscript nochmal auszuführen. Dann können wir auch sicher sein, dass alles an Ort und Stelle ist.

Bei Let’s Encrypt kann es notwendig sein, deren Root- und Intermediate-Zertifikate dem UCS als vertrauenswürdig beizubringen.
Ohne es komplett durchgetestet zu haben, sollte es wie folgt funktionieren:

Ordner unterhalb von /usr/local/share/ca-certificates/ erstellen und dort hinein wechseln:

mkdir /usr/local/share/ca-certificates/letsencrypt
cd /usr/local/share/ca-certificates/letsencrypt

Dann dorthin das Root Cert und die Intermediates von Let’s Encrypt herunterladen:

wget https://letsencrypt.org/certs/isrgrootx1.pem.txt -O isrgrootx1.crt
wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt -O lets-encrypt-x3-cross-signed.crt
wget https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt -O letsencryptauthorityx3.crt

Wichtig ist das Umbenennen der Dateiendung in .crt
Dann machen wir das System noch mit den neuen Zertifikaten vertraut:

update-ca-certificates 
Updating certificates in /etc/ssl/certs... 3 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.

Anschließend das joinscript 50nextcloud.inst nochmal forciert ausführen. Entweder über die UMC oder auf der Kommandozeile wie folgt:

univention-run-join-scripts --force --run-scripts 50nextcloud.inst

Und dann nochmal in die join.log schauen bzw. testen ob es nun funktioniert.

RUNNING 50nextcloud.inst
2017-05-09 13:04:56.821687997+02:00 (in joinscript_init)
Object exists: cn=services,cn=univention,dc=identt-gmbh,dc=intranet
Object exists: cn=Nextcloud,cn=services,cn=univention,dc=identt-gmbh,dc=intranet
WARNING: cannot append Nextcloud to service, value exists
No modification: cn=ucs-3348,cn=dc,cn=computers,dc=identt-gmbh,dc=intranet
Not updating nextcloud/ucs/modifyUsersFilter
Not updating nextcloud/ucs/userEnabled
Not updating nextcloud/ucs/userQuota
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=identt-gmbh,dc=intranet
INFO: No change of core data of object nextcloud.
No modification: cn=nextcloud,cn=ldapschema,cn=univention,dc=identt-gmbh,dc=intranet

Waiting for activation of the extension object nextcloud: OK
Object exists: cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudUserEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudUserQuota,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
E: Object exists: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
No modification: cn=nextcloudGroupEnabled,cn=nextcloud,cn=custom attributes,cn=univention,dc=identt-gmbh,dc=intranet
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (51) SSL peer certificate or SSH remote key was not OK
EXITCODE=0

Di 9. Mai 13:05:00 CEST 2017
univention-run-join-scripts finished

Leider wieder kein Glück. Muss ich vielleicht die externe Domain eintragen die curl dann versucht aufzurufen? Habe häufiger das Problem das irgendwo firma.intranet steht und dann natürlich nix geht… Wo holt er das Zertifikat denn her was er da validiert?

Hallo,

achso, d.h. das Let’s Encrypt Zertifikat ist auf eine externe Domain ausgestellt und der interne Hostname ist komplett anders? Daran hatte ich gar nicht gedacht. cURL redet mit dem lokalen Apache und spricht über https://${hostname}.${domainname}/nextcloud die API an. Das matched dann sicher nicht mit dem Zertifikat. Das ist jetzt auch gar nicht so trivial zu automatisieren, wie mir scheint (also nicht mit den Mitteln die wir aktuell haben), denn das Nextcloud joinscript weiß ja gar nicht über welche externe Domain Nextcloud erreichbar ist (wo das Zertifikat dann stimmen würde).
Die elegante Variante ist nun, das Zertifikat auf den externen und den internen FQDN auszustellen. Aber bei .intranet oder .local Domain wird das nicht durch die Validierung der Zertifizierungsstelle gehen :slight_frown:
Stattdessen würde ich temporär dem Apache wieder das originale, von der UCS CA ausgestellte Hostzertifikat geben, dann das joinscript nochmal ausführen und danach wieder das Let’s Encrypt Zertifikat aktivieren.

Nächster Fehler:

Neue Installation UCS 4.2.0, Kopano und Nextcloud. KEIN Zertifikat.

Woran kann dies nun liegen?

Sowohl Server wie Client liegen im 192.168.0.0/24 Netz - woher kommt die 172er IP?

Grüße

Frank

Das ist ein “internes” Netz für Docker (und auch Docker-Standard und nichts UCS-spezifisches). Dein Server hat auch ein Bridge-Interface docker0 mit genau der IP über das der Netzwerkverkehr von und zu den Containern läuft.

Um das Problem zu verstehen bräuchten wir mindestens die relevanten Auszüge aus folgende Dateien:

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

Hallo,

anbei die zwei Logs…

nextcloud.log (16.8 KB)
join.log (6.8 KB)

Danke

Frank

Hm, da scheint wirklich was grundlegendes im Argen zu liegen. Im joinscript klappt auch schon die Verbindung zur Nextcloud API nicht sauber:

Could not Administrator to admin group, because user was not found:
<?xml version="1.0"?> <ocs> <meta> <status>failure</status> <statuscode>404</statuscode> 
<message>Invalid query, please check the syntax. API specifications are here: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services. DEBUG OUTPUT: </message> </meta> <data/> </ocs>

Da hab ich jetzt so auch keine wirklich Idee. Wir könnten aber versuchen dem Joinscript etwas mehr Informationen zu entlocken:

  • Unter /var/lib/univention-install/50nextcloud.inst liegt das Joinscript. Die Datei einmal wegsichern. Das Original dann bitte mal mit dem Editor der Wahl öffnen.
  • In der ersten Zeile an das #!/bin/bash ein -x anhängen, also so: #!/bin/bash -x
  • Dann das Joinscript nochmal forcieren: univention-run-join-scripts --force --run-scripts 50nextcloud.inst
  • Dann nochmal die join.log anhängen

Hallo,

anbei das neue

join.log (193.8 KB)

Danke und Grüße

Frank

Mastodon