Registration of the workspace is unskippable in version 6.5

[provelo-ict]

Hello,

I've had an instance of Rocket.Chat running for three years now, and I've never had the need (let alone the desire) to register it as I don't use push notification nor store addons or anything that are limited to subscribed users.

After upgrading to version 6.5, the admin account get the modal below, without the ability to skip this step or the continue the wizard without registering.

This issue is similar to #31157 but I want to focus on the fact that there should be a way to skip the registration. This would also be needed for instances in test environments.

Server Setup Information:

• Version of Rocket.Chat Server: 6.5
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Number of Running Instances: 1

[Gummikavalier]

Indeed there are circumstances where you simply cannot connect to cloud.rocket.chat for registering. Not even once.

[ExTechOp]

I'm sorry to say that sneaking in undocumented stuff like into upgrades makes me lose faith in the integrity and trustworthiness of the Rocket.chat developer team.

[72tlukas72]

Just look at 2.5k issues. That faith is already gone...

Same problem in airgap with docker.

[LeeThompson]

This is extremely lame of RocketChat.

[maswan]

I don't appreciate suddenly being cut off from communicating with my team, especially when we have to discuss if the terms and conditions and privacy policy for the cloud account are acceptable to our organization.

[florisvangeel]

If you set the environment variables properly for the registration fields needed in this wizard then the option environement flag to OVERWRITE_SETTING_Show_Setup_Wizard=completed should still be available in 6.5.0

[provelo-ict]

If you set the environment variables properly for the registration fields needed in this wizard then the option environement flag to OVERWRITE_SETTING_Show_Setup_Wizard=completed should still be available in 6.5.0

Thanks a lot @florisvangeel !

So for someone using snap, it means creating a file /var/snap/rocketchat-server/common/override-setup-wizard.env (the name of the file itself could be anything as long as it has an .env extension) and setting its content to OVERWRITE_SETTING_Show_Setup_Wizard=completed

Then, restarting the server by systemctl restart snap.rocketchat-server.rocketchat-server.service

[florisvangeel]

Seems this issue can be closed. Thank you for the continuous great work @Rocket.Chat Team.

[TLINDEN]

Doesn't work for me. I have set the environment variable:

I have no name!@rocketchat-fitsintegration-rocketchat-5478d9df75-dw8hh:/app/bundle$ echo $OVERWRITE_SETTING_Show_Setup_Wizard
completed

But when I visit the page after the update, there's still the registration wizard active and wants me to complete the process w/o any "skip" function anywhere.

[Cloud-Kid]

The solution provided by @provelo-ict worked for me in a docker environment ! But for how log before the team doesn't allow it at all ? :(

[amsnek]

OVERWRITE_SETTING_Show_Setup_Wizard=completed -> this does not work anymore in 6.6.x?

[provelo-ict]

OVERWRITE_SETTING_Show_Setup_Wizard=completed -> this does not work anymore in 6.6.x?

Works for me in 6.6.2, but I have to restart the service after every update to make the Wizard disappear.

[amsnek]

restarting in 6.6.3 did not work for me but a community member pointed out to this solution:

db.rocketchat_settings.update({"_id":"Show_Setup_Wizard"}, {$set: {"value" : "completed"} });

[TLINDEN]

I added this setting, but the wizard came up anyway.

[amsnek]

you need to restart rocketchat i also have additionally the environment setting: OVERWRITE_SETTING_Show_Setup_Wizard=completed

-> but that alone didnt suffice (anymore) I have rolled back from 6.6.x to 6.5.x because a lot of chat histories freeze the browser/client when entering such chats after I updated from 6.5.3 -> 6.6.3

[TLINDEN]

you need to restart rocketchat

Yeah, I'm deploying the helm chart with ansible to K8S, so it's being restarted anyway.

But I saw, that going from 6.5.x => up the setting works. It only doesn't work going from 6.4.x => 6.5.

-> but that alone didnt suffice (anymore) I have rolled back from 6.6.x to 6.5.x because a lot of chat histories freeze the browser/client when entering such chats after I updated from 6.5.3 -> 6.6.3

Oh, good to know, is there an issue for this already?

[amsnek]

No issue for that, i have seen some commuity reports, but I am still uncertain about the possible causes. Initially i thought it was related to (historic) Jitsi Calls in those rooms/chats -> but I am not sure anymore, still trying to pinpoint. I will try a new update approach from latest 6.5.4 -> 6.60. What seems a bit odd though, it doesnt do the usual "run migrations"

