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 
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
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.instliegt das Joinscript. Die Datei einmal wegsichern. Das Original dann bitte mal mit dem Editor der Wahl öffnen. - In der ersten Zeile an das
#!/bin/bashein-xanhängen, also so:#!/bin/bash -x - Dann das Joinscript nochmal forcieren:
univention-run-join-scripts --force --run-scripts 50nextcloud.inst - Dann nochmal die
join.loganhängen
Oh, schade, das Joinscript hat einen kleinen Mechanismus um zu erkennen, ob es schon mal gelaufen ist und steigt dann gar nicht mehr in den relevanten Teil ein. Kannst du folgende Datei löschen:
/var/lib/univention-appcenter/apps/nextcloud/conf/initial_config_done
und dann nochmal anstoßen?
univention-run-join-scripts --force --run-scripts 50nextcloud.inst
Sorry, das hatte ich nicht auf dem Zettel.
Guten Tag,
ich habe leider die gleichen Probleme wie Frank, daher die Frage, ob es hier schon eine Lösung gibt?
@omega: Ist es sicher das gleiche Problem? Bei Frank lautete die Fehlermeldung beim Aufruf der API:
<message>Invalid query, please check the syntax. API specifications are here: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services.
Das hab ich so noch nicht gesehen.
Was ich vorallem nicht verstehe ist, wenn ich ein System mit 4.1 aufsetzte. Kopano und Nextcloud und LetsEncrypt einrichte, dann das Update auf 4.2 mache - dann geht es.
Ebenso wenn ich 4.1 installiere, gleich das Update auf 4.2 und dann Kopano, Nextcloud und Letsencrypt.
Nur wenn ich gleich 4.2 installiere geht es nicht…
Ja, exakt gleicher Eintrag im Logfile.
Ich habe das Bild heute nach einem Neustart auch gesehen…
Mein Container hatte recht spärliche /etc/resolv.conf und /etc/hosts Dateien.
Nachdem ich da den UCS-Master eingetragen habe, geht die Anmeldung der LDAP-Benutzer wieder. Auch ich hatte den user=-- im log-file.
Allerdings gibt es noch keine Verbindung von Nextcloud zum Internet, nur:
GuzzleHttp\Exception\ConnectException: cURL error 6: Could not resolve host: www.github.com
etc.
Das scheint bei mir geholfen zu haben. Ebenfalls in der /etc/hosts im nexctloud-docker die IP des UCS-Master eingetragen und jetzt kann ich mich anmelden.
Apps kann ich auch nachziehen, daher gehe ich davon aus, dass der Internzugang funktioniert bei mir.
@Grandjean Vielleicht hilft Euch das ja, den “Fehler” zu lokalisieren.
//edit: Einziges Manko, den Eintrag in die hosts “merkt” sich der nextcloud-Docker nicht - jemand einen Tipp, wie man das permanent macht?
Kannst du noch kurz schreiben wie der Eintrag genau bei dir aussieht? Den trage ich dann mit Hilfe der Dockershell im laufenden Container ein?
Zuerst per univention-app shell nextcloud in den Container und dort dann
echo -e "<IP.IP.IP.IP>\t<HOSTNAME>" >> /etc/hosts"
Wie gesagt, ist leider nicht permanent. Vl. könnte man den Thread hier auch mal splitten, um das ungelöste Problem wieder nach oben zu bringen @Grandjean