@ansib said in Kopano Meet behind apache reverse proxy:

Does the kwebd service have problems running behind an apache proxy?
kwebd is running under port 443 with tls enabled (with valid certificate) so apache <> kwebd is using an https connection.

No, kwebd is of no concern here since you said it works when used directly. So the issue is the Apache configuration. Not exactly sure where the issue is though.

A working Apache configuration is like this

RewriteEngine On 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

Since yours looks very similar - maybe another rule matches before those rules in your config.

@longsleep thank you for your answer. that’s what i expected. i think a solution like skype, hangouts would be nice (the solution which you or fbartels already provided). this topic can be closed or marked as solved, thank you

@fbartels
FYI - with the release of meet 1.0.0 this now works as expected. Thank you.

Pinging @domiblouw and @BigCheese. Maybe they can share what they changed.

Hi @markkahanmo,

no unfortunately still busy with other projects. If this is for a commercial deployment I’d recommend to get in contact with our support.

Thanks for the trace Thomas! This helped and there is a missing return after an error was handled and because of that later on an unhandled panic happens.

While i will fix the missing line shortly, this does not fix your problem. Since this is a configuration/setup error with a client the corresponding log entry is only logged when you enable debug logging. If you enabled that, you will see a log entry like "no request object signing alg for client_id key" which indicates, that the client configuration (in identifier-registration.yaml) has an invalid or unknown value for the request_object_signing_alg field.

@q5616417 FYI there are a few more places where you need to set this value. https://documentation.kopano.io/kopano_meet_manual/installation.html#Kopano-configuration should be helpful here.

@cguenther said in Webmeeting login with password containing special character '<' not possible:

Resetting the password one without this special character, seems to be a workaround. Nevertheless, this might indicate to a problem of not proper escaping of the password

Seems that i missed to merge one of my branches and then forgot about it. The underlaying issue is fixed in kcc-go 4.0.0 which will be part of the next Konnect release - both master branches have been updated accordingly.

Thanks for reporting!

Hi @irreleph4nt,

that value is sent to the client after he logged in and is not stored on the server side.

@longsleep
Your suspicion regarding TLS validation was spot on. Using insecure mode, things started working right away, so I looked into it and sorted out my SSL certificates. Thank you! :)

Hi @fbartels

thanks for your quick answer.

Actually the text field is missing entirely from our installation. i still was wondering since some more things were missing from our setup that were present in the documentation. Maybe instead of investing more time into kopano webmeeting i will take a look at Kopano Meet.

Thank you for your time though

Thank you for your support.
Regards.

@ansib said in Kopano WebMeeting and Plugins vs Kopano Meet:

this surplus $ is still in my binscript under /usr/sbin

Yes, I was already thinking it was something like that. I don’t think we have meanwhile tagged a new release, therefore it’s not yet in the packages.

@ansib said in Kopano WebMeeting and Plugins vs Kopano Meet:

unfortunatly there is still no video media data, only a blue screen, if i start a call.

Debugging turn is a bit more difficult. I would recommend to get in direct contact with our support so they can look at it in a remote session.

@ansib said in Kopano Meet with Kopano Web Daemon:

I changed konnectd to authentication with ldap, which does not seem to work correctly.

Yes, indeed at this moment (definitely for the packages in the “final” repo) Meet only really works with everything set to the Kopano backend. The goal for Meet (and the other apps you have spotted) is that they will in the future also work with other backends.

@ansib said in Kopano Meet with Kopano Web Daemon:

Does these three apps replace the not mobile ready webapp?

yes, eventually these app will replace the current WebApp in general. These apps are not yet public, since they just exist as simple proof of concepts. But we are making good progress on them. Have a look at https://www.youtube.com/watch?v=sz2iDNHu9JI to get some impressions how these apps will look in the future.

@fbartels said in Is Kopano WebMeetings here to stay?:

Hi @burgessja,

