Support `auth` alongside target & module as distinct property

[RichiH]

auth is orthogonal from the target, the data model and from what data to receive. As such, it will be split out into its own section.

For backwards compatibility, inline auth should be supported, but the new pattern encouraged.

Open questions:

• Should we allow auth to live in a secondary file to completely detach global OID etc configuration from user-specific config?
• Should we offer inline-line loading of files or explicitly have a few distinct files? Inline seems better.
• Should we offer a baseline UI to show which files are loaded?
• Should the exporter emit information like files loaded in _info or through a gauge?

As this touches a lot of questions in #85 CC @glensc

[RichiH]

https://docs.google.com/document/d/1McJJIiJfHgoecVrVNXx4ABJmI5M21e-6O9IgMNbVnvw

[RichiH]

After more thought:

Should we allow auth to live in a secondary file to completely detach global OID etc configuration from user-specific config?
#85 will take care of this and people can structure it as they wish.

The new default config we provide should most likely break it out.

Should we offer inline-line loading of files or explicitly have a few distinct files? Inline seems better.

I flipped. Let's make it explicit on CLI. Directory support takes away the need for inlinig, IMO. As such, we should offer fewer ways to do the same thing to avoid long-term confusion.

Should we offer a baseline UI to show which files are loaded?

I think we must.

Should the exporter emit information like files loaded in _info or through a gauge?

I think we should. Unclear if we should do

• one _info, lots of labels
• one _info, overload a single label
• one metric per file

New open question: Does that mean we're listing the directory name, what is found and activated inside, or both of those?

[xkilian]

What you are describing should be handled in logging at exporter startup, and in the web UI. It is not meant for info metrics IMO.

[pobk]

My 2 pence:

1. Credentials should be stored separately from the MIB definitions. Having a file which contains credentials separate from the snmp config would allow a greater flexibility around securing that file.
2. Allowing the exporter to be targeted using credentials= as well as module= would allow for some flexibility in targeting.

My employer uses LastPass, and we've integrated that into an ansible workflow. This gives greater protection to our systems estate since if you don't have access to the credentials from the credentials store you cannot access the system to run any of the playbooks. This is something that could easily be implemented in other ways too.

This also works for generating files full of credentials where each node has separate credentials configured.