Closed awsumco closed 4 years ago
Rather than using the command
module to call systemctl
directly, I would rather this utilize Ansible's built in systemd
module. Look at how we enable gpg-agent.socket. You can basically copy that same task, just changing the name of the unit and removing the conditional. That will replace both your enable
and start
tasks.
I would also prefer to remove the clipboard
tag from the tasks. The user can assign that tag to the entire role when they add it to the playbook. That way is less repetitive.
Oh Aweome let me updates my codes, I see user is being replaced witch scope in Ansible. Thanks for pointing that out.
On that noted can I add a role to start ssh-agent via systemd when gnome is not being used?
You also need to set the XDG_RUNTIME_DIR
environment variable like in the gpg-agent.socket task or else that task can fail. (If I remember correctly, the task will function the way you currently have it if you login as the user and run Ansible via sudo, but without that environment variable it will fail if you login as root, as you would during the initial run.)
On that noted can I add a role to start ssh-agent via systemd when gnome is not being used?
I think you mean when GnuPG is not being used. In that case, yes, I think I would be ok with an additional task in the SSH role which checked for a variable like ssh.enable_agent
(that defaulted to False
) and enabled the agent via systemd.
However, it is worth noting that we do install Keychain, which is what I used to manage the SSH agent prior to moving to GnuPG for that. Using Keychain may be more attractive than starting the SSH agent as a systemd user service. You'd start it in your shell config, so there's no additional Ansible task required.
Thanks for the help, i am going to look into GnuPG as ssh-agent alternative.
PR for hacktoberfest along with adding missing clipboard,
I suggest adding to playbook.yml with clipboard: true in playbook.yml