Environment Variables: Unified access vs. Usability

[markus2330]

Currently Elektra by default completely ignores environment variables. This is a necessity for unified access, only then every application sees the configuration in the same way.

Unfortunately, this approach makes it also less convenient to use Elektra (in particular if you are not root). Should we:

1. keep it as: no environment variable should influence configuration file location by default
2. adapt to XDG by default (i.e. always provide environment variables to locate configuration files, see XDG variables #734) [1 vote]
3. adapt to XDG as default for non-linux systems
4. make it easier to switch between var/non-var setup, or
5. provide two different builds of Elektra for different use cases?
6. user/dir mountpoint #1074 with userspec mounts (so that users also can mount specifications)
7. allow kdb to preload keys (which are used if nothing is found in the later kdb.get -- in the same way as applications would do), e.g. kdb get --preload <somefile> /something # somefile contains spec/something; see kdb: preload config #1269
8. introduce env variables for kdb only (not in the core). I only mention it here for completeness: It is not a good idea thus it would not only fragment Elektra's namespace but also the names of env vars for how to fragment it.

[sanssecours]

Overview

Proposal	Opinion
Keep it as is	👌
Adapt XDG	👎
Easier switch between setups	❓
Provide two different builds of Elektra	👎👎🏻👎🏼👎🏽👎🏾👎🏿👎⬇️↓🙅

Keep it as Is

Keeping the current behaviour sounds okay. The only time I wish Elektra supports environment variables – namely the variable "$EDITOR" – is, when kdb editor opens vim instead of TextMate. And yes, I know I can change the editor via:

kdb set user/sw/elektra/kdb/#0/current/editor /Applications/TextMate.app/Contents/Resources/mate

. However if I want to test something, then I often remove the whole configuration beforehand. This implies, that the setting for user/sw/elektra/kdb/#0/current/editor is gone afterwards too.

Adapt XDG

I like the idea behind XDG, since I prefer that tools do not litter all over the base level of my home directory. However, I recently tried to change $XDG_CONFIG_HOME on my own computer (macOS), and did not find a working way to change this variable before login. This makes this specification pretty useless to me, since then all my login items will use an incorrect value for $XDG_CONFIG_HOME.

Easier Switch Between Setups

I think this item should include a description on how we can switch between setups. All in all it sound like implementing this would require a lot of work, without providing many benefits.

Provide two Different Builds

I dislike this idea, since it possibly means twice the work. Especially since we then need to debug two slightly different versions of Elektra.

[markus2330]

Thanks for the detailed answer!

did not find a working way to change this variable before login

Yes, and even if you would found a place to fix it for this situation, there are dozens of other places where you have the same issue (cron and at jobs or anything else executed from some background daemons).

Maybe some more concrete background about the issue at hand. We have some people running Mac OS X who should run scripts using Elektra. The scripts also need a specification to be present. Homebrew certainly helps them to have an easy installation. But in the current situation, they would need to execute at least one script as root so that the mounting can be done.

A completely different way to achieve it (not listed above before) would be to have #1074 but with userspec mounts.

[sanssecours]

A completely different way to achieve it (not listed above before) would be to have #1074 but with userspec mounts.

Implementing user spec mounts sounds like a good idea. Especially, if it allows us to close this issue without adding support for environment variables.

[markus2330]

Thanks for the discussion yesterday!

I added one more point which could be interesting. In the same way as applications can have built-in configuration (keysets compiled in), we could allow kdb to "preload" a keyset which will be used if kdbGet finds nothing. This preload functionality is something which need apps use to work even if /etc and /usr is not there, so it is something apps will do whether or not we like it.

I am not sure, but maybe @KurtMi already wanted to say this yesterday ;)

And one more thought about user spec namespace: It might open the box to Pandora's box because one might argue: why not have a local spec (for apps installed in /usr/local), opt spec (for apps installed in /opt), and vendor spec namespace.

Discussions about implementation of kdb --preload please in #1269, discussion about "Unified access vs. Usability" continues here.

I also look forward for @BernhardDenner views!

[beku]

I vote for XDG as it is the thing on Linux. I understand the rationale behind consistent configuration access. However, calling a command was and is always different on POSIX systems depending on the PATH variable.

Aren't security concerns separate? One way might be to ignore environment variables in elektra, for e.g. user ID's < 500.

[markus2330]

Thanks for your vote!

Aren't security concerns separate?

Yes, security in this context only means that admins lose control over which configuration their users receive. One can argue that for a kiosk system many other modifications are needed (disable executable bit in writable dirs, disable LD_LIBRARY_PATH) that a non-default Elektra variant does not matter at all.

Open questions when adopting XDG as default are:

• Should be XDG only for user namespace or should we extend it to cover the other namespaces, too? I opened the discussion in XDG variables #734
• Should we use XDG only as default on non-linux systems? (I added it as option above)

[markus2330]

Thank you for the discussion. #734 is the issue for the implementation.