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)
made new sections for vars, started explaining scope, gave example on command line override of connection vars
added some formatting changes and clarifications
When I followed these instructions, the generated path was 'rpm-build', not 'rpmbuild'. My rpm-build version is rpm-build-4.11.1-25.el7.x86_64 if that's relevant. Maybe this is 'just me', but wanted to feed back in case it's the same for everyone.
commit 9921bb9d20
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Mon Aug 10 20:19:44 2015 +0530
Document --ssh-extra-args command-line option
commit 8b25595e7b
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Thu Aug 13 13:24:57 2015 +0530
Don't disable GSSAPI/Pubkey authentication when using --ask-pass
This commit is based on a bug report and PR by kolbyjack (#6846) which
was subsequently closed and rebased as #11690. The original problem was:
«The password on the delegated host is different from the one I
provided on the command line, so it had to use the pubkey, and the
main host doesn't have a pubkey on it yet, so it had to use the
password.»
(This commit is revised and included here because #11690 would conflict
with the changes in #11908 otherwise.)
Closes#11690
commit 119d032389
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Thu Aug 13 11:16:42 2015 +0530
Be more explicit about why SSH arguments are added
This adds vvvvv log messages that spell out in detail where each SSH
command-line argument is obtained from.
Unfortunately, we can't be sure if, say, self._play_context.remote_user
is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in
ansible.cfg, -u on the command line, or an ansible_ssh_user setting in
the inventory or on a task or play. In some cases, e.g. timeout, we
can't even be sure if it was set by the user or just a default.
Nevertheless, on the theory that at five v's you can use all the hints
available, I've mentioned the possible sources in the log messages.
Note that this caveat applies only to the arguments that ssh.py adds by
itself. In the case of ssh_args and ssh_extra_args, we know where they
are from, and say so, though we can't say WHERE in the inventory they
may be set (e.g. in host_vars or group_vars etc.).
commit b605c285ba
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Tue Aug 11 15:19:43 2015 +0530
Add a FAQ entry about ansible_ssh_extra_args
commit 49f8edd035
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Mon Aug 10 20:48:50 2015 +0530
Allow ansible_ssh_args to be set as an inventory variable
Before this change, ssh_args could be set only in the [ssh_connection]
section of ansible.cfg, and was applied to all hosts. Now it's possible
to set ansible_ssh_args as an inventory variable (directly, or through
group_vars or host_vars) to selectively override the global setting.
Note that the default ControlPath settings are applied only if ssh_args
is not set, and this is true of ansible_ssh_args as well. So if you want
to override ssh_args but continue to set ControlPath, you'll need to
repeat the appropriate options when setting ansible_ssh_args.
(If you only need to add options to the default ssh_args, you may be
able to use the ansible_ssh_extra_args inventory variable instead.)
commit 37c1a5b679
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Mon Aug 10 19:42:30 2015 +0530
Allow overriding ansible_ssh_extra_args on the command-line
This patch makes it possible to do:
ansible somehost -m setup \
--ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"'
This overrides the inventory setting, if any, of ansible_ssh_extra_args.
Based on a patch originally by @Richard2ndQuadrant.
commit b023ace8a8
Author: Abhijit Menon-Sen <ams@2ndQuadrant.com>
Date: Mon Aug 10 19:06:19 2015 +0530
Add an ansible_ssh_extra_args inventory variable
This can be used to configure a per-host or per-group ProxyCommand to
connect to hosts through a jumphost, e.g.:
inventory:
[gatewayed]
foo ansible_ssh_host=192.0.2.1
group_vars/gatewayed.yml:
ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"'
Note that this variable is used in addition to any ssh_args configured
in the [ssh_connection] section of ansible.cfg (so you don't need to
repeat the ControlPath settings in ansible_ssh_extra_args).
`constants.py` is referenced in the *Environmental configuration* section of the documentation. This change provides a link from the documentation to the source code.
This is based on some code from (closed) PR #7872, but reworked based on
suggestions by @abadger and the other core team members.
Closes#7872 by @darkk (hash_merge/hash_replace filters)
Closes#11153 by @telbizov (merged_dicts lookup plugin)
added info/link for ansible-lockdown to mailing list section, minor editing
(can't help myself it seems) to the paragraph about subscribing from a non-google account
The bit about git rebase vs git merge is repeated in the paragraph below. The bit about test/integration is repeated in the paragraph above.
(And the bit about aliasing git pull to git pull --rebase is unclear, since git's aliases cannot override builtin operations.)
This important point gets lost in the fixed width word wrap of the docs site. Separating it out to it's own line stops it being lost in the noise of the previous sentence.
