Today I was playing with Rocket.Chat, a neat open source web chat platform / framework with a lot of useful features. Unfortunately, the project still has a lot of issues during the installation and first configuration phases; for this very reason, within the first few hours I had to deal with several issues that were not documented in the official site and/or within the GitHub's issues tab.
More specifically:
- The Heroku one-click installer is broken (at the time of writing).
- The ROOT_URL configuration settings works in a misleading way and can easily prevent you from being able to run the app.
Unfortunately, at the time of writing there are no working fixes for the first issue (see issues #16179 and #16333, both still open and unresolved as of today); the only way to get over it is to perform a Manual Installation by strictly following the instructions given by the official website, which are basically OK - at least for CentOS 7 and 8.
The issue
As for the latter issue, here's a breakdown summary for the problem: during the manual installation phase, you'll have to specify the remotely accessible URL for your own Rocket.Chart service, which will be in the following form:
- http://your-website.com:3000/
More precisely, you'll have to write it down in an Environment Variable called ROOT_URL, which is contained within the /lib/systemd/system/rocketchat.service file. If you type it properly (and don't want to change it afterwards) you'll be good to go: however, if you want (or need) to change it later on, you'll easily notice that all the subsequent changes you might want to apply to that environment variable won't work: as a matter of fact, the web service will still continue to listen to the old file.
Such odd behaviour can be easily confirmed by launching a systemctl status rocketchat and see the Site URL parameter that will be shown in the console: you'll always see the firstly inserted ROOT_URL value there, regardless of any change you might have made to the ROOT_URL variable afterwards.
It goes without saying that I tried to reload the units...
|
1 |
systemctl daemon-reload |
... and also to restart the web app...
|
1 |
systemctl restart rocketchat |
... and even to reset the server by issuing a reboot command: unfortunately, none of those workaround worked.
The reason
After almost an hour I finally found the underlying reason of the problem: it seemed like, when the service is launched for the first time, it reads the ROOT_URL value and immediately writes it within the MongoDB database; such db-stored value becomes then the only "source" that the web app actually reads on all subsequent starts, thus ignoring the ROOT_URL environment variable since then.
That's definitely a strange behaviour to deal with an environment variable, isn't it?
The fix
Luckily enough, once the underlying cause of the issue has been exposed, the fix was easy enough to pull off:
- Open a Terminal session (or a SSH shell)
- Open a mongo shell by typing mongo
- type use rocketchat to switch to the rocketchat database.
- type db.rocketchat_settings.update({"_id" : "Site_Url"},{$set:{value:"<YOUR NEW URL>"}}) to change the former Site_Url value stored within the DB with a new one of your choice; needless to say, replace the <YOUR NEW URL> placeholder accordingly to suit your needs.
Conclusions
That's it, at least for now: I definitely hope that this post will help some system / network administrators who are trying to figure out why their Rocket.Chat instance's Site URL is not changing at all despite all the changes performed on the ROOT_URL environment variable.
