Install packages for network configuration

soupdiver commented 7 months ago

Is this a new feature request?

[X] I have searched the existing issues

Wanted change

It would be nice if basic tools like ifconfig or ip would be included in the image

Reason for change

When starting the container the unifi-controller always gets an ip address from a wrong network. At least in my case. I can exec into the container but am unable to do any diagnostics or set the ip address manuall, which is suggested in the unifi forums. I also can not simply install net-tools because there is package conflict with unifi and mongodb in apt and resolving this means uninstalling unifi.

So yea.. I'm stuck with either having the container always in the wrong network or having to uninstall unifi to install net-tools

If there is any way through the UI or env var or so to specify the network interface that the controller should use would also solve the issue I think.

Proposed code change

Make the network interface/address configurable or add tools to the image to manually configure the network

github-actions[bot] commented 7 months ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

thespad commented 7 months ago

If you are in the situation of having to manually configure the interface address of a container from within that container you are already doing something very wrong.

This seems like a very X/Y problem but without additional context it's impossible to identify your actual issue.

j0nnymoe commented 7 months ago

Packages to change the IP should not be required. The IP that the container is detecting is the one from the docker network which is perfectly fine. You can then configure the controller to force the correct inform URL to your devices.

soupdiver commented 7 months ago

If you are in the situation of having to manually configure the interface address of a container from within that container you are already doing something very wrong.

yes but what should I do if I can't specify the interface which the controller uses?

On my host I have my en0 interface and podman0 which I aussume is the default podman bridge. When I run the container with network_mode: host then unifi-controller gets an IP on the podman0 interface, at leas that's what I see on the web UI. But I can't find any way to configure either an IP in my "real" network or tell it to use en0 to listen on.

The IP that the container is detecting is the one from the docker network which is perfectly fine.

It is not perfectly fine in my case.

What other options do I have to get the container into my real network and some docker/podman internal network?

j0nnymoe commented 7 months ago

Perhaps provide some more context to why this is an issue for yourself? Also note that our container could be behaving differently to how we expect as you're using podman while we test using docker.

soupdiver commented 7 months ago

Perhaps provide some more context to why this is an issue for yourself? Also note that our container could be behaving differently to how we expect as you're using podman while we test using docker.

yea that also crossed my mind.. I'm migrating a setup from one machine to another. Containers are managed by Portainer but I switched the underlying engine to podman. I will keep digging tomorrow and give an update here.

soupdiver commented 7 months ago

I'm still stuck here... I checked if Docker and Podman do something different when using --network host but it loos similar from inside the container. All my hosts network interfaces show up.

But my docker-unifi-network-application still shows me an IP of the wrong interface and I have no clue how to change that.

