Red Hat and CentOS recently announced that CentOS will be converted to a rolling release distribution in the form of CentOS Stream.

While CentOS 7 will be supported till 2024, CentOS 8 support ends by the end of 2021.

With this development, the current CentOS 8 users are left with two choices, either move to server distributions like Debian, openSUSE, Ubuntu LTS, or update the current CentOS system to CentOS Stream.

In this tutorial, I'm going to show you how you can update your current CentOS 8 install to CentOS Stream.

Upgrading CentOS 8 to CentOS Stream

The idea is simple. To convert, you need to add Stream's repos, and remove the existing ones.

Fortunately, you don't have to do all that manually. There is a handy tool provided by the CentOS team for this purpose.

Make a backup before you update. The update procedure is simple but create backup for the sake of it.

Step 1: Install the repo files

Install the package centos-release-stream. This contains all the repo files that are needed.

dnf install centos-release-stream -y

Step 2: Update the system

Update the system or the packages to be specific, by running the distro-sync command.

dnf distro-sync -y

This syncs all the local packages to the upstream's versions.

Step 3: Reboot and double-check the installed version

Now, reboot your server:

reboot

After the system is booted successfully, verify the migration by checking the CentOS version.

You can do that by reading the os-release file:

[root@li2029-76 ~]# cat /etc/centos-release 
CentOS Stream release 8

Or, read the centos-release file:

[root@li2029-76 ~]# cat /etc/os-release 
NAME="CentOS Stream"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Stream 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"

You should see a similar output.

I have made a video of the entire process. The video is being edited but you can follow it nonetheless.

Is it safe to upgrade to CentOS Stream?

How careful should you be before starting the update? Is it safe? To be honest, I can't tell you "Oh do it, it'll be just alright" in confidence. A lot of moving parts contribute to the stability of a system. This process doesn't exactly make sure nothing will break.

To roughly test whether the process will break all of the existing setups or not, I deployed a CentOS 8 server on Linode. On this server, I installed Nextcloud, natively i.e. no containers, HTTPS enabled. I also disabled SELinux and firewalld just to make the process slightly faster.

After installing the centos-release-stream package and running the dnf distro-sync command, there was a total of 101 packages that needed to be updated. I updated and rebooted afterwards, fortunately, everything was just fine.

But here's the thing, this experiment of mine is no proof of anything. If anything, this shows that not all of the existing setups will break, if you're updating to CentOS Stream from 8. This still doesn't confirm whether it's totally safe or not. The stability of your system post-upgrade, depends on a lot of things, like:

• How many services is the server currently running?
• How the services are set up or installed?
• How many packages does it currently have installed?
• When was the last time it was updated?

This is why I suggest taking a snapshot of your system if you are running in a VM. Take backup because you can never be too careful.

As for service downtime, if your system is part of a cluster, the orchestrator should take care of the total number of running instances, eliminating downtime. If you're using a single node docker environment, using the live-restore feature of docker will eliminate any downtime in case a docker update is on the queue. Other than that, your current methods of countering any downtime should be good enough.

I hope this article was helpful to you. You can reach me @imdebdut, or @linuxhandbook. You can also join our Telegram group.

Resizing a logical volume in Linux is not very difficult and can be achieved through very straightforward approach. Here are the usual steps:

1. Create new partition on hard disk.
2. Add the partition you just created as a physical volume.
3. Add the new physical volume to the volume group.
4. Assign space from the volume group to the logical volume.
5. Resize the filesystem.

But in this scenario, you have the root filesystem (as an LVM partition) mounted under an extended partition, not within a primary partition. You just have one primary partition which is mounted on /boot and rest all space is part of that extended partition.

Sounds troublesome? Let me show you how to resize LVM inside extended partition.

Resizing LVM partition inside extended partition

I am using a Linux installed in virtual machine in this tutorial.

Please keep in mind that you should be very careful while dealing with disk partitions.

Step 1:  Shut down your VM and increase the disk size

First, shut down your VM and increase the disk size. Here, I have increased the disk /dev/sda size by 20 GB to around 40 GB. Then start your VM and go to the console.

Have a look at our disk partitions.

root@Ubuntu14:~# fdisk -l

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a975f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          501758    41940991    20719617    5  Extended
/dev/sda5          501760    41940991    20719616   8e  Linux LVM

If you analyze the disk space with df command, here's what it shows for me:

root@Ubuntu14:~# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  989M  4.0K  989M   1% /dev
tmpfs          tmpfs     201M  716K  200M   1% /run
/dev/dm-0      ext4       19G  1.5G   16G   9% /
none           tmpfs     4.0K     0  4.0K   0% /sys/fs/cgroup
none           tmpfs     5.0M     0  5.0M   0% /run/lock
none           tmpfs    1001M     0 1001M   0% /run/shm
none           tmpfs     100M     0  100M   0% /run/user
/dev/sda1      ext2      236M   40M  184M  18% /boot

Here, the object is to increase the size of the partition /dev/dm-0 which is mounted on /dev/sda5.

Let me also show the current status of physical volumes, volume groups and logical volumes:

root@Ubuntu14:~# lvs
  LV     VG          Attr      LSize    Pool Origin Data%  Move Log Copy%  Convert
  root   ubuntu14-vg -wi-ao---   18.74g                                           
  swap_1 ubuntu14-vg -wi-ao--- 1020.00m   
  
root@Ubuntu14:~# pvs
  PV         VG          Fmt  Attr PSize  PFree 
  /dev/sda5  ubuntu14-vg lvm2 a--  19.76g 20.00m
  
root@Ubuntu14:~# vgs
  VG          #PV #LV #SN Attr   VSize  VFree 
  ubuntu14-vg   1   2   0 wz--n- 19.76g 20.00m

They all have around 20 GB of storage space assigned to them.

Step 2: Begin the LVM resizing process

Here are the steps for resizing the LVM partition:

Open fdisk utility and look at the partitions:

root@Ubuntu14:~# fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a975f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          501758    41940991    20719617    5  Extended
/dev/sda5          501760    41940991    20719616   8e  Linux LVM

Delete the extended partition (/dev/sda2) using command d, which will automatically delete the underlying LVM partition which is /dev/sda5.

Command (m for help): d
Partition number (1-5): 2

Create a new partition again as extended using command n with default start and end cylinder values.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): e
Partition number (1-4, default 2): 
Using default value 2
First sector (499712-83886079, default 499712): 
Using default value 499712
Last sector, +sectors or +size{K,M,G} (499712-83886079, default 83886079): 
Using default value 83886079

Command (m for help): p

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a975f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          499712    83886079    41693184    5  Extended

Create a logical partition (dev/sda5) using the default start and end cylinder values.

Command (m for help): n
Partition type:
   p   primary (1 primary, 1 extended, 2 free)
   l   logical (numbered from 5)
Select (default p): l
Adding logical partition 5
First sector (501760-83886079, default 501760): 
Using default value 501760
Last sector, +sectors or +size{K,M,G} (501760-83886079, default 83886079): 
Using default value 83886079

Switch to expert mode by pressing x.

Command (m for help): x

Run expert command b to adjust the beginning of the partition (this changes the partition size, not where it ends). Enter the start value as it was earlier before deleting the partitions. Here it is 501760.

Expert command (m for help): b
Partition number (1-5): 5
New beginning of data (499713-83886079, default 501760): 501760

Then run r to return to the main menu.

Expert command (m for help): r

Check the partition number just to make sure.

Command (m for help): p

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a975f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          499712    83886079    41693184    5  Extended
/dev/sda5          501760    83886079    41692160   83  Linux

Now change the partition type to LVM by pressing t command and chose type 8e.

Command (m for help): t
Partition number (1-5): 5
Hex code (type L to list codes): 8e
Changed system type of partition 5 to 8e (Linux LVM)

Press w to write all the changes to the disk.

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

Step 3: Make manual changes to physical and logical volume

Run partprobe command to inform OS about partition table changes:

root@Ubuntu14:~# partprobe /dev/sda

Run lsblk command to see that /dev/sda5 is now around 40 GB in size (for me).

root@Ubuntu14:~# lsblk 
NAME                           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                              8:0    0    40G  0 disk 
├─sda1                           8:1    0   243M  0 part /boot
├─sda2                           8:2    0     1K  0 part 
└─sda5                           8:5    0  39.8G  0 part 
  ├─ubuntu14--vg-root (dm-0)   252:0    0  18.8G  0 lvm  /
  └─ubuntu14--vg-swap_1 (dm-1) 252:1    0  1020M  0 lvm  [SWAP]
sr0                             11:0    1  1024M  0 rom  

Run the df command and you'll notice that /dev/dm-0  still shows the old size details:

root@Ubuntu14:~# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  989M  4.0K  989M   1% /dev
tmpfs          tmpfs     201M  716K  200M   1% /run
/dev/dm-0      ext4       19G  1.5G   16G   9% /
none           tmpfs     4.0K     0  4.0K   0% /sys/fs/cgroup
none           tmpfs     5.0M     0  5.0M   0% /run/lock
none           tmpfs    1001M     0 1001M   0% /run/shm
none           tmpfs     100M     0  100M   0% /run/user
/dev/sda1      ext2      236M   40M  184M  18% /boot

Same is the case with Physical volumes, Volume groups and Logical volumes:

root@Ubuntu14:~# lvs
  LV     VG          Attr      LSize    Pool Origin Data%  Move Log Copy%  Convert
  root   ubuntu14-vg -wi-ao---   18.74g                                           
  swap_1 ubuntu14-vg -wi-ao--- 1020.00m   
  
root@Ubuntu14:~# pvs
  PV         VG          Fmt  Attr PSize  PFree 
  /dev/sda5  ubuntu14-vg lvm2 a--  19.76g 20.00m
  
root@Ubuntu14:~# vgs
  VG          #PV #LV #SN Attr   VSize  VFree 
  ubuntu14-vg   1   2   0 wz--n- 19.76g 20.00m

You'l have to do some manual effort here.

Resize the Physical volume:

root@Ubuntu14:~# pvresize /dev/sda5 
Physical volume "/dev/sda5" changed
1 physical volume(s) resized / 0 physical volume(s) not resized

Now check Physical Volume and Volume group status and see that it is properly showing the new size:

root@Ubuntu14:~# pvs
PV         VG          Fmt  Attr PSize  PFree 
/dev/sda5  ubuntu14-vg lvm2 a--  39.76g 20.02g

root@Ubuntu14:~# vgs
VG          #PV #LV #SN Attr   VSize  VFree 
ubuntu14-vg   1   2   0 wz--n- 39.76g 20.02g

Similarly, resize the logical volume:

root@Ubuntu14:~# lvextend -l +100%FREE /dev/ubuntu14-vg/root
  Extending logical volume root to 38.76 GiB
  Logical volume root successfully resized

Lastly, resize the filesystem:

root@Ubuntu14:~# resize2fs /dev/ubuntu14-vg/root
resize2fs 1.42.9 (4-Feb-2014)
Filesystem at /dev/ubuntu14-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/ubuntu14-vg/root is now 10161152 blocks long.

Verify the disk status and see that LVM is now resized properly:

root@Ubuntu14:~# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  989M  4.0K  989M   1% /dev
tmpfs          tmpfs     201M  716K  200M   1% /run
/dev/dm-0      ext4       39G  1.5G   35G   4% /
none           tmpfs     4.0K     0  4.0K   0% /sys/fs/cgroup
none           tmpfs     5.0M     0  5.0M   0% /run/lock
none           tmpfs    1001M     0 1001M   0% /run/shm
none           tmpfs     100M     0  100M   0% /run/user
/dev/sda1      ext2      236M   40M  184M  18% /boot

That's all! You have successfully resized the LVM partition inside an extended partition.

Questions or suggestion? Leave a comment below.

How do you use SSH to enter a Docker container? The traditional approach consists of two steps:

Step 1: SSH into your remote Linux server (if you are running the container in a remote system).‌

ssh user_name@server_ip_address

Step 2: And then you enter the shell of your running Docker container in interactive mode like this:

docker exec -it container_ID_or_name /bin/bash

With that, you can run Linux command or do some maintenance of the service running inside the container.

There is nothing wrong with the above method. This is the traditional and recommended way of effortlessly entering containers.

However, with some efforts, you can actually SSH into a running container directly, without logging into the host system first.

SSH into a Docker container: But why?

This is kind of weird, isn't it? Logging into a container, through SSH. Though it sounds non-traditional, it might still be useful to you, according to your use cases.

