[FEAT] Allow specifying the playbook state directory

[Neil Schelly]

Is your feature request related to a problem? Please describe.
We have multiple users who might run ansible configuration playbooks against a given system. Since the state for the playbook is stored in a user-specific state directory based on either env.XDG_STATE_HOME or env.HOME, that means that the current state isn't always found depending on who runs the ansible commands.

Describe the solution you'd like
I think the best solution would be allowing a variable like tailscale_state_directory that could override the following set_fact declaration in the playbook. It would have to be a shared folder that allows multiple users to read/write it too.

- name: Install | Determine state folder
  ansible.builtin.set_fact:
    # Following https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
    tailscale_state_folder: "{{ ansible_env.XDG_STATE_HOME | default(ansible_env.HOME + '/.local/state') }}"

[Max Kramarenko]

Thanks for raising this @neilschelly
I have had this issue in my backlog for quite some time, and I was just about to post the same thing. I believe another way to make the state user-independent is to place the state into the /var/lib/<role_name> folder, which is specifically designed for storing the state.

[Ari Kalfus]

Is this not resolved by setting XDG_STATE_HOME to your desired location? The state folder will install as $XDG_STATE_HOME/artis3n-tailscale/state or $HOME/.local/state/artis3n-tailscale/state. It sounds like you would like to customize the location of the artis3n-tailscale directory, in which case you can set the XDG_STATE_HOME env var when invoking this playbook. Could you help me better understand your use case if this isn't sufficient?

[Neil Schelly]

@artis3n , yes, I believe you could do something like that. I guess I felt like that was a mis-use of the XDG_STATE_HOME variable, since it implies that value should be some user-specific location. Then, we'd have to ensure that every user who uses this in our organization uses it with the same XDG_STATE_HOME set, which I think we could handle.

I do think there would be more to it though, because of permissions.

If I chose a more global place, like /var/lib/artis3n-tailscale/, the code looks like it would fail unless my user can create folders under /var/lib without become: true privileges. Even if I used /tmp/artis3n-tailscale, my user could create it without become: true, but it would be created with 0700 permissions, so other users wouldn't be able to get the state.

[Ari Kalfus]

This makes sense - the state folder could be globally readable, it just includes a sha256 hash of the Tailscale authkey so I wanted to restrict access unless necessary. Does overriding a tailscale_state_directory variable satisfy this, it feels like permissions would need to be more open regardless, right?

And I agree now with the conceptual difference of allowing configuring tailscale_state_directory as a role variable vs. setting XDG_STATE_HOME, to your point that it's a misuse of that env var since this state is specific to the server, not to a user on the server.

[Neil Schelly]

How about something like this?

tailscale_state_directory: {{ ansible_env.XDG_STATE_HOME | default(ansible_env.HOME + '/.local/state') }}
tailscale_state_directory_owner: "{{ansible_user_id}}"
tailscale_state_directory_group: "{{ansible_user_gid}}"
tailscale_state_directory_mode: 0700

The other change would be that you'd need to use become: true in the - name: Install | Set state idempotency folder task.

This would basically recreate the existing configuration, but allow someone to put the folder in a better shared location with other users able to access it for deployments too.