Also Push scheint in der Docker-Inkarnation von Rocketchat (Version 0.74.2) im UCS noch nicht zu funktionieren. Sollte es aber, wenn man die Rocketchat App für Mobile und das Gateway von denen benutzt.
Jemand die gleichen Erfahrungen gemacht?
Schade, muss ich wohl auf eine neuere Version warten. Ohne Push nutzt mir das nichts …
Hello,
here a translation for our international readers.
Subject: Rocket.Chat Push
So Push doesn’t seem to work in the Docker incarnation of Rocketchat (version 0.74.2) in UCS yet. But it should, if you use the Rocketchat app for mobile and the gateway from them.
Anyone had the same experience?
Too bad, I have to wait for a newer version. Without Push it doesn’t help me …
Best regards,
Nico
Can you provide more details please? Have you tried in admin the test push button? Are they not working for iOS or Android? Have you tried both?
Push notifications definitely are working others. So this must be something in setup. Will try and help you get to the bottom of it.
Hello, I currently only have the opportunity to test with an iOS device. With “Send a test push to my user” and logged in admin account in the Rocketchat app comes the message “Your push was send to 1 devices”. But the iPhone remains silent.
Here the Log:
rocketchat: logger server.js: 199 System ➔ error Error sending push to gateway (3 try) -> {Error: connect ETIMEDOUT 3.93.26.21:443 at Object._errnoException (util.js: 992: 11) at _exceptionWithHostPort (util.js: 1014: 20) at TCPConnectWrap.afterConnect [as oncomplete] (net.js: 1186: 14) code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect', address: '3.93. 26.21 ', port: 443}.
I use the Rocket.Chat Gateway - not a self-compiled app.
On the same UCS installation Mattermost works with Push. So is it a problem with the Docker container from Rocketchat?
So in this thread other People have problems with Docker container, but no problem without docker: https://github.com/RocketChat/Rocket.Chat/issues/13608
Quote:
Same here - but only in a docker environment. Debian 9, native Rocket.Chat (= without docker): push works. Debian 9, Docker: push doesn’t work. (Rocket.Chat 0.74.3)
Interesting looks like its timing out while trying to connect to the push gateway.
$ dig +short gateway.rocket.chat
svc.cloud.rocket.chat.
3.93.26.21
Can you do a curl from that host and show me the output?
curl -v https://gateway.rocket.chat
Hello rc-aaron, outside the container apparently without problems:
root@intern:~# curl -v https://gateway.rocket.chat
* Rebuilt URL to: https://gateway.rocket.chat/
* Trying 3.93.26.21...
* TCP_NODELAY set
* Connected to gateway.rocket.chat (3.93.26.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; OU=EssentialSSL Wildcard; CN=*.rocket.chat
* start date: Jan 18 00:00:00 2017 GMT
* expire date: Jan 18 23:59:59 2020 GMT
* subjectAltName: host "gateway.rocket.chat" matched cert's "*.rocket.chat"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x557e0f991a90)
> GET / HTTP/1.1
> Host: gateway.rocket.chat
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< access-control-allow-headers: Content-Type, Authorization, Content-Length, X-Requested-With
< access-control-allow-methods: GET, PUT, POST, DELETE, OPTIONS
< access-control-allow-origin: *
< access-control-expose-headers: Content-Type, Authorization, Cache-Control, Expires, Pragma, X-powered-by
< cache-control: private, no-cache, no-store, must-revalidate
< content-type: text/html; charset=utf-8
< date: Tue, 19 Mar 2019 04:07:38 GMT
< expires: -1
< pragma: no-cache
< x-powered-by: Rocket Fuel and Rocketeers
< content-length: 32
<
* Curl_http_done: called premature == 0
* Connection #0 to host gateway.rocket.chat left intact
<h1>Rocket.Chat PushGateway</h1>root@intern:~#
But here is another log entry right at the beginning after a Rocketchat Server reboot. I’m not sure if it has anything to do with it:
rocketchat:logger server.js:199 LDAPHandler ➔ error { InvalidCredentialsError: Invalid Credentials
at messageCallback (/app/bundle/programs/server/npm/node_modules/ldapjs/lib/client/client.js:1419:45)
at Parser.onMessage (/app/bundle/programs/server/npm/node_modules/ldapjs/lib/client/client.js:1089:14)
at emitOne (events.js:116:13)
at Parser.emit (events.js:211:7)
at Parser.write (/app/bundle/programs/server/npm/node_modules/ldapjs/lib/messages/parser.js:111:8)
at Socket.onData (/app/bundle/programs/server/npm/node_modules/ldapjs/lib/client/client.js:1076:22)
at emitOne (events.js:116:13)
at Socket.emit (events.js:211:7)
at addChunk (_stream_readable.js:263:12)
at readableAddChunk (_stream_readable.js:250:11)
at Socket.Readable.push (_stream_readable.js:208:10)
at TCP.onread (net.js:597:20) lde_message: 'Invalid Credentials', lde_dn: null }
Hello @blue67,
it looks like either the credentials in the Rocket.Chat configuration for the LDAP connection are wrong. Please do the following to set a new LDAP password for the app and configure it in Rocket.Chat:
rocke….If you want to remember that password, a good place to save it is in the file /etc/machine.secret in the Rocket.Chat app:
$ univention-app shell rocketchat sh -c 'echo "<your new password>" > /etc/machine.secret'
Did that help?
Best regards,
Nico
aren’t push notifications only available after registering the installation with Rocket Chat? The last time I checked the univention app the first run wizard (which leads to the registration) was disabled on the univention app.
Yes, the first run wizard aka setup wizard is marked as completed in the app and some settings are made automatically. If an important setting is missing here, it would probably be enough to set the appropriate setting in the app configuration.
Best regards,
Nico
This will actually overwrite the machine.secret file on the Docker host, not inside the app’s container, as the current shell interprets that redirection. If you want the shell spawned inside the container to interpret it, you’ll have to escape everything and run it through the shell:
$ univention-app shell rocketchat sh -c 'echo "<your new password>" > /etc/machine.secret'
That has the additional advantage of handling the password properly in case it contains any type of shell-specific meta character. Otherwise the following happens:
univention-app) sees "<your new password>" and does its thing by not interpreting certain characters." before passing that argument to the univention-app command.univention-app command then executes the command echo <your new password> (note the missing quotes), and therefore the shell inside the container will act on those special characters.Hello gulden, unfortunately no change. I also tested an uninstall and reinstall of Rocketchat. On “Test Connection” always “InvalidCredentialsError”. But LDAP works for example with Kopano and Nextcloud. Hello fbartels, yes you do not get to see the Setup Wizard. It would be helpful to know if others have the same problem with Push and / or LDAP. But apparently I’m the only one here who really test that … I think Rocketchat needs a little more bug fixes in UCS 
Hello @Moritz_Bunkus,
Good catch. Thank you very much for the correction. I updated my posting accordingly.
Best regards,
Nico
Hello @blue67,
I think Rocket.Chat itself works fine. There may be some issue with the networking in the multi container setup that is used with the app here. For testing purpose, could you just temporarily deactivate the Univention Firewall on your UCS system with service univention-firewall stop to see if the behavior changes?
Best regards,
Nico.
Sorry, unfortunately, no change …
What about the URL previews, are they working? They are generated from a HTTPS request made from the server, if they are also not working, maybe the server is being blocked for outgoing connections.
I had time now and installed UCS fresh for a test with Rocketchat alone. The LDAP problem was solved, but not the push problem. That remains unresolved. I also noticed that UCS or Docker suffers from a huge problem: Lack of complete, clean uninstallation routines of the individual modules. The forum is full of questions and instructions on how the remnants of Docker installations can be completely removed … So far, all this has to be laboriously solved somehow. And not always, the whole thing is crowned with success and only a reinstallation of UCS promises success. Apps like Guacamole or Rocketchat are currently not ready for a final installation and should be moved to the beta section. Much criticism, but I still find the concept of UCS very good. Unfortunately, there is still a lack of quality control. I can see that Bitwarden will soon be available as selfhosting. That’s great. One more reason to use UCS. UCS has great potential. However, unfinished apps should be rigorously pushed into the beta section before they destroy the UCS installation.
just fyi. its not an “app” but merely a script to start and integrate it, but I’ve posted how I use bitwarden on my ucs system at Running bitwarden_rs on Univention
Hello @blue67,
thank you for your honest feedback. Can you help me with some more details? What remnants of a Docker installation would you expect to be removed?
What were your steps to reproduce it?
Best regards,
Nico
I used docker rm to remove all docker rocketchat images. Maybe I also made the mistake of just removing the images … Anyway, at the end I chose the path of a clean reinstall of UCS. The best thing would be for Docker-based apps to have a clean, complete uninstall without having to use the terminal. So by ticking a selection box. Now I have reinstalled all apps that I use. And with Rocketchat, the missing push functionality remains … And nobody from the UCS team can still confirm it with their own test installation :: Yes, Push in Rocketchat does not work. And if the problem lies with Rocketchat or UCS …