Here are a few things you can achieve with the ability to SSH into a container:

1. You can set up a fake host for any potential attacker. By using a non-standard port for your host's SSH daemon, and serving an SSH connection at port 22 for the attackers.
2. A totally separate authorization level, i.e. password logins or different ssh keys all up to you and separate from whatever your host is currently using.
3. Running any automated remote process, without using the same ssh keys that are used to log in by your team's individuals.

Before I show you how to do all the above things, I'll walk you through the idea of how this actually works.

Using ssh login for existing container' is not recommended. That kills the whole point of host isolation.

Setting up SSH access for Docker containers [Intermediate to Expert]

If you're not interested in the workings of this, you can safely ignore this section. I am going to show you with a dummy container. You may follow the steps to practice.

Run a container

First, you need to start a Docker container. I'll use the extremely small alpine:latest image for now. Start the container with this command:

docker run --rm --name ssh-test -it -p 22:7655 alpine:latest ash 

Some noticeable points regarding the command line options are as follows

• With the --rm option, you don't have to explicitly remove the container afterwards.
• The -it options are there so that you can have a working, interactive shell of the container.
• Finally, you are binding the container's port 22 to the host's port number 7655 (or any other port number that is not already used by SSH daemon on your host system). Keep in mind which port you are using.

Set up the SSH daemon in the container

Now you need to install the ssh server inside the container. In Alpine Linux, you can use these commands:‌

apk update; apk add openssh-server

Next, you need to change a configuration parameter quickly to allow root logins. You can do it by manually editing the /etc/ssh/sshd_config file or using this command:

sed -E 's/^#(PermitRootLogin )no/\1yes/' /etc/ssh/sshd_config -i 

Generate the host keys with:

ssh-keygen -A

Finally, start the ssh server, run /usr/sbin/sshd &. Check if it's running by ps aux.

Set a password for your container's root account

By default, your container's root account doesn't have a password. If you are opening SSH access to it, you must set the password for the root account.

You can use the passwd command without any option and follow the instructions on the screen:

passwd

Log into the container via SSH

From another host, try to log into the container now.

ssh root@IP_address_of_host_server -p port_number

You don't need the -p option if you bound to port 22 previously. For IP use the host server's IP address (not the container's).

When you run the command, you should see an output similar to this:

debdut@shinchan:/mnt/data/documents/Linux Handbook/container-ssh$ ssh root@domain.com
   root@domain.com's password: 
   Welcome to Alpine!
   
   The Alpine Wiki contains a large amount of how-to guides and general
   information about administrating Alpine systems.
   See <http://wiki.alpinelinux.org/>.
   
   You can setup the system with the command: setup-alpine
   
   You may change this message by editing /etc/motd.
   
   c4585d951883:~#

How does this work?

This can be understood better visually. Take a look at the following diagram:‌

Think of the containers as a virtual machine whose port 22 is glued together with the host's port 7655 (or the one you chose). This enables you to have two different ssh processes running on the same machine bound to different ports.

Let's say you use some other port for SSH on the host system and glue the port 22 with the container's port. Now, if somebody tries to connect to the host server using SSH default port 22, he/she will be inside the container's root file system.

Setting up SSH for containers using Docker Compose [Experts]

It wouldn't be fair if I leave you at this spot without providing some reliable option for an SSH server container.

If you wanted to take advantage of having a different, isolated ssh server with a separate root file system running on your remote system, that could be done, but not by following the previous walk-through, i.e. installing and configuring sshd on a running base container.

Simply because it's not easily reproducible, every change you make on the running container, are not persistent, a container restart and everything is gone.

So, here I give you a much simpler, easily reproducible, configurable way of deploying an SSH server container on your remote host.

Prerequisites

You need to have docker compose installed obviously. Basic knowledge of docker compose is a must here.

Since you will be accessing the server via SSH keys, you need to add the public SSH key of your local system to your host Linux server's directory where docker-compose file is located and keep the name "id_rsa.pub" just to be sure.

Prepare the compose file

I suggest using the linuxserver/openssh-server image. This is a very lightweight image with good enough configuration options through environment variables.

Here the whole compose file is going to be pasted. Copy this over to some location on your server and name the file docker-compose.yaml.‌

version: "3.7"

services:
    ssh:
        image: "linuxserver/openssh-server"
        ports:
            - "22:2222"
        volumes:
            - "./id_rsa.pub:/pubkey:ro"
        environment:
            PUID: ${ID}
            PGID: ${ID}
            TZ: ${TZ}
            PUBLIC_KEY_FILE: "/pubkey"
            SUDO_ACCESS: "false"
            PASSWORD_ACCESS: "false"
            USER_NAME: ${USER_NAME}
        restart: "always"

Quite a small compose file, isn't it? Let me explain different parts of this compose file.

Volumes: You only have a single bind mount, which mounts the public key within the container as pubkey. It's also read only.

Ports: The sshd process inside the container runs on port 2222. That's why I have bound that port to my host's port 22. Change 22 according to your needs but remember that as you'll need it to log into the container through SSH later.

Environment Variables:

• USER_NAME :The in-container user, you'll be logging in as from your local machine.
• PUID & PGID: USER_NAME's UID and GID. This is optional, the container will assign a pair of non-root IDs automatically if the environment variables are not set.
• TZ: Your current time zone. You can get that by cat /etc/timezone.
• PUBLIC_KEY_FILE: The location of the public key file
• SUDO_ACCESS & PASSWORD_ACCESS: Self explanatory.

Restart policy: I have set the "always" restart policy which will restart the container even if the daemon is reloaded.

Deploy the service

To make it easy for you, I have made a Bash script that will ask you a couple of questions, and based on the answer it'll deploy the service.

#! /usr/bin/env bash

vars=("ID" "USER_NAME")
defaults=("991" "dummy")
questions=("What'd be your preferred UID & GID for the username of your choice? [default] " "Your preferred username for the container? [dummy] ")

put()
{
    echo "$1" >> .env
}

for i in {1..0}; do
    read -p "${questions[$i]}" ans
    case $ans in
        ""|"default")
            put "${vars[$i]}=${defaults[$i]}" ;;
        *)
            put "${vars[$i]}=$ans" ;;
    esac
done

put "TZ=$(cat /etc/timezone)"

docker-compose up -d

I saved the bash script as deploy.sh in the same directory where docker-compose file was located.

Now, if you run this script, it will ask you some questions and then run the docker container:

bash deploy.sh

Once it's done, try logging into the server:

ssh user@ip -p port 

That concludes this article on ssh with docker containers. If you liked it, or have anything else to mention, feel free to comment down below or tweet to me @imdebdut.

If you'd like me to write some other article feel free to let me know.

The simplest way to print in Linux command line is by using echo command.

echo "Value of var is $var"

However, echo command won't be adequate when you need to print formatted output.

This is where printf command helps you. The bash printf command operates like the printf command in C/C++ programming language.

printf "My brother %s is %d years old.\n" Prakash 21

Can you guess the output?

The first argument %s expects a string, %d expects a decimal integer, just like C/C++. Don't worry if you are not familiar with C/C++.

You don't need to learn it just for using printf command in your Bash scripts. Let me show you some examples of Bash printf command.

Using Bash printf command

Let's start with the syntax first.

printf format [arguments]

Here, format is a string that determines how the subsequent values will be displayed.

In the example printf "My brother %s is %d years old.\n" Prakash 21, the entire "My brother %s is %d years old.\n" is format and it is followed by the arguments Prakash and 21. The arguments are used for replacing the format specifiers (%s, %d etc) which I'll explain later in this article.

In its simplest form, printf can be used as echo command for displaying a string.

printf "Hello World\n"

Notice the new line character \n at the end? The difference between echo and printf command is that echo automatically adds a new line character at the end but for printf, you have to explicitly add it.

Pay special attention to type and number of arguments

Keep in mind that the format string tries to be applied to all the arguments. This is why you should pay special attention to it.

abhishek@handbook:~$ printf "Hello, %s! \n" Abhishek Prakash
Hello, Abhishek! 
Hello, Prakash!

Similarly, you should also pay attention to the kind of format specifier it expects in the format string.

As you can see in the above example, if it doesn't find intended arguments, it displays the default values which is null for strings and 0 for integers.

printf "Hi %s, your room number is %d. \n" Abhishek Prakash 131
bash: printf: Prakash: invalid number
Hi Abhishek, your room number is 0. 
Hi 131, your room number is 0.

Here, it takes Abhishek Prakash as first set of arguments and 131 as second set of arguments.

When it finds a string (Prakash) instead of an integer, it complains but it continues to display the output with second argument at its default value 0.

Similarly, it sees 131 as string in the second set of arguments and since the second argument is absent, it defaults to 0.

Format specification characters

There are several format specifiers available for you to display your output in desired format. Here are some of the most common ones:

Now that you are familiar with the format specifier, let's see some more examples that shows them in action.

Bash printf command examples

I don't think you need detailed explanation for most of these examples as they are self-explanatory.

abhishek@handbook:~$ printf "The octal value of %d is %o\n" 30 30
The octal value of 30 is 36

Let's see the use of the %b specifier for correctly interpreting the backslash escaped character.

abhishek@handbook:~$ printf "String with backslash: %s\n" "Hello\nWorld!"
String with backslash: Hello\nWorld!

You see for %s, it makes no difference. But with %b the new line escape character will be correctly interpreted:

abhishek@handbook:~$ printf "String with backslash: %b\n" "Hello\nWorld!"
String with backslash: Hello
World!

When you use the %c, it reads only character at a time.

abhishek@handbook:~$ printf "Character: %c\n" a
Character: a
abhishek@handbook:~$ printf "Character: %c\n" a b c
Character: a
Character: b
Character: c
abhishek@handbook:~$ printf "Character: %c\n" abc
Character: a

Using modifiers to display printf output in specific style

There are modifiers to change the look of the output as per your liking.

# modifier for octal and hexadecimal numbers

Earlier you saw the use of %o for converting decimal to octal. However, it wasn't very clear that it was an octal number. You can use the # modifier to display octal and hexadecimal numbers in proper format.

abhishek@handbook:~$ printf "%d is %#o in octal and %#x in hexadecimal\n" 30 30 30
30 is 036 in octal and 0x1e in hexadecimal

Space modifier for positive integers

You can use a space between % and d in %d to display a positive integer with a leading space. This helps when you have a column of positive and negative numbers. See which one looks more 'pretty':

abhishek@handbook:~$ printf "%d \n%d \n%d \n" 10 -10 10
10 
-10 
10 
abhishek@handbook:~$ printf "% d \n%d \n% d \n" 10 -10 10
 10 
-10 
 10 

Width modifier

The width modifier is a integer that specifies the minimum field width of the argument.

By default, it is right aligned:

abhishek@handbook:~$ printf "%10s| %5d\n" Age 23
       Age|    23

You can make it left aligned by adding - flag to it:

abhishek@handbook:~$ printf "%-10s| %-5d\n" Age 23
Age       | 23

Precision modifier

You can use the precision modifier (.) dot to specify a minimum number of digits to be displayed with %d, %u, %o, %x. It adds zero padding on the left of the value.

abhishek@handbook:~$ printf "Roll Number: %.5d\n" 23
Roll Number: 00023

If you use the precision modifier with a string, it specifies the maximum length of the string. If the string is longer, it gets truncated in the display.

abhishek@handbook:~$ printf "Name: %.4s\n" Abhishek
Name: Abhi

You may combine both width and precision modifier:

abhishek@handbook:~$ printf "Name: %.4s\n" Abhishek
Name: Abhi
abhishek@handbook:~$ printf "Name: %10.4s\n" Abhishek
Name:       Abhi

Bonus Example: Display output in tabular format with printf

Let's put what you have learned about printf command to some good use with a slightly more complicated example. This will showcase the true potential of the printf command in bash scripts.

Let's use printf command to print the following table using bash:

Here's the shell script I wrote for this task. Your script may vary:

#/bin/bash
seperator=--------------------
seperator=$seperator$seperator
rows="%-15s| %.7d| %3d| %c\n"
TableWidth=37

printf "%-15s| %-7s| %.3s| %s\n" Name ID Age Grades
printf "%.${TableWidth}s\n" "$seperator"
printf "$rows" "Sherlock Holmes" 122 23 A
printf "$rows" "James Bond" 7 27 F
printf "$rows" "Hercules Poirot" 6811 59 G
printf "$rows" "Jane Marple" 1234567 71 C

