R8 in Docker auto binds to any network adapter it finds
AnsweredRunning R8 in Docker, the routing logic keeps binding to any new adapter, including virtual adapters used by other docker containers.
I unbind unwanted adapters, come back in a few days, and then more adapters were bound.
This logic to auto bind to any network adapter found is problematic, I expect binding to be done explicitly by the admin only.
The problem also pollutes the resource graph with too many lines, and no way to remove them.
-
Hi Pieter Viljoen,
Firstly I want to thank you for all the feedback you provide in regard to the Docker build.
For sure, we have tested and verified the build before publishing it, but you manage to provide decent feedback that helps us to improve the build and this help to speed up the process to move the Docker build from an experimental feature to a supported feature.I will provide this feedback to our Docker developers and ask them for feedback and hopefully a solution.
In the meantime, here is an article that at least describes how to remove the duplicate nodes.JIRA-VMS-19663
-
Pieter Viljoen
Thanks for the feedback! Can you clarify, is polluting the interface is the main problem for you? Or the fact that the software binds to the interfaces automatically also causing problems? What are those problems?
Changing default auto-bind logic sounds wrong for me, cause it works perfectly on other non-Docker platforms. But stopping auto-binding might be a non-default option, we will consider that.
But some UI improvements can also take place (e.g., hiding link-local addresses) -
Tagir
Stating it works perfectly on non-docker platforms is a classic positive bias argument. I bet that if I install Nx on the host Debian OS, not on Docker, that Nx would also use all the virtual docker, physical, and bridge adapters.
But yes, I have not experienced functional issues due to binding.
The graph is impossible to use at it contains too much data and no way to filter the superfluous traces.
As a system administrator I believe should have control, use storage defined by me, use the network assigned by me.
-
Pieter Viljoen
> is a classic positive bias argument
yeah, of course, it is a positivity bias (a.k.a. Polyanna principle), for sure! Besides that, I assume Nx works well in Docker and on Debian, although those platforms are not officially supported :) also positive thinking
Yeah, I'm not stating it works any different, I was just trying to say that we haven't received this feedback from Windows/Ubuntu/Arm servers users. They just don't have that many interfaces
And one more to positivity: I hope we will be able to release Docker support in some future releases -
Supporting Pieter, here is some feedback on binding to every network interface on other platforms.
It's undesirable. It means NX is listening everywhere, even where it is not welcome. On subnets where camera access is not required or desirable, meaning more firewall rules are needed. Combined with it's regular STUN operation to ascertain it's public IP, and it's incessant phone-home behavior, it is effectively collating the private IP address space accessible behind every public IP running NX. Should a leak or breach or subpoena occur in the mobile app, phone home transport or storage, a wealth of network access data is available to the access seeker.
NX's incessant need-to-know and auto-magic omnipresence is overreach, especially in the sensitive security appliance space. It is a very uncommon approach in Linux application servers. Where it might be tolerated in Windows servers, it is unwelcome in Linux. Allowing admins free choice in this behaviour is the right thing to do. Settings for autodiscover to be on/off/once and able to edit the results. Same for the immutable and broken autodiscover on storage volumes. Similar for the aggressive autodiscover on cameras, which triggers their lockout features before the correct credentials can even be configured. Same with obsessive calculating of the hardware hash for licence control - very sensitive to minor change, which is more common in virtual servers. All auto-usefulness, until it encounters an unconsidered situation, then it becomes a problem.
NX however is also exceptionally reliable, very user friendly and packed with useful features. It is the best camera recording software available on Linux, at an excellent price point. Customers love it, and it is really nice to work with, very efficient at finding issues caught on camera in physical space. The look and feel is clean and efficient and flexible on all platforms. It is quite capable of uptime in years, which is very reassuring.
The obsession with software quality is perhaps same obsessive style that drives the auto-everything octopus approach. Keep up the good work NX team, and perhaps subject your auto- discussions to wider consultation or deeper introspection.
-
Thank you for your feedback!
we are considering adding turning off auto-binding as an option in our future releases.
Your comments are appreciated! your scenarios and feedback helps us a lot!
Also, guys, can you please click on the upvote button on the initial request if you are interested? We usually use this for prioritization (besides comments)
Thanks! -
Pieter Viljoen
I double-checked this. It looks like we had this for a while in mediaserver.conf:{ "defaultValue": "", "description": "Allow only specific network adapter(s) for the Server. Contains a semicolon-separated list of hosts/IPs. If not specified, no limitation is in effect.", "name": "if" },
-
Prior 5.0 and web admin overhaul we had it there (https://support.networkoptix.com/hc/en-us/articles/360036389693-How-to-access-Nx-Server-configuration-options). Now it’s returned in API only
`/api/settingsDocumentation`
Please sign in to leave a comment.
Comments
11 comments