search

George3d6 / Inquisitor

An easily extensible, minimal footprint monitoring tool. (Still in the testing phase)
BSD 2-Clause "Simplified" License
30 stars 4 forks source link

Default config generation #56

Open Deedasmi opened 6 years ago

Deedasmi commented 6 years ago

So I was thinking of how to help solve the issue of config files.

I thought of two options. One is an API change, the other isn't but is a little more unstable.

First, the unstable one:

Have our plugins catch 'file not found' errors, and create a base config that marks it as disabled, then write that config to disk in the given config directory. The benefit is that it won't be required by all plugins.

The second requires an API change:

Require a plugin::generate_config option that returns a serialized config that we write to disk. This would basically require every plugin to have serde, as well as the additional function definition. This would allow us to have a agent.exe --build-config option. This would also be another thing not documented in inquisitor_lib (but would be documented in the plugin creation guide) that plugins would have to implement.

George3d6 commented 6 years ago

Is it really an issue if config files are missing ? It will only result in plugins being disabled. The default distribution should come with default config files anyway.

I can see the point of moving these default files into the plugin themselves, and having the plugins generate them, but I think this would make it harder for users (that would just download the .tar.gz or look over the project) to figure out how plugins are configured.

Deedasmi commented 6 years ago

This was more of a "quick-install" process if there are no configs found. First time you run the agent it tells you "We generated a template config for all your plugins! Edit the file(s) and run this program again to start monitoring". Obviously, they should generate disabled (except for maybe Alive).

How I would probably go about implementing this is to have it check for the binary config (agent/receptor) and if not call a Plugin::generate() function that returns a Result<String, ()> (so plugins can 'opt out'). Then the agent/receptor takes care or writing the files/checking for duplicate plugin configs.

George3d6 commented 6 years ago

Hmh, I think it's adding extra functionality that isn't needed to be honest. In that, people will probably not generate and edit configs manually when they "install" the agent, but rather have the configs centralized and picks between templates.

I also thing this could be more easily done by simply having the "install" mode of the agent run:

wget https://github.com/George3d6/Inquisitor/path/to/plugin_name/config.yml

Which would just be a single OS command executing (and I can't think of any server distros that wouldn't have wget or at least a fallback option like curl or GET)

But I can't really think of a usecase for this. Like, what is a situation in which a user would want to run the agent in order to generate default configs, then edit them. Rather than just getting the default configs from the release and editing them ?

Maybe this kind of thing could be moved into an install script for the agent, something that downloads the config + a systemd service file + places the binary in /usr/bin + checks if the required libraries are present (though I assumed they'd be on any linux distro that's less than 10 years old). Which would also pave the way to getting a .deb, .rpm... etc for the agent, meaning people can install it with their package manager.