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/etPan.5365bc59.6b8b4567.16f22%40mobiletuvix.rackspace.corp. For more options, visit https://groups.google.com/d/optout.