Now if I run this bash shell script, here's what it prints:

Isn't it wonderful to use the bash printf command to print beautifully formatted output for your scripts?

I hope you liked this detailed tutorial on the printf command in Linux. If you have questions or suggestions, please let me know. And don't forget to become a member of Linux Handbook for more such informational Linux learnings.

In the previous tutorial about decision making in Ansible, you learned how to do simple file modifications by using the blockinfile or inline Ansible modules.

In this tutorial, you will learn how to use Jinja2 templating engine to carry out more involved and dynamic file modifications.

You will learn how to access variables and facts in Jinja2 templates. Furthermore, you will learn how to use conditional statements and loop structures in Jinja2.

To try the examples in this tutorial, you should follow the entire RHCE Ansible tutorial series in the correct order.

Accessing Variables in Jinja2

Ansible will look for jinja2 template files in your project directory or in a directory named templates under your project directory.

Let’s create a templates directory to keep thing cleaner and more organized:

[elliot@control plays]$ mkdir templates
[elliot@control plays]$ cd templates/

Now create your first Jinja2 template with the name index.j2:

[elliot@control templates]$ cat index.j2 
A message from {{ inventory_hostname }}
{{ webserver_message }}

Notice that Jinja2 template filenames must end with the .j2 extension.

The inventory_hostname is another Ansible built-in (aka special or magic) variable that references that ‘current’ host being iterated over in the play. The webserver_message is a variable that you will define in your playbook.

Now go one step back to your project directory and create the following check-apache.yml:

[elliot@control plays]$ cat check-apache.yml 
---
- name: Check if Apache is Working
  hosts: webservers
  vars:
    webserver_message: "I am running to the finish line."
  tasks:
    - name: Start httpd
      service:
        name: httpd
        state: started

    - name: Create index.html using Jinja2
      template:
        src: index.j2
        dest: /var/www/html/index.html

Note that the httpd package was already installed in a previous tutorial.

In this playbook, you first make sure Apache is running in the first task Start httpd. Then use the template module in the second task Create index.html using Jinja2to process and transfer the index.j2 Jinja2 template file you created to the destination /var/www/html/index.html.

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook check-apache.yml 

PLAY [Check if Apache is Working] **********************************************

TASK [Gathering Facts] *********************************************************
ok: [node3]
ok: [node2]

TASK [Start httpd] *************************************************************
ok: [node2]
ok: [node3]

TASK [Create index.html using Jinja2] ******************************************
changed: [node3]
changed: [node2]

PLAY RECAP *********************************************************************
node2                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0

Everything looks good so far; let’s run a quick ad-hoc Ansible command to check the contents of index.html on the webservers nodes:

[elliot@control plays]$ ansible webservers -m command -a "cat /var/www/html/index.html"
node3 | CHANGED | rc=0 >>
A message from node3
I am running to the finish line.
node2 | CHANGED | rc=0 >>
A message from node2
I am running to the finish line.

Amazing! Notice how Jinja2 was able to pick up the values of the inventory_hostname built-in variable and the webserver_message variable in your playbook.

You can also use the curl command to see if you get a response from both webservers:

[elliot@control plays]$ curl node2.linuxhandbook.local
A message from node2
I am running to the finish line.
[elliot@control plays]$ curl node3.linuxhandbook.local
A message from node3
I am running to the finish line.

Accessing Facts in Jinja2

You can access facts in Jinja2 templates the same way you access facts from your playbook.

To demonstrate, change to your templates directory and create the info.j2 Jinja2 file with the following contents:

[elliot@control templates]$ cat info.j2 
Server Information Summary
--------------------------

hostname={{ ansible_facts['hostname'] }}
fqdn={{ ansible_facts['fqdn'] }}
ipaddr={{ ansible_facts['default_ipv4']['address'] }}
distro={{ ansible_facts['distribution'] }}
distro_version={{ ansible_facts['distribution_version'] }}
nameservers={{ ansible_facts['dns']['nameservers'] }}
totalmem={{ ansible_facts['memtotal_mb'] }}
freemem={{ ansible_facts['memfree_mb'] }}

Notice that info.j2 accesses eight different facts. Now go back to your project directory and create the following server-info.yml playbook:

[elliot@control plays]$ cat server-info.yml 
---
- name: Server Information Summary
  hosts: all
  tasks:
   - name: Create server-info.txt using Jinja2
     template:
       src: info.j2
       dest: /tmp/server-info.txt

Notice that you are creating /tmp/server-info.txt on all hosts based on the info.j2 template file. Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook server-info.yml 

PLAY [Server Information Summary] *******************************************

TASK [Gathering Facts] **********************************
ok: [node4]
ok: [node1]
ok: [node3]
ok: [node2]

TASK [Create server-info.txt using Jinja2] ********
changed: [node4]
changed: [node1]
changed: [node3]
changed: [node2]

PLAY RECAP *************************
node1                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node2                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node4                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0

Everything looks good! Now let’s run a quick ad-hoc command to inspect the contents of the /tmp/server-info.txt file on one of the nodes:

[elliot@control plays]$ ansible node1 -m command -a "cat /tmp/server-info.txt"
node1 | CHANGED | rc=0 >>
Server Information Summary
--------------------------

hostname=node1
fqdn=node1.linuxhandbook.local
ipaddr=10.0.0.5
distro=CentOS
distro_version=8.2
nameservers=['168.63.129.16']
totalmem=1896
freemem=1087

As you can see, Jinja2 was able to access and process all the facts.

Conditional statements in Jinja2

You can use the if conditional statement in Jinja2 for testing various conditions and comparing variables. This allows you to determine your file template execution flow according to your test conditions.

To demonstrate, go to your templates directory and create the following selinux.j2 template:

[elliot@control templates]$ cat selinux.j2 
{% set selinux_status = ansible_facts['selinux']['status'] %}

{% if selinux_status == "enabled" %}
	"SELINUX IS ENABLED"
{% elif selinux_status == "disabled" %}
	"SELINUX IS DISABLED"
{% else %}
	"SELINUX IS NOT AVAILABLE"
{% endif %}

The first statement in the template creates a new variable selinux_statusand set its value to ansible_facts['selinux']['status'].

You then use selinux_status in your if test condition to determine whether SELinux is enabled, disabled, or not installed. In each of the three different cases, you display a message that reflects Selinux status.

Notice how the if statement in Jinja2 mimics Python’s if statement; just don’t forget to use {% endif %}.

Now go back to your project directory and create the following selinux-status.yml playbook:

[elliot@control plays]$ cat selinux-status.yml 
---
- name: Check SELinux Status
  hosts: all
  tasks:
    - name: Display SELinux Status
      debug:
        msg: "{{ ansible_facts['selinux']['status'] }}"

    - name: Create selinux.out using Jinja2
      template:
        src: selinux.j2
        dest: /tmp/selinux.out

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook selinux-status.yml 

PLAY [Check SELinux Status] ****************************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node2]
ok: [node3]
ok: [node1]

TASK [Display SELinux Status] **************************************************
ok: [node1] => {
    "msg": "enabled"
}
ok: [node2] => {
    "msg": "disabled"
}
ok: [node3] => {
    "msg": "enabled"
}
ok: [node4] => {
    "msg": "Missing selinux Python library"
}

TASK [Create selinux.out using Jinja2] *****************************************
changed: [node4]
changed: [node1]
changed: [node3]
changed: [node2]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node2                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    node4                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0  

From the playbook output; you can see that SELinux is enabled on both node1 and node3. I disabled SELinux on node2 before running the playbook and node4 doesn’t have SELinux installed because Ubuntu uses AppArmor instead of SELinux.

Finally, you can run the following ad-hoc command to inspect the contents of selinux.out on all the managed hosts:

[elliot@control plays]$ ansible all -m command -a "cat /tmp/selinux.out"
node4 | CHANGED | rc=0 >>

	"SELINUX IS NOT AVAILABLE"
 
node2 | CHANGED | rc=0 >>

	"SELINUX IS DISABLED"
 
node3 | CHANGED | rc=0 >>

	"SELINUX IS ENABLED"
 
node1 | CHANGED | rc=0 >>

	"SELINUX IS ENABLED"

Looping in Jinja2

You can use the for statement in Jinja2 to loop over items in a list, range, etc. For example, the following for loop will iterate over the numbers in the range(1,11)and will hence display the numbers from 1->10:

{% for i in range(1,11) %}
	Number {{ i }}
{% endfor %}

Notice how the for loop in Jinja2 mimics the syntax of Python’s for loop; again don’t forget to end the loop with {% endfor %}.

Now let’s create a full example that shows off the power of for loops in Jinja2. Change to your templates directory and create the following hosts.j2 template file:

[elliot@control templates]$ cat hosts.j2 
{% for host in groups['all'] %}
{{ hostvars[host].ansible_facts.default_ipv4.address }}  {{ hostvars[host].ansible_facts.fqdn }}  {{ hostvars[host].ansible_facts.hostname }}
{% endfor %}

Notice here you used a new built-in special (magic) variable hostvars which is basically a dictionary that contains all the hosts in inventory and variables assigned to them.

You iterated over all the hosts in your inventory and then for each host; you displayed the value of three variables:

1. {{ hostvars[host].ansible_facts.default_ipv4.address }}
2. {{ hostvars[host].ansible_facts.fqdn }}
3. {{ hostvars[host].ansible_facts.hostname }}

Notice also that you must include those three variables on the same line side by side to match the format of the /etc/hosts file.

Now go back to your projects directory and create the following local-dns.yml playbook:

[elliot@control plays]$ cat local-dns.yml 
---
- name: Dynamically Update /etc/hosts File
  hosts: all
  tasks:
    - name: Update /etc/hosts using Jinja2
      template:
        src: hosts.j2
        dest: /etc/hosts

Then go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook local-dns.yml 

PLAY [Dynamically Update /etc/hosts File] *********************************************

TASK [Gathering Facts] ***************************
ok: [node4]
ok: [node2]
ok: [node1]
ok: [node3]

TASK [Update /etc/hosts using Jinja2] ***********************************************
changed: [node4]
changed: [node3]
changed: [node1]
changed: [node2]

PLAY RECAP **********************
node1                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node2                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0    
node4                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0 

Everything looks good so far; now run the following ad-hoc command to verify that /etc/hosts file is properly updated on node1:

[elliot@control plays]$ ansible node1 -m command -a "cat /etc/hosts"
node1 | CHANGED | rc=0 >>
10.0.0.5  node1.linuxhandbook.local  node1
10.0.0.6  node2.linuxhandbook.local  node2
10.0.0.7  node3.linuxhandbook.local  node3
10.0.0.8  node4.linuxhandbook.local  node4

Perfect! Looks properly formatted as you expected it to be.

I hope you now realize the power of Jinja2 templates in Ansible. Stay tuned for next tutorial where you will learn to protect sensitive information and files using Ansible Vault.

How do you know how many files are there is a directory?

In this quick tutorial, you'll learn various ways to count the number of files in a directory in Linux.

Method 1: Use ls and wc command for counting number of lines in directory

The simplest and the most obvious option is to use the wc command for counting number of files.

ls | wc -l

The above command will count all the files and directories but not the hidden ones. You can use -A option with the ls command to list hidden files but leaving out . and .. directories:

ls -A | wc -l

If you only want to count number of files, including hidden files, in the current directory, you can combine a few commands like this:

ls -Ap | grep -v /$ | wc -l

Let me explain what it does:

• -p with ls adds / at the end of the directory names.
• -A with ls lists all the files and directories, including hidden files but excluding . and .. directories.
• grep -v /$ only shows the lines that do NOT match ( -v option) lines that end with /.
• wc -l counts the number of lines.

Basically, you use ls to list display all the files and directories (with / added to directory names). You then use pipe redirection to parse this output to the grep command. The grep command only displays the lines that do not have / at the end. The wc command then counts all such lines.

List Only Directories in Linux With ls and Other Commands

Listing the contents of a directory is easy. But what if you want to list only the directories, not files and links?

Abhishek PrakashLinux Handbook

Method 2: Use tree command for counting number of files in directory

You can use the tree command for displaying the number of files in the present directory and all of its subdirectories.

tree -a

As you can see, the last line of the output shows the number of directories and files, including the hidden ones thanks to option -a.

If you want to get the number of files in current directory only, exclude the subdirectories, you can set the level to 1 like this:

