You need to setup the hostname in the Cosmos installer if that’s what you are asking. You can put your IP or something if you dont have your domaoin yet
You need to setup the hostname in the Cosmos installer if that’s what you are asking. You can put your IP or something if you dont have your domaoin yet
- I think domain is preferable for home servers because then you get subdomains for apps, which are easier and can also share the auth cookies for SSO
- you probably had a cached certificate
You dont need to do anything to migrate, Cosmos will just work with Portainer, including just picking up your existing containers
You are correct, and Sab is due to be added
Docker is an important ingredient in the mix, to isolate the applications completely, and make things much more streamlined than traditional VM, but I understand if it’s not for everyone
Truenas
Haven’t used it, but it looks like there are overlap.
Cosmos does not yet have storage management (but soon) and uses Docker instead of VM
I am considering Podman support but probably more next year when Cosmos is feature-complete for 1.0
Keep in mind it might be a challenge to do everything rootless but I will see what I can do
The VPN part is basically a “secret” (encrypted) tunnel between multiple devices/servers. Whenever one device wants to talk to your server, it sends messages via the tunnel, and on the other end, the tunnel dispatch the message to the right port. Using this, you have access to your server without exposing all your ports, so only people connected to your VPN can see it. Keep in mind this is different than a traditional VPN who transfer all your data to the server to hide your IP. Here only the traffic to your server is tunneled. This way your other activities are not affected (performance wise especially)
2FA uses any authenticator app (the one where you scan a QR code and get a 6 digits number) to protect your account. If someone gets your password, they still cant login because they also need your phone (unlocked) to get the 6 digits (it changes every 30 secs)
You need root access to manage docker containers that’s (almost) unavoidable. Also Cosmos does not support managing remote docker instances. On the other hand, a good (and secure) pattern is to use Constellation (the integrated VPN) on 2 servers with cosmos installed on each. you can connect them together. One of the servers (the seedbox) is the main server running services but it is not exposed on the internet and the only way to access it is to connect to the VPN on the other VPS
Docker is an important ingredient in the mix, to isolate the applications completely, and make things much more streamlined than traditional VM, but I understand if it’s not for everyone!
Don’t get me wrong, I am fully aware that you need to reduce as much as possible the amount of access something has but as you said:
you should never have permissions to things you don’t need
well Cosmos needs to see your files if you want Cosmos to manage your files. It’s that simple. By default its on because it is needed for Cosmos to function. You can remove it, but at the expense of some of the functionalities of the server.
By the way Cosmos, as a Docker management software, has access to your docker socket. Which mean, you can remove anything you want from the container, technically, it can add it back itself. Having access to the socket means being able to manage the containers, including itself. In other words, having this mount in the docker run command is just a comfort thing, but in term of privilege, whether it’s Cosmos or Portainer or any other docker manager, they have full root access to your system and that’s unavoidable.
why not have -v /CasaFolder:/mnt/host or something similar
Because it would require users to always update their Cosmos containers to add additional folders all the time, giving a terrible and very error prone user experience.
If there is a solution out there, that solves that problem (as in allows Cosmos to continue to work the same without that mount) then I will gladly implement it. But as far as I can see there isn’t such solution
Another way of seeing it is, if Cosmos wasn’t a container it would see `/` anyway. It’s not extra access, it’s just a workaround for Docker
Thank you!
Yes keeping your containers updated is a huge step toward preserving the server’s security
Cosmos is a fully fledged server management platform, as such it requires those access to the host server in order to operate.
“–privileged -v /:/mnt/host” is not as bad of a thing as you would think in that context, in fact it is equivalent to running a daemon like you would with any other alternative (CasaOS, Umbrel, etc…) those are just requirement for Cosmos to run with the same level of exposure as those alternatives who are not docker containers.
My only alternative would have been to make Cosmos a daemon and not a container, but then it would make install and maintenance harder
I understand your point, and yes ideally it would run as an isolated container, but it’s just not possible to have a supervisor software managing your server running in an isolated container with no container, it is contradictory
I propose as alternative to run Cosmos with lower privilege, in which case some features will not work but the default is to run cosmos with the privileges it requires for all features to work as expected.
And the bottom line, the security benefits behind Cosmos for your average home-server outweigh by far this “–privileged -v /:/mnt/host”. Slight reminder than a very large portion of people running alternatives like Casa, Umbrel, etc… Also expose those root daemon without even HTTPS or anything!
It does not include volume data, but backing up volumes is a planned feature too, it’s just a lot more difficult of a feature to develop :p
Basically backing up volumes is easy without Cosmos, it’s just a folder, but backing up your container is much harder, that’s why I added it in priority
If you are experiencing any performance issue, feel free to document them to me so I can investigate your setup and potentially fix any shortcomings :)
Using an outdated version of a container (including DBs!) that have known vulnerabilities that will be very easy to exploits including by bots, is so much worse than the risk of a container breaking after an update. Just monitor your server properly and you’ll be good