Adopt XDG installation layout

[aricart]

Currently, nsc uses $NSC_HOME and $NKEYS_PATH to determine where to find cli configuration and write files. nats uses the XDG Base Directory Specification.

Migrate nsc to also use XDG to determine where to store assets:

• binary moves from $NSC_HOME/bin (~/.nsc/bin) to $XDG_DATA_HOME/bin (~/.local/bin)
• nsc configuration moves from $NSC_HOME/nsc.json to $XDG_CONFIG_HOME/nsc/nsc.json (~/.config/nsc)
• default store moves from $NSC_HOME/nats to $XDG_DATA_HOME/nsc/stores (~/.local/share/nsc/stores)
• nkeys from NKEYS_PATH (~.nkeys) to $XDG_DATA_HOME/nsc/nkeys (~/.local/share/nsc/nkeys)

Migrating the tools to the new location also requires updating nats cli configurations stored in .config/nats/context as some files may embed paths pointing to ~/.nsc/nats...

https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-21.md

[aricart]

@philpennock @derekcollison I wanted to get any comments/suggestions you may have on this, as this could be a somewhat painful experience if we don't get it right. This possibly would be good time to add a context command to the tool so that at the very least we can reference stores/nkeys directories using a profile like natscli does.

[derekcollison]

Might be worth a call tomorrow.

Also, IIRC we were going with ~/.config/nats/nsc no?

[aricart]

Also, IIRC we were going with ~/.config/nats/nsc no?

the nats cli took ownership of that directory in its entirety.

[derekcollison]

That directory is for all of nats, not just the cli. So let's make sure they both live under that location.

[aricart]

We'll have to move some top-level contents one down.

…

On Wed, Jan 19, 2022 at 9:22 AM Derek Collison ***@***.***> wrote: That directory is for all of nats, not just the cli. So let's make sure they both live under that location. — Reply to this email directly, view it on GitHub <#445 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH4GEGTF2QAM5QMSQTTFFLUW3JNFANCNFSM5MIQCEZA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[derekcollison]

Let's make sure we do that. NATS cli should not own that space.

[aricart]

I am not sure that is the right thing to do. The reason being is that by each tool having its own set of dirs (even if we agree on some common ones) upgrades and other things can be safer as the tool can assert if there are contents it doesn't expect somewhere.

In the case of nats-cli the library itself decides where most of the assets are located by following the XDG specification. Only when it comes to storing data it looks up $XDG_DATA_HOME which by default will resolve to ~/.local/share (in my case I have nothing there), the rest of the config (context dir, context.txt, and other things) are automagically routed to ~/.config/nats

[philpennock]

AFAIK the nats CLI only uses the context/ sub-dir and the context.txt file.
I agree that we should be cautious about multiple tools working in the same space, but ... we should still use the same space. People trying to find all the configuration for talking to a NATS server should not have to memorize all the different tools available to find all the configuration: it should just be inside the "nats" area.

To deal with the need for caution, perhaps just an ADR doc which describes how we use the space, says what is guaranteed for other tools vs implementation details we reserve the right to change and registers the "ownership" of each bit within the space.

I think that the right way to deal with multiple paths is to have the tool migrate the data from old location to new, then drop in place a symlink pointing from the old-place to the new so that other configurations will keep working. We can later add migration warnings.

The one thing to be careful of is making sure to either handle, or detect and gracefully bail out, when files are laid out a bit differently to how we expect. For instance, my ~/.nsc/nats is a symlink pointing to ../etc/private/nats-dothome/nsc_nats because ~/etc/private is a gocryptfs mount which isn't always mounted. This is where I keep credential files which have to live on-disk as-is.

If we're going to migrate, we should also consider that macOS does not follow XDG, and nor does Windows. Even if we don't want to pull in an extra dependency, the layouts at https://github.com/adrg/xdg should be examined and understood before migrating. And if we're going to migrate: even if we don't start using the Keychain now, we should document in the same ADR what our tentative plans are.

(Note: using Keyrings on Linux is not at all comparable in security or quality to Keychain on macOS; the Keychain is a step forward for security, the Keyring is a step backwards)

[philpennock]

After discussion with Alberto, I've written nats-io/nats-architecture-and-design#88 to address the various concerns and properly document how things should be handled. It's a first draft, it might be a little rough.

[aricart]

This is already implemented