tree -a -L 1

Method 3: Use find command to count number of files in a directory

The evergreen find command is quite useful when it comes with dealing with files.

If you want to count the number of files in a directory, use the find command to get all the files first and then count it using the wc command.

find directory_path -type f | wc -l

With -type f you tell the find command to only look for files.

If you don't want the files from the subdirectories, limit the scope of find command at level 1, i.e. current directory.

find . -maxdepth 1 -type f | wc -l

There could be some other ways to count the number of lines in a directory in Linux. It's up to you how you want to go about.

I hope you find this helpful. Feel free to leave a question or suggestion in the comment section.

The way DevOps as a culture is gaining momentum, tools like Ansible and Terraform witnessing a huge demand and popularity.

Both tools are considered as Infrastructure as Code (IaC) solutions which helps in deploying code and infrastructure. While Ansible acts as a configuration management solution commonly abbreviated as “CM”, Terraform is a service orchestration or provisioning tool.

Note that there are overlaps and these terms are not necessarily mutually exclusive. This is what confuses people and this is why I am going to compare Ansible and Terraform.

I'll explain what are these tools used for, what are their pros and cons. This will help you decide whether you should use Ansible or Terraform in your projects.

Ansible and Terraform: What are these tools?

Let's first briefly take a look at what are these popular DevOps tools.

What is Ansible?

Ansible is an IT automation tool. It can configure systems, deploy software, and perform more advanced IT tasks such as continuous deployments or zero downtime rolling updates.

What is Terraform?

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

Before highlighting the differences between these two tools let us first understand what Configuration Management and Orchestration is.

Configuration Management vs. Orchestration

Configuration management is a set processes and procedures that ensures that the desired and consistent state of your infrastructure which includes servers and software's are always met. In other words, it's a way to make sure that a system performs as it's expected to as changes are made over time.

CM tools ensure that IT deployments are faster, incremental, repeatable, scalable, predictable, and maintains the desired state, which brings managed assets into an expected state.

Tools like Ansible are used for doing configuration management.

When it comes to orchestration you can use the orchestration tools to not only provision servers, but also databases, caches, load balancers, queues, monitoring, subnet configuration, firewall settings, routing rules, SSL certificates, and almost every other aspect of your infrastructure, mainly public cloud infrastructure.

Terraform is an orchestration tool. It is designed to provision the server instances themselves, leaving the job of configuring those servers to other tools.

Procedural vs. Declarative Language

DevOps tools can be categorized as Procedural or Declarative based on how they perform their actions when applied.

Procedural describes an application that requires the exact steps to be laid out in the code whereas Declarative “declares” exactly what is needed, not the process by which the result is achieved.

Ansible uses procedural style where you write the code that specifies, step-by-step tasks in order to achieve desired end state.

Whereas tools like Terraform, AWS CloudFormation all are declarative in defining the process where you write code that specifies your desired end state. For example, if you needed 5 EC2 instances, that’s exactly how many you would have after the code has been executed.

Ansible and Terraform: Comparison

Let's see what are the advantages and disadvantages of using Terraform:

Pros of Terraform

• Terraform maintains whole cloud infrastructure and make those resources available as code. That makes incremental change process very easy.
• Modular design.
• Simple and Easy-to-Learn
• It maintains the state of the resources created. All the objects created by Terraform shall be recreated if deleted by any other process.
• Seamless integration with CI/CD pipelines.
• It allows import of existing resources to bring them in Terraform state.
• When you run terraform plan, it shows the changes that are about to be applied to resources that already exist. This gives DevOps engineers an insight into the changes they're about to make, particularly if the changes are not as expected.

Cons of Terraform

• No rollbacks. You need to destroy everything and re-run of the tf script is required.
• Error handling is not mature. As of Terraform v.12.20 there are two new functions available for consumers try() and can().
• Terraform scripts creation isn't allowed directly from state files.
• Terraform tool is still under development and going through many beta releases each month.
• Not every item can be imported.  terrafom import command can only import one resource at a time. This means you can't yet point Terraform import to an entire collection of resources such as an AWS VPC and import all of it.

Pros and cons of using Ansible

Now, let's take a look at the positives and negatives of Ansible.

Pros of Ansible

• Simple and Easy-to-Learn
• Agentless
• Make the whole deployment process automated and developer friendly
• YAML based simple and readable scripts (Ansible Playbooks)
• Huge module support
• Availability of a central repository called Ansible galaxy to find and reuse Ansible content.

Cons of Ansible

• Lacks in UI offering. AWX which eventually evolved into Ansible tower still has a huge room for improvement.
• No state maintenance. Ansible doesn’t keep track of dependencies. It just executes a sequential series of tasks, stops when it finishes, fails or encounters an error.
• Not up to the mark when it comes to Windows OS support. Ansible is still in early stages to extend support for Windows.
• Not that straightforward if you have to write complex scripts with extensive logics in playbooks.
• Enterprise support isn't yet matured/reliable.
• Lacks descriptive error messages when it comes to debugging complex playbooks.

Terraform or Ansible? Which one is better for you?

Believe me, it's not a simple question to answer. Because it depends largely on your requirements.

In real world, within IT organizations, you never rely on one tool instead you use combination of different tools to achieve the desired results.

Both Ansible and Terraform tools do a lot of things pretty well. And my personal preference is to use Terraform for orchestration/provisioning and Ansible for configuration management.

Terraform performs at its best of capabilities when used for infrastructure orchestration (managing cloud resources) as this is what it was created for.

Ansible, on the other hand, is best suited and optimized for configuration management tasks (provisioning software and machines). Orchestration tasks also can be performed with it, but that is just part of what it does.

My suggestion - use what is best and originally created for the task you want to perform.

But that's not the rule of thumb either as you may find people who prefer to use one tool for everything and it works for them!

Conclusion

Both tools have their own benefits as well as limitations when designing Infrastructure as Code environments for automation. And yes, the success totally depends on knowing which tools to use for which jobs.

I hope I have made a few things around Ansible and Terraform clearer for you. If you still have questions or suggestion, please let me in the comment section.

In this tutorial, you will learn how to add decision making skills to your Ansible playbooks.

You will learn to:

• Use when statements to run tasks conditionally.
• Use block statements to implement exception handling.
• Use Ansible handlers to trigger tasks upon change.

Needless to say that you should be familiar with Ansible playbooks, ad-hoc commands and other Ansible basics to understand this tutorial. You may follow the earlier chapter of this RHCE Ansible series.

This tutorial follow the same setup that was mentioned in the first chapter of this series: 1 Red Hat control, 3 CentOS nodes and 1 Ubuntu node.

Choosing When to Run Tasks

Let's start to put conditions on when to run a certain task with Ansible.

Using when with facts

You can use when conditionals to run a task only when a certain condition is true. To demonstrate, create a new playbook named ubuntu-server.yml that has the following content:

[elliot@control plays]$ cat ubuntu-server.yml 
---
- name: Using when with facts 
  hosts: all
  tasks:
    - name: Detect Ubuntu Servers
      debug:
        msg: "This is an Ubuntu Server."
      when:  ansible_facts['distribution'] == "Ubuntu"

Now go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook ubuntu-servers.yml 

PLAY [Using when with facts] *******************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node1]
ok: [node3]
ok: [node2]

TASK [Detect Ubuntu Servers] ***************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
ok: [node4] => {
    "msg": "This is an Ubuntu Server."
}

PLAY RECAP *********************************************************************
node1                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    

node2                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    
node3                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    
node4                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0   

Notice how I used the Ansible fact ansible_facts['distribution'] in the when condition to test which nodes are running Ubuntu. Also, notice that you don’t need to surround variables with curly brackets when using when conditionals.

In the playbook output, notice how TASK [Detect Ubuntu Servers] skipped the first three nodes as they are all running CentOS and only ran on node4 as it is running Ubuntu.

Using when with registers

You can also use when conditionals with registered variables. For example, the following playbook centos-servers.yml will reveal which nodes are running CentOS:

[elliot@control plays]$ cat centos-servers.yml 
---
- name: Using when with registers
  hosts: all
  tasks:
    - name: Save the contents of /etc/os-release
      command: cat /etc/os-release
      register: os_release

    - name: Detect CentOS Servers
      debug:
        msg: "Running CentOS ..."
      when: os_release.stdout.find('CentOS') != -1

The playbook first starts by saving the contents of the /etc/os-release file into the os_release register. Then the second tasks displays the message “Running CentOS …” only if the word ‘CentOS’ is found in  os_release standard output.

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook centos-servers.yml 

PLAY [Using when with registers] ***********************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node1]
ok: [node3]
ok: [node2]

TASK [Save the contents of /etc/os-release] ************************************
changed: [node4]
changed: [node1]
changed: [node2]
changed: [node3]

TASK [Detect CentOS Servers] ***************************************************
ok: [node1] => {
    "msg": "Running CentOS ..."
}
ok: [node2] => {
    "msg": "Running CentOS ..."
}
ok: [node3] => {
    "msg": "Running CentOS ..."
}
skipping: [node4]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node2                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node4                      : ok=2    changed=1    unreachable=0    failed=0    skipped=1    

Notice how TASK [Detect CentOS Servers] only ran on the first three nodes and skipped node4 (Ubuntu).

Testing multiple conditions with when

You can also test multiple conditions at once by using the logical operators. For example, the following reboot-centos8.yml playbook uses the logical and operator to reboot servers that are running CentOS version 8:

[elliot@control plays]$ cat reboot-centos8.yml 
---
- name: Reboot Servers
  hosts: all
  tasks:
    - name: Reboot CentOS 8 servers
      reboot: 
        msg: "Server is rebooting ..."
      when: ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "8"

You can also use the logical or operator to run a task if any of the conditions is true. For example, the following task would reboot servers that are running either CentOS or RedHat:

  tasks:
    - name: Reboot CentOS and RedHat Servers 
      reboot: 
        msg: "Server is rebooting ..."
      when: ansible_facts['distribution'] == "CentOS" or ansible_facts['distribution'] == "RedHat"

Using when with loops

If you combine a when conditional statement with a loop, Ansible would test the condition for each item in the loop separately.

For example, the following print-even.yml playbook will print all the even numbers in the range(1,11):

[elliot@control plays]$ cat print-even.yml
---
- name: Print Some Numbers
  hosts: node1
  tasks:
    - name: Print Even Numbers
      debug:
        msg: Number {{ item }} is Even.
      loop: "{{ range(1,11) | list }}"
      when: item % 2 == 0

Go ahead and run the playbook to see the list of all even numbers in the range(1,11):

[elliot@control plays]$ ansible-playbook print-even.yml

PLAY [Print Some Numbers] **********************************

TASK [Gathering Facts] ****************************
ok: [node1]

TASK [Print Even Numbers] ******************************
skipping: [node1] => (item=1) 
ok: [node1] => (item=2) => {
    "msg": "Number 2 is Even."
}
skipping: [node1] => (item=3) 
ok: [node1] => (item=4) => {
    "msg": "Number 4 is Even."
}
skipping: [node1] => (item=5) 
ok: [node1] => (item=6) => {
    "msg": "Number 6 is Even."
}
skipping: [node1] => (item=7) 
ok: [node1] => (item=8) => {
    "msg": "Number 8 is Even."
}
skipping: [node1] => (item=9) 
ok: [node1] => (item=10) => {
    "msg": "Number 10 is Even."
}

PLAY RECAP ***********************************
node1                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0

Using when with variables

You can also use when conditional statements with your own defined variables. Keep in mind that conditionals require boolean inputs; that is, a test must evaluate to true to trigger the condition and so, you need to use the bool filter with non-boolean variables.

To demonstrate, take a look at the following isfree.yml playbook:

[elliot@control plays]$ cat isfree.yml 
---
- name: 
  hosts: node1
  vars:
    weekend: true
    on_call: "no"
  tasks:
    - name: Run if "weekend" is true and "on_call" is false
      debug:
        msg: "You are free!"
      when: weekend and not on_call | bool

Notice that I used the bool filter here to convert the on_call value to its boolean equivalent (no -> false).

Also, you should be well aware that not false is true and so the whole condition will evaluate to true in this case; you are free!

You can also test to see whether a variable has been set or not; for example, the following task will only run if the car variable is defined:

tasks:
    - name: Run only if you got a car
      debug:
        msg: "Let's go on a road trip ..."
      when: car is defined

The following task uses the fail module to fail if the keys variable is undefined:

