Author Archives: John Lieske
Author Archives: John Lieske
Welcome to another entry in the Getting Started series! In this post we’ll talk about how to use Red Hat Satellite 6 as an inventory source within Ansible Tower. A common scenario we see is the use of Satellite 6.3 to manage Red Hat Enterprise Linux infrastructure, which makes adding Red Hat Ansible Tower to the existing environment a snap.
Ansible Tower will need to authenticate to Satellite, so create a user with an integration role that has the permissions needed to manage inventory. The permissions needed are:
|Fact value||view_facts||Read Satellite Server facts.|
|Host||view_hosts||Read Satellite Server hosts.|
|Host group||view_hostgroups||View Satellite Server host groups.|
Once you’ve created your user, log in to the Tower host.
Navigate to Settings >> Credentials in Tower and create a new credential.
The credential type can be found in the credential type list:
Once you select ‘Red Hat Satellite 6’, the field to add the Satellite URL will be available:
With the Satellite server prepared and the credential in place within Tower, all that’s left Continue reading
Welcome to the fourth installment of our Windows-centric Getting Started Series!
One of the duties of most IT departments is keeping systems up to date. In this post we’re taking a quick look at using Ansible to manage updates on your Windows nodes. Starting with a small example of six Windows machines, we’ll show an example of a play against those hosts. We’ll share the full example at the end.
Managing Windows updates is something that can be understood and customized quickly with Ansible. Below is a small-scale example of running updates on hosts with some flexibility in what gets updated in the process. The example here is assuming a domain exists and the hosts are being passed domain credentials. If you’re looking to test this example, be sure to read Bianca’s earlier Getting Started post on connecting to a Windows host.
Because this example is running against exclusively Windows machines, the information needed to connect can be included in the inventory file:
[all:vars] ansible_connection: winrm ansible_user: administrator ansible_password: This-Should-Be-a-Password!
The example hosts include three groups of servers, two in each group. There are terminal servers, application servers, and directory servers. For the purposes of Continue reading
Welcome to the second installment of our Windows-centric Getting Started series!
Last time we walked you through how Ansible connects to a Windows host. We’ve also previously explored logging into Ansible Tower while authenticating against an LDAP directory. In this post, we’ll go over a few ways you can use Ansible to manage Microsoft’s Active Directory. Since AD plays a role in many Windows environments, using Ansible to manage Windows will probably include running commands against the Active Directory domain.
We’ll be using WinRM to connect to Windows hosts, so this means making sure Ansible or Tower knows that. Machine credentials in Ansible Tower can be created and used along with variables, but when using Ansible in a terminal the playbook should make it clear with variables:
--- - name: Your Windows Playbook hosts: win vars: ansible_ssh_user: administrator ansible_ssh_pass: ThisIsWhereStrongPassesGo ansible_connection: winrm ansible_winrm_server_cert_validation: ignore - tasks:
Along with using the local admin account/pass, the WinRM connection method is named specifically. The variable to ignore the certificate validation is for standalone, non-domain hosts because a domain-joined instance should have certificates validated on the domain.
Speaking of domains, Ansible can spin up a new domain Continue reading
Thanks for checking out the Getting Started series! This quick tutorial lists the basic steps needed to perform an upgrade of Red Hat Ansible Tower in a standalone configuration. Specifically, we'll be upgrading Ansible Tower 3.1.0 to the latest (as of this writing) version 3.2.2 in a few simple steps. There are some things you’ll need to keep in mind while upgrading (e.g., editing the inventory file appropriately), and a description will be offered with each example.
The steps to upgrading are similar to installing Ansible Tower. The original inventory file from the install should already have the hostnames and variables you'll be using, so it's suggested that you work from your current install's inventory file to populate the upgrade file.
Your older inventory file may have some different lines than the newer upgrade version, due to updated configuration options or added features. In this example, the difference between the 3.1.0 and the 3.2.2 inventory files is the added ability to enable isolated key generation for clustered installs. See below for a side-by-side comparison:
|Ansible Tower 3.1.0||Ansible Tower 3.2.2|
Next in the Getting Started series is covering the basics of configuring Red Hat Ansible Tower to allow users to log in with LDAP credentials. In this post, we'll explain a few troubleshooting tips to help narrow down problems and correct them. As long as you have a map of your LDAP tree/forest, this post should help get users logging in with their LDAP credentials.
To configure your Ansible Tower for LDAP authentication, navigate to Settings (the gear icon) and to the "Configure Tower" section. The area within these configuration settings we're focusing on is "Authentication", and the sub category should be set to "LDAP".
The fields that will be the primary focus are:
The other fields will allow you to refine your LDAP searches to reduce the resources used in production or map your organization.
The LDAP URI is simply the IP or hostname of your LDAP server prepended with the protocol (ldap://).
The bind DN will be a user credential and password (followed by the group and domain) with access to read the LDAP structure.
With Ansible Tower able to connect to the LDAP Continue reading
This is a practical use story utilizing Ansible to solve a small hurdle in an everyday workflow.
Code for this can be found here.
In this post, I’ll be sharing a practical situation where Ansible makes tasks easier. The Getting Started team works with organizations who may be putting together a proof-of-concept to evaluate Red Hat® Ansible® Tower. If troubleshooting gets into the weeds, it can include sharing documentation, instructions for common setup scenarios, or going through system settings to make sure everything’s in order.
Sometimes there's no other way: we need to get a full environment report from the system to troubleshoot, mostly in the form of a sosreport. We found that getting the report to us can be challenging, so we had to find a reliable way for people to send us their log files. A file drop web app that could be spun up on demand fit the need nicely. A Nextcloud install with a CentOS LAMP stack turned out to be a great tool, using Ansible to automate the provisioning and installation for us. Because this little trick proved so helpful, I wanted to share how I put the short playbook together, Continue reading
Welcome to another post in our Getting Started series. Keep reading to learn how to draft a Playbook that can be run in Ansible or Ansible Tower. You can also use it along with the Module Index and the other docs to build your own Playbooks later.
Playbooks are esentially sets of instructions (plays) that you send to run on a single target or groups of targets (hosts). Think about the instructions you get for assembling an appliance or furniture. The manufacturer includes instructions so you can put the parts together in the correct order. When followed in order, the furniture looks like what was purchased.
That's basically how a Playbook works.
The Playbook we're building will install a web server on a target RHEL/CentOS 7 host, then write an index.html file based on a template file that will reside with the final Playbook. You'll be able to take the example Playbook and additional files from this blog and test it out for yourself. While going over the example Playbook, we'll explain the modules that are used.Authors
The author adds instructions for the modules to run, often with additional values (arguments, locations, etc. Continue reading