- Add support for inserting module args into PowerShell modules. Fixes#11661.
- Support Windows paths containing spaces. Applies changes from #10727 to v2. Fixes#9999. Should also fixansible/ansible-modules-core#944 and ansible/ansible-modules-core#1007.
- Change how execution policy is set for running remote scripts. Applies changes from #11092 to v2. Also fixesansible/ansible-modules-core#1776.
- Use codepage 65001 (UTF-8) for WinRM connection instead of default (CP437), convert command to UTF-8 and results from UTF-8. Replaces changes from #10024. Fixes#11198.
- Close WinRM connection when task completes.
- Use win_stat, win_file and win_copy modules instead of stat, file and copy when called from within other action plugins (only when using WinRM+PowerShell).
- Unquote Windows path arguments before passing to win_stat, win_file, win_copy and slurp modules (only when using WinRM/PowerShell).
- Check for win_ping module to determine if core modules are missing (only when using WinRM/PowerShell).
- Add stdout_lines to result from running low level commands (so stdout_lines is available when using raw/script).
- Update copy action plugin to use shell functions for joining paths and checking for trailing slash.
- Update fetch action plugin to unquote source path when using Windows paths.
- Add win_copy and win_template action plugins that inherit from copy and template.
- Support running .bat and .cmd scripts using default system encoding instead of UTF-8.
- Always send PowerShell commands as base64-encoded blobs to allow for running simple PowerShell commands via raw.
- Support running modules on Windows with interpreters other than PowerShell.
- Update integration tests to support above changes and test unicode fixes.
- Add test for win_user error from ansible/ansible-modules-core#1241 (fixed by ansible/ansible-modules-core#1774).
- Add test for additional win_stat output values (implemented by ansible/ansible-modules-core#1473).
- Add test for OS architecture and name from setup.ps1 (implemented by ansible/ansible-modules-core#1100).
All WinRM integration tests pass for me with these changes.
This allows usage of tls-1.1 and tls-1.2 if the underlying openssl
library supports it. Unfortunately it also allows sslv2 and sslv3 if
the server is only configured to support those. In this day and age,
that's probably something that the server administrator should fix
anyhow.
If you look at the meaning of the different syslog levels, NOTICE means that the event may need someone to look at it. Whereas INFO is pure informational.
Since module invocations are in fact requested (deliberate) actions, they shouldn't need any additional post-processing, and therefore should not be logged as NOTICE.
This may seem like hairsplitting, but correctly categorizing system events helps weeding through the noise downhill.
According to Wikipedia: https://en.wikipedia.org/wiki/Syslog
5 Notice notice Events that are unusual but not error conditions .
6 Informational info Normal operational messages -no action required. Example an application has started, paused or ended successfully.
The current code expects "uname -W" on AIX to always succeed. The AIX 5
instance I have doesn't support the -W flag and facts gathering always
crashes on it.
This skips some WPAR handling code if "uname -W" doesn't work.
- swapinfo on FreeBSD 6 (maybe 7 too?) doesn't support the "-m" flag for
fetching amounts in megabytes. This patch fetches amounts in kilobytes
and divides by 1024 (and also returns the result as an int instead of
a string).
- When no swap is configured, swapinfo prints a header line and nothing
else:
$ swapinfo
Device 1K-blocks Used Avail Capacity
The old version unexpectedly parsed that header line and emitted
nonsense values like:
"ansible_swapfree_mb": "Avail"
"ansible_swaptotal_mb": "1K-blocks"
This version emits those items altogether.
Since we use domain and account data to filter the project, listall is not needed and can return the wrong identical named project of another account if root admin permissions are used.
Fixed projects names are not case insensitive.
We're being too strict - there is a third possibility, which is that a
user will have defined the OS_* environment variables and expect them to
pass through.
There is a common pattern in modules where some parameters are required
only if another parameter is present AND set to a particular value. For
instance, if a cloud server state is "present" it's important to
indicate the image to be used, but if it's "absent", the image that was
used to launch it is not necessary. Provide a check that takes as an
input a list of 3-element tuples containing parameter to depend on, the
value it should be set to, and a list of parameters which are required
if the required parameter is set to the required value.
With this fix, we get a friendly error message:
failed: [localhost] => {"failed": true}
msg: value of argument start_port is not of type int and we were unable to automatically convert
With this fix, we get a friendly error message:
failed: [localhost] => {"failed": true}
msg: value of argument start_port is not of type int and we were unable to automatically convert