tasks:
    - name: Fail if you got no keys
      fail:
        msg: "This play require some keys"
      when: keys is undefined

Handling Exceptions with Blocks

Let's talk about handling exceptions.

Grouping tasks with blocks

You can use blocks to group related tasks together. To demonstrate, take a look at the following install-apache.yml playbook:

[elliot@control plays]$ cat install-apache.yml 
---
- name: Install and start Apache Play
  hosts: webservers
  tasks:
    - name: Install and start Apache
      block:
         - name: Install httpd
           yum:
             name: httpd
             state: latest

         - name: Start and enable httpd
           service:
             name: httpd
             state: started
             enabled: yes

    - name: This task is outside the block
      debug:
        msg: "I am outside the block now ..."

The playbook runs on the webservers group hosts and has one block with the name Install and start Apache that includes two tasks:

1. Install httpd
2. Start and enable httpd

The first task Install httpd uses the yum module to install the httpd apache package. The second task Start and enable httpd uses the service module to start and enabled httpd to start on boot.

Notice that the playbook has a third task that doesn’t belong to the Install and start Apache block.

Now go ahead and run the playbook to install and start httpd on the webservers nodes:

[elliot@control plays]$ ansible-playbook install-apache.yml 

PLAY [Install and start Apache Play] *******************************************

TASK [Gathering Facts] *********************************************************
ok: [node3]
ok: [node2]

TASK [Install httpd] ***********************************************************
changed: [node2]
changed: [node3]

TASK [Start and enable httpd] **************************************************
changed: [node3]
changed: [node2]

TASK [This task is outside the block] ******************************************
ok: [node2] => {
    "msg": "I am outside the block now ..."
}
ok: [node3] => {
    "msg": "I am outside the block now ..."
}

PLAY RECAP *********************************************************************
node2                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0     
node3                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

You can also follow up with an ad-hoc command to verify that httpd is indeed up and running:

[elliot@control plays]$ ansible webservers -m command -a "systemctl status httpd"
node3 | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-11-03 19:35:13 UTC; 1min 37s ago
     Docs: man:httpd.service(8)
 Main PID: 47122 (httpd)
   Status: "Running, listening on: port 80"
    Tasks: 213 (limit: 11935)
   Memory: 25.1M
   CGroup: /system.slice/httpd.service
           ├─47122 /usr/sbin/httpd -DFOREGROUND
           ├─47123 /usr/sbin/httpd -DFOREGROUND
           ├─47124 /usr/sbin/httpd -DFOREGROUND
           ├─47125 /usr/sbin/httpd -DFOREGROUND
           └─47126 /usr/sbin/httpd -DFOREGROUND

Nov 03 19:35:13 node3 systemd[1]: Starting The Apache HTTP Server...
Nov 03 19:35:13 node3 systemd[1]: Started The Apache HTTP Server.
Nov 03 19:35:13 node3 httpd[47122]: Server configured, listening on: port 80
node2 | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-11-03 19:35:13 UTC; 1min 37s ago
     Docs: man:httpd.service(8)
 Main PID: 43695 (httpd)
   Status: "Running, listening on: port 80"
    Tasks: 213 (limit: 11935)
   Memory: 25.1M
   CGroup: /system.slice/httpd.service
           ├─43695 /usr/sbin/httpd -DFOREGROUND
           ├─43696 /usr/sbin/httpd -DFOREGROUND
           ├─43697 /usr/sbin/httpd -DFOREGROUND
           ├─43698 /usr/sbin/httpd -DFOREGROUND
           └─43699 /usr/sbin/httpd -DFOREGROUND

Nov 03 19:35:13 node2 systemd[1]: Starting The Apache HTTP Server...
Nov 03 19:35:13 node2 systemd[1]: Started The Apache HTTP Server.
Nov 03 19:35:13 node2 httpd[43695]: Server configured, listening on: port 80

Handling Failure with Blocks

You can also use blocks to handle task errors by using the rescue and always sections. This is pretty much similar to exception handling in programming languages like the try-catch in Java or try-except in Python.

You can use the rescue section to include all the tasks that you want to run in case one or more tasks in the block has failed.

To demonstrate, let’s take a look at the following example:

tasks:
  - name: Handling error example
    block:
      - name: run a command
        command: uptime

      - name: run a bad command
        command: blabla

      - name: This task will not run
        debug:
          msg: "I never run because the above task failed."

    rescue: 
      - name: Runs when the block failed
        debug:
          msg: "Block failed; let's try to fix it here ..."

Notice how the second task in the block run a bad command generates an error and in turn the third task in the block never gets a chance to run. The tasks inside the rescue section will run because the second task in the block has failed.

You can also use ignore_errors: yes to ensure that Ansible continue executing the tasks in the playbook even if a task has failed:

tasks:
  - name: Handling error example
    block:
      - name: run a command
        command: uptime

      - name: run a bad command
        command: blabla
        ignore_errors: yes

      - name: This task will run
        debug:
          msg: "I run because the above task errors were ignored."

    rescue: 
      - name: This will not run
        debug:
          msg: "Errors were ignored! ... not going to run."

Notice that in this example, you ignored the errors in the second task run a bad command in the block and that’s why the third task was able to run. Also, the rescue section will not run as you ignored the error in the second task in the block.

You can also add an always section to a block. Tasks in the always section will always run regardless whether the block has failed or not.

To demonstrate, take a look at the following handle-errors.yml playbook that has all the three sections (block, rescue, always) of a block:

[elliot@control plays]$ cat handle-errors.yml 
---
- name: Handling Errors with Blocks
  hosts: node1
  tasks:
    - name: Handling Errors Example
      block:
        - name: run a command
          command: uptime

        - name: run a bad command
          command: blabla

        - name: This task will not run
          debug:
            msg: "I never run because the task above has failed!"

      rescue:
        - name: Runs when the block fails
          debug:
            msg: "Block failed! let's try to fix it here ..."

      always:
        - name: This will always run
          debug:
            msg: "Whether the block has failed or not ... I will always run!"

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook handle-errors.yml 

PLAY [Handling Errors with Blocks] *********************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [run a command] ***********************************************************
changed: [node1]

TASK [run a bad command] *******************************************************
fatal: [node1]: FAILED! => {"changed": false, "cmd": "blabla", "msg": "[Errno 2] No such file or directory: b'blabla': b'blabla'", "rc": 2}

TASK [Runs when the block fails] ***********************************************
ok: [node1] => {
    "msg": "Block failed! let's try to fix it here ..."
}

TASK [This will always run] ****************************************************
ok: [node1] => {
    "msg": "Whether the block has failed or not ... I will always run!"
}

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=1    unreachable=0    failed=0    skipped=0

As you can see; the rescue section did run as the 2^ndtask in the block has failed and you didn’t ignore the errors. Also, the always section did (and will always) run.

Running Tasks upon Change with Handlers

Let's see about changing handlers and running tasks.

Running your first handler

You can use handlers to trigger tasks upon a change on your managed nodes. To demonstrate, take a look at the following handler-example.yml playbook:

[elliot@control plays]$ cat handler-example.yml 
---
- name: Simple Handler Example
  hosts: node1
  tasks:
    - name: Create engineers group
      group:
        name: engineers
      notify: add elliot

    - name: Another task in the play
      debug:
        msg: "I am just another task."

  handlers: 
    - name: add elliot
      user:
        name: elliot
        groups: engineers
        append: yes

The first task Create engineers group creates the engineers group and also notifies the add elliot handler.

Let’s run the playbook to see what happens:

[elliot@control plays]$ ansible-playbook handler-example.yml 

PLAY [Simple Handler Example] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Create engineers group] **************************************************
changed: [node1]

TASK [Another task in the play] ************************************************
ok: [node1] => {
    "msg": "I am just another task."
}

RUNNING HANDLER [add elliot] ***************************************************
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

Notice that creating the engineers caused a change on node1 and as a result triggered the add elliot handler.

You can also run a quick ad-hoc command to verify that user elliot is indeed a member of the engineers group:

[elliot@control plays]$ ansible node1 -m command -a "id elliot"
node1 | CHANGED | rc=0 >>
uid=1000(elliot) gid=1000(elliot) groups=1000(elliot),4(adm),190(systemd-journal),1004(engineers)

Ansible playbooks and modules are idempotent which means that if a change in configuration occurred on the managed nodes; it will not redo it again!

To fully understand the concept of Ansible’s idempotency; run the handler-example.yml playbook one more time:

[elliot@control plays]$ ansible-playbook handler-example.yml 

PLAY [Simple Handler Example] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Create engineers group] **************************************************
ok: [node1]

TASK [Another task in the play] ************************************************
ok: [node1] => {
    "msg": "I am just another task."
}

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=0    unreachable=0    failed=0    skipped=0  

As you can see; the Create engineers group task didn’t not cause or report a change this time because the engineers group already exists on node1 and as a result; the add elliot handler did not run.

Controlling when to report a change

You can use the changed_when keyword to control when a task should report a change. To demonstrate, take a look at the following control-change.yml playbook:

[elliot@control plays]$ cat control-change.yml 
---
- name: Control Change
  hosts: node1
  tasks:
    - name: Run the date command
      command: date
      notify: handler1

    - name: Run the uptime command
      command: uptime

  handlers:
     - name: handler1
       debug:
         msg: "I can handle dates"

Notice how the first task Run the date command triggers handler1. Now go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook control-change.yml 

PLAY [Control Change] **********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Run the date command] ****************************************************
changed: [node1]

TASK [Run the uptime command] **************************************************
changed: [node1]

RUNNING HANDLER [handler1] *****************************************************
ok: [node1] => {
    "msg": "I can handle dates"
}

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

Both tasks Run the date command and Run the uptime command reported changes and handler1 was triggered. You can argue that running a date and uptime commands don’t really change anything on the managed node and you are totally right!

Now let’s edit the playbook to stop the Run the date command task from reporting changes:

[elliot@control plays]$ cat control-change.yml 
---
- name: Control Change
  hosts: node1
  tasks:
    - name: Run the date command
      command: date
      notify: handler1
      changed_when: false

    - name: Run the uptime command
      command: uptime

  handlers:
     - name: handler1
       debug:
         msg: "I can handle dates"

Now run the playbook again:

[elliot@control plays]$ ansible-playbook control-change.yml 

PLAY [Control Change] **********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Run the date command] ****************************************************
ok: [node1]

TASK [Run the uptime command] **************************************************
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0   

As you can see, the Run the date command task didn’t report a change this time and as a result, handler1 was not triggered.

Configuring services with handlers

Handlers are especially useful when you are editing services configurations with Ansible. That’s because you only want to restart a service when there is a change in its service configuration.

To demonstrate, take a look at the following configure-ssh.yml playbook:

[elliot@control plays]$ cat configure-ssh.yml 
---
- name: Configure SSH 
  hosts: all
  tasks:
     - name: Edit SSH Configuration
       blockinfile:
         path: /etc/ssh/sshd_config
         block: |
            MaxAuthTries 4
            Banner /etc/motd
            X11Forwarding no
       notify: restart ssh

  handlers: 
    - name: restart ssh
      service:
        name: sshd
        state: restarted

Notice I used the blockinfile module to insert multiple lines of text into the /etc/ssh/sshd_config configuration file. The Edit SSH Configuration task also triggers the restart ssh handler upon change.

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook configure-ssh.yml 

PLAY [Configure SSH] ***********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node3]
ok: [node1]
ok: [node2]

TASK [Edit SSH Configuration] **************************************************
changed: [node4]
changed: [node2]
changed: [node3]
changed: [node1]

RUNNING HANDLER [restart ssh] **************************************************
changed: [node4]
changed: [node3]
changed: [node2]
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node2                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node4                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0  

Everything looks good! Now let’s quickly take a look the last few lines in the /etc/ssh/sshd_config file:

[elliot@control plays]$ ansible node1 -m command -a "tail -5 /etc/ssh/sshd_config"
node1 | CHANGED | rc=0 >>
# BEGIN ANSIBLE MANAGED BLOCK
MaxAuthTries 4
Banner /etc/motd
X11Forwarding no
# END ANSIBLE MANAGED BLOCK

Amazing! Exactly as you expected it to be. Keep in mind that if you rerun the configure-ssh.yml playbook, Ansible will not edit (or append) the /etc/ssh/sshd_config file. You can try it for yourself.

I also recommend you take a look at the blockinfile and lineinfile documentation pages to understand the differences and the use of each module:

