Support multiple configuration files

[aplanas]

And other refactoring of the config module

[aplanas]

Seems that the config module have extra functions that are helpers, and not related with the configuration file. How would you feel if I extracted those functions from there?

[THS-on]

Moving the helpers from config into the right places makes sense to me.

Removing the licensing header needs to be discussed, because we currently this header in every file.

[aplanas]

Removing the licensing header needs to be discussed, because we currently this header in every file.

Dropped this commit. I will create an issue for the discussion.

[THS-on]

If KEYLIME_CONFIG is set the config is still merged with the other ones, right?
I would expect it fully overwrite the config.

[aplanas]

If KEYLIME_CONFIG is set the config is still merged with the other ones, right? I would expect it fully overwrite the config.

They are merged, you can see it in the tests (5860d8c#diff-45fa5f8530eb815c0cf606032e587adedb04dc70e59b203535d51c44654cfc4dR52)

This will enable the separation of a system wide configuration (/usr/etc/keylime.conf), an admin overwrite (/etc/keylime.conf) and a user overwrite ($HOME/.config/keylime.conf)

The overwrites can add new key/values and replace previous set key/values.

[THS-on]

That changes the current behaviour, but I think this change is a good one and should not break deployments (outside of testing).

It might be nice to have the option to load only one configuration for testing etc.

[mpeters]

If KEYLIME_CONFIG is set the config is still merged with the other ones, right? I would expect it fully overwrite the config.

This would be my expectation as well. I like the "stacked" nature of the default config paths, but I would assume that something like KEYLIME_CONFIG would be used for testing or other automated setups that would like to completely control the whole config. But I'm willing to be convinced otherwise.

[aplanas]

That changes the current behaviour, but I think this change is a good one and should not break deployments (outside of testing).

The exposed API is the same, and the changes outside the module are minimal.

It might be nice to have the option to load only one configuration for testing etc.

For tests it is there already. Check test code, is adjusting the list of config files to load for validation.

For a more general case, like for example adding a -c /path/my_keylime.conf new command line parameter, we will need more changes. I plan to do them in a different commit, as I will need this option too.

[aplanas]

This would be my expectation as well. I like the "stacked" nature of the default config paths, but I would assume that something like KEYLIME_CONFIG would be used for testing or other automated setups that would like to completely control the whole config. But I'm willing to be convinced otherwise.

As commented, the new tests added for the config module are already updating the KEYLIME_CONFIGS parameter. The 3rd party tests outside keylime can be adjusted easily, as the API is the same.

[THS-on]

LGTM. I'm fine with KEYLIME_CONFIG also to be stacking as long we introduce -c /path/to/config as an option to manually overwrite it.