Encouraging users to use this Ansible module to enable SELinux seems
like a better idea. It also warms Dan Walsh's heart.
Signed-off-by: Major Hayden <major@mhtx.net>
Allows user to decide if git submodule should track branches/tags or track commit hashes defined in the superproject.
Add track_branches parameter to the git module.
Defaults to track branches behavior.
The default is not very useful to sort between different
keys and user. Adding the hostname in the comment permit to later
sort them if you start to reuse the key and set them in different
servers. See https://github.com/ansible/ansible/pull/7420
for the rational.
This can be tested with this command :
ansible -c local -m copy -a 'src=/etc/group dest=foo/' all
This is a corner case of the algorithm used to find how we should
copy recursively a folder, and this commit detect it and avoid it.
Check https://github.com/ansible/ansible/issues/9092 for the story
It turns out the Route53 API cares if the zone and record specified in the playbook are lower case or not when deleting a record. If you use a variable to name your servers and care about case, using that same proper case name will cause Route53 DNS delete requests to fail.
The change requested adds .lower() to the module.params.get for both zone and record when used in the underlying code.
Both zone and record are mandatory variables, and as such a more complicated implementation is not needed, as they must always be specified when using this module see lines 169 and 170 for the required state).
If you use lowercase names (or don't use a name variable and share it between a tag and DNS entries) then you will never see this issue.
Tested/Confirmed as an issue in Ansible 1.6.6 and above.
Also moves the calculation of the destination file name until after
the slurp of the file contents, since the source as returned by slurp
may now be different, so we want to use that expanded path locally.
Fixes#8942
standards compliant return codes but return a verbose error message via
stdout. Limit the times when we invoke the heuristic to attempt to work
around this.
The example was showing how to use the `files` option to pass in a local file as an authorized public key for root. While this works, it's a bit sloppy, given that there's a specific option, `key_name` which will use one of your public keys on your rackspace account and add it as an authorized key for root. In our case, one of our admins didn't notice the `key_name` option because they scrolled straight to the example and saw the `files` strategy.
I propose that the example still shows `files`, but not using a root public key as an example, and instead also demonstrate the `key_name` option so that it's clear from the example how to get the initial root public key deployed.
