You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
ansible/test/integration/targets/user/tasks/test_local.yml

244 lines
5.4 KiB
YAML

user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
## Check local mode
# Even if we don't have a system that is bound to a directory, it's useful
# to run with local: true to exercise the code path that reads through the local
# user database file.
# https://github.com/ansible/ansible/issues/50947
- name: Create /etc/gshadow
file:
path: /etc/gshadow
state: touch
when: ansible_facts.os_family == 'Suse'
tags:
- user_test_local_mode
- name: Create /etc/libuser.conf
file:
path: /etc/libuser.conf
state: touch
when:
- ansible_facts.distribution == 'Ubuntu'
- ansible_facts.distribution_major_version is version_compare('16', '==')
tags:
- user_test_local_mode
- name: Ensure luseradd is present
action: "{{ ansible_facts.pkg_mgr }}"
args:
name: libuser
state: present
when: ansible_facts.system in ['Linux']
tags:
- user_test_local_mode
- name: Create local account that already exists to check for warning
user:
name: root
local: yes
register: local_existing
tags:
- user_test_local_mode
- name: Ensure no local_ansibulluser
user:
name: local_ansibulluser
state: absent
local: yes
remove: true
tags:
- user_test_local_mode
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
- name: Create local_ansibulluser
user:
name: local_ansibulluser
state: present
local: yes
register: local_user_test_1
tags:
- user_test_local_mode
- name: Create local_ansibulluser again
user:
name: local_ansibulluser
state: present
local: yes
register: local_user_test_2
tags:
- user_test_local_mode
- name: Remove local_ansibulluser
user:
name: local_ansibulluser
state: absent
remove: yes
local: yes
register: local_user_test_remove_1
tags:
- user_test_local_mode
- name: Remove local_ansibulluser again
user:
name: local_ansibulluser
state: absent
remove: yes
local: yes
register: local_user_test_remove_2
tags:
- user_test_local_mode
- name: Create test groups
group:
name: "{{ item }}"
loop:
- testgroup1
- testgroup2
- testgroup3
- testgroup4
- testgroup5
- testgroup6
- local_ansibulluser
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
tags:
- user_test_local_mode
register: test_groups
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
- name: Create local_ansibulluser with groups
user:
name: local_ansibulluser
state: present
local: yes
groups: ['testgroup1', 'testgroup2']
register: local_user_test_3
ignore_errors: yes
tags:
- user_test_local_mode
- name: Append groups for local_ansibulluser
user:
name: local_ansibulluser
state: present
local: yes
groups: ['testgroup3', 'testgroup4']
append: yes
register: local_user_test_4
ignore_errors: yes
tags:
- user_test_local_mode
- name: Append groups for local_ansibulluser (again)
user:
name: local_ansibulluser
state: present
local: yes
groups: ['testgroup3', 'testgroup4']
append: yes
register: local_user_test_4_again
ignore_errors: yes
tags:
- user_test_local_mode
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
- name: Test append without groups for local_ansibulluser
user:
name: local_ansibulluser
state: present
append: yes
register: local_user_test_5
ignore_errors: yes
tags:
- user_test_local_mode
- name: Assign named group for local_ansibulluser
user:
name: local_ansibulluser
state: present
local: yes
group: testgroup5
register: local_user_test_6
tags:
- user_test_local_mode
- name: Append groups for local_ansibulluser using group id
user:
name: local_ansibulluser
state: present
append: yes
groups: "{{ test_groups.results[5]['gid'] }}"
register: local_user_test_7
ignore_errors: yes
tags:
- user_test_local_mode
- name: Append groups for local_ansibulluser using gid (again)
user:
name: local_ansibulluser
state: present
append: yes
groups: "{{ test_groups.results[5]['gid'] }}"
register: local_user_test_7_again
ignore_errors: yes
tags:
- user_test_local_mode
# If we don't re-assign, then "Set user expiration" will
# fail.
- name: Re-assign named group for local_ansibulluser
user:
name: local_ansibulluser
state: present
local: yes
group: local_ansibulluser
ignore_errors: yes
tags:
- user_test_local_mode
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
- name: Remove local_ansibulluser again
user:
name: local_ansibulluser
state: absent
remove: yes
local: yes
tags:
- user_test_local_mode
- name: Remove test groups
group:
name: "{{ item }}"
state: absent
loop:
- testgroup1
- testgroup2
- testgroup3
- testgroup4
- testgroup5
- testgroup6
- local_ansibulluser
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
tags:
- user_test_local_mode
- name: Ensure local user accounts were created and removed properly
assert:
that:
- local_user_test_1 is changed
- local_user_test_2 is not changed
- local_user_test_3 is changed
- local_user_test_4 is changed
- local_user_test_4_again is not changed
- local_user_test_6 is changed
- local_user_test_7 is changed
- local_user_test_7_again is not changed
user - properly handle password and password lock when used together (#73016) Do the right thing on Linux when password lock and a password hash are provided by writing out the password hash prepended by the appropriate lock string rather than using -U and -L. This is the correct way to set and lock the account in one command. On BSD, run separate commands as appropriate since locking and setting the password cannot be done in a single action. FreeBSD requires running several commands to get the account in the desired state. As a result, the rc, output, and error from all commands need to be combined and evaluated so an accurate and complete summary can be given at the end of module execution. * Improve integration tests to cover this scenario. * Break up user integration tests into smaller files * Properly lock account when creating a new account and password is supplied * Simplify rc collection in FreeBSD class Since the _handle_lock() method was added, the rc would be set to None, which could make task change reporting incorrect. My first attempt to solve this used a set and was a bit too complicated. Simplify it my comparing the rc from _handle_lock() and the current value of rc. * Improve the Linux password hash and locking behavior If password lock and hash are provided, set the hash and lock the account by using a password hash since -L cannot be used with -p. * Ensure -U and -L are not combined with -p since they are mutually exclusive to usermod. * Clarify password_lock behavior.
4 years ago
- local_user_test_remove_1 is changed
- local_user_test_remove_2 is not changed
tags:
- user_test_local_mode
- name: Ensure warnings were displayed properly
assert:
that:
- local_user_test_5['warnings'] is search("'append' is set, but no 'groups' are specified. Use 'groups'")
- local_existing['warnings'] is not defined
when: ansible_facts.system in ['Linux']
tags:
- user_test_local_mode
- name: Test expires for local users
import_tasks: test_local_expires.yml