Hi!
I’ve seen that the latest version rocket.chat that is available in the App Center is rather dated. 3.14 was released a few days ago. Skimming through the support forum, I’ve found out that the question for updates came up a few times in the past already.
Do you have a (internal) policy on when the app is sync’ed to the latest release?
Thanks for a short clarification.
Kind regards,
M.
Yes, I would be interested in that as well.
I just changed the Docker-Compose to have the newest Version.
cd /var/lib/univention-appcenter/apps/rocketchat/compose
nano docker-compose.yaml
change image line to: image: "rocketchat/rocket.chat:latest"
Run this commands onces
cd /var/lib/univention-appcenter/apps/rocketchat/compose/
docker ps
docker stop ROCKETCHATID
docker stop MONGODBID
docker rm rocketchat_rocketchat_1
docker network rm rocketchat_appcenter_net
docker-compose down
docker network prune
docker-compose up -d
every time you want to updates rocket.chat
cd /var/lib/univention-appcenter/apps/rocketchat/compose
docker pull rocketchat/rocket.chat:latest
docker-compose down
docker-compose up -d rocketchat
But then u cant use the UCS Appcenter Updater for rocket.chat anymore. You still keep the ldap/saml settings and settings in UMC.
Use on your own risk. But we were annoyed about the updates on with this solution we kept all data and are always up to date. We are running this solution abount 6 months now with no issues.
Edit: You also could just setup your rocket.chat via docker on your own but we liked the pre settings an possibility to enable the App on user import
Thanks, @crunch for your helpful suggestion. Nevertheless, we are hoping for an official statement on an officially supported app from the app center. What’s the use of an automated update system that doesn’t do its job correctly?
Perhaps it really is some kind of known security bug that is holding Univention back. But then again, so many security fixes have been issued this year alone that it is highly recommended not to use the “official” version from the app center. Amongst then really nasty XSS vulnerabilities:
I have not done this with Rocketchat, but generally speaking there are better ways than to modify the compose file and using a mixture of docker and docker-compose commands.
docker-compose ps inside of the folder these containers do not show. To fix this simply create a file called .env inside of /var/lib/univention-appcenter/apps/rocketchat/compose. The file needs to have the following content:COMPOSE_PROJECT_NAME=rocketchat
docker-compose.yml means that changes done will be lost when there is an update of the app. Docker-compose has a mechanism called override files that will prevent changes getting lost. So just create a file called docker-compose.override.yml in the above directory with the following content:version: '2'
services:
rocketchat:
image: rocketchat/rocket.chat:3.14.0
Afterwards you can just do a docker-compose pull && docker-compose up -d to update and start your new container.
:latest personally, but rather a defined tag. But that does not mean that you need to lose ease of use. The version of a container could be stored in a variable in the .env file as well and with a small piece of bash you could automatically get their newest tag and store in back in the .env file.The following command gives you their latest non development tag: git ls-remote --refs --tags https://github.com/RocketChat/Rocket.Chat | grep -v 'rc\|develop' | sort -t '/' -k 3 -V | awk -F/ '{ print $3 }
Check https://github.com/fbartels/ucs-lightmeter/blob/master/run.sh to see how I am getting the newest tag for my Lightmeter app.
Would this work the same way for other apps?
This has worked perfectly:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ee36ad3c8db3 rocketchat/rocket.chat:3.13.3 "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 0.0.0.0:40001->3000/tcp rocketchat_rocketchat_1
7cf5bc2ea21b docker.software-univention.de/rocketchat-mongo:3.7.4 "docker-entrypoint.s…" 3 months ago Up 45 seconds 27017/tcp rocketchat_mongo_1
Should we then do the same with MongoDB?
Yes, unless a custom docker container is used for the ucs app this should work for all apps that use docker-compose. Also not only to change versions, but also to specify additional configuration. I recently explained how to use this method to add additional settings to Kopano Meet. The only thing that you cannot do with an override is removing values.
But: proceed at your own risk 
Since the database is not globally reachable I would just keep it as it is.
We have become very cautious in the meantime. Rocket.Chat releases new versions so often that we have already had problems several times. Now we write a version (of a testet Release) in the docker-compose-file for users of Rocket.Chat in EGroupware installations and no longer take every version with us.
Especially for updates with database update there is no downgrade anymore (without database backup).
We always publish an explicit reference to the database version:
Ultimately, however, every admin can also write in other versions or just latest/stable and then install the new container. Proceed as described above.
Stefan
EGroupware Community Manager
As you are either looking for alternatives or have implemented different update solutions, @StefanU, @fbartels, it seems like you are not very confident that this issue will be solved by Univention? :-/
It not entirely on Univention to be honest, but on the app provider (which is Rochet Chat itself) to submit newer versions. My intention was not to provide an alternative update solution, but simply to provide a cleaner approach to the workaround given by @crunch.
I wanted to say first of all that with Rocket.Chat it is difficult to publish a version that is stable enough and does not cause problems in any environment. The development is too dynamic for that.
But it is true that updates are necessary just because of the security fixes. That is why we also release updates for EGroupware.
Because of new functions, most users who “only” want to chat do not always need the latest version.
We provide Rocket.Chat as an installation option for EGroupware own installations. For EGroupware on UCS one then uses/integrates UCS-Rocket.Chat.
In this respect, we have not looked for an alternative solution but can do both.
We provide containers (for EGroupware installations):
https://quay.io/repository/egroupware/rocket.chat?tag=latest&tab=tags
Test it for a few days and then release it as stable.
If Univention builds/maintains the package: Yes!
Otherwise, Rocket.Chat has to take care of itself.
I don’t know exactly what the constellation is…
Stefan
It seems like the integration was actively pushed by @gulden back in 2019, he even posted a promotional blog entry on the topic back then.
Unfortunately it is not clear which of the two parties, rocket.chat or Univention is responsible for keeping stuff up to date. A similar bug report was closed a few weeks ago for formal reasons on rocket.chat’s github.
I guess we will have to wait for an official statement.
Thanks for you support!
We will probably ban Rocket Chat from UCS for us and for all customers. That would work with Docker, but it would take us away from UCSapps again. So it will either be removed completely, or we will set it up again with Ubuntu and Snap on its own machine. Hopefully there will be updates soon. In the meantime, RocketChat is probably as full of holes as a Swiss cheese.
Thanks @fbartels for sharing this efficient workaround.
However for upgrades of rocket.chat beyond 4.8.7, mongodb needs to be upgraded as well, which I am having trouble to see what the best image would be to work with. Anyone that would have a good insight here?