sadly the underlying signalling server hasn’t seen activity in quite a while, therefore we had to start looking for alternatives. In the end we decided to go for a reimplementation based on what we learned from our usage of the old product. The result of this is a new signalling server, which is for example way easier to compile and package for us.

And while there is a plugin in Mattermost this was more of a proof on concept client that was easier to implement (since Mattermost gave the framework for it) and our main focus is on a stand alone web client (we are still looking for feedback on it btw). Meet is the first of a new family of web clients, how it integrates with the old WebApp still remains to be seen, though.

This sounds interesting. I did send an email off inquiring about testing the new Meet client. So it sounds like you are working on a new WebApp as well?

The WebMeeting feature of Kopano is a big selling point for our customers. The schools that we work with will often have video chats with other educational institutions, and getting everyone to agree on the platform (Skype, Hangouts, GoToMeeting, FaceTime, Zoom, etc. ), and set up with accounts, is time consuming. While Kopano WebMeetings did have some issues, for the most part it was “Create Meeting” > “Send Link” > “Start Talking”. The ability to invite guests and the support for every operating system with no required plugins made the software very appealing.

Hi mcostan and thank you for your reply,
I have a turnserver installed but are not sure if configured right. Here’s the turn server.conf:

listening-port=3478 # Uncomment to use fingerprints in the TURN messages. # By default the fingerprints are off. # fingerprint # Uncomment to use long-term credential mechanism. # By default no credentials mechanism is used (any user allowed). # lt-cred-mech # This allows TURN credentials to be accounted for a specific user id. # If you don't have a suitable id, the timestamp alone can be used. # This option is just turning on secret-based authentication. # The actual value of the secret is defined either by option static-auth-secret, # or can be found in the turn_secret table in the database (see below). # use-auth-secret # 'Static' authentication secret value (a string) for TURN REST API only. # If not set, then the turn server # will try to use the 'dynamic' value in turn_secret table # in user database (if present). The database-stored value can be changed on-the-fly # by a separate program, so this is why that other mode is 'dynamic'. # static-auth-secret=our-auth-secret realm=our-domain-name # Total allocation quota. # default value is 0 (no quota). # This option can also be set through the database, for a particular realm. # total-quota=100 # # Maximum server capacity. # Total bytes-per-second bandwidth the TURN server is allowed to allocate # for the sessions, combined (input and output network streams are treated separately). # bps-capacity=0 # Uncomment if extra security is desired, # with nonce value having limited lifetime. # By default, the nonce value is unique for a session, # and has unlimited lifetime. # Set this option to limit the nonce lifetime. # It defaults to 600 secs (10 min) if no value is provided. After that delay, # the client will get 438 error and will have to re-authenticate itself. # stale-nonce=600 # Option to set the log file name. # By default, the turnserver tries to open a log file in # /var/log, /var/tmp, /tmp and current directories directories # (which open operation succeeds first that file will be used). # With this option you can set the definite log file name. # The special names are "stdout" and "-" - they will force everything # to the stdout. Also, the "syslog" name will force everything to # the system log (syslog). # In the runtime, the logfile can be reset with the SIGHUP signal # to the turnserver process. # log-file=/var/log/turn.log # Option to suppress STUN functionality, only TURN requests will be processed. # Run as TURN server only, all STUN requests will be ignored. # By default, this option is NOT set. # no-stun # Flag that can be used to disallow peers on the loopback addresses (127.x.x.x and ::1). # This is an extra security measure. # no-loopback-peers # Flag that can be used to disallow peers on well-known broadcast addresses (224.0.0.0 and above, and FFXX:*). # This is an extra security measure. # no-multicast-peers

The firewall allows port 3478 tcp and udp.

The log says almost nothing:

cat /var/log/turn_2018-10-09.log 287090: log file opened: /var/log/turn_2018-10-09.log

Hi Felix,
to bring this topic to an end: because you wrote, that everything is working fine for you, I did a fresh install on another machine and voilà - webmeetings is working and it looks very good :)
So, thank you for your support.