In today’s Ansible series, we will learn about automating changes using Ansible. Specifically, we will automate changes to the sshd config file. Table of Contents
In this article, we will review how we can automate a task that checks the timezone using Ansible, offering a detailed walkthrough of the steps involved in automating the verification and configuration of time zones across target machines.
Welcome to our latest blog post, where we delve into the world of automation with Ansible. In this article, our focus is on a crucial yet often overlooked aspect of system configuration – timezone management. We’ll walk you through the process of performing a task that checks and configures timezones using Ansible. Automation not only simplifies these tasks but also ensures uniformity across your infrastructure.
Ansible, a powerful open-source automation tool, was created by Michael DeHaan, a former Red Hat employee. It was first released to the public in 2012 and quickly gained popularity for its simplicity and agentless architecture. The name “Ansible” is inspired by a fictional instantaneous communication system in science fiction.
One of Ansible’s distinctive features is its agentless nature, meaning it doesn’t require any software to be installed on the target systems. Instead, it communicates using SSH, making it lightweight and easy to deploy. This design choice contributed significantly to its rapid adoption in the DevOps community.
In 2015, Red Hat acquired Ansible Inc., further solidifying its position in the automation landscape. The tool continued to evolve, with regular updates and contributions from a thriving community of developers. Ansible’s playbooks, written in YAML, offer a human-readable way to describe automation tasks, making it accessible to both developers and system administrators.
Now, let’s explore a playbook (named tz_check.yaml
) designed to verify your system’s timezone and output the result to a file. We’ll dissect each component of the playbook to gain a comprehensive understanding of its functionality.
The YAML file below is inherently clear for individuals acquainted with Ansible basics. Its purpose is to generate an output file (tzdata.out
) in the /tmp
directory of the executing machine or localhost. To guarantee an empty output file with each playbook run, the >
redirection is employed instead of >>
, which appends the file and retains existing contents. The playbook utilizes the lineinfile
function to insert the hostname and timezone (both Ansible variables) into the tzdata.out
file.
Now, let’s delve into the details of the playbook [tz_check.yaml
].
---
- name: Check system timezone and output results to a file
hosts: localhost
become: true
tasks:
# Ready the output file
- name: Initialize an output file [/tmp/tzdata.out] on localhost
shell: echo "" > /tmp/tzdata.out
run_once: yes
delegate_to: localhost
# Output hostname and corresponding timezone setting to a file
- name: Insert hostname and timezone information into output file
lineinfile:
path: /tmp/tzdata.out
line: 'Hostname: {{ ansible_fqdn }} || Timezone: {{ ansible_date_time.tz }}'
insertbefore: BOF
delegate_to: localhost
As depicted above, crafting this playbook is a straightforward task, achievable in less than 20 lines of code.
Upon execution, a file called tzdata.out
will be created under the /tmp directory of the localhost (where you are running the play from).
Then, pre-defined ansible functions likeansible_fqdn
andansible_date_time
are called to display the fully-qualified domain name (localhost.localdomain
in this case) and the current timezone of the machine (EDT, CDT, UTC, GMT, etc).
The ansible module lineinfile: will allow us to place the results of those two pre-defined functions into the tzdata.out file.
Run the following command to run the playbook:
[admin@localhost ~]$ ansible-playbook tz_checks.yaml
NOTE: Since we are executing this playbook on our local machine, it is not mandatory to supply an inventory file for Ansible reference. Upon reviewing the output below, it is evident that Ansible issues a warning alerting us to the absence of an inventory file.
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
PLAY [Check system timezone and output results to a file] **********************************************************************************************************
TASK [Gathering Facts] *********************************************************************************************************************************************
ok: [localhost]
TASK [Initialize an output file [/tmp/tzdata.out] on localhost] ****************************************************************************************************
changed: [localhost]
TASK [Insert hostname and timezone information into output file] ***************************************************************************************************
changed: [localhost]
PLAY RECAP *********************************************************************************************************************************************************
localhost : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
As shown above, the playbook executed seamlessly. The subsequent output displays the content of the tzdata.out
file.
[admin@localhost ~]$ cat /tmp/tzdata.out
Hostname: localhost.localdomain || Timezone: UTC
In this article, we explored the creation of a playbook designed to verify a machine’s timezone and capture the results in a file. We value your feedback, so whether this article proved helpful or not, we encourage you to share your thoughts with us by leaving a comment below. Your insights help us tailor our content to better meet your needs and ensure that our future articles align with your expectations.
Related Posts
In today’s Ansible series, we will learn about automating changes using Ansible. Specifically, we will automate changes to the sshd config file. Table of Contents
In this article, we will examine a play used to change the root password using Ansible. It will also encrypt the file the password is stored
In this article, we will review how to enable the sitemap.xml function on Drupal. For SEO purposes, having a sitemap.xml page is critical and setting