Ansible 2.8 sudo escalation problem

If you use Ansible, probably you have some habits, that are hard to give them up. Also, many people have a very nasty sin – they ignore deprecation warnings. Moreover, some of them even like turning off warnings about deprecated features! And due to that, they are forced to digging the Internet and looking for the solution to their problem. But there is also another reason for digging – lack of documentation. It’s hard to say what is the cause of the problem which I’m going to describe, but I assume that both causes may be possible. Ok, so what’s the problem? Ansible 2.8 sudo escalation problem. 🙂

What is the problem?

You want to upgrade your Ansible to version 2.8. You read Porting Guide, check the changelog and you think that everything is clear. Then you made necessary changes in your playbook and made an upgrade. And then what? Your playbook crashes for example with the following error:

Of course, it can be another warning, even during the playbook execution (depending on how do you use become). Please check now your ansible.cfg file and check whether you have something like this inside the file:

The flags don’t matter – just check if you have sudo_flags under the defaults section. If the answer is yes, just try to remove this line and add the following section:

So I have Ansible 2.8 sudo escalation problem – but why?

There may be a lot of reasons, but in this article, I want to focus on one – wrong ansible.cfg configuration. In the older version of Ansible, you are able to overwrite the default flags passed to sudo by sudo_flags option. By default, it has -H -S -n value. If you don’t use sudo_flags, nothing bad happens. But if you overwrite like in my example:

You should see the following deprecation warning prior to Ansible 2.8:

It says, that since Ansible 2.8 sudo_flags has been removed. Now Ansible uses [privilege_escalation] section to pass these flags, what you can see in the official documentation. So probably your Ansible 2.8 sudo escalation problem can be caused by that change.

sudo_flags has been changed to become_flags and moved to the [privilege_escalation] section

I hope that was the only problem and my post solved your issue. Of course, if you didn’t change default sudo_flags value, you would not have this problem. So there is a chance, that this solution won’t solve your problem and you need to go deeper.

Bibliography:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.