Categories
Ansible Ansible Tower Red Hat

Ansible Tower – Local_Action + Sudo ?

There are many times when you run an Ansible playbook through Ansible Tower and you have to become a privileged user on the target system. This is business as usual for Ansible and Ansible Tower.

This is normally achieved by specifying become as part of your playbook, such as this snippet.

---
- name: Patch Linux
  hosts: all
  gather_facts: true
  become: true

Typically, as part of a patching playbook, you would reboot the system and wait for the reboot to finish using a code fragment like this :

 - name: Wait for server to restart
   local_action:
     module: wait_for
       host={{ ansible_ssh_host }}
       port=22
       delay=60
       timeout=300

This local_action inherits the become: true from the parent definition and this is where Tower starts to complain. Remember, with Ansible Tower, it’s the tower server itself where the local_action will run. You can expect to see something like this :

"module_stderr": "sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?\n",

No, you SHOULD NOT enable the awx user to use sudo on the Tower system as the AWX service user is intentionally restricted from sudo operations. The best approach is to de-privilege the local_action. Fortunately, local_action has it’s own become capability so you can turn off the request for privileged access as you don’t need it.

The above code block is now :

 - name: Wait for server to restart
   become: false
   local_action:
     module: wait_for
       host={{ ansible_ssh_host }}
       port=22
       delay=60
       timeout=300

and the tower job template will execute without any errors.

Categories
vRA vRealize

vRA, where is my template?

So, you’ve automated everything related to your template creation. You use packer like a boss as part of your CI/CD toolchain. They’re automatically placed onto your vmware environment and you wait for a mystical event to occur where the templates become available to vRA so you can use them in blueprints…. you sigh

Yes, you know you can set the refresh for the inventory to an hour ….. an hour… OMG you’ll be watching cat videos and forget what you’re doing before that happens.

Yes, you also know that you can navigate the clicky clicky world of vRA and refresh the inventory on demand as part of the data collection tasks. Sadly Jenkins is a little unwilling to clicky click and demands programmatic access (I know the REST api would be better for this use case, please humour me).

Well, Cloudclient comes to the rescue. In a previous post I introduced you to Cloudclient, a CLI interface to vRA.

The thing to note here is that the compute resources are managed by the IaaS servers and not the vRA appliance itself. Since you’ll be asking the IaaS server to do something (refresh the inventory) you’ll need to ensure your Cloudclient session is logged into the IaaS infrastructure.

vra login iaas --server {iaas-server-vip} --domain {domain} --user {user} --password {password}
vra computeresource list
vra computeresource datacollection start --name {resource-name} --waitforcompletion yes

You’re a wizard!