[elliot@control plays]$ ansible-doc blockinfile
[elliot@control plays]$ ansible-doc lineinfile

Alright! This takes us to the end of our Decision Making in Ansible tutorial. Stay tuned for next tutorial as you are going to learn how to use Jinja2 Templates to manage files and configure services dynamically in Ansible.

The ls command in Linux is used for listing the contents of any directory.

By default, it lists all the contents, be it a file or a directory or a link or a named pipe.

But what if you want to list only the directories? How do you that?

Like anything in Linux, there are several ways to accomplish the same task. Listing only the directories is no different:

• ls -d */
• ls -l | grep '^d'
• find . -maxdepth 1 -type d
• echo */
• tree -d -L 1

Don't worry. I'll explain things in detail. Here's the content of the directory I am going to use in the examples here:

Use ls command to list directories only

It is always good to do it with the familiar ls command because this is the command you use for displaying the content of a directory.

To list only the subdirectories, use the -d option with ls command like this:

ls -d */

Here's the output it shows:

[abhishek@localhost Documents]$ ls -d */
another_dir/  my_dir/

Why */? Because without it, ls -d will only return the directory name. The -d option list directories not its contents (which includes file, directories etc).

The */ is a pattern. With *, you list all the content (including contents of the subdirectories) and the / restricts the pattern to directories.

This picture depicts the difference pretty well.

You may combine it with long listing option -l and most other options:

[abhishek@localhost Documents]$ ls -ld */
drwxrwxr-x. 1 abhishek abhishek 16 Nov  7 18:22 another_dir/
drwxrwxr-x. 1 abhishek abhishek 44 Nov  7 18:22 my_dir/

If you do not want the trailing slash (/) at the end of the directory names, you can use the cut command to cut it out:

[abhishek@localhost Documents]$ ls -ld */ | cut -f1 -d'/'
drwxrwxr-x. 1 abhishek abhishek 16 Nov  7 18:22 another_dir
drwxrwxr-x. 1 abhishek abhishek 44 Nov  7 18:22 my_dir

List only subdirectories in a specific directory

The above command works in the current directory. What if you are not in the same directory?

In this situation, you can use */ at the end of the path of the directory with ls -d:

ls -d Path/To/Dir/*/

Here's an example where I move out of the Documents directory and then list only the directories inside Documents directory:

[abhishek@localhost ~]$ ls -ld Documents/*/
drwxrwxr-x. 1 abhishek abhishek 16 Nov  7 18:22 Documents/another_dir/
drwxrwxr-x. 1 abhishek abhishek 44 Nov  7 18:22 Documents/my_dir/

Did you notice that it doesn't list the hidden directory? That's one shortcoming of this method. You may use ls -d .*/ to display hidden directories, but it only displays hidden directories.

Use combination of ls and grep command

You can always rely on the good old grep command for filtering the output for specific content.

If you long list the contents, you can identify the directories because start with d.

You can use grep to filter the contents that start with d:

ls -l | grep '^d'

But this gives you a lot more fields than just the directory names:

[abhishek@localhost Documents]$ ls -l | grep '^d'
drwxrwxr-x. 1 abhishek abhishek 16 Nov  7 18:22 another_dir
drwxrwxr-x. 1 abhishek abhishek 44 Nov  7 18:22 my_dir

Use find command to list only directories

Here's how to use the find command to list only the subdirectories:

find directory_path -maxdepth 1 -type d

I hope you are familiar with the find command. I'll explain it nonetheless.

With type d, you ask the find command to only look for directories.

With maxdepth 1 you ask the find command to keep the search at the current level only (and not go inside the subdirectories).

[abhishek@localhost Documents]$ find . -maxdepth 1 -type d
.
./my_dir
./another_dir
./.my_hidden_dir

As you can see in the output above, it also shows the hidden directory.

Use tree command to list only directories

If your aim is to list only the directories, you may also use the tree command.

By default, the tree command gives you the complete directory structure. You can modify it to show only directories and only at the current level.

tree -dai -L 1

• d - look for directories only
• a - look for hidden files and directories as well
• i - remove the tree structure from the display
• L 1 - don't go into the subdirectories

Here's the output:

abhishek@localhost Documents]$ tree -dai -L 1
.
another_dir
my_dir
.my_hidden_dir

3 directories

Using echo command for listing directories

The unlikely candidate? You'll be surprised to know that echo command in Linux can also be used for displaying the contents of a directory. Try using echo * and see for yourself.

Similar to the ls command, you can also use the */ pattern to list only the directories in the current working directory.

echo */

Here's the output which is identical to what you got with the ls -d command:

There could be more ways for listing only the directories, not files. In fact, the methods discussed here may have some ifs and buts based on what you are looking for.

If your aim is to just display the directories, most of the commands I discussed would work. If you want something more specific like only getting the directories name with slash etc, you'll have to do some formatting on your own.

I hope you find this Linux tip helpful. Questions and suggestions are always welcome.

You may sometimes want to repeat a task multiple times. For example, you may want to create multiple users, start/stop multiple services, or change ownership on several files on your managed hosts.

In this tutorial, you will learn how to use Ansible loops to repeat a task multiple times without having to rewrite the whole task over and over again.

Before you look at loops in Ansible, I hope you have followed other chapters in this Ansible tutorial series. You should know the concept of Ansible playbooks, aware of the ad-hoc commands and know the basic terminology associated with Ansible like list, dictionaries etc.

Knowing the basics of YAML is also appreciated.

Looping over lists

Ansible uses the keywords loop to iterate over the elements of a list. To demonstrate, let’s create a very simple playbook named print-list.yml that shows you how to print the elements in a list:

[elliot@control plays]$ cat print-list.yml 
---
- name: print list
  hosts: node1
  vars:
    prime: [2,3,5,7,11]
  tasks:
    - name: Show first five prime numbers
      debug:
        msg: "{{ item }}"
      loop: "{{ prime }}"

Notice that I use the item variable with Ansible loops. The task would run five times which is equal to the number of elements in the prime list.

On the first run, the item variable will be set to first element in the prime array (2). On the second run, the item variable will be set to the second element in the prime array (3) and so on.

Go ahead and run the playbook to see all the elements of the prime list displayed:

[elliot@control plays]$ ansible-playbook print-list.yml 

PLAY [print list] **************************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Show first five prime numbers] *******************************************
ok: [node1] => (item=2) => {
    "msg": 2
}
ok: [node1] => (item=3) => {
    "msg": 3
}
ok: [node1] => (item=5) => {
    "msg": 5
}
ok: [node1] => (item=7) => {
    "msg": 7
}
ok: [node1] => (item=11) => {
    "msg": 11
}

PLAY RECAP *********************************************************************
node1                      : ok=2    changed=0    unreachable=0    failed=0

Now you apply loops to a real life application. For example, you can create an add-users.yml playbook that would add multiple users on all the hosts in the dbservers group:

[elliot@control plays]$ cat add-users.yml 
---
- name: Add multiple users
  hosts: dbservers
  vars:
    dbusers:
      - username: brad
        pass: pass1
      - username: david
        pass: pass2
      - username: jason
        pass: pass3
  tasks: 
    - name: Add users
      user:
        name: "{{ item.username }}"
        password: "{{ item.pass | password_hash('sha512') }}"
      loop: "{{ dbusers }}"

I first created a dbusers list which is basically a list of hashes/dictionaries. I then used the user module along with a loop to add the users and set the passwords for all users in the dbusers list.

Notice that I also used the dotted notation item.username and item.pass to access the keys values inside the hashes/dictionaries of the dbusers list.

It is also worth noting that I used the password_hash('sha512') filter to encrypt the user passwords with the sha512 hashing algorithm as the user module wouldn’t allow setting unencrypted user passwords.

RHCE Exam Tip: You will have access to the docs.ansible.com page on your exam. It a very valuable resource, especially under the “Frequently Asked Questions” section; you will find numerous How-to questions with answers and explanations.

Now let’s run the add-users.yml playbook:

[elliot@control plays]$ ansible-playbook add-users.yml 

PLAY [Add multiple users] ******************************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]

TASK [Add users] ***************************************************************
changed: [node4] => (item={'username': 'brad', 'pass': 'pass1'})
changed: [node4] => (item={'username': 'david', 'pass': 'pass2'})
changed: [node4] => (item={'username': 'jason', 'pass': 'pass3'})

PLAY RECAP *********************************************************************
node4                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0 

You can verify that the three users are added by following up with an Ansible ad-hoc command:

[elliot@control plays]$ ansible dbservers -m command -a "tail -3 /etc/passwd"
node4 | CHANGED | rc=0 >>
brad:x:1001:1004::/home/brad:/bin/bash
david:x:1002:1005::/home/david:/bin/bash
jason:x:1003:1006::/home/jason:/bin/bash

Looping over dictionaries

You can only use loop with lists. You will get an error if you try to loop over a dictionary.

For example, if you run the following print-dict.yml playbook:

[elliot@control plays]$ cat print-dict.yml 
---
- name: Print Dictionary
  hosts: node1
  vars:
    employee: 
      name: "Elliot Alderson"
      title: "Penetration Tester"
      company: "Linux Handbook"
  tasks:
    - name: Print employee dictionary
      debug:
        msg: "{{ item }}"
      loop: "{{ employee }}"

You will get the following error:

[elliot@control plays]$ ansible-playbook print-dict.yml 

PLAY [Print Dictionary] ********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Print employee dictionary] ***********************************************
fatal: [node1]: FAILED! => {"msg": "Invalid data passed to 'loop', it requires a list, got this instead: {'name': 'Elliot Alderson', 'title': 'Penetration Tester', 'company': 'Linux Handbook'}. Hint: If you passed a list/dict of just one element, try adding wantlist=True to your lookup invocation or use q/query instead of lookup."}

As you can see the error, it explicitly says that it requires a list.

To fix this error; you can use the dict2items filter to convert a dictionary to a list. So, in the print-dict.yml playbook; edit the line:

loop: "{{ employee }}"

and apply the dict2items filter as follows:

loop: "{{ employee | dict2items }}"

Then run the playbook again:

[elliot@control plays]$ ansible-playbook print-dict.yml 

PLAY [Print Dictionary] ********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Print employee dictionary] ***********************************************
ok: [node1] => (item={'key': 'name', 'value': 'Elliot Alderson'}) => {
    "msg": {
        "key": "name",
        "value": "Elliot Alderson"
    }
}
ok: [node1] => (item={'key': 'title', 'value': 'Penetration Tester'}) => {
    "msg": {
        "key": "title",
        "value": "Penetration Tester"
    }
}
ok: [node1] => (item={'key': 'company', 'value': 'Linux Handbook'}) => {
    "msg": {
        "key": "company",
        "value": "Linux Handbook"
    }
}

PLAY RECAP *********************************************************************
node1                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0

Success! The key/value pairs of the employee dictionary were displayed.

Looping over a range of numbers

You can use the range() function along with the list filter to loop over a range of numbers.

For example, the following task would print all the numbers from 0-9:

- name: Range Loop
  debug:
    msg: "{{ item }}"
  loop: "{{ range(10) | list }}"

You can also start your range at a number other than zero. For example, the following task would print all the numbers from 5-14:

- name: Range Loop
  debug:
    msg: "{{ item }}"
  loop: "{{ range(5,15) | list }}"

By default, the stride is set to 1. However, you can set a different stride.

For example, the following task would print all the even IP addresses in the 192.168.1.x subnet:

- name: Range Loop
  debug:
    msg: 192.168.1.{{ item }}
  loop: "{{ range(0,256,2) | list }}"

Where start=0, end<256, and stride=2.

Looping over inventories

You can use the Ansible built-in groups variable to loop over all your inventory hosts or just a subset of it. For instance, to loop over all your inventory hosts; you can use:

loop: "{{ groups['all'] }}"

If you want to loop over all the hosts in the webservers group, you can use:

loop: "{{ groups['webservers'] }}"

To see how this works in playbook; take a look at the following loop-inventory.yml playbook:

[elliot@control plays]$ cat loop-inventory.yml 
---
- name: Loop over Inventory 
  hosts: node1
  tasks:
    - name: Ping all hosts
      command: ping -c 1 "{{ item }}"
      loop: "{{ groups['all'] }}"

This playbook tests if node1 is able to ping all other hosts in your inventory. Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook loop-inventory.yml 