Here is my network config on the host:

ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:4d:21:6d:0e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.141  netmask 255.255.0.0  broadcast 10.0.255.255
        inet6 fe80::df04:3f32:5edc:2516  prefixlen 64  scopeid 0x20<link>
        inet6 2003:c3:ff29:3600:4ac5:1ba8:2b34:e6b0  prefixlen 64  scopeid 0x0<global>
        inet6 fdcd:520c:fae:4181:1120:3685:1455:b458  prefixlen 64  scopeid 0x0<global>
        ether 2a:b2:0b:fe:85:df  txqueuelen 1000  (Ethernet)
        RX packets 287403  bytes 440943372 (420.5 MiB)
        RX errors 0  dropped 12  overruns 0  frame 0
        TX packets 130359  bytes 123003695 (117.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 10049  bytes 2362227 (2.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10049  bytes 2362227 (2.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

podman0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.88.0.1  netmask 255.255.0.0  broadcast 10.88.255.255
        inet6 fe80::b863:ccff:fe38:e6d3  prefixlen 64  scopeid 0x20<link>
        ether ae:75:b2:d9:9d:f3  txqueuelen 1000  (Ethernet)
        RX packets 88438  bytes 59439177 (56.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 83875  bytes 124218878 (118.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

podman2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.89.1.1  netmask 255.255.255.0  broadcast 10.89.1.255
        inet6 fe80::f469:44ff:fe65:a6a7  prefixlen 64  scopeid 0x20<link>
        ether ba:4b:a8:aa:59:33  txqueuelen 1000  (Ethernet)
        RX packets 1703  bytes 8301151 (7.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2564  bytes 1294712 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ac75:b2ff:fed9:9df3  prefixlen 64  scopeid 0x20<link>
        ether ae:75:b2:d9:9d:f3  txqueuelen 1000  (Ethernet)
        RX packets 84119  bytes 43813336 (41.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 78327  bytes 120279309 (114.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::941a:75ff:fee2:9cc5  prefixlen 64  scopeid 0x20<link>
        ether ba:4b:a8:aa:59:33  txqueuelen 1000  (Ethernet)
        RX packets 829  bytes 1198861 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1074  bytes 184531 (180.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens18 is the interface which is attached to my LAN and which I want to use. There are also podman0 and podman2... which are for different networks inside podman.

I start the docker-unifi-network-application container with host network. I can actually reach the web UI through https://10.0.2.141:844 but after loggin in I'm greeted with an IP from the podman2 network.

If things would still work I could live with that but all of my network devices are shown as Offline. So I suspect that there is a communication issue because the controller is/thinks(?) it's in a different network that the other devices.

For already mentioned reasons I can't do much debugging in the container because there arent any network packages available and I can't install any without uninstallg unifi. Is there any feedback from you regarding this broken state of apt? Is this known/expected?

Any idea how I get the conainer into the right network?

soupdiver commented 7 months ago

I tried another approach and created a macvlan network and added the unifi container to that network. Looks good on the first glance Container gets an IP through dhcp and I can ping it. However when I try to access the unif conroller on that IP all I get is a 404

No logs or anything to see in the container

[migrations] started
[migrations] no migrations found
───────────────────────────────────────
      ██╗     ███████╗██╗ ██████╗ 
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝ 
   Brought to you by linuxserver.io
───────────────────────────────────────
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:    1000
User GID:    1000
───────────────────────────────────────
[custom-init] No custom files found, skipping...
no crontab for abc
no crontab for root

soupdiver commented 7 months ago

About the apt issues. Not the actual problem but makes it hard to debug with the image

apt install net-tools
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 unifi : Depends: mongodb-server (>= 1:3.6.0) but it is not installable or
                  mongodb-10gen (>= 3.6.0) but it is not installable or
                  mongodb-org-server (>= 3.6.0) but it is not installable
         Depends: mongodb-server (< 1:5.0.0) but it is not installable or
                  mongodb-10gen (< 5.0.0) but it is not installable or
                  mongodb-org-server (< 5.0.0) but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following packages will be REMOVED:
  unifi
0 upgraded, 0 newly installed, 1 to remove and 13 not upgraded.
After this operation, 256 MB disk space will be freed.

j0nnymoe commented 7 months ago

I still don't believe you've explained why you need this issue? Because you're the first person I've seen ask request this in the years we've had a unifi container.

The only thing you really need to do to get your devices back online is to force the inform URL within the controller for it to push the correct inform information to your devices.

soupdiver commented 7 months ago

I still don't believe you've explained why you need this issue?

I'm trying to debug and figure out what's going on here..

I asked if it's expected to be unable to install any more package in the image, no answer I asked why the controller would respond with 404 and no logs, no answer I aksed how to set the ip address the controller should use, no answer

Telling me you don't believe I need this doesn't help me either.

I provided information about my network setup, how I run the image, which engine I use etc but you guys only tell me that I dont need this ... but the container isn't working for me and I try to figure out why 🤷

The only thing you really need to do to get your devices back online is to force the inform URL within the controller for it to push the correct inform information to your devices.

Yes, but well if the controller only gives me a 404 how to do that then?

j0nnymoe commented 7 months ago

Re the 404, have you ever been able to access the webui?

soupdiver commented 7 months ago

Re the 404, have you ever been able to access the webui?

yes I have but it randomly stops working. Can't really tell what's the issue since there is not a single line of logs anywhere of that controller.

I mean... since I get the 404 I assume I can actually reach the container and it responds. But why the 404, no clue. Sometimes it took a moment for the web app to come up and then the 404 disappeared and I got the login.

When I search online for "unifi controller 404" I get a dozen posts telling me to repair the mongodb database. Everyone also refers to a local mongodb. Not sure why this images needs a databse runnign on another container.

It's just hard to debug without any logs and only a 404. Is there a way to make the whole thing more verbose maybe?

j0nnymoe commented 7 months ago

The unifi logs themselves will show within your /config mount. That 404 likely came up when you set the macvlan because it couldn't reach your mongodb container.

soupdiver commented 7 months ago

That 404 likely came up when you set the macvlan because it couldn't reach your mongodb container.

I don't think so... I tried to reach the databse from multiple endpoints and it works and actually having a look at the logs in my volume (thanks!) I can see this:

[2023-11-13 12:11:27,793] <launcher> INFO  db     - db connection established...
[2023-11-13 12:11:38,294] <launcher> INFO  db     - db connection established...
[2023-11-13 12:11:48,795] <launcher> INFO  db     - db connection established...
[2023-11-13 12:11:59,296] <launcher> INFO  db     - db connection established...
[2023-11-13 12:12:09,797] <launcher> INFO  db     - db connection established...`

soupdiver commented 7 months ago

Oh lord... 💆 For the x time I destroyed it all... cleaned the volumes and brought the stack up.

And now it seems to work... at least for now... I will see how long this will last. All my network devices are still shown as "Offline". They still have the old/wrong inform URL I guess....

Any way to get the devices onto this new controller then without factory resetting them all? 🤔 I restored a backup of my old setup but the ip of the new controller is still a different one

soupdiver commented 7 months ago

I have it running "fine" now but it keeps being flaky. But I guess this is more a reason of the underlying unifi-controller and not the image. Randomly it refuses to start... just showing the 404 and no errors. Deleting all data and reimporting a backup "fixes" this. Until ntext time I guess

linuxserver / docker-unifi-network-application