ansible_facts["user_dir"] holds unexpected literal as value
#10
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I believed that the string value held by
ansible_facts["user_dir"]would be equivalent to the home directory path of the user Ansible used to log in to the remote host / managed node via SSH (e.g.,ansible_user) based on the ran playbook. Turns out this is not the case, just as it is not the case thatansible_userandansible_facts["user_id"]are equal in string value when running an Ansible playbook.I may have to replace all instances of
ansible_facts["user_dir"]in the code base that intended to refer to the Ansible playbook SSH user's home directory with some other variable, variable and string literal concatenation, or mere string literal.Given the Ansible playbook was run in check mode, it may be some unique or irregular behavior due to the check mode context. This is a reasonable hypotheses given that, in another case, the group module under check mode does not actually make any changes and thus any following user module that tries to reference a group meant to be created by a group module task may fail. This in spite of check mode reporting it as a successful change--it is successful only so far as the atomic simulation of the task. This means there may be problems with value passing across tasks, especially when some modules may even lack support in check mode.
Rather than use
check modefor validation, its best to use staging instead.For staging, use either a virtual machine (using Vagrant or virt-manager?) or a container.
A Debian 13 based headless virtual machine with SSH service has been spun up using
virt-manager.