Add CLI options to negate configuration values

[NoSuchCommand]

Proposal: Add CLI options to negate configuration values

Author: Fabien Malfoy <@NoSuchCommand>

Date: 2019-01-25

• Status: New
• Proposal type: feature
• Targeted release: future release

Motivation

There is currently no way to negate the configuration file's boolean values from the command line.

Problems

Main configuration parameters can be specified either inside the configuration file and on the command line. When the same parameter in specified in both the ansible.cfg and the CLI, the command line option usually has precedence. However, regarding boolean values like defaults/ask_pass, privilege_escalation/become and privilege_escalation/become_ask_pass, there is no way to exceptionally negate them from the command line if they have been set to True in the configuration.

As an example, if the configuration sets privilege_escalation/become to True, then the following command will always escalate privileges on the managed host :

someuser@controlnode$ ansible somehost -m anymodule

If one exceptionally wants to run that command/playbook without the privilege escalation (for testing purpose, etc.) and cannot (or does not want) to change the configuration file, the only (inelegant) way is to copy the configuration file to some place else, set privilege_escalation/become to False (or remove it) in the copy, and then set the ANSIBLE_CONFIG environment variable to point to this copy prior to running the ansible command. That seems a lot of work to just negate a configuration parameter.

Solution proposal

Many existing UNIXy commands handle this problem by providing a --no-<option> flag (or, with the spread of golang, an =false suffix to the original flag, eg. --<option>=false).

I would suggest to add at least the following three options to the ansible and ansible-playbook commands :

• --no-become to negate privilege_escalation/become=True
• --no-ask-become-pass to negate privilege_escalation/become_ask_pass=True
• --no-ask-pass to negate defaults/ask_pass=True

Testing (optional)

The command ansible somelinuxhost -u unprivileged_user -m command -a 'ls /root' --no-become (unprivileged_user having unauthenticated sudo as the superuser configured on somelinuxhost) should fail despite privilege_escalation/become set to True in the configuration file.

The command ansible somehost -m module --no-ask-become-pass should not request a become password despite privilege_escalation/become_ask_pass set to True in the configuration file.

The command ansible somehost -m module --no-ask-pass should not request an password despite defaults/ask_pass set to True in the configuration file.

[agaffney]

You can already override these various options from the commandline using env vars (ANSIBLE_BECOME=no, ANSIBLE_BECOME_ASK_PASS=no, and ANSIBLE_ASK_PASS=no). The env vars will always win out over ansible.cfg and commandline flags, You can read more about the various config options and their env var counterparts at:

https://docs.ansible.com/ansible/latest/reference_appendices/config.html

Also, this is a small enough change that a proposal is probably overkill. The proposal process is for changes with far-reaching consequences, and a few new commandline flags doesn't really fit. This could really just be a simple feature request issue (or a pull request) in the https://github.com/ansible/ansible repo.

[NoSuchCommand]

You're right. I forgot about these environment variables. Thank you. But it seems there is no general rule about whether a parameter will be actionable through a command line flag or an environment variable.

Regarding the process, I simply followed the information there : https://docs.ansible.com/ansible/latest/community/reporting_bugs_and_features.html#requesting-a-feature I will file an issue on the project then.

[gundalow]

Ah, that page isn't very well worded, I'll update it.