Is it posible to get option in snap that allows disabling of mongodb?
I’m not sure but why would you want to disable it?
Snaps are self contained and not easy to change.
If you want that sort of flexibility, use docker. You can then either use a docker mongo, or a local install.
Because I want my database to be native to the OS, not a part of snap.
Because I don’t think that service and its database should be bundled together, but if you do so, plz give an option to not use it.
Docker is not giving flexibility, at least not according to me.
OK, but then you should understand that snaps are extremely restrictive. There is a lot of things they do not let you do. Complain to Ubuntu or Debian about that one 
It’s to save people with little experience of DBs a world of pain. Again, be aware of what snaps are allowed/not allowed to do. Almost certainly a snap Rocket would not be able to talk to a local Mongo. Because of snaps structure, not anything else.
Hmm. It seems that it is actually snaps not giving you the flexibility as docker will do this.
You should consider that your view is likely because you don’t understand enough about either docker, or snaps, or both.
Snaps are meant to be simple and safe. As such they are very tightly controlled about what they can and cannot do. As above.
Docker is much more flexible for a huge variety of reasons. But the result is something that is also much more open to abuse. See say bridged vs host networking. Etc.
FYI for various reasons I run my own systems with a native Mongo and a dockererised Rocket. Easy.
If that is the scenario you want, use docker as it will not be available in snaps.
To whom should I complain about different database names in Docker and Snap?
Nothing wrong in that. Just give the option to ppl that have more than one app using the same database.
And you should consider point of view other than the programmer’s one.
Every time someone has some problem with snaps or standalone installation I read some variation of the above. Probably you should reconsider your “support” of anything but docker. That will save a lot of time of both sides.
Thank you for the longwinded way of saying “No” to my original question.
It’s technically a bug - and there is a history attached - and probably had one opened on github if you search.
However, as it won’t affect the running of either snaps or docker so it’s largely irrelevant and no point in opening one.
Again, this is more an issue with snaps.
They are meant to be self contained with little external access for security. From bitter experience they are as flexible as a compiled binary. They are very limited in their ability to access any local services.
I’m not a programmer. I barely understand a line of Typescript or node or meteor.
I hack a bit of perl & php. I’ve just been a long time user of Rocket since just after it was open sourced.
I have a fair bit of experience with it, and know the people who do write it pretty well.
Because like it or not, it’s the answer.
Snaps do work and are one of the most used deployments, but due to limitations imposed by snaps they are inflexible in many ways.
They are supported because despite their limitations, they tend to be reliable because people can’t hack them about much.
This is really an xy problem.
Don’t use a hammer to install a screw.
If you want easy and simple, use snaps. Anything else - in your case - use docker.
That’s absolutely untrue. Rocket is using only tcp/ip for any communication, which is not limited by any way or form by snap. Even more there is option to use external database. So it is not xy problem.
Realy? Node 14 and Meteor 2?
Yes I get. But when the task in my jira says “Remove Rocket.Chat from docker” and verbal task is either we find a way to use something less convoluted or we are going to Teams, gues what will happen.
Nevere the less thanks for your time. I’ll give a try with custom snap build by myself. After that Teems it is.
It really depends how the snap is set up. I’m sure you are well away of many options available when building snaps.
Snaps are usually highly restricted for security - whether you agree with snap developers policy or not - be that Rocket devs or Snap devs (I hate snaps and always remove the whole snap infra from any of my machines as I have been bitten before).
Yes Rocket can use a port to access a DB, but it isn’t set up that way in a snap, and won’t be. It is simpler for users, and more secure. It is easier for Rocket.Chat to maintain.
You MAY be able to access via a port if you rebuild. Almost certainly not via a local socket (which is really a much more secure way of doing it)
If you want complexity and fancier options - use docker. That is the ‘supported’ answer, like it or not.
Don’t be rude please. You know perfectly well I am talking about Rocket devs.
The fact that this doesn’t do it the way you want it, despite there being alternatives, is not a reason to attack me.
You have never explained exactly WHY you wanted to remove Rocket from docker. You didn’t mention you even used Rocket in docker. No mention of the issues you currently face, and what you are actually trying to achieve and why. Those sort of things help a conversation.
If you want more stability, don’t use ‘latest’ - but then you will probably start wanting newer versions, and snaps lag behind.
As I said. XY. Explain what, where, and why first.
I’d say just running Rocket in docker with a local Mongo is no more convoluted that trying to wrestle snap to use a local Mongo.
YMMV.
NP. It may surprise you but I am not here to try and make your life difficult.
There is an answer to your question, which is the what Rocket supports. You are of course free to do exactly what you want - it is open source.
Snaps are not going to be rebuilt because of your scenario. Yup, I can speak to the people who build them for answers (see your caddy question) but as you might understand, I don’t ‘work’ here or get paid (anymore) so I am not inclined to do so if you are going to abuse me or get angry because it won’t work the way you want it too.
Good luck with Teams if that is your solution.