lcdproc: -c option

[markus2330]

support to choose another config file with -c. Two options with #1074

1. A dir mountpoint to /LCDproc.conf is already done within the source repo. This means: if you are in the source code directory, /LCDproc.conf will be used. That would be the case, however, even if you start the installed binary. (Except the starter script for the installed binary, modifies the current working directory anyway).
2. We could write a starter script that mounts /LCDproc.conf as dir-mountpoint (and unmounts afterwards). Or even cd and mount the file as given by -c.

[haraldg]

I have been thinking a bit about this -c option - not necessarily from an lcdproc POV, but trying to come up with valid use cases that elektra might have trouble with. This is not a proposal, just a few random thoughts that I haven't dismissed yet after turning them for 24hrs...

Maybe '-c' doesn't stand for config file, but for container? I guess the idea of a configuration container is very alien to somebody working in application integration all the time, but it might be a valid thing to do for trivial sandboxing, unit testing, build server integration, etc.

This is what I'd expect a configuration container to do: Bypass any elektra setup that exists on the system other then the file named after the -c option and also not touch anything in the system at all. That is, whatever (mis)configuration of elektra might be present on the system, the user can be sure that the application only sees the content of that one file (and maybe some keys already defined at compile time), and no other files will be created/modified and no scripts (from fancy plugins like lua or python) will be run.

Maybe -c wouldn't be implemented in elektra (as it would already need to be initialized to parse it), but elektra could provide some API to make it easy for applications to implement it.

[markus2330]

Thanks for sharing! Elektra actually has two containers (aka namespaces): user which only searches for config files in the home directory and dir which only searches for config files in the current working directory. So a -c option where you could specify the folder where the config file is located is trivial: simply do a chdir and fix the specification to exclusively use the dir namespace.

Applications, however, could still write out user or system config. To avoid this, we could write a plugin that rejects unwanted (=unspecified) namespaces.

In any case, with our proposed API (elektraOpen elektraParse) it is only an implementation issue to add such restrictions. With the lower-level Elektra API it is more challenging, because parsing command-line is not an integrated part (but just another namespace the application can append keys to).

[haraldg]

Yet an other usecase where having one global configuration database is somewhat quirky: Suppose I'm mounting a foreign rootfs somewhere on my system (i.e. to unbrick it after something went wrong). If I want to use elektra tools to modify the configuration, I guess the usual answer is to chroot into the foreing rootfs -- however if the host system is x86 and the target is arm, this won't work. Maybe there is a workaround, but I guess it is a corner case that should be kept in mind.

Of course this is a purely theoretical problem at the moment and shouldn't distract anybody from working on the next release.

[markus2330]

Wouldn't this specific use case work when we do chroot as late as possible (at a point where no further exec is required)?

But, you are right: In many custom installations, build servers, or development setups a global key database is unwanted. By recompiling Elektra (and possibly having multiple Elektras on the system) you can already support such setups (E.g. on our build server, each Elektra in every build job gets its own folders for all namespaces). The question is if we should make it easier to split the global key database, also see #1249.

[haraldg]

markus2330 writes:

Wouldn't this specific use case work when we do chroot as late as possible (at a point where no further `exec` is required)?

I doubt this would work with elektra's plugin architecture ...

[markus2330]

I doubt this would work with elektra's plugin architecture ...

I quickly tried it, and except of an issue unrelated to dlopen (#1455) it worked. I have to admit, however, that there might be issues with dlopen in the dynamic compilation variant (BUILD_SHARED), e.g. plugins loading further plugins or when a plugin gets loaded in the chroot that has not been loaded before. Statically compiled (BUILD_STATIC or BUILD_FULL), however, there would be no dlopen at run-time at all.

[markus2330]

moved to ElektraInitiative/lcdproc#12