R8 in Docker auto binds to any network adapter it finds

Answered

Comments

11 comments

  • Avatar
    Norman - Nx Support

    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

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    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) 

    0
    Comment actions Permalink
  • Avatar
    Pieter Viljoen

    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.

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    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

    0
    Comment actions Permalink
  • Avatar
    David McNeill

    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.

    1
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    Pieter Viljoen
    David McNeill

    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!

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    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"
          },
    0
    Comment actions Permalink
  • Avatar
    Pieter Viljoen

    Thx, where do I see that full description you pasted, my mediaserver.conf only has a few entries?

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    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`

    0
    Comment actions Permalink
  • Avatar
    Pieter Viljoen

    This is super useful, thank you.

    Q on logLevel, is DEBUG2 is not listed, is that now VERBOSE?

    0
    Comment actions Permalink
  • Avatar
    Tagir Gadelshin

    Yes, I think so. VERBOSE is the most detailed log level

    0
    Comment actions Permalink

Please sign in to leave a comment.