SNMP should not be included by default

[jorgensigvardsson]

I saw SNMP (or more specifically netsnmp) is included in netbox by default. Is this really something we want at this base level? In my mind, SNMP is something that's pretty dated, and should only be enabled if required by the application running on top of netbox.

I may very well be out of my depth here, so feel free to shoot this discussion down. :)

[troglobit]

Yes, I think so at least. The founding idea behind NetBox is for it to be able to stand on its own legs compared to any specialized offering by Westermo. It's an opinionated take on Buildroot, a Networking Toolbox, a reference to our internal SW products, and also a useful OS both for us and our customers (and others) should they want to use it. SNMP is still very useful, and a common way to check availability, uptime, and other data.

Note: only the OS flavor carries these tools, the app flavor is stripped down and basically only has a full-blown Busybox and Finit.

After Feb 18, however, I'm no longer part of this organization, so I leave it up to the new maintainers to give their own take on this. It's up to you all now to define what NetBox is and where it should go in the future. Take care of it, for it has served us well so far <3

Cc: @joazet and @ccb3

[ccb3]

I also see it like @troglobit, it is useful and In the case of a final product one can always disable it if needed. I don't see the disadvantage of having it there since it is quite lite weight and useful for those that are interested in getting status information from the devices without having to log in to it.

[jorgensigvardsson]

Ok, so there's obviously need/want for SNMP. Could we make it safe by default?

People have been poking us about SNMP v2. From a cyber security perspective, I totally get that.

Would it be a bad move to have only SNMP v3 on by default? Obviously it would require some default accounts, but what doesn't?

[ccb3]

As I see it snmpd is not started by default so the user has to start it them selves, and then they have the ability to decide which version they are comfortable running.

[troglobit]

Yeah, I've been a lazy bum and not written a service stub to Finit for it yet 😞

I'd like to take a different route on the defaults. Instead of trying to figure out our own, we should follow, e.g. Debian. Buildroot doesn't ship a default /etc/snmp/snmpd.conf, but Debian's defaults are really good -- no SNMPv3, but only rocommunity and limited to the systemonly view.

For activating more advanced features in daemon's, generally speaking, I think NetBox should adopt Alpine Linux-style setup-foo where the user gets asked as series of guiding questions (e.g. SNMPv3 user password) and then the foo.conf is generated. The basic .conf generator (script) can also be used by libCFG2 in WeLinux if we want.

[ccb3]

Alright, I figured it was because snmp is not as static as many other protocols ;) The setup-foo solution sounds like a great approach for those kind of daemons that are not as static as others. I haven't looked to much in to it yet but from what you say and what I have read so far it seems like a quite nice (and made easy) way to solve configuration options for the users that are not as comfortable with writing their own .conf files.

[jorgensigvardsson]

A follow up question: is it possible to remove a package from a netbox derivative? Suppose we're tasked to build a custom image, and some requirements stipulates "package X cannot be on the image". Is that as easy as setting BR2_PACKAGE_X=n in the config? 🤔

[ccb3]

Yes, =n overrides =y which overrides 'is not set' :)

[troglobit]

Yup exactly that, which we've done now I guess in one project already. There's also the option of keeping completely stand-alone foo_defconfig files in derivatives. This is something we haven't talked as much about, but is a definite possibility for real off-shoots.