Day: June 5, 2018
How to setup Ansible to manage Windows hosts with Centos 7
Note- This assumes you already have a out of the box ansible setup and a windows AD and windows test VM joined to the domain.
Install Prerequisite Packages on centos7 with ansible already installed
Use Yum to install the following packages.
Install GCC required for Kerberos
yum -y group install “Development Tools”
Install EPEL
yum -y install epel-release
Install Ansible
yum -y install ansible
Install Kerberos
yum -y install python-devel krb5-devel krb5-libs krb5-workstation
Install Python PIP
yum -y install python-pip
Install BIND utilities for nslookup
yum -y install bind-utils
Bring all packages up to the latest version
yum -y update
Check that Ansible and Python is Installed
Run the commands:
ansible – – version | head -l 1
python – – version
The versions of Ansible and Python here are 2.4.2 and 2.7.5. Ansible is developing extremely rapidly so these instructions will likely change in the near future.
Configure Kerberos
There are other options than Kerberos, but Kerberos is generally the best option, though not the simplest.
Install the Kerberos wrapper:
pip install pywinrm[Kerberos]
Kerberos packages were installed previously which will have created /etc/krb5.conf
Edit /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = HOME.NICKTAILOR.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
HOME.NICKTAILOR.COM = {
kdc = HOME.NICKTAILOR.COM
admin_server = HOME.NICKTAILOR.COM
}
[domain_realm]
.home.nicktailor.com = HOME.NICKTAILOR.COM
home.nicktailor.com = HOME.NICKTAILOR.COM
Test Kerberos
Run the following commands to test Kerberos:
kinit administrator@HOME.NICKTAILOR.COM <–make sure you do this exact case sensitive or your authenication will fail. Also the user has to have domain admin privileges.
You will be prompted for the administrator password klist
You should see a Kerberos KEYRING record.
[root@localhost win_playbooks]# klist
Ticket cache: FILE:/tmp/krb5cc_0Default principal: administrator@HOME.NICKTAILOR.COM
Valid starting Expires Service principal05/23/2018 14:20:50 05/24/2018 00:20:50 krbtgt/HOME.NICKTAILOR.COM@HOME.NICKTAILOR.COM renew until 05/30/2018 14:20:40
Configure Ansible
Ansible is complex and is sensitive to the environment. Troubleshooting an environment which has never initially worked is complex and confusing. We are going to configure Ansible with the least complex possible configuration. Once you have a working environment, you can make extensions and enhancements in small steps.
The core configuration of Ansible resides at /etc/ansible
We are only going to update two files for this exercise.
Update the Ansible Inventory file
Edit /etc/ansible/hosts and add:
[windows]
HOME.NICKTAILOR.COM
“[windows]” is a created group of servers called “windows”. In reality this should be named something more appropriate for a group which would have similar configurations, such as “Active Directory Servers”, or “Production Floor Windows 10 PCs”, etc.
Update the Ansible Group Variables for Windows
Ansible Group Variables are variable settings for a specific inventory group. In this case, we will create the group variables for the “windows” servers created in the /etc/ansible/hosts file.
Create /etc/ansible/group_vars/windows and add:
—
ansible_user: Administrator
ansible_password: Abcd1234
ansible_port: 5986
ansible_connection: winrm
ansible_winrm_server_cert_validation: ignore
This is a YAML configuration file, so make sure the first line is three dashes “‐‐‐”
Naturally change the Administrator password to the password for WinServer1.
For best practices, Ansible can encrypt this file into the Ansible Vault. This would prevent the password from being stored here in clear text. For this lab, we are attempting to keep the configuration as simple as possible. Naturally in production this would not be appropriate.
Configure Windows Servers to Manage
To configure the Windows Server for remote management by Ansible requires a bit of work. Luckily the Ansible team has created a PowerShell script for this. Download this script from [here] to each Windows Server to manage and run this script as Administrator.
Log into WinServer1 as Administrator, download ConfigureRemotingForAnsible.ps1 and run this PowerShell script without any parameters.
Once this command has been run on the WinServer1, return to the Ansible1 Controller host.
Test Connectivity to the Windows Server
If all has gone well, we should be able to perform an Ansible PING test command. This command will simply connect to the remote WinServer1 server and report success or failure.
Type:
ansible windows -m win_ping
This command runs the Ansible module “win_ping” on every server in the “windows” inventory group.
Type: ansible windows -m setup to retrieve a complete configuration of Ansible environmental settings.
Type: ansible windows -c ipconfig
If this command is successful, the next steps will be to build Ansible playbooks to manage Windows Servers.
Managing Windows Servers with Playbooks
Let’s create some playbooks and test Ansible for real on Windows systems.
Create a folder on Ansible1 for the playbooks, YAML files, modules, scripts, etc. For these exercises we created a folder under /root called win_playbooks.
Ansible has some expectations on the directory structure where playbooks reside. Create the library and scripts folders for use later in this exercise.
Commands:
cd /root
mkdir win_playbooks
mkdir win_playbooks/library
mkdir win_playbooks/scripts
Create the first playbook example “netstate.yml”
The contents are:
– name: test cmd from win_command module
hosts: windows
tasks:
– name: run netstat and return Ethernet stats
win_command: netstat -e
register: netstat
– debug: var=netstat
This playbook does only one task, to connect to the servers in the Ansible inventory group “windows” and run the command netstat.exe -a and return the results.
To run this playbook, run this command on Ansible1:
ansible-playbook netstat_e.yml
How to setup ansible on centos 7
Prerequisites
To follow this tutorial, you will need:
Step 1 — Installing Ansible
To begin exploring Ansible as a means of managing our various servers, we need to install the Ansible software on at least one machine.
To get Ansible for CentOS 7, first ensure that the CentOS 7 EPEL repository is installed:
Once the repository is installed, install Ansible with yum:
We now have all of the software required to administer our servers through Ansible.
Step 2 — Configuring Ansible Hosts
Ansible keeps track of all of the servers that it knows about through a “hosts” file. We need to set up this file first before we can begin to communicate with our other computers.
Open the file with root privileges like this:
You will see a file that has a lot of example configurations commented out. Keep these examples in the file to help you learn Ansible’s configuration if you want to implement more complex scenarios in the future.
The hosts file is fairly flexible and can be configured in a few different ways. The syntax we are going to use though looks something like this:
Example hosts file
[group_name]
alias ansible_ssh_host=your_server_ip
The group_name is an organizational tag that lets you refer to any servers listed under it with one word. The alias is just a name to refer to that server.
Imagine you have three servers you want to control with Ansible. Ansible communicates with client computers through SSH, so each server you want to manage should be accessible from the Ansible server by typing:
You should not be prompted for a password. While Ansible certainly has the ability to handle password-based SSH authentication, SSH keys help keep things simple.
We will assume that our servers’ IP addresses are 192.168.0.1, 192.168.0.2, and 192.168.0.3. Let’s set this up so that we can refer to these individually as host1, host2, and host3, or as a group as servers. To configure this, you would add this block to your hosts file:
/etc/ansible/hosts
[servers]
host1 ansible_ssh_host=192.168.0.1
host2 ansible_ssh_host=192.168.0.2
host3 ansible_ssh_host=192.168.0.3
Hosts can be in multiple groups and groups can configure parameters for all of their members. Let’s try this out now.
Ansible will, by default, try to connect to remote hosts using your current username. If that user doesn’t exist on the remote system, a connection attempt will result in this error:
Ansible connection error
host1 | UNREACHABLE! => {
“changed”: false,
“msg“: “Failed to connect to the host via ssh.”,
“unreachable”: true
}
Let’s specifically tell Ansible that it should connect to servers in the “servers” group with the nick user. Create a directory in the Ansible configuration structure called group_vars.
Within this folder, we can create YAML-formatted files for each group we want to configure:
Add this code to the file:
/etc/ansible/group_vars/servers
—
ansible_ssh_user: ansiblenick
YAML files start with “—“, so make sure you don’t forget that part.
Save and close this file when you are finished. Now Ansible will always use the ansiblenick user for the servers group, regardless of the current user.
If you want to specify configuration details for every server, regardless of group association, you can put those details in a file at /etc/ansible/group_vars/all. Individual hosts can be configured by creating files under a directory at /etc/ansible/host_vars.
Step 3 — Using Simple Ansible Commands
Now that we have our hosts set up and enough configuration details to allow us to successfully connect to our hosts, we can try out our very first command.
Ping all of the servers you configured by typing:
Ansible will return output like this:
Output
host1 | SUCCESS => {
“changed”: false,
“ping”: “pong”
}
host3 | SUCCESS => {
“changed”: false,
“ping”: “pong”
}
host2 | SUCCESS => {
“changed”: false,
“ping”: “pong”
}
This is a basic test to make sure that Ansible has a connection to all of its hosts.
The -m ping portion of the command is an instruction to Ansible to use the “ping” module. These are basically commands that you can run on your remote hosts. The ping module operates in many ways like the normal ping utility in Linux, but instead it checks for Ansible connectivity.
The all portion means “all hosts.” You could just as easily specify a group:
You can also specify an individual host:
You can specify multiple hosts by separating them with colons:
The shell module lets us send a terminal command to the remote host and retrieve the results. For instance, to find out the memory usage on our host1 machine, we could use:
As you can see, you pass arguments into a script by using the -a switch. Here’s what the output might look like:
Output
host1 | SUCCESS | rc=0 >>
total used free shared buffers cached
Mem: 3954 227 3726 0 14 93
-/+ buffers/cache: 119 3834
Swap: 0 0 0