PLAY [Loop over Inventory] *****************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Ping all hosts] **********************************************************
changed: [node1] => (item=node1)
changed: [node1] => (item=node2)
changed: [node1] => (item=node3)
changed: [node1] => (item=node4)

PLAY RECAP *********************************************************************
node1                      : ok=2    changed=1    unreachable=0    failed=0    skipped=0   

If you get any errors; this would mean that your managed hosts are not able to ping (reach) each other.

Pausing within loops

You may want to pause for a certain amount of time between each loop iteration. To do this, you can use the pause directive along with the loop_control keyword.

To demonstrate, let’s write a countdown.yml playbook that would simply do a ten seconds countdown before displaying the message “Happy Birthday!” on the screen:

[elliot@control plays]$ cat countdown.yml 
---
- name: Happy Birthday Playbook
  hosts: node1
  tasks:
  - name: Ten seconds countdown
    debug:
      msg: "{{ 10 - item }} seconds remaining ..."
    loop: "{{ range(10) | list }}"
    loop_control: 
      pause: 1

  - name: Display Happy Birthday
    debug:
      msg: "Happy Birthday!"

Go ahead and run the playbook:

[elliot@control plays]$ ansible-playbook countdown.yml 

PLAY [Happy Birthday Playbook] *************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Wait for ten seconds] ****************************************************
ok: [node1] => (item=0) => {
    "msg": "10 seconds remaining ..."
}
ok: [node1] => (item=1) => {
    "msg": "9 seconds remaining ..."
}
ok: [node1] => (item=2) => {
    "msg": "8 seconds remaining ..."
}
ok: [node1] => (item=3) => {
    "msg": "7 seconds remaining ..."
}
ok: [node1] => (item=4) => {
    "msg": "6 seconds remaining ..."
}
ok: [node1] => (item=5) => {
    "msg": "5 seconds remaining ..."
}
ok: [node1] => (item=6) => {
    "msg": "4 seconds remaining ..."
}
ok: [node1] => (item=7) => {
    "msg": "3 seconds remaining ..."
}
ok: [node1] => (item=8) => {
    "msg": "2 seconds remaining ..."
}
ok: [node1] => (item=9) => {
    "msg": "1 seconds remaining ..."
}

TASK [Display Happy Birthday] **************************************************
ok: [node1] => {
    "msg": "Happy Birthday!"
}

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=0    unreachable=0    failed=0    skipped=0   

So, you get familiar with loops in Ansible. Stay tuned for next tutorial as you are going to learn how to add decision-making skills to your Ansible playbooks.

If you have not already, consider becoming a pro member of Linux Handbook for more ad-free, reading experience with independent publishers like us. You may always support us on Buy Me a Coffee.

YAML has gained a lot of popularity over the last few years as it became part of crucial DevOps tools, technologies and processes such as Ansible, Kubernetes, CI/CD pipelines and so on.

We have already covered lots of tutorials on Ansible and Kubernetes. I thought of covering YAML essentials so that you must be aware for a smoother working with your DevOps tools configuration.

What is YAML?

YAML stands for "YAML Ain't Markup Language" originally was an acronym for 'Yet Another Markup Language'. YAML is a “data serialization” language and basically a human-readable structured data format.

It is designed to be read and write friendly. The object serialization feature of YAML presents itself as a practicable alternative to JSON. YAML is a superset of JSON with the use of indentation-based scoping to denote the structure like Python.

Here's a sample YAML example:

--- 
 Student-ID: 314159
 First-Name: Linus
 Last-Name: Torvalds

Phone-numbers:
    - 281.555.7777
    - 832.676.8888
    - 937.996.9999

Addresses:
    - Street: 123 Main St.
    - City: Houston
    - State: Tx
---

YAML basic rules you should always remember

If you don't want to see repeated errors while parsing your YAML file, you must always keep the following in your mind while working on YAML:

• Tabs are NOT allowed in YAML. You should use space for indention.
• Though the amount of space doesn't matter as long as the child node indentation is more than the parent, it is a good practice to keep the same number of spaces.
• There must be space between different elements of YAML (explained later).
• YAML is case-sensitive.
• YAML file should end with extensions like .yaml or .yml.
• YAML allows UTF-8, UTF-16 and UTF-32 encoding.

Let's understand the YAML syntax now.

Elements of a YAML file: Basic syntax

A YAML file is used to describe data. In a YAML file the content is all about a collection of key-value pairs where the value can be anything ranging from a string to a tree.

Let us understand it by an example. This is a Kubernetes service manifest file.

kind: Service
metadata:  
  name: web-app-svc
spec:  
  type: NodePort  
  ports:  
  - port: 8080         #service port    
    targetPort: 8080   #Pod Port    
    nodePort: 30012  #Node Port from the range - 30000-32767  
  selector:    
    app: web-app

It's self explainable that it's a set of key value pair elements: Name: Value.

As you can see from the file above, a YAML file is constructed of a number of different elements. Together, they can be used to describe a wide variety of structures.

1. Spaces or indentation

In YAML, you indent with whitespace, not tabs. And there MUST be a space between elements.

Correct specification:

Kind: Service

Incorrect specification:

Kind:Service

Because there is no space after the colon in the above statement!

2. Comments in YAML

Comments can be defined by placing a hash in front of an item '#'. Comments can be made at the start of a line of anywhere in the line.

If you go through our YAML configuration file we have three inline comments such as "#service port" etc.

3. Scalar (key-value)

Scalars are the strings and numbers that make up the data on the page. In simple terms they are the key value pairs.

kind: Service
metadata:  
  name: web-app-svc

4. Collections & Lists

List and collection elements or members are the lines that begin at the same indentation level, starting with a dash followed by a space.

- web-app-prod 
- prod-deployments 
- prom-monitored

It is a basic list with each item in the list placed in its own line with an opening dash.

5. Nested collections

If you want to create a nested sequence with items and sub-items, you can do so by placing a single space before each dash in the sub-items.

- 
 - web-app-prod 
 - prod-deployments 
 - prom-monitored
-  
 - web-app-test 
 - staging-deployments 
 - not-monitored

6. Dictionaries

Dictionaries comprise a key: value format with contents indented.

ports:    
- port: 8080         #service port    
  targetPort: 8080   #Pod Port    
  nodePort: 30012  #Node Port from the range - 30000-32767

You can merge and mix-up collections of lists and dictionaries like this:

ports:    
- port: 8080         #service port    
  targetPort: 8080   #Pod Port    
  nodePort:       
  - 30012       
  - 30013       
  - 30014

These are very basic concepts of YAML but essential for a DevOps engineer.

You don't need special editor for YAML. Your favorite text editor should already be supporting YAML or use a plugin if required.

There are many things you can dig deeper and learn. For that, you may always refer to YAML's official documentation.

Want to be a better sysadmin or DevOps? Do become a Linux Handbook member today.

There will always be a lot of variances across your managed systems. For this reason, you need to learn how to work with Ansible variables.

In this tutorial, you will learn how to define and reference variables Ansible. You will also learn how to use Ansible facts to retrieve information on your managed nodes.

Furthermore, you will also learn how to use registers to capture task output.

If it is your first time here, please have a look at previous chapters in this series:

• Ansible RHCE #1: Introduction and installation
• Ansible RHCE #1: Running ad-hoc commands
• Ansible RHCE #1: Understanding playbooks

Part 1: Working with variables in Ansible

Let's start with variables first. Keep in mind that all this is written in your YML file.

Defining and referencing variables

You can use the vars keyword to define variables directly inside a playbook.

For example, you can define a fav_color variable and set its value to yellow as follows:

---
- name: Working with variables
  hosts: all
  vars:
    fav_color: yellow

Now how do you use (reference) the fav_color variable? Ansible uses the Jinja2 templating system to work with variables. There will be a dedicated tutorial that discusses Jinja2 in this series but for now you just need to know the very basics.

To get the value of the fav_color variable; you need to surround it by a pair of curly brackets as follows:

My favorite color is {{ fav_color }}

Notice that if your variable is the first element (or only element) in the line, then using quotes is mandatory as follows:

"{{ fav_color }} is my favorite color."

Now let’s write a playbook named variables-playbook.yml that puts all this together:

[elliot@control plays]$ cat variables-playbook.yml 
---
- name: Working with variables
  hosts: node1
  vars:
    fav_color: yellow
  tasks:
    - name: Show me fav_color value
      debug:
        msg: My favorite color is {{ fav_color }}.

I have used the debug module along with the msg module option to print the value of the fav_color variable.

Now run the playbook and you shall see your favorite color displayed as follows:

[elliot@control plays]$ ansible-playbook variables-playbook.yml 

PLAY [Working with variables] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Show me fav_color value] *************************************************
ok: [node1] => {
    "msg": "My favorite color is yellow."
}

PLAY RECAP *********************************************************************
node1                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Creating lists and dictionaries

You can also use lists and dictionaries to define multivalued variables. For example, you may define a list named port_nums and set its value as follows:

  vars:
    port_nums: [21,22,23,25,80,443]

You could have also used the following way to define port_nums which is equivalent:

vars:
    port_nums:
      - 21
      - 22
      - 23
      - 25
      - 80
      - 443

You can print all the values in port_nums as follows:

All the ports {{ port_nums }}

You can also access a specific list element:

First port is {{ port_nums[0] }}

Notice that you use an index (position) to access list elements.

You can also define a dictionary named users as follows:

vars:
    users:
      bob:
        username: bob
        uid: 1122
        shell: /bin/bash
      lisa:
        username: lisa
        uid: 2233
        shell: /bin/sh

There are two different ways you can use to access dictionary elements:

• dict_name['key'] -> users['bob']['shell']
• dict_name.key -> users.bob.shell

Notice that you use a key to access dictionary elements.

Now you can edit the variables-playbook.yml playbook to show lists and dictionaries in action:

[elliot@control plays]$ cat variables-playbook.yml 
---
- name: Working with variables
  hosts: node1
  vars:
    port_nums: [21,22,23,25,80,443]
 
    users: 
      bob:
        username: bob
        uid: 1122
        shell: /bin/bash
      lisa:
        username: lisa
        uid: 2233
        shell: /bin/sh
  tasks:
    - name: Show 2nd item in port_nums
      debug:
        msg: SSH port is {{ port_nums[1] }}

    - name: Show the uid of bob
      debug:
        msg: UID of bob is {{ users.bob.uid }}

You can now run the playbook to display the second element in port_nums and show bob’s uid:

[elliot@control plays]$ ansible-playbook variables-playbook.yml 

PLAY [Working with variables] **************************************************

TASK [Show 2nd item in port_nums] **********************************************
ok: [node1] => {
    "msg": "SSH port is 22"
}

TASK [Show the uid of bob] *****************************************************
ok: [node1] => {
    "msg": "UID of bob is 1122"
}

Including external variables

Just like you can import (or include) tasks in a playbook. You can do the same thing with variables as well. That is, in a playbook, you can include variables defined in an external file.

To demonstrate, let’s create a file named myvars.yml that contains our port_nums list and users dictionary:

[elliot@control plays]$ cat myvars.yml 
---
port_nums: [21,22,23,25,80,443]

users:
  bob:
    username: bob
    uid: 1122
    shell: /bin/bash
  lisa:
    username: lisa
    uid: 2233
    shell: /bin/sh

Now you can use the vars_files keyword in your variables-playbook.yml to include the variables in myvars.yml as follows:

[elliot@control plays]$ cat variables-playbook.yml 
---
- name: Working with variables
  hosts: node1
  vars_files: myvars.yml
  tasks:
    - name: Show 2nd item in port_nums
      debug:
        msg: SSH port is {{ port_nums[1] }}

    - name: Show the uid of bob
      debug:
        msg: UID of bob is {{ users.bob.uid }}

Keep in mind that vars_files preprocesses and load the variables right at the start of the playbook. You can also use the include_vars module to dynamically load your variables in your playbook:

[elliot@control plays]$ cat variables-playbook.yml 
---
- name: Working with variables
  hosts: node1
  tasks:
    - name: Load the variables
      include_vars: myvars.yml

    - name: Show 2nd item in port_nums
      debug:
        msg: SSH port is {{ port_nums[1] }}

Getting user input

You can use the vars_prompt keyword to prompt the user to set a variable’s value at runtime.

For example, the following greet.yml playbook asks the running user to enter his name and then displays a personalized greeting message:

