I'd like to add, that I'm a bit torn about this workaround, as it's not overly idiomatic and it might not be obvious to the user that the file that is actually being run against is a copy in the store.

This could also lead to confusion when modifying the original out-of-store config file and restarting the service manually. Maybe there is some nifty way to get symlinks added to the sandbox that I'm not aware of yet.

So maybe just throwing a meaningful error at the user is more straightforward overall.

@d-goldin fIrst of all, thank you for reporting this issue 👍

I think that the main issue with silently adding the config to the nix store is when it's done in a scenario with basic auth credentials in the configuration, that should not happen without informing the user. Mentioning this in the option description and maybe even throwing a warning during eval would be enough for my taste.

Regarding the service reload on config change, where the config file is not copied to the store:
As I am not aware of any mechanism that solves this for us (restartTriggers would not pick up on changes here I guess) we might only be able to also mention that manual service restarts on config change are needed when using a config file outside the nix store. I would also prefer an automated solution here if there is any :)

I would therefore propose to do two things:

• throw a warning when the config file is copied to the nix store and mentioning this behaviour in the option description for configFile with respect to any potential secrets and the need for rebuilding the system after config changes
• add a switch to allow users to keep the specified configFile outside the nix store by disabling the check (e.g. enableConfigCheck with default true), mentioning the use case and the need for a manual service reload after config changes in its description

I'm happy to hear any suggestions on these proposed changes :)

@WilliButz: Agreed on the silently adding, this was the main reason why I was not a fan.

Regarding config out of store and reloading - I dont think this necessarily needs to be solved, I just thought that it was a bit incosnsitent behaviour between the two ways passing the config there.

I agree with the suggestions as improvement over the current state. It might be possibly more ideal to be able to define the whole config in nix itself, but I'm not sure if it's worth the effort and it would also still come with the usual issue of secrets management.

I'll update this PR a bit later.

I kept the commits separate for legibility. Will squash once reviewed.

@GrahamcOfBorg test prometheus-exporters.blackbox

backported in 3ddf0b3