Open neilschelly opened 5 months ago
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.
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?
@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.
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.
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.
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
orenv.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 followingset_fact
declaration in the playbook. It would have to be a shared folder that allows multiple users to read/write it too.