I have Mattermost deployed through Cloudron on a locally hosted VM Linux server and whenever I go into the Mattermost System Console and change the listening address from :8065 to :443 (required to forward port 80 to 443 and enable TLS via Let's Encrypt) the server will not start on reboot. There is a note that "you must have permissions to bind to that port. On Linux you can use: "sudo setcap cap_net_bind_service=+ep ./bin/mattermost" to allow Mattermost to bind to well-known ports." - however I can't figure out how the Cloudron version was installed to direct my terminal setcap command to the correct location. /opt/mattermost/bin/mattermost is not correct as noted in the official Mattermost instructions.
It seems to me that since Cloudron uses Docker images, this may have something to do with how Mattermost is containerized with Docker - perhaps that Docker doesn't allow the setcap function? Using the Mattermost terminal within Cloudron I was able to find in my Linux file explorer where the Mattermost executable was located, but don't seem to be able to act on it through that console. Below is the what I get:
root@bc5dfc3e-6ab4-4cce-93dd-96b17871aca7:/app/code# sudo setcap cap_net_bind_service=+ep /bin/mattermost
Failed to set capabilities on file `/bin/mattermost' (No such file or directory)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
I did get a note from @girish on git.cloudron.io on the Cloudron/Mattermost page that "On Cloudron, TLS+Port management etc are all automatic. You should never need to change all these things." - If this is true and TLS/Port management are handled via Cloudron, it would make sense why Mattermost isn't letting me change these settings in the System Console - since this port is local to the docker container.
Can anyone confirm if Cloudron is handling TLS/Port Management and that I don't need to be concerned about unencrypted traffic flowing from connected clients to my server?
Actually on Cloudron all apps run behind a TLS terminating reverse proxy. That nginx instance runs on the host port 443 and handles all connection encryption on its own. The apps run on an internal network and are not setup to use TLS and there is also no need for that, as everything is on localhost.
Ideally mattermost settings view would not even show those things in such a setup to avoid confusion, but we generally do not patch apps for such things.
If you open your mattermost instance in a browser, it should show you a lock icon for valid SSL by default. If you adjust things here, then it is expected to break.
@nebulon great, thanks so much for this! I should have posted here sooner, I've been scouring the internet for days looking for this. It wasn't listed in any documentation anywhere on containerized versions of Mattermost. Thanks everyone here for all the incredible work you do.