UNMS
UNMS copied to clipboard
Ubiquiti-App
Dont't rely on Docker for install
Docker is great for dev's but is a real challenge to validate security environment of the executing code and where it originated from for security analysis. IE who build redis and where was the build server secure when it was built?
Please provide standard RPM or DEB packages for the final product that don't rely on any additional container technology to run.
I'd like to weigh in on this, I would prefer an installation guide that expects me to wrangle the sub-components over having to deal with the complexity of the docker environment. I get that you're bypassing some of the complexity by trying to make the application be stateless off a single folder, but it would just be better for many of us not to have to bring docker into our ecosystems.
You get the added benefit of people packaging your stuff up for different distributions if you can maintain an installation sequence that is transparent for one of the big guys (e.g. fedora, debian).
Docker add several bridges/virtual if's/interfaces and firewall rules, and this makes system/OS/VM UNMS is running on, very insecure.
Also making my VM accessible where I don't want it to.
/Paetur
I'd also like to see a .deb and maybe one day a repo just like UniFi and UniFi-Video. I have a bunch of EdgeMAX and AirMAX devices and would love to be able to manage them with this.
It was disappointing to see the thread about this in the Ubiquiti community get locked. I realize as the developer it's frustrating to have a large group of users disagree with a decision you made, but part of what makes Ubiquiti special is the community and the way you guys listen to and interact with your customers.
Maybe everyone complaining about it is just afraid of change, for my part I just don't understand Docker well enough to deploy it while feeling safe. Does the Docker daemon still have to be run as root? And if a process inside the container is running as root, does it still automatically have root privileges on the underlying system as well? That makes me nervous, although again I am not a Linux expert by any means.
agree, docker gives me a whole lot of other issues I do not want to have ';) .deb is fine
If you guys want this feature please add your kudos to this feature request, if it gets enough maybe ubnt will implement it.
https://community.ubnt.com/t5/UNMS-Feature-Requests/deb-install-just-like-Unifi-and-Unifi-Video-without-Docker-Maybe/idi-p/1982000
I also want UNMS without Docker option. As an example, I have a dedicated Linux VM for UniFi controller because doing just apt-get update and apt-get upgrade is preferred to having to do that and also run upgrade on Docker containers.
Unable to install UNMS due to compatibility issues with running docker inside an LXC container. We already have containers and virtualization we neither need nor desire yet another container mechanism
One of the issues with relying on docker is using VPS servers that are on OpenVZ instead of KVM. OpenKVM is not (currently) running the 3+ linux kernel, with the exception of testing, which most VPS providers will not install.
does not really matter. LXC OpenVz bother are conatiners and you can not install docker inside them. As far as KVM which is full virtd listen to this “ lets install a vm container technology inside a vm and hope this works for production” this sounds sane right?
The docker container is fine but the lack of documentation of the custom containers and the way they interact is frustrating to say the least. ~~Is fluentd actually used internally to the containers or is it just a way to log messages?~~ yes, it's consumed by UNMS I've got one IP and I already have a nginx reverse proxy with lets-encrypt, just tell me which ports are exposed and what they are expecting.
I'm slowly pulling this apart but the unms is a custom nodejs ( based on mhart/alpine-node ) http/ws app which requires rabbitmq / postgres / reddis backends ( all standard images ) but does not seem to need the custom nginx for operation. Why are firmware downloads protected by a weird random md5 check, I presume they are checked by the device before being applied, correct? Since this is just an alpine with a few files, why not release the Dockerfile for nginx, why are we needing to pull this apart to find these quirks?
May I suggest you take a look at gitlab omnibus. It's a very complicated system which drives half a dozen services all from a single config. It also exists as a single docker instance as well. UNMS looks like it could be a handy system but the lengths to which the installer script go through at this point make it far too distro specific and over the top for my taste.
PS: As I'm doing more inspection it appears that the primary issue seems to be a lot of hoops are jumped through so that the UNMS container has access to the data folders from all the other containers which seems like a blatant container sharing violation. If they need to share like that then they should be one container not 6. If this is not truly needed then let's simplify the config by not jumping through custom hoops. They should be communicating with APIs not by sharing filespace. Being able to pcap on the public interface is also something that I would feel a lot more comfortable with if there was better docs ( I presume for auto-discovery, but to give node access just doesn't seem wise )!
Time for a bump. +1 get this out of Docker. If UniFi runs outside a Docker, so can UNMS. Everything I've run inside a Docker has gone terribly wrong. It's a flawed technology. That said, this repo seems rather dead, so perhaps so is the project. An honest shame at the premium paid for these devices.
Everything I've run inside a Docker has gone terribly wrong.
I run literally hundreds of docker containers across multiple servers and have never had anything go "terribly wrong". Seems to be user error instead if everything you've tried with it has gone "terribly wrong".
Everything I've run inside a Docker has gone terribly wrong.
I run literally hundreds of docker containers across multiple servers and have never had anything go "terribly wrong". Seems to be user error instead if everything you've tried with it has gone "terribly wrong".
I get that a lot from Docker users. This isn't the place for that. This thread is about pulling out of Docker, not falling deeper down the rabbit's hole. I assure you, it's not user error.
Everything I've run inside a Docker has gone terribly wrong.
I run literally hundreds of docker containers across multiple servers and have never had anything go "terribly wrong". Seems to be user error instead if everything you've tried with it has gone "terribly wrong".
I've literally seen entire businesses go offline for hours and hours multiple times because their entire docker based clusters cascade failed due to actual bugs in docker. So yeah please let me base running my business on something that can take me out of action and shed customers.
While I can appreciate wanting a documented INSTALL procedure that doesn't require docker, if you have a bug report than open a bug report. I've had no problems running this and a lot of other complicated stacks on docker or k8s/containerd. The problems I've encountered have been of my own creation.
Personally I run a small UNMS derivative on a k8s cluster running on raspberry Pis without issue.
We are not here to discuss wether a workload runs ok or not ok on docker.
There are a lot of reasons why someone wants to run UNMS outside of docker. Personally, I run everything on FreeBSD, and there's no docker there.
UNMS needs docker, unifi doesn't.
Please, provide an install for UNMS that is, like unifi, NOT depending on docker.
Nothing is stopping anyone from pulling apart the image and using native daemons, other have done so to create alternate images. UISP is just a collection of standard services with a nginx/node frontend. While it would be nice to have official documentation of how it all fits together I would not hold me breath.
Docker itself isn't too bad. The problem is that most people run Docker images that are created by others. And who knows how that person set it up without diving deep into it. In-which most people don't, and possible don't know how to. That's the point of grabbing a docker image from someone else. They done the work for you.
So here's one issue. UBNT assumes you're going to put a firewall in front of your UISP server. UBNT implements the below very insecure firewall rules. Even if you've created your own locked down iptables rule set. Once you start the docker images. They will amend their rules to your iptables and null in void any securing of these ports that you've previously done. Even if you run a firewall in front of it, every level should not expose more than it needs to.
All ports used in UISP are allowed from any incoming interface that isn't originating from the interface running the service that the docker container is on. So without a firewall in front of UISP, all the ports are exposed to the public.
As far as I know, 2055 & 24224 are only used between the containers. There's no reason this needs to be exposed to the users & admins, much less publicly accessible. I shouldn't even be able to access these ports from my host machine, or other docker containers that don't have a relation to that port; if you truly want it to be called "secure."
80, 81, & 443 should be secured to only trusted IPs & VPN interfaces. Not open to any external source interface.
ui@uisp:~# iptables -S DOCKER
-N DOCKER
-A DOCKER -d 172.18.251.2/32 ! -i br-19ea571ebc89 -o br-19ea571ebc89 -p udp -m udp --dport 2055 -j ACCEPT
-A DOCKER -d 172.18.251.3/32 ! -i br-19ea571ebc89 -o br-19ea571ebc89 -p tcp -m tcp --dport 24224 -j ACCEPT
-A DOCKER -d 172.18.251.5/32 ! -i br-19ea571ebc89 -o br-19ea571ebc89 -p tcp -m tcp --dport 443 -j ACCEPT
-A DOCKER -d 172.18.251.5/32 ! -i br-19ea571ebc89 -o br-19ea571ebc89 -p tcp -m tcp --dport 81 -j ACCEPT
-A DOCKER -d 172.18.251.5/32 ! -i br-19ea571ebc89 -o br-19ea571ebc89 -p tcp -m tcp --dport 80 -j ACCEPT
ui@uisp:~# iptables -L DOCKER -v
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- !br-19ea571ebc89 br-19ea571ebc89 anywhere 172.18.251.3 tcp dpt:24224
0 0 ACCEPT tcp -- !br-19ea571ebc89 br-19ea571ebc89 anywhere 172.18.251.5 tcp dpt:https
0 0 ACCEPT tcp -- !br-19ea571ebc89 br-19ea571ebc89 anywhere 172.18.251.5 tcp dpt:81
0 0 ACCEPT tcp -- !br-19ea571ebc89 br-19ea571ebc89 anywhere 172.18.251.5 tcp dpt:http
0 0 ACCEPT udp -- !br-19ea571ebc89 br-19ea571ebc89 anywhere 172.18.251.2 udp dpt:2055
Thanks for the firewall info. But once again, this issue is not to describe things with docker, but to have something that does NOT rely on docker.
Not because docker is bad or anything, but there are platforms where docker simply is not an option.