Can you record you sharing the link with https://birdeatsbug.com/?
No, it should have a #guest=1 at the end of the url.
Can you record you sharing the link with https://birdeatsbug.com/?
No, it should have a #guest=1 at the end of the url.
@UweP did you manage to resolve your issue?
PS: since we are currently working on an app appliance with Meet preinstalled I created a small script to configure the UCS host system to use a single domain for access. The script is part of a currently open pull request and can be found at https://stash.z-hub.io/projects/K4U/repos/kopano-apps/browse/kopano-meet/appliance_hook?at=1821869d2a18af46dd2639ab261e46bc876141cf
No, I couldn’t fix the problem.
I have found out in the tests that Meet can only be used with a TURN service if connections from/to outside your own network are required. But since the access to the TURN service of Kopano is probably connected to a subscription and this is for the occasional private use with 75€ per month a little bit beyond what I am willing to invest for it, I decided to stop testing with Meet. To set up my own TURN server I don’t have the knowledge and the time to get used to it, especially since I read that the setup is not exactly trivial. An installation of a TURN service within UCS is what I would like to have. That would make things round. Is such a thing planned?
Thanks for the help anyway.
Yes, but that is something that is already mentioned in the description of the app.
For optimal effect the turn service should be reachable from two ip addresses and listen on port 443. while the first may be possible on ucs, the second won’t (since the ucs apache is listening there already).
@Christian_Voelker can you move the last post into its own topic?
Hi @kidvidiot,
can you post the information from https://wiki.z-hub.io/display/K4U/Debugging+Kopano+on+Univention#DebuggingKopanoonUnivention-Containerisedapps?
Especially the curl command is interesting.
Thank you for responding so quickly! There is an upgrade in there today, let me execute it and see if that solves the issue! Thanks
Ok the update didnt make the issue go away.
root@ucs-bdc:~# univention-app info
UCS: 4.4-3 errata499
Installed: adconnector=12.0 fetchmail=6.3.26 letsencrypt=1.2.2-8 mailserver=12.0 samba-memberserver=4.7 wekan=3.56 4.3/collabora=3.4.1.1 4.3/kopano-meet=2.1.0_0-1 4.3/openid-connect-provider=1.1-konnect-0.23.3 4.3/rocketchat=0.73.2 4.2/owncloud=10.0.9-20180720 4.2/wordpress=4.9.4
Upgradable: wekan collabora rocketchat owncloud wordpress
–
root@ucs-bdc:~# curl $(ucr get oidc/konnectd/issuer_identifier)/.well-known/openid-configuration
{
“issuer”: “https://www.mydomain.com”,
“authorization_endpoint”: “https://www.mydomain.com/signin/v1/identifier//authorize",
“token_endpoint”: “https://www.mydomain.com/konnect/v1/token”,
“userinfo_endpoint”: “https://www.mydomain.com/konnect/v1/userinfo”,
“end_session_endpoint”: "https://www.mydomain.com/signin/v1/identifier//endsession”,
“registration_endpoint”: “https://www.mydomain.com/konnect/v1/register”,
“check_session_iframe”: “https://www.mydomain.com/konnect/v1/session/check-session.html”,
“jwks_uri”: “https://www.mydomain.com/konnect/v1/jwks.json”,
“scopes_supported”: [
“openid”,
“offline_access”,
“profile”,
“email”,
“konnect/uuid”,
“konnect/raw_sub”
],
“response_types_supported”: [
“id_token token”,
“id_token”,
“code id_token”,
“code id_token token”
],
“subject_types_supported”: [
“public”
],
“id_token_signing_alg_values_supported”: [
“PS256”,
“PS384”,
“PS512”,
“RS256”,
“RS384”,
“RS512”
],
“userinfo_signing_alg_values_supported”: [
“PS256”,
“PS384”,
“PS512”,
“RS256”,
“RS384”,
“RS512”
],
“request_object_signing_alg_values_supported”: [
“ES256”,
“ES384”,
“ES512”,
“RS256”,
“RS384”,
“RS512”,
“PS256”,
“PS384”,
“PS512”,
“none”,
“EdDSA”
],
“token_endpoint_auth_methods_supported”: [
“client_secret_basic”,
“none”
],
“token_endpoint_auth_signing_alg_values_supported”: [
“PS256”,
“PS384”,
“PS512”,
“RS256”,
“RS384”,
“RS512”
],
“claims_parameter_supported”: true,
“claims_supported”: [
“iss”,
“sub”,
“aud”,
“exp”,
“iat”,
“name”,
“family_name”,
“given_name”,
“email”,
“email_verified”
],
“request_parameter_supported”: true,
“request_uri_parameter_supported”: false
}
kopano_grapi /usr/bin/dumb-init – /kop … Up (healthy)
kopano_kapi /usr/bin/dumb-init – /kop … Up (healthy)
kopano_konnect wrapper.sh Up (healthy) 6777/tcp, 8777/tcp
kopano_kwmserver docker-entrypoint.sh wrapp … Up (healthy) 6778/tcp, 8778/tcp
kopano_meet /kopano/start-service.sh Up (healthy)
kopano_ssl /start.sh Exit 0
kopano_web docker-entrypoint.sh wrapp … Up (healthy) 0.0.0.0:2015->2015/tcp, 443/tcp, 80/tcp
@kidvidiot
i think i had the same problem. After reading the other thread i found, that @raceface2nd has done this:
a2enconf openid-connect-provider.conf
systemctl reload apache2
after that, it runs on my system…
hope this helps
Thank you, I saw that and tried it to no avail!
Hi @kidvidiot,
In your post you are missing the output of ucr dump | grep kopano/docker | grep -v PASSWORD
Since the curl command gets the right output and all containers have started up healthy my only conclusion so far is that oidc/konnectd/issuer_identifier
and kopano/docker/FQDN_SSO
are pointing to different domains.
Sorry - here you go:
root@ucs-bdc:~# ucr dump | grep kopano/docker | grep -v PASSWORD
kopano/docker/FQDN_MEET: ucsdesigncloud.com
kopano/docker/FQDN_SSO: ucsdesigncloud.com
kopano/docker/GRID_WEBAPP: no
kopano/docker/INSECURE: no
kopano/docker/MEET_GUEST_ALLOW: yes
kopano/docker/MEET_GUEST_REGEXP: ^group/public/.*
kopano/docker/TURN_SERVICE_URL: https://ucs-turn.kopano.com/turnserverauth/
–
From appearances, it seems like the sign in window from kopano meet is failing to connect with the openID login window in the right place, like they are missing each other
Here is openid-connect-provider
#####################################################################
#####################################################################
ProxyPass /.well-known/openid-configuration http://localhost:8777/.well-known/openid-configuration retry=0
ProxyPass /konnect/v1/jwks.json http://localhost:8777/konnect/v1/jwks.json retry=0
ProxyPassReverse /konnect/v1/jwks.json http://localhost:8777/konnect/v1/jwks.json
ProxyPass /konnect/v1/token http://localhost:8777/konnect/v1/token retry=0
ProxyPassReverse /konnect/v1/token http://localhost:8777/konnect/v1/token
ProxyPass /konnect/v1/userinfo http://localhost:8777/konnect/v1/userinfo retry=0
ProxyPassReverse /konnect/v1/userinfo http://localhost:8777/konnect/v1/userinfo
ProxyPass /konnect/v1/static http://localhost:8777/konnect/v1/static retry=0
ProxyPassReverse /konnect/v1/static http://localhost:8777/konnect/v1/static
ProxyPass /konnect/v1/session http://localhost:8777/konnect/v1/session retry=0
ProxyPassReverse /konnect/v1/session http://localhost:8777/konnect/v1/session
ProxyPass /konnect/v1/register http://localhost:8777/konnect/v1/register retry=0
ProxyPassReverse /konnect/v1/register http://localhost:8777/konnect/v1/register
ProxyPass /signin/ http://localhost:8777/signin/ retry=0
ProxyPassReverse /signin/ http://localhost:8777/signin/
I did notice in kopano-meet.conf there is a different port
Header unset X-Frame-Options
Header unset Content-Security-Policy
ProxyPass /meet http://localhost:2015/meet retry=0
ProxyPass /api/config/v1/kopano/meet/ http://localhost:2015/api/config/v1/kopano/meet/ retry=0
ProxyPass /api/gc/v1/ http://localhost:2015/api/gc/v1/ retry=0
ProxyPass /api/kvs/v1/ http://localhost:2015/api/kvs/v1/ retry=0
ProxyPass /meetid/.well-known/openid-configuration http://localhost:2015/.well-known/openid-configuration retry=0
ProxyPass /meetid/ http://localhost:2015/meetid/ retry=0
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/meet$ [OR]
RewriteCond %{REQUEST_URI} ^/meet/
RewriteRule ^(.*)$ https://ucsdesigncloud.com/meet/ [R,L]
RewriteCond %{REQUEST_URI} ^/meet$ [OR]
RewriteCond %{REQUEST_URI} ^/meet/
RewriteCond %{HTTP_HOST} !^ucsdesigncloud.com$ [NC]
RewriteRule ^(.*)$ https://ucsdesigncloud.com/meet/ [R,L]
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /api/kwm/v2/(.*) ws://localhost:2015/api/kwm/v2/$1 [P,L]
ProxyPass /api/kwm/v2/ http://localhost:2015/api/kwm/v2/ retry=0
hm… with these censored domain names its sadly impossible to say what is exactly wrong here.
Sorry, wasnt sure having it out there was secure or inviting disaster:
root@ucs-bdc:~# ucr dump | grep kopano/docker | grep -v PASSWORD
kopano/docker/FQDN_MEET: belldesigncloud.com
kopano/docker/FQDN_SSO: belldesigncloud.com
kopano/docker/GRID_WEBAPP: no
kopano/docker/INSECURE: no
kopano/docker/MEET_GUEST_ALLOW: yes
kopano/docker/MEET_GUEST_REGEXP: ^group/public/.*
kopano/docker/TURN_SERVICE_URL: https://ucs-turn.kopano.com/turnserverauth/
in each place there is only ‘bell’ replaced by ucs - thanks for looking and just let me know what else is helpful for you!
Ah, so the www. in the openid config windows wasn’t just sloppy anonymisation, but part of the actual configuration.
The value in FQDN_SSO
needs to match oidc/konnectd/issuer_identifier
(minus the https).
Ok - that makes sense - so I changed it in the UCR:
root@ucs-bdc:~# ucr dump | grep kopano/docker | grep -v PASSWORD
kopano/docker/FQDN_MEET: www.belldesigncloud.com
kopano/docker/FQDN_SSO: www.belldesigncloud.com
kopano/docker/GRID_WEBAPP: no
kopano/docker/INSECURE: no
kopano/docker/MEET_GUEST_ALLOW: yes
kopano/docker/MEET_GUEST_REGEXP: ^group/public/.*
kopano/docker/TURN_SERVICE_URL: https://ucs-turn.kopano.com/turnserverauth/
Still getting the same error, should I change it anywhere else? Thanks!
kopano_grapi /usr/bin/dumb-init – /kop … Up (healthy)
kopano_kapi /usr/bin/dumb-init – /kop … Up (healthy)
kopano_konnect wrapper.sh Up (healthy) 6777/tcp, 8777/tcp
kopano_kwmserver docker-entrypoint.sh wrapp … Up (healthy) 6778/tcp, 8778/tcp
kopano_meet /kopano/start-service.sh Up (healthy)
kopano_ssl /start.sh Exit 0
kopano_web docker-entrypoint.sh wrapp … Up (healthy) 0.0.0.0:2015->2015/tcp, 443/tcp, 80/tcp
root@ucs-bdc:/var/lib/univention-appcenter/apps/kopano-meet/compose#
Chrome output:
Feels super close though
Unfortunately I am running out of idea. Your openid provider responds with temporarily_unavailable
and therefore login fails. At least initially the openid discovery document did not properly respond on your system (but later it was).
I recommend reaching out to the Kopano support so that someone can have a direct look at your system.
I had the same problem but got it resolved.
In /etc/kopano/docker/konnectd-identifier-registration.yaml check value of key “iss”. This should point to URL of your openid provider. In my case it was pointing to UCS SSO Server.
ah yes, that is a good observation @wytia. I noticed the same yesterday on a customer system. Once the guest keys are already present in the identifier registration a change of the domain is not reflected in it.
I have just finished reworking said test and have pushed a container image which handles this better. Before continuing updating the app itself can the others in this topic confirm that guest login works if they do the following:
/var/lib/univention-appcenter/apps/kopano-meet/compose/docker-compose.yml
in an editor kopano_konnect:
# Image was: fbartels/kopano_konnect:0.30.0
image: docker.software-univention.de/kopano-meet-kopano_konnect:2.1.0_0-1
image: docker..
with the following:image: fbartels/kopano_konnect:0.30.0@sha256:53cc8b3f369e4a64104ecb4b1a39168693bc127a2fbb7200ae3f6ad8b6af3c10
docker-compose pull && docker-compose up -d
/etc/kopano/docker/konnectd-identifier-registration.yaml
if there is now an entry with the id kpop-https://your-domain/meet/
(where ¨your-domain¨ is your actual domain name).Edit: why modify the compose file? Normally I would recommend to use an override file because it would make changes persistent. But in this specific case the change should no longer stay active once the next app version has been released.
Edit2: the changed code can be found at https://github.com/zokradonh/kopano-docker/pull/377 (for those interested in it)
With the client part fixed I did look into your above message a bit more deeply. For me the value changes properly when changing this in the app settings.
With the current point release of UCS to 4.4-4 and the latest release of Kopano Meet 1.0 I decided to give it a try.
The good news: With the default settings everything worked out of the box
The bad news: Any adaptation I make leads to a non working configuration and I am slightly confused about some circumstances. Let’s start from the beginning:
My setup:
UCS 4.4-4 with a working set of the following applications:
The server and the applications are available through:
After installing Kopano Meet it runs fine using the default values (server.intern.domain.com and ucs-sso.intern.domain.com)
As those are FQDNS are available only internal I needed to change them.
Working: server.intern.domain.com AND ( id.domain.com OR ucs-sso.intern.domain.com)
Not Working: meet.domain.com AND ( id.domain.com OR ucs-sso.intern.domain.com )
The apache config for meet.domain.com looks as follows:
<VirtualHost *:443>
IncludeOptional /etc/apache2/ucs-sites.conf.d/kopano-meet.conf
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLCertificateFile /etc/univention/ssl/server.intern.domain.com/cert.pem
SSLCertificateKeyFile /etc/univention/ssl/server.intern.domain.com/private.key
ServerName meet.domain.com
</VirtualHost>
I can connect to https://meet.domain.com/meet, I am redirected to the login page on id.domain.com and after entering the credentials I end up with “ERROR 400”.
What Iam missing ?
(Checking the insecure checkbox in order to exlcude certificate problems does not change anything)
The second point I am confused about are the docker containers I have running now:
“docker ps” shows me:
8c6cba0612e5 docker.software-univention.de/kopano-meet-kopano_konnect:2.1.0_0-1 "wrapper.sh" About an hour ago Up About an hour (healthy) 6777/tcp, 8777/tcp kopano_konnect
fc11a75f3d29 docker.software-univention.de/kopano-meet-kopano_meet:2.1.0_0-1 "/kopano/start-servi…" About an hour ago Up About an hour (healthy) kopano_meet
1d607da232f9 docker.software-univention.de/kopano-meet-kopano_kapi:2.1.0_0-1 "/usr/bin/dumb-init …" About an hour ago Up About an hour (healthy) kopano_kapi
77efaaaa4048 docker.software-univention.de/kopano-meet-kopano_kwmserver:2.1.0_0-1 "docker-entrypoint.s…" About an hour ago Up About an hour (healthy) 6778/tcp, 8778/tcp kopano_kwmserver
8f9ad02043d1 docker.software-univention.de/kopano-meet-web:2.1.0_0-1 "docker-entrypoint.s…" About an hour ago Up About an hour (healthy) 80/tcp, 443/tcp, 0.0.0.0:2015->2015/tcp kopano_web
1eff67b227c6 docker.software-univention.de/kopano-meet-kopano_grapi:2.1.0_0-1 "/usr/bin/dumb-init …" 20 hours ago Up 3 hours (healthy) kopano_grapi
a81cfef1fb03 docker.software-univention.de/openid-connect-provider:1.1-konnect-0.23.3 "docker-entrypoint-u…" 4 months ago Up 3 hours (healthy) 0.0.0.0:8777->8777/tcp zen_ardinghelli
Why do I have now to “konnect” containers running ? As I described I had a running setup of OpenID Connect before installing Kopano Meet. So why has there been anyway installed a (supposingly) default containter ?
Thanks for any assistance.