When I executed `launchctl limit maxfiles 1024 2048` , my entire system would become unusable, as all of the sudden no process could use any file anymore, reporting that the max file limit was reached.
Only a hard reboot could fix the problem, which fortunately revealed that the configuration was not saved.
The change I made *should* remedy the issue, even though I didn't test it.
Therefore I hope you can revise the documentation to be sure nothing bad happens.
# Meta
Tested on OSX 10.11.2
The sentence seemed to imply that return codes from modules are significant, while they are not. The second part of the sentence confirms this, as it advises to use standard return codes only for future proofing.
At its most basic, this is nothing more than an array or hash lookup,
but when used in conjunction with map, it is very useful. For example,
while constructing an "ssh-keyscan …" command to update known_hosts on
all hosts in a group, one can get a list of IP addresses with:
groups['x']|map('extract', hostvars, 'ec2_ip_address')|list
This returns hostvars[a].ec2_ip_address, hostvars[b].ec2_ip_address, and
so on. You can even specify an array of keys for a recursive lookup, and
mix string and integer keys depending on what you're looking up:
['localhost']|map('extract', hostvars, ['vars','group_names',0])|first
== hostvars['localhost']['vars']['group_names'][0]
== 'ungrouped'
Includes documentation and tests.
The inventory pattern delimiter used in the examples switches between the comma and colon. While both are valid I've found this throws off new users so I've modified the examples to consistently use a colon, the more common of the two in my experience.
Noticed that the v1 variable precedence docs list facts discovered as having a lower precedence than inventory variables. It is in reality the other way around. The v2 section gets this right.
I found it difficult to find documentation for how to pull from a git-based scm that wasn't github. The only way I could find this option was to dig through the google-group.
This is a confusing part of roles and tags. Most people assume that tagging a role means that the tagged tasks inside the role will run based on the tags specified. But in reality, it tags the whole role with those tags.
Closes#12990.
Alternative to #12992
This PR excludes all attributes of the following data types: lists,
tuples, dicts, sets, integers, floats, strings and Unicode objects.
It is expected that only the attributes of dicts and sets would cause an
problem like in #12990.
I was caught out by the different behaviour of lookups & local tasks, and could not find the difference documented anywhere at all, so I took the liberty of proposing this change.
Lookups are always relative to the role or play.
Local tasks are relative to the cwd from which you execute.
In the installation guide, the raw module is mentioned as an option for
installing Python or simplejson on managed nodes that don't have them.
This change adds an example for users that may already be familiar with
using ansible but are checking install docs because they don't know the
requirements for managed nodes, or are using a distribution that doesn't
include Python 2 by default.
This work fulfills PR #11799. Moved the content out of the vault file,
into best practices, edited it, then referenced it from variables and
vaults content files.
ansible_ssh_* changes from 1.9 to 2.0, original note made into a separate file
for easier editing, and an include for this new file added to each of the 6 file affected
by this change
Ansible 2.0 has depricated the “ssh” from ansible_ssh_user,
ansible_ssh_host, and ansible_ssh_port to become ansible_user,
ansible_host, and ansible_port. If you are using a version of
Ansible prior to 2.0, you should continue using the older style
variables (ansible_ssh_*). These shorter variables are ignored,
without warning, in older versions of Ansible.
added a note like the following to each file hit with unlabled 2.0 changes...
Ansible 2.0 moved away from using ansible_ssh_* variables to accepting
ansible_* variables. If you are using a version of Ansible prior to 2.0,
you should continue using the older style variables (ansible_ssh_*), such
as ansible_ssh_user instead of ansible_user and ansible_ssh_port instead of
ansible_port, which appear in the following content. These shorter variables
are ignored, without warning, in older versions of Ansible.
Now we have the following ways to set additional arguments:
1. [ssh_connection]ssh_args in ansible.cfg: global setting, prepended to
every command line for ssh/scp/sftp. Overrides default ControlPersist
settings.
2. ansible_ssh_common_args inventory variable. Appended to every command
line for ssh/scp/sftp. Used in addition to ssh_args, if set above, or
the default settings.
3. ansible_{sftp,scp,ssh}_extra_args inventory variables. Appended to
every command line for the relevant binary only. Used in addition to
#1 and #2, if set above, or the default settings.
3. Using the --ssh-common-args or --{sftp,scp,ssh}-extra-args command
line options (which are overriden by #2 and #3 above).
This preserves backwards compatibility (for ssh_args in ansible.cfg),
but also permits global settings (e.g. ProxyCommand via _common_args) or
ssh-specific options (e.g. -R via ssh_extra_args).
Fixes#12576
This allows the EC2 inventory plugin to be used with
the same configuration against different EC2 accounts
Profile can be passed using --profile variable or using
EC2_PROFILE environment variable e.g.
```
EC2_PROFILE=prod ansible-playbook -i ec2.py playbook.yml
```
Added documentation on profiles to EC2 dynamic inventory doc
Only tries to use profiles if --profile argument is given
or EC2_PROFILE is set to maintain compatibility will boto < 2.24.
Works around a minor bug in boto where if you try and use
a security token with a profile it fails (boto/boto#2100)