* Only report change when home directory is different
Add tests with home: parameter
Have to skip macOS for now since there is a bug when specifying the home directory path for an existing user that results in a module failure. That needs to be fixed in a separate PR.
* fix a (forgotten?) change in moving createhome -> create_home
Fix for following bug on FreeBSD host whith user module:
```
fatal: [webssp]: FAILED! => {"changed": false, "module_stderr": "X11 forwarding request failed
Traceback (most recent call last):
File \"/tmp/ansible_2rmlBl/ansible_module_user.py\", line 2487, in <module>
main()\n File \"/tmp/ansible_2rmlBl/ansible_module_user.py\", line 2426, in main
(rc, out, err) = user.modify_user()
File \"/tmp/ansible_2rmlBl/ansible_module_user.py\", line 1011, in modify_user
if (info[5] != self.home and self.move_home) or (not os.path.exists(self.home) and self.createhome):
AttributeError: 'FreeBsdUser' object has no attribute 'createhome'
", "module_stdout": "", "msg": "MODULE FAILURE", "rc": 1}
```
It happenned with 'createhome' AND with 'create_home' form, with python 2.7 AND python 3.6
* Add changelog
Co-authored-by: dgeo <dgeo@users.noreply.github.com>
* win_reboot: fix 2.6 issues and better handle post reboot reboot
* changed winrm _reset to reset
* Add handler to reset calls when .reset() throws an AnsibleError on older hosts
* Moving back to _reset to get the issue fixed
The ssh connection plugin is overzealous in thinking that error code 255
can only come from ssh. Python can return 255 in some circumstances and
error from php does as well.
* __file__ won't work if we want to invoke modules via -m or if we
figure out how to keep modules from hitting the disk with pipelining.
* module.tmpdir is the new way to place a file where it will be cleaned
automatically.
Change format string to not depend on __file__:
* cloud/amazon/ec2_elb_lb.py
* cloud/amazon/elb_classic_lb.py
Use module.tempdir:
* packaging/os/apt.py
* files/unarchive.py
* Add additional puppet options
Add support for puppet options --debug, --verbose, --summary,
and extend logdest to support logging to stdout and syslog at
the same time.
Fixes issue: #37986
* Fix docs
* Doc fix, add release note
* Fix silly yaml error
* Correct changelog, add C() to params in doc
* Fix tmpdir on non root become
- also avoid exception if tmpdir and remote_tmp are None
- give 'None' on deescalation so tempfile will fallback to it's default behaviour
and use system dirs
- fix issue with bad tempdir (not existing/not createable/not writeable)
i.e nobody and ~/.ansible/tmp
- added tests for blockfile case
* Revert "Temporarily revert c119d54"
This reverts commit 5c614a59a6.
* changes based on PR feedback and changelog fragment
* changes based on the review
* Fix tmpdir when makedirs failed so we just use the system tmp
* Let missing remote_tmp fail
If remote_tmp is missing then there's something more basic wrong in the
communication from the controller to the module-side. It's better to
be alerted in this case than to silently ignore it.
jborean and I have independently checked what happens if the user sets
ansible_remote_tmp to empty string and !!null and both cases work fine.
(null is turned into a default value controller-side. empty string
triggers the warning because it is probably not a directory that the
become user is able to use).
* Revert "Account for empty string regexp in lineinfile (#41451)"
This reverts commit 4b5b4a760c.
* Use context managers for interacting with files
* Store line and regexp parameters in a variable
* Add warning when regexp is an empty string
* Remove '=' from error messages
* Update warning message and add changelog
* Add tests
* Improve warning message
Offer an equivalent regexp that won't trigger the warning.
Update tests to match new warning.
* Add porting guide entry for lineinfile change
* elasticsearch_plugin - Show STDERR on module failures.
I tried to install a ES plugin without
become: yes
and found after debugging the module that the module failed ude to permission issues.
The only error message I got was
Is analysis-icu a valid plugin name?
That was strange considering I followed the example documentation by the letter.
I found out that when this module fails, it hides the real reason for failure.
This patch replaces the generic error with more meaningful diagnostics.
* elasticsearch_plugin - Show STDERR on module failures. Changelog fragment
samdoran commented 2 days ago
This looks good. Please create a changelog fragment to go along with this change. See fragments for examples.
* runas + async - get working on older hosts
* fixed up sanity issues
* Moved first task to end of test for CI race issues
* Minor change to async test to be more stable, change to runas become to not touch the disk
* moved async test back to normal spot
* Add aws/core.py function to check for specific AWS error codes
* Use sys.exc_info to get exception object if it isn't passed in
* Allow catching exceptions with is_boto3_error_code
* Replace from_code with is_boto3_error_code
* Return a type that will never be raised to support stricter type comparisons in Python 3+
* Use is_boto3_error_code in aws_eks_cluster
* Add duplicate-except to ignores when using is_boto3_error_code
* Add is_boto3_error_code to module development guideline docs
In the process of building up the inventory by parsing each inventory
source with each available inventory plugin, there are three kinds of
possible errors (listed in order from earliest to latest):
1. One source could not be parsed by a particular plugin.
2. One source could not be parsed by any available plugin.
3. ALL sources could not be parsed by any available plugin.
The errors in (1) are a part of normal operation, e.g., the script
plugin is expected to fail to parse an ini-format source, and we will
ignore that error and try the next plugin. There is currently no way to
control this, and no known compelling use-case for a setting to control
it. This commit does not make any changes here.
We implement "any_unparsed_is_failed" to handle (2) above. If enabled,
this requires that every available source be parsed validly by at least
one plugin. In an inventory comprising a static hosts file and ec2.py,
this setting will cause a fatal error if ec2.py fails (a situation that
attracted only a warning earlier).
We clarify that the existing "unparsed_is_failed=true" setting causes a
fatal error only in (3) above, i.e., if NO inventory source could be
parsed. In other words, if there is ANY valid source in the inventory
(e.g., an ini-format static file), no combination of errors and the
setting will cause a fatal error.
If you want to execute your playbooks when your inventory is…
(a) complete, use "any_unparsed_is_failed=true".
(b) not empty, use "unparsed_is_failed=true".
The "unparsed_is_failed" setting should be renamed to
"all_unparsed_is_failed", but this commit does not do so.
Fixes#40512Fixes#40996
