Ansible Review

Install and Configure an Ansible Control Node

This objective is made up of the following items:

  • Install required packages.
  • Create a static host inventory file (covered in other lessons but also shown again).
  • Create a configuration file (covered in other lessons, and not shown in this lesson).
  • Configure privilege escalation on managed nodes.
  • Validate a working configuration using ad-hoc Ansible commands.
  • We will create a user for Ansible called ansible.
  • User on managed nodes will need to have passwordless sudo setup.
  • User ansible will need to be able to ssh into nodes without needing password.

Ansible on CentOS requires epel-relase. Let’s install required packages:

Creating ansible user:

Allow ansible user to run any command::

Editing hosts file:

Editing inventory file:

Checking connectivity to managedhost1:

Connecting to managedhost1:

Creating ansible user on managedhost1:

Allowing ansible user to run any command on managedhost1:

Logging out from managedhost1:

Doing the same on managedhost2:

On controlnode switch to ansible user:

Create SSH key:

Copy key to localhost and managedhosts:

Checking SSH conectivity:

Let’s try if we have ansible connection with managedhosts:

The same with -b option (becoming a root user):

 

Simple Shell Scripts for Running Ad-Hoc Commands

Why shell scripts?

  • Shell scripts can be used to hide complexity.
  • You can use shell scripts easily with Ansible ad-hoc commands.
  • People not experienced in Ansible can leverage them.
  • People not skilled in Ansible can create and use them.
  • There is no need to know YAML and .yml formatting.

It is a simple script which installs package given as argument on managedhosts:

Let’s install elinks on managedhosts using the script:

 

Ansible and Firewall Rules
• There are Ansible modules that can be used with firewalls.
• The firewalld module like others, can be used to add or remove rules.
• Here is the URL for more information: https://docs.ansible.com/ansible/latest/modules/firewalld_module.html
• There is a module for iptables
https://docs.ansible.com/ansible/latest/modules/iptables_module.html

The simple playbook which install and enable firewalld service::

Check the syntax of playbook:

Run the playbook:

Playbook  setup-server.yml install elinks and apache. Make http service enabled.

Run the playbook:

At this moment we can’t connect to http service:

So let’s create a firewall-rule.yml playbook:

Check a syntax and run:

Now we can connect to apache service from controlnode to managedhost1:

Also we can connect from managedhost1 to controlnode:

 

Archiving

The Archive Module

  • There are Ansible modules that can be used for archive purposes.
  • It is mentioned as part of the exam’s EX407 objectives.
  • Archive Module Documentation page: https://docs.ansible.com/ansible/latest/modules/archive_module.html
  • Assumes the compression source exists on the target.
  • Does not copy source files from the local system to the target before archiving.
  • You can delete source files after archiving by using the remove=true option.

The Unarchive Module

  • The opposite module is unarchive
  • Unarchive Module Documentation page: https://docs.ansible.com/ansible/latest/modules/unarchive_module.html
  • If checksum is required, then use get_url or uri instead.
  • By default it will copy from the source file to the target before unpacking.

Example of playbook with archive module:

Check and run the playbook:

Now we can check if the playbook  create archives on managed hosts:

Now let’s use the fetch module:

Check and run the playbook:

Check if the playbook really fetch the backups annd store them locally:

 

Cron

The Cron Module

  • The cron module is used to manage crontab on your nodes,
  • You can create environment variables as well as named crontab entries.
  • You can add, update, and delete entries.
  • You should add a name with th crontab entry so it can be removed easily with a playbook.
    • e.g. name: “Job 0001”
  • When managing environment variables, no comment line gets added; however, the module uses the name parameter to find the correct definition line.

Extra Parameters

  • You remove the crontab entry by using state: absent in a playbook.
  • The name: gets matched for a removal.
  • You can use the boolean disabled to comment out an entry (only works if state=present.
  • Jobs can be set to run at reboot if required. Use th special_time: reboot if that is required.
  • You can add a specific user if you need to set crontab entry for a user (need to become root).
  • Use insertafter or insertbefore to add env entry before or after another env entry.

The example playbook :

Check and run the playbook:

Check if playbook works. We need list crontab as root so use sudo :

Now we modify playbook:

Chec and run:

And check what new playbook has done:

It added environment variables APP_HOME and PATH. APP_HOME has been added to crrontab before PATH as we wanted.

If we want to delete our entries from cron we should use state: absent keyword:

Run the playbook:

Check the crontab:

It is empty.

 

at module

at software (in Linux)

  • The at command is used to schedule jobs that will be running once in the future.
  • It is used for single ad-hoc jobs and is not meant as a replacement for cron
  • It is part of a group of commands that get installed with the at software.
  • The other commands are:
    • at Executes commands at a specific time.
    • atq Lists the users pending jobs.
    • atrm Deletes a job by its job number.
    • batch Executes the command depending on specific system load levels. A value must be specified.
  • Only at and atrm are controlled via the at module.

Service Details

  • It may not be on all systems, so verify its installation.
  • On Red Hat or CentOS systems it is installed with a yum install at command.
  • The service is controlled via the atd daemon.

Example of at playbook:

Check and run the playbook:

Checck if at has been installed:

Let’s modify playbook to add at job:

Check and run the playbook:

Check if the playbook works:

We can disable at job from the playbook by state:absent statement:

Check if the job has been removed:

 

Security
Ansible Security Tasks

  • Ansible is very useful as a security tool.
  • You can make security changes to many nodes at once.
  • You can apply changes to help with easily securing nodes.
  • You can check lots of nodes for vulnerabilities quickly.
  • It can work well with other tools that you may have in place.
  • Check for Ansible modules that can be used for security tasks.
  • Not just for Linux can be used for OS X, Solaris, Windows, and others.
  • Can be used for devices such as NetApp or EMC storage, F5, and others.

There are many modules that can be useful for security:

    • selinux Configures the SELinux mode and policy.
    • firewalld iptables Both manage firewall policies.
    • pamd — Manages PAM modules.
  • Capable of working with Datadog, Nagios, and other monitoring tools.
  • Manage users and groups (bulk add and delete users if you don’t have SSO ability).
  • Can manage certificates such as OpenSSL or SSH.
  • A colossal amount of other abilities exist. Search the All Modules page: https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html

 

Example of playbook with selinux module:

Check and run the playbook:

Nothing has been changed because selinux policy has already been set to enforcing.

Example of playbook with firewall module:

Before we run the playbook let’s check which services are allowed on firewall at this moment:

Check and run the playbook:

Let’s which services are allowed on firewall now:

 

Let’s add a group developers to the managed hosts:

Check and run the playbook:

To create a user we need a password hash:

Besides the password hash we need expires date which we can get from www.epochconverter.com site.

The playbook looks like:

The playbook with expires and password:

 

 

Let’s check if user james20 is added to system:

To remove user from system we need to use state:absent statement: