Nicely explained and thanks, Matt. How should we handle running 'ansible' with '--ask-sudo-pass' but without '--sudo' then?
1. Have '--ask-sudo-pass' trigger an error for 'ansible' without '--sudo'. But what of 'ask_sudo_pass = True' in ansible.cfg when you run 'ansible' without '--sudo'? Is this going to be a problem then for running ad-hoc commands, when you have to be forced to pass in '--sudo', or be errored out? 2. Go ahead and make passing '--ask-sudo-pass' to 'ansible' (whether at the command line, or as part of the config) make it imply '--sudo'. If you have 'ask_sudo_pass = True' in your config, this is going to be a problem for you because now all ad-hoc commands will be run with '--sudo'! 3. (current behaviour right now) Have "--ask-sudo-pass" (whether at the command line, or as part of the config) *not* imply "--sudo" for 'ansible', even though one might be so tempted to make the implication. Slightly unintuitive (at the command line), and If you have 'ask_sudo_pass = True' in your ansible config, also has the slightly irritating behaviour of making ad-hoc commands ask for a password every time, '--sudo' or no '--sudo'. But solves the problem of 2! 4. (an interesting thought) Given all the attendant problems in 1, 2, and 3 with 'ask_sudo_pass = True' in the config... would be it possible to make ad-hoc commands *ignore* the 'ask_sudo_pass' setting in ansible.cfg? I'm not really pushing for this, but it just struck me, and I'm putting it out there as a thought experiment.... thanks all, -jf On Sun, May 4, 2014 at 12:04 PM, Matt Martz <[email protected]> wrote: > The problem here (which was solved by making --ask-sudo-pass not imply > --sudo), is that many people are likely going to have 'ask_sudo_pass = True' > in their ~/.ansible.cfg file. > > 'ask_sudo_pass = True' in ~/.ansible.cfg is the same as supplying > --ask-sudo-pass/-K on the command line. > > So if you use 'ask_sudo_pass = True' in to prevent having to always type > 'ansible-playbook -K', you now have no way of not running ansible ad-hoc > commands without sudo, unless you change your ~/.ansible.cfg or override it > using an env var. > > I think the current functionality is the correct functionality. > > Otherwise, if we want to have --ask-sudo-pass imply --sudo, we need to > decouple the logic that makes 'ask_sudo_pass = True' the same as supplying > --ask-sudo-pass. But then this becomes somewhat inconsistent handling > between config file and command line option. > > -- > Matt Martz > [email protected] > > On May 3, 2014 at 10:49:24 PM, Jeffrey 'jf' Lim ([email protected]) wrote: > > On Sun, May 4, 2014 at 11:17 AM, Michael DeHaan <[email protected]> wrote: >> I was assuming you were talking about ansible-playbook, and while the >> above >> makes sense for ansible, > > Right. I was aware of the difference already before submission (I know > I'm dumb, but not that dumb!) and did understand that it should not be > the case for 'ansible-playbook'. I thought I had made that clear as > well. If you have any suggestions for how to make that clearer > (rewrite subject for PR?), please let me know. > > >> it doesn't make sense for ansible-playbook, and I'm >> wondering if the two should be different. >> > > Definitely not for 'ansible-playbook', true! The 2 ('ansible', vs > 'ansible-playbook') are just naturally different use cases as we know. > > >> (It might be better to make --ask-sudo-pass be an error for >> /usr/bin/ansible >> without --sudo ?) >> > > That's a possible alternative, although I'd prefer the "implies" for > 'ansible' for convenience's sake. Others might have other thoughts on > it, of course, but I think 2 things should be clear right now: one, > something should be done about the current handling in 'ansible' right > now (cos as mentioned in the PR, if you pass in '--ask-sudo-pass' > without '--sudo', 'ansible' will wastefully / frustratingly ask for > the password, but then never activate '--sudo'), and two, the 2 > ('ansible', and 'ansible-playbook') really are 2 different use cases, > and I am only specifically talking about *ansible*. > > My thoughts on this are that if '--sudo-user' can imply '--sudo' (this > is also *specific to 'ansible'*), '--ask-sudo-pass' should imply > '--sudo' too. This was what prompted me to submit the patch. > > -jf > > -- > He who settles on the idea of the intelligent man as a static entity > only shows himself to be a fool. > > Mensan / Full-Stack Technical Polymath / System Administrator > 12 years over the entire web stack: Performance, Sysadmin, Ruby and Frontend > > >> >> >> >> On Sat, May 3, 2014 at 9:02 PM, Jeffrey 'jf' Lim <[email protected]> >> wrote: >>> >>> hi guys, >>> >>> I recently submitted a PR to the project for adding the "implies" back >>> to the *ansible* binary (as opposed to the *ansible-playbook* binary, >>> which is for plays containing multiple commands). The purpose for this >>> was to have *ansible* automatically imply '--sudo' when you give it >>> '--ask-sudo-pass', or '-K' >>> (https://github.com/ansible/ansible/pull/7264). >>> >>> `ansible` (again, as opposed to `ansible-playbook`) should only be for >>> running just the one command; so I dont really see why this should be >>> a problem. Am I missing something here? Does nobody think that >>> `ansible` should assume '--sudo' when you pass it '--ask-sudo-pass'? >>> >>> -jf >>> >>> -- >>> He who settles on the idea of the intelligent man as a static entity >>> only shows himself to be a fool. >>> >>> Mensan / Full-Stack Technical Polymath / System Administrator >>> 12 years over the entire web stack: Performance, Sysadmin, Ruby and >>> Frontend >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/ansible-project/CAE4WMGiYwK4sSq4Utxzm35tkpfwe-i2-r7GgVzs5-KDP4-%2By0Q%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyFna_45Sj4qmDhe6gz%2BtDiHy6%2Bxf9yCOrpJkatKW3JTQ%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAE4WMGg-ZwOs%2B7fZMnY-4CUsG-0jZrKk7VwqSEr2gG-iQmpoZA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAE4WMGhNHLF-tyi6w4i%2BY7g0sd5VwDNz6xnpV197_%2BY74pXOhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