[elliot@control plays]$ cat greet.yml 
---
- name: Greet the user
  hosts: node1
  vars_prompt:
     - name: username
       prompt: What's your name?
       private: no

  tasks:
    - name: Greet the user
      debug:
        msg: Hello {{ username }}

Notice I used private: no so that you can see your input on the screen as you type it; by default, it’s hidden.

Now run the playbook and enter your name:

[elliot@control plays]$ ansible-playbook greet.yml 
What's your name?: Elliot

PLAY [Greet the user] **********************************************************

TASK [Greet the user] **********************************************************
ok: [node1] => {
    "msg": "Hello Elliot"
}

Setting host and group variables

You can set variables that are specific to your managed hosts. By doing so, you can create much more efficient playbooks as you don’t need to write repeated tasks for different nodes or groups.

To demonstrate, edit your inventory file so that your managed nodes are grouped in the following three groups:

[elliot@control plays]$ cat myhosts 
[proxy]
node1

[webservers]
node2
node3

[dbservers]
node4

Now to create variables that are specific to your managed nodes; first, you need to create a directory named host_vars. Then inside host_vars, you can create variables files with filenames that corresponds to your node hostnames:

[elliot@control plays]$ mkdir host_vars
[elliot@control plays]$ echo "message: I am a Proxy Server" >> host_vars/node1.yml
[elliot@control plays]$ echo "message: I am a Web Server" >> host_vars/node2.yml
[elliot@control plays]$ echo "message: I am a Web Server" >> host_vars/node3.yml
[elliot@control plays]$ echo "message: I am a Database Server" >> host_vars/node4.yml

Now let’s create a playbook named motd.yml that demonstrates how host_vars work:

[elliot@control plays]$ cat motd.yml 
---
- name: Set motd on all nodes
  hosts: all
  tasks:
    - name: Set motd = value of message variable.
      copy: 
        content: "{{ message }}"
        dest: /etc/motd

I used the copy module to copy the contents of the message variable onto the /etc/motd file on all nodes. Now after running the playbook; you should see that the contents of /etc/motd has been updated on all nodes with the corresponding message value:

[elliot@control plays]$ ansible all -m command -a "cat /etc/motd"
node1 | CHANGED | rc=0 >>
I am a Proxy Server
node2 | CHANGED | rc=0 >>
I am a Web Server
node3 | CHANGED | rc=0 >>
I am a Web Server
node4 | CHANGED | rc=0 >>
I am a Database Server

Awesome! Similarly, you can use create a group_vars directory and then include all group related variables in a filename that corresponds to the group name as follows:

[elliot@control plays]$ mkdir group_vars
[elliot@control plays]$ echo "pkg: squid" >> group_vars/proxy
[elliot@control plays]$ echo "pkg: httpd" >> group_vars/webservers
[elliot@control plays]$ echo "pkg: mariadb-server" >> group_vars/dbservers

I will let you create a playbook that runs on all nodes; each node will install the package that is set in the node’s corresponding group pkg variable.

Understanding variable precedence

As you have seen so far; Ansible variables can be set at different scopes (or levels).

If the same variable is set at different levels; the most specific level gets precedence.  For example, a variable that is set on a play level takes precedence over the same variable set on a host level (host_vars).

Furthermore, a variable that is set on the command line using the --extra-vars takes the highest precedence, that is, it will overwrite anything else.

To demonstrate, let’s create a playbook named variable-precedence.yml that contains the following content:

[elliot@control plays]$ cat variable-precedence.yml 
---
- name: Understanding Variable Precedence
  hosts: node1
  vars:
    fav_distro: "Ubuntu"
  tasks:
    - name: Show value of fav_distro
      debug:
        msg: Favorite distro is {{ fav_distro }}

Now let’s run the playbook while using the -e (--extra-vars) option to set the value of the fav_distro variable to“CentOS” from the command line:

[elliot@control plays]$ ansible-playbook variable-precedence.yml -e "fav_distro=CentOS"

PLAY [Understanding Variable Precedence] ***************************************

TASK [Show value of fav_distro] ************************************************
ok: [node1] => {
    "msg": "Favorite distro is CentOS"
}

Notice how the command line’s fav_distro value “CentOS” took precedence over the play’s fav_distro value “Ubuntu”.

Part 2: Gathering and showing facts

You can retrieve or discover variables that contain information about your managed hosts. These variables are called facts and Ansible uses the setup module to gather these facts. The IP address on one of your managed nodes is an example of a fact.

You can run the following ad-hoc command to gather and show all the facts on node1:

[elliot@control plays]$ ansible node1 -m setup

Here's the output:

node1 | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "10.0.0.5"
        ],
        "ansible_all_ipv6_addresses": [
            "fe80::20d:3aff:fe0c:54aa"
        ],
        "ansible_apparmor": {
            "status": "disabled"
        },
        "ansible_architecture": "x86_64",
        "ansible_bios_date": "06/02/2017",
        "ansible_bios_version": "090007",
        "ansible_cmdline": {
            "BOOT_IMAGE": "(hd0,gpt1)/vmlinuz-4.18.0-193.6.3.el8_2.x86_64",
            "console": "ttyS0,115200n8",
            "earlyprintk": "ttyS0,115200",
            "ro": true,
            "root": "UUID=6785aa9a-3d19-43ba-a189-f73916b0c827",
            "rootdelay": "300",
            "scsi_mod.use_blk_mq": "y"
        },
        "ansible_default_ipv4": {
            "address": "10.0.0.5",
            "alias": "eth0",
            "broadcast": "10.0.0.255",
            "gateway": "10.0.0.1",
            "interface": "eth0",
            "macaddress": "00:0d:3a:0c:54:aa",

This is only a fraction of all the facts related to node1 that you are going to see displayed on your terminal. Notice how the facts are stored in dictionaries or lists and they all belong to the ansible_facts dictionary.

By default, the setup module is automatically called by playbooks to do the facts discovery. You may have noticed that facts discovery happens right at the start when you run any of your playbooks:

[elliot@control plays]$ ansible-playbook motd.yml 

PLAY [Set motd on all nodes] ***************************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node3]
ok: [node2]
ok: [node1]

You can turn off facts gathering by setting gather_facts boolean to false right in your play header as follows:

[elliot@control plays]$ cat motd.yml 
---
- name: Set motd on all nodes
  gather_facts: false 
  hosts: all
  tasks:
    - name: Set motd = value of message variable.
      copy: 
        content: "{{ message }}"
        dest: /etc/motd

If you run the motd.yaml playbook again; it will skip facts gathering:

[elliot@control plays]$ ansible-playbook motd.yml 

PLAY [Set motd on all nodes] ***************************************************

TASK [Set motd = value of message variable.] ********************************

The same way you show a variable’s value; you can also use to show a fact’s value. The following show-facts.yml playbook displays the value of few facts on node1:

[elliot@control plays]$ cat show-facts.yml 
---
- name: show some facts
  hosts: node1
  tasks:
    - name: display node1 ipv4 address
      debug:
        msg: IPv4 address is {{ ansible_facts.default_ipv4.address }}

    - name: display node1 fqdn
      debug:
        msg: FQDN is {{ ansible_facts.fqdn }} 

    - name: display node1 OS distribution
      debug:
        msg: OS Distro is {{ ansible_facts.distribution }}

Now run the playbook to display the facts values:

[elliot@control plays]$ ansible-playbook show-facts.yml 

PLAY [show some facts] ******

TASK [Gathering Facts] *******
ok: [node1]

TASK [display node1 ipv4 address] *******
ok: [node1] => {
    "msg": "IPv4 address is 10.0.0.5"
}

TASK [display node1 fqdn] ********
ok: [node1] => {
    "msg": "FQDN is node1.linuxhandbook.local"
}

TASK [display node1 OS distribution] ******
ok: [node1] => {
    "msg": "OS Distro is CentOS"
}

PLAY RECAP **********
node1          : ok=4    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Creating customs facts

You may want to create your own custom facts. To do this, you can either use the set_fact module to add temporarily facts or the /etc/ansible/facts.d directory to add permanent facts on your managed nodes.

I am going to show you how to add permanent facts to your managed nodes. It’s a three steps process:

1. Create a facts file on your control node.
2. Create the /etc/ansible/facts.d directory on your managed node(s).
3. Copy your facts file (step 1) from the control node to your managed node(s).

So, first, let’s create a cool.fact file on your control node that includes some cool facts:

[elliot@control plays]$ cat cool.fact 
[fun]
kiwi=fruit
matrix=movie
octupus='8 legs'

Notice that your facts filename must have the .fact extension.

For the second step, you are going to use the file module to create and the /etc/ansible/facts.d directory on the managed node(s). And lastly for the third step, you are going to use the copy module to copy cool.fact file from the control node to the managed node(s).

The following custom-facts.yml playbook combines step 2 and 3:

[elliot@control plays]$ cat custom-facts.yml 
---
- name: Adding custom facts to node1
  hosts: node1
  tasks:
    - name: Create the facts.d directory
      file:
        path: /etc/ansible/facts.d
        owner: elliot
        mode: 775
        state: directory
        
    - name: Copy cool.fact to the facts.d directory
      copy:
        src: cool.fact
        dest: /etc/ansible/facts.d

Now run the playbook:

[elliot@control plays]$ ansible-playbook custom-facts.yml 

PLAY [Adding custom facts to node1] **********************************

TASK [Gathering Facts] ****************************
ok: [node1]

TASK [Create the facts.d directory] ******************************
changed: [node1]

TASK [Copy cool.fact to the facts.d directory] **********************
changed: [node1]

The cool facts are now permanently part of node1 facts; you can verify with the following ad hoc command:

[elliot@control plays]$ ansible node1 -m setup -a "filter=ansible_local"

"ansible_local": {
            "cool": {
                "fun": {
                    "kiwi": "fruit",
                    "matrix": "movie",
                    "octupus": "'8 legs'"
                }
            }
        }

You can now display the octopus’s fact in a playbook as follows:

An octopus has {{ ansible_local.cool.fun.octupus }}

Part 3: Capturing output with registers in Ansible

Some tasks will not show any output when running a playbook. For instance, running commands on your managed nodes using the command, shell, or raw modules will not display any output when running a playbook.

You can use a register to capture the output of a task and save it to a variable. This allows you to make use of a task output elsewhere in a playbook by simply addressing the registered variable.

The following register-playbook.yml shows you how to capture a task output in a registered variable and later display its content:

[elliot@control plays]$ cat register-playbook.yml 
--- 
- name: Register Playbook
  hosts: proxy
  tasks:
    - name: Run a command
      command: uptime
      register: server_uptime

    - name: Inspect the server_uptime variable
      debug:
        var: server_uptime

    - name: Show the server uptime
      debug:
        msg: "{{ server_uptime.stdout }}"

The playbook starts by running the uptime command on the proxy group hosts (node1) and registers the command output in the server_uptime variable.

Then, you use the debug module along with the var module option to inspect the server_uptime variable. Notice, that you don’t need to surround the variable with curly brackets here.

Finally, the last task in the playbook shows the output (stdout) of the registered variable server_uptime.

Run the playbook to see all this in action:

[elliot@control plays]$ ansible-playbook register-playbook.yml 

PLAY [Register Playbook Showcase] **********************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Run a command] ***********************************************************
changed: [node1]

TASK [Inspect the server_uptime variable] **************************************
ok: [node1] => {
    "server_uptime": {
        "changed": true,
        "cmd": [
            "uptime"
        ],
        "delta": "0:00:00.004221",
        "end": "2020-10-29 05:04:36.646712",
        "failed": false,
        "rc": 0,
        "start": "2020-10-29 05:04:36.642491",
        "stderr": "",
        "stderr_lines": [],
        "stdout": " 05:04:36 up 3 days,  6:56,  1 user,  load average: 0.24, 0.07, 0.02",
        "stdout_lines": [
            " 05:04:36 up 3 days,  6:56,  1 user,  load average: 0.24, 0.07, 0.02"
        ]
    }
}

TASK [Show the server uptime] **************************************************
ok: [node1] => {
    "msg": " 05:04:36 up 3 days,  6:56,  1 user,  load average: 0.24, 0.07, 0.02"
}

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Notice how the registered variable server_uptime is actually a dictionary that contains a lot of other keys beside the stdout key. It also contains other keys like rc (return code), start (time when command run), end (time when command finished), stderr (any errors), etc.

Alright! This takes us to the end of this tutorial. Stay tuned for next tutorial as you are going to learn to use loops in Ansible.