[amsnek]

edit: never mind, still freezing on certain chats / rooms etc after going to 6.6.0

[florisvangeel]

true, there is no 'substantial changes' between 6.5.4 and 6.6.0 so no migrations needed.

This combination of client (app) enforced upgrades (current <12 days to 6.6.3) and unstable/funneled new version 6.6.x that enrols automatically into a subscription of 'Starter Licence' is deadly for user-land and potentially also for community usage.

Until this is fixed i have to stick to 6.5.x and change API reported version to match the client check to keep the app behaving.

[amsnek]

@florisvangeel that is an interesting approach, how do you change the reported version for the API? adjusting the contents from /api/info?

[smirnovegorv]

Horrible behavior. Truely horrible. Setting OVERWRITE_SETTING_Show_Setup_Wizard: completed in my docker-compose.yml environment section worked, but thats the last call. Each Rocket Chat update now breaks something, removes features (like read receitps when updating from older versions) and forces cloud registration now. That's really a sign to switch to some other chat.

[florisvangeel]

@florisvangeel that is an interesting approach, how do you change the reported version for the API? adjusting the contents from /api/info?

yes i still need to test this method also in relation to future working updates, it would drill down to getServerInfo.ts or one level deeper

[amsnek]

@florisvangeel k, thanks! I am pondering if I should provide a "customized" /api/info on the reverse proxy for electron clients in the future (minimumClientVersions). Not sure if i would want to adjust the "version" (server) itself

[florisvangeel]

@florisvangeel k, thanks! I am pondering if I should provide a "customized" /api/info on the reverse proxy for electron clients in the future (minimumClientVersions). Not sure if i would want to adjust the "version" (server) itself

me neither, still need to test this route with updates, most likely within this json and introduce an environment flag like OVERWRITE_SETTING_allow_update (default: false) to keep things sane.

[florisvangeel]

@amsnek i like your idea to tackle this for the time being in the proxy serving a single json statically on /api/info buys us some time to fix this properly.

[jittygitty]

I just found this thread. For those of you who had trouble bypassing registration and agreement to their cloud privacy policy, please make sure that you create the environment variable set to completed for the user the user that rocketchat service is running under (usually 'rocketchat'?). Since setting that environment variable worked for me. See my issue: https://github.com/RocketChat/Rocket.Chat/issues/32658

Does anyone have confirmation that setting that OVERWRITE_SETTING_Show_Setup_Wizard=completed actually does OPT-OUT of any data sharing to their cloud and doesn't just make the codebase think that you already "AGREED" and completed their form to agree to their privacy policy and data sharing etc? Would be great if someone can confirm this.

[Gummikavalier]

Traditionally RocketChat has called to home in many ways: One of the clearest is the use of go.rocket.chat help links on the home page call home from the client addresses. Every link triggers through their own server at that address.

Also marketplace, online registration and update checks actively use RocketChat cloud services.

Home page used to have direct links to call for different kind of registration schemes but those have been removed.

At one point there were also several trackers assigned but not anymore; I think the RC devs were was just tracking out their user base size to consider their sales tactics. With open source this has always been quite hard to measure.

[amsnek]

Yes, while I do not know what RC wants to access (probably things like latest version, Marketplace information, etc ?) it does attempt to connect to the internet. For me, the UID under which it runs is not allowed to create outgoing connections.

[jittygitty]

Thanks for the info, any of you using portmaster or opensnitch or other application firewall to more easily detect such outgoing traffic? amsnek using iptables -A OUTPUT -m owner --uid-owner rocketchat -j DROP ? (thought that might break chat functionality)

[amsnek]

in my case, it is still just with iptables with OUTPUT -m owner --uid , with REJECT and not DROP howerver, else the application will hang quite a while on startup. It can reply to established incoming connections of course from the reverse proxy/lb (haproxy) :)

[jittygitty]

@amsnek Great! That sounds like a good setup, thanks for the tip!

[Gummikavalier]

Note that if you use message previews, fetching and parsing of those happens on the server side. So you should be specific on what connections to cut. (If you test this out old messages previews keep working as they are cached in the database for a certain time.)

[amsnek]

good point. Previews (I assume you mean loading images, videos or apps like giphy etc) are disabled in my setup though, so that is not an issue. Might still be possible to reject/ristrict outgoing traffic with a (whitelist) proxy though.

[jittygitty]

I purposefully disable previews etc if there's option to, so I guess this limitation would be a "feature" for me?