* Don't treat parsing problems as async task timeout
If there is a problem reading/writing the status file that manifests as
not being able to parse the data, that doesn't mean the task timed out,
it means there was what was likely a tempoarary problem. Move on and
keep polling for success. The only things that should cause the async
status to not be parseable are bugs in the async_runner.
* Add comment explaining not bailing out of loop
* Return different error when result is unparseable
* Remove extraneous else
* Instead of rebuilding the handler list all over the place, we now
compile the handlers at the point the play is post-validated so that
the view of the play in the PlayIterator contains the definitive list
* Assign the dep_chain to the handlers as they're compiling, just as we
do for regular tasks
(cherry picked from commit 930d090507)
Since the rest of the file already use a non 2.4 syntax
(such as format), I didn't bother using the 2.4 syntax for
exceptions.
(cherry picked from commit eb52dc9af0)
We want to update host vars for all hosts (even those that might
have failed), and the in case of a refresh_inventory, the code has
a stale restrictions list at this point anyway.
(cherry picked from commit 0c4effb8a6)
This patch corrects the way we look in the inventory hosts list for
implicit localhost entries when localhost aliases are used.
Fixes#16568
(cherry picked from commit 83e4a4048b)
* Parse async response in async action.
* Add async test for non-JSON data before module output.
* Fix existing async unit test.
Resolves#16156
(cherry picked from commit 292785ff2b)
In the case of using YAML anchors/aliases, YAML actually uses references
to the duplicated object so any modifications to the original impacts
later uses of the object.
Fixes#13575
(cherry picked from commit af249b83e6)
* Lookup unencrypted password must not include salt
* Integration test lookup: remove previous directory
* Test that lookup password doesn't return salt
* Lookup password: test behavior with empty encrypt parameter
Closes#16189
(cherry picked from commit b361bf90d7)
* Remove unnecessary copying of values from parents to role deps, as
this can cause problems when roles have multiple parents (or the same
parents with different params speficied through deps)
* Since we're already checking the dep chain in the block for role
things (which every task in a role should have), it is not necessary
to check the role directly in case it improperly grabs something
Fixes#14438
(cherry picked from commit 3e4755f7e4)
Our custom encoder for the to_json filter was simply returning the
object if it was not a HostVars object, leading in some cases to a
TypeError when the data contained an undefined variable. This lead
to an odd error message being propagated up, so we now properly catch
this as an undefined variable error.
Fixes#15610
(cherry picked from commit c24c0f5f6b)
The find_mount_point function does not resolve the mount point of paths with a soft-link correctly and returns the wrong mount-point.
I have mounted an NFS filesystem on /nfs-mount. This directory contains a directory called "directory". I also created a soft-link to this last directory: /soft-link-to-directory -> /nfs-mount/directory. I created the following task to copy a file into /soft-link-to-directory:
- name: copy file to nfs-mount
copy:
src: "file"
dest: "/soft-link-to-directory/file"
This throws an exception:
invalid selinux context: [Errno 95] Operation not supported
This is caused by the find_mount_point function to return '/' as the mount point for '/soft-link-to-directory/file'. This should have been /nfs-mount. Because the find_mount_point returns the wrong mount-point, the is_special_selinux_path function does not recognise the file is on an NFS mount and tries to set the default SELinux context (system_u:object_r:default_t:s0), which fails. The context should have been: system_u:object_r:nfs_t:s0
Full Ansible output:
TASK [copy file to nfs-mount] **************************************************
fatal: [hostname]: FAILED! => {"changed": false, "checksum": "f34b60930a5d6d689cf49a4c16bd7f9806be608c", "cur_context": ["system_u", "object_r", "nfs_t", "s0"], "failed": true, "gid": 24170, "group": "foundation", "input_was": ["system_u", "object_r", "default_t", "s0"], "mode": "0644", "msg": "invalid selinux context: [Errno 95] Operation not supported", "new_context": ["system_u", "object_r", "default_t", "s0"], "owner": "root", "path": "/soft-link-to-directory/.ansible_tmpWCT6Z4file", "secontext": "system_u:object_r:nfs_t:s0", "size": 37, "state": "file", "uid": 0}
(cherry picked from commit 23349911f1)
Again, as we're carrying failed/unreachable hosts forward from play to play via
internal structures, we need to remember which ones had previously failed so that
unrelated host failures don't inflate the numbers for a given serial batch in the
PlaybookExecutor causing a premature exit.
Fixes#16364
(cherry picked from commit 4c1601e9f2)
When the PYTHONPATH is an empty string python will treat it as though
the cwd is in the PYTHONPATH. This can be undesirable. So make sure we
delete PYTHONPATH from the environment altgether in this case.
Fixes#16195
Due to the fact that roles may be instantiated with different sets of
params (multiple inclusions of the same role or via role dependencies),
simply tracking notified handlers by name does not work. This patch
changes the way we track handler notifications by using the handler
object itself instead of just the name, allowing for multiple internal
instances. Normally this would be bad, but we also modify the way we
search for handlers by first looking at the notifying tasks dependency
chain (ensuring that roles find their own handlers first) and then at
the main list of handlers, using the first match it finds.
This patch also modifies the way we setup the internal list of handlers,
which should allow us to correctly identify if a notified handler exists
more easily.
Fixes#15084
Symlinks inside of the chroot were failng because we weren't able to
determine if they were pointing to a real file or not. We could write
some complicated code to walk the symlink path taking into account where
the root of the tree is but that could be fragile. Since this is just
a sanity check, instead we just assume that the chroot is fine if we
find that /bin/sh in the chroot is a symlink. Can revisit if it turns
out that many chroots have a /bin/sh that's a broken symlink.
Fixes#16097
