Before we delve into the topics in detail, you will need to set a few things up. Let’s look at what they are.

Setting up GitHub access

You will need a free GitHub account in order to access some of the code that will be provided throughout this book. Please sign up for a free account at https://github.com/. We will be utilizing the code found in the following repository throughout the course of this book: https://github.com/PacktPublishing/Red-Hat-Certified-Specialist-in-Services-Management-and-Automation-EX358-. We will be utilizing the code snippets found in the ch1 folder of this code repository (aka repo) for our iSCSI automation hands-on exercises, which can be found here: https://github.com/PacktPublishing/Red-Hat-Certified-Specialist-in-Services-Management-and-Automation-EX358-Exam-Guide/tree/main/Chapter01. The code placed here will allow you to check your work and ensure you are on the right track when writing your playbooks within Ansible. Please keep in mind these are one person’s way of writing tested playbooks that will meet the exam objectives; however, there are many ways of writing successful playbooks to meet these objectives.

Setting up your lab environment

All of the demonstrations of VirtualBox and coding will be shown on macOS but can be performed on Windows as well as Linux OSs. We will be setting up some iSCSI block devices. First, you will need a machine that can run VirtualBox with enough memory to run your machine and three VMs that each have 2 GB of memory, one 10 GB hard drive, and one 5 GB hard drive, which equals 15 GB of required hard drive space per VM, as can be seen in the following screenshot:

Figure 1.1 – Layout of the VirtualBox deployment

This is mainly for the storage hands-on labs, and you can revert to one 10 GB hard drive for exercises. RHEL 8.1 requires at least 9.37 GB of space to run. Using a Red Hat Developer account (https://developers.redhat.com/), you can access real Red Hat software to develop your skills as well as the software in order to set this up:

Figure 1.2 – Signup is simple!

Because the exam is set for RHEL 8.1, I recommend using this version for your studying needs in order to get the most authentic exam-like infrastructure possible. In the following screenshot, the correct version you should download is the first option:

Figure 1.3 – The correct version for the exam and for you

This will be true for the entirety of the book, including the comprehensive review and lab at the end. Before installing the OS, you can create a second hard drive in VirtualBox from the settings, as can be seen in the following screenshot:

Figure 1.4 – Creating a second hard drive for your VM

You also need to ensure that you choose Bridged Adapter mode for your network Attached to option. The Promiscuous Mode option is also allowed so that it can reach the internet and other adapters. One caveat to keep in mind is that bridged-over Wi-Fi does not always play nice, so try to ensure you have a wired connection if you are setting up your lab in this manner:

Figure 1.5 – Bridged adapter with Promiscuous Mode option

From here, you can then mount the downloaded ISO and kick off the installation:

Figure 1.6 – Mounting RHEL DVD ISO that was downloaded previously

There are some best practices you need to keep in mind. We will be installing the Server with the GUI option. Make sure to create yourself an administrator account as well as keeping your root account as you will want to do everything as sudo and not directly as root for security purposes and all-around good habits. The user creation screen, as follows, allows you to set up your root password and any users you would like to create:

Figure 1.7 – Administrator accounts are best practices; sudo over root is always preferred

Next, you will need to use the login for your Red Hat Developer account and license the VMs using the account credentials. See the following screenshot for how to correctly apply a Red Hat subscription license:

Figure 1.8 – Red Hat Developer credentials or an active Red Hat account needed

You can create one machine and then clone it into the other two you need. Make sure you choose to generate new MAC addresses and to make a full clone to ensure that no overlap causes network or storage issues, as shown in the following screenshot:

Figure 1.9 – Full clones with new MAC generation and a new name for the VM

Next, we will set up the host file with the domain of example.com in order to route correctly to and from the different systems. You will need to do the following on the servers in a command line to get your IP addresses and then go to each device and set up the host file with the same information:

Figure 1.10 – Hostname and IP of rhel1.example.com system

Next, let’s gather the hostnames or change them to what you would like them to be using the following commands and review the output in this case, which is rhel1.example.com:

[emcleroy@rhel1 ~]$ sudo hostnamectl set-hostname rhel1.example.com
[emcleroy@rhel1 ~]$ hostname
 rhel1.example.com

Use the hostnames and the IP addresses to build the inventory for the host file. After you do this, make sure that you shut down the system for it to save the changes permanently. Next, you’re going to want to add these as noted to the host file on all three VMs using the following command:

$ sudo vi /etc/hosts

Here is an example of the completed /etc/hosts file:

Figure 1.11 – Finished /etc/hosts file

Keep in mind your /etc/hosts file will look different based on your IPs. You should now be able to ping via the hostname and IP of all of the different VMs from one to another:

Figure 1.12 – Example of working networking environment

Next, for ease of use, let’s set up passwordless sudo for our user account, which in my case would be emcleroy.

We will start by running the following command:

$ sudo visudo

Next, we will locate the lines of code highlighted in the following screenshot and add the highlighted lines of text. Also, note that if you are allowing administrators, you can simply uncomment # in front of the %wheel line as well:

Figure 1.13 – Highlighted lines of text to be added, substituting your username for mine

You will need to do this for all three of the servers.

Finally, we will add SSH keys across the servers to allow for fast connectivity so that we do not have to type passwords every time we need to log in from one server to another. Start by generating SSH keys with the following command on your rhel1 VM:

$ ssh-keygen

Just leave the defaults and keep hitting Enter, and then once that is generated, you will want to do the following:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub username@server

This will push the keys to the servers and allow all the servers to talk bi-directionally. You will want to do that for all three servers, so you will do the following (including for the server you are currently on to ensure that the keys are pushed to the known host file for all of the servers):

$ ssh-copy-id -i ~/.ssh/id_rsa.pub emcleroy@rhel1
$ ssh-copy-id -i ~/.ssh/id_rsa.pub emcleroy@rhel2
$ ssh-copy-id -i ~/.ssh/id_rsa.pub emcleroy@rhel3

From here, you have full access to a three-VM lab running RHEL 8.1 with secondary HDDs for use with this iSCSI hands-on exercise. The only minor differences will come up in the networking hands-on labs where we will go over adding additional network interface controllers (NICs) for network teaming. This will be another topic that you need to understand in order to ace the EX358 exam.

Congratulations! You have now successfully set up your lab environment. Pat yourself on the back and take a break. We will now be talking about the manual steps to build out iSCSI block devices and use them. This will be followed by putting that lab environment you just built to the test and getting hands-on experience with the technology.

There are a number of things you need to know about block storage and, in this case, iSCSI. It is a storage area network (SAN) protocol that allows for devices or parts of devices to be seen as block storage by an end device. SAN is how iSCSI connects to the network and gives the ability to provide network logical unit numbers (LUNs). This allows systems to use these block devices as if they were physical hard drives in the system that they can boot from, save files to, or use like any hard drive that you have in your normal computer. With this in mind, we have to take a few things into account.

First, you have to ensure that your network can handle the connectivity without congestion as this will cause your systems to slow down and possibly lag behind what you are doing, causing users to become frustrated. Knowing this, you have to plan out your SAN extremely well and properly network out your block storage onto a normally non-encrypted network setup that meets the minimum speeds of 10 GB but can go much higher in a lot of cases. This allows smooth usage of your storage without the headaches you will run into as a system administrator. If you were to put this on the same network as your LAN traffic and expect your streaming (don’t do this while at work!) users are watching videos while trying to also do their jobs from a machine that is hosted from a SAN iSCSI block storage device. Other things to keep in mind are you need to ensure proper firewalld syntax is utilized and SELinux protocols are followed to allow connectivity at startup or you will have a giant paperweight without much happening.

There are some main items you have to take into account when you are looking at iSCSI using targetcli, and I will get to more details about targetcli as that is the toolset we will utilize to allow us to use iSCSI in our RHEL 8.1 environment. The main things you need to know are the initiator, target, Portal, LUN, Access Control List (ACL), and Target Portal Group (TPG). These items make up iSCSI storage and lead to a lot of misconceptions. Let’s test your knowledge before we dig deeper into the systems and how they work together to provide block storage over the network to remote servers.

Testing your knowledge

Answer the following questions:

1. What is an iSCSI storage source on an iSCSI server?
   1. Target
   2. LUN
   3. iSCSI Qualified Name (IQN)
   4. ACL
2. What is a unique worldwide name used to identify both initiators and targets?
   1. Target
   2. LUN
   3. IQN
   4. ACL
3. An iSCSI client that is typically software-based is known as a:
   1. TPG
   2. Portal
   3. IQN
   4. Initiator
4. Which of the following is an access restriction using the IQN?
   1. Target
   2. LUN
   3. IQN
   4. ACL
5. What is the most commonly used software for setting up RHEL 8.1 iSCSI block storage?
   1. firewalld
   2. SELinux
   3. targetcli
   4. networkd
6. Which service or port do you need to allow for iSCSI to work through your firewall?
   1. iSCSI-target
   2. 3260/UDP
   3. iSCSI
   4. targetcli
7. What includes the named item 2020-06.com.mcleroy.www?
   1. Target
   2. LUN
   3. IQN
   4. ACL
8. Which system do you need to enable to ensure iSCSI will start at boot?
   1. firewalld
   2. Target
   3. targetcli
   4. networkd

Answers:

1. A. Target
2. C. IQN
3. D. Initiator
4. D. ACL
5. C. targetcli
6. A.iSCSI-target
7. C. IQN
8. B. Target

We will start by installing targetcli and using that to set up iSCSI to provide block-based storage to other systems for file usage, boot systems, and so on. This will showcase the wide range of uses that come with iSCSI block storage implemented with RHEL 8.1. We will then show how to decommission the storage device and clean up the systems after utilizing the resources.

First, we will install targetcli in order to utilize the iSCSI systems on rhel1:

$ sudo dnf install targetcli -y

We will follow that by enabling the system to start up the iSCSI block storage. When the system boots or has an issue that causes the target system to need to restart, it will reload the service in order to keep the storage up and operational:

$ sudo systemctl enable target

After that, we will allow iscsi-initiator through firewalld in order to ensure that the other servers are able to access the block storage without issue. We will also reload the firewall, or the opening you just made will not be there:

$ sudo firewall-cmd --permanent --add-service=iscsi-target
$ sudo firewall-cmd –reload

After that, we will be utilizing the new service we just installed—targetcli—to create network block storage in order to share it with rhel2.example.com:

Figure 1.14 – targetcli initiated for the first time

We will now create backstores for the physical disk partitioning. We will be creating backstores of the type block in order to meet the needs of the iSCSI system today. This will allow the persistent filesystems and us to set up how we would like the LUNs to be in terms of size and security:

/> cd /backstores/block
/backstores/block> create blockstorage1 /dev/sdb
Created block storage object blockstorage1 using /dev/sdb.

Next, we will create an IQN in the /iscsi directory in order to provide a target and destination for the block storage device:

/backstores/block> cd /iscsi
/iscsi> create iqn.2022-05.com.example:rhel1
Created target iqn.2022-05.com.example:rhel1.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
/iscsi> ls
o- iscsi ..................................... [Targets: 1]
  o- iqn.2022-05.com.example:rhel1 .............. [TPGs: 1]
    o- tpg1 ........................ [no-gen-acls, no-auth]
      o- acls ................................... [ACLs: 0]
      o- luns ................................... [LUNs: 0]
      o- portals ............................. [Portals: 1]
        o- 0.0.0.0:3260 .............................. [OK]

As you can see in the preceding code snippet, a default portal was created on port 3260 for connectivity to the block storage backstores using the create command for the IQN. Next, we will create a LUN for physically supporting the storage needs of the iSCSI block storage:

/iscsi> cd /iscsi/iqn.2022-05.com.example:rhel1/tpg1/luns
/iscsi/iqn.20…sk1/tpg1/luns> create  /backstores/block/blockstorage1
Created LUN 0.

The next thing we need for iSCSI is an ACL to allow traffic to reach our storage devices successfully. We will need to exit out of targetcli temporarily to view the Red Hat name for the initiator’s IQN. It can be found in /etc/iscsi/initiatorname.iscsi:

Global pref auto_save_on_exit=true
Configuration saved to /etc/
[emcleroy@rhel1 ~]$ vi /etc/iscsi/initiatorname.iscsi

Here is an example of the initiator name that is currently being used on the next image:

Figure 1.15 – initiatorname.iscsi

We will go back into targetcli and finish up the system preparations, setting up the system to use an ACL of our choosing for the system that will be utilizing the block storage:

[emcleroy@rhel1 ~]$ sudo targetcli
targetcli shell version 2.1.53
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
> cd /iscsi/iqn.2022-05.com.example:rhel1/tpg1/acls
/iscsi/iqn.20...sk1/tpg1/acls> create iqn.2022-05.com.example:rhel2
Created Node ACL for iqn.2022-05.com.example:rhel2
Created mapped LUN 0.

Next, we will remove the default portal and create one on the specific IP address of our server:

> cd /iscsi/iqn.2022-05.com.example:rhel1/tpg1/portals
/iscsi/iqn.20.../tpg1/portals> delete 0.0.0.0 3260
Deleted network portal 0.0.0.0:3260
/iscsi/iqn.20.../tpg1/portals> create 192.168.1.198 3260
Using default IP port 3260
Created network portal 192.168.1.198:3260.

Finally, the following is your completed block storage target:

Figure 1.16 – iSCSI block storage target

We have just shown how to provision iSCSI block storage for consumption. Now, we will showcase how to utilize that block storage for actual usage in your systems. We will connect from rhel1.example.com to rhel2.example.com and mount it, provision it, and utilize it to move and store files, as one of the examples of how we can use these systems is to increase the storage capacity of remote servers without needing to increase space, power, or cooling directly for the rack the server is housed within.

The first thing we will need to do is install the iSCSI utilities, as on the exam you may not have the installation of the Server with the GUI:

$ sudo dnf install iscsi-initiator-utils targetcli -y

This allows us to ingest the iSCSI block storage that we created previously. Next, we are going to look up the configured target on rhel1 (192.168.1.198) (please note: this might be a different IP for you in your lab) and log in to it to ensure connectivity. From here, we need to set the login information on the /etc/iscsi/iscsid.conf file in order to pass the correct login information so that we can log in to the storage device:

$ sudo getent hosts rhel1

Now, we will set the InitiatorName field so that we can pass a known entry to the connecting server using the following commands:

[emcleroy@rhel1 ~]$ sudo vi /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.2022-05.com.example:rhel1
[emcleroy@rhel1 ~]$ sudo systemctl restart iscsid.service

Please note you can use the manual page to gain further insight into the iscsiadm command set with the man iscsiadm command. On rhel2, we will do a discovery of available block devices using the iscsiadm command. The –m flag specifies the mode—in this case, discovery. The –t flag specifies the type of target—in our case, st, which is sendtargets, which tells the server to send a list of iSCSI targets. The –p flag specifies which portal to use, which is a combination of IP address and port. If no port is passed, it will default to 3260:

[emcleroy@rhel2 ~]$ sudo iscsiadm -m discovery -t st -p 192.168.1.198:3260

Please note the output from the preceding command will be as follows:

 192.168.1.198:3260,1 iqn.2022-05.com.example:rhel1

As you can see here, we have a block device that is showing as available.

We will try to log in to the device, and you can see we have logged in and it is showing the device connected, as follows:

[emcleroy@rhel2 ~]$ sudo iscsiadm -m node -T iqn.2022-05.com.example:rhel1  -p 192.168.1.198 -l

In the preceding code, we are using the –m flag to choose node mode. We are using the –T flag to specify the target name. We are again using the –p flag for the portal, which defaults to port 3260. Finally, we are using the –l flag to tell iscsiadm to log in to the target.

Next, we are going to use the –m mode flag to check the session and –P to print the information level of 3:

[emcleroy@rhel2 ~]$ sudo iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 6.2.1.4-1
Target: iqn.2022-05.com.example:rhel1 (non-flash)
     Current Portal: 192.168.1.198:3260,1
     Persistent Portal: 192.168.1.198:3260,1

You can see that we have sdb, which is the second drive on rhel2, and now we have sdc as well:

Figure 1.17 – sdc drive is now showing up

Next, we are going to partition the drive and format it with xfs. This will allow us to mount the system on boot as well as to save persistent files. This can be used for many things from file storage to OS or databases. First, we are going to format the drive to xfs:

[emcleroy@rhel2 ~]$ sudo mkfs.xfs /dev/sdc
meta-data=/dev/sdc               isize=512    agcount=4, agsize=327680 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=1310720, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Then, we are going to use the following command to get the UUID to use in fstab to make it a persistent mount that will automatically mount at startup:

[emcleroy@rhel2 ~]$ lsblk -f /dev/sdc
NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sdc  xfs          38505868-00de-4269-88d8-3357a22f2101
[emcleroy@rhel2 ~]$ sudo vi /etc/fstab

Here, we can see an example of the added value highlighted in fstab:

Figure 1.18 – Updated fstab after adding the iSCSI block storage device

Here are the lines where we added the new iSCSI drive to fstab. Please note that for network devices, we pass the _netdev option. Next, we are going to mount the system in order to use it for moving files around:

[emcleroy@rhel2 ~]$ sudo mkdir -p /data
[emcleroy@rhel2 ~]$ sudo mount /data
[emcleroy@rhel2 ~]$ df /data
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/sdc         5232640 69616   5163024   2% /home/emcleroy/data
[emcleroy@rhel2 ~]$ cd /data

After it is mounted, we are going to move into the new drive, create a folder and a test .txt file, and ensure it saves, which it does by using the following commands:

[emcleroy@rhel2 ~]$ sudo mkdir test
[emcleroy@rhel2 ~]$ cd test/
[emcleroy@rhel2 ~]$ sudo vi test.txt

Next, we are going to remove the mount, log out of the connection, and delete the leftovers:

[emcleroy@rhel2 ~]$ cd
[emcleroy@rhel2 ~]$ sudo umount /data
[emcleroy@rhel2 ~]$ sudo iscsiadm -m node -T iqn.2022-05.com.example:rhel1 -p 192.168.1.198 -u
Logging out of session [sid: 8, target: iqn.2022-05.com.example:rhel1, portal: 192.168.1.198,3260]
Logout of [sid: 8, target: iqn.2022-05.com.example:rhel1, portal: 192.168.1.198,3260] successful.
[emcleroy@rhel2 ~]$ sudo iscsiadm -m node -T iqn.2022-05.com.example:rhel1 -p 192.168.1.198 -o delete

This wraps up the section on manually setting up iSCSI. Next is automating it. We will go into more detail in the hands-on review and the quiz at the end of the book. I hope you are enjoying this journey as much as I am.

We will start the automation portion of working with iSCSI block storage by first installing and configuring the use of Ansible core 2.9 as that is what is used in the EX358 exam. I will not be using the fully qualified collection name (FQCN) as that can sometimes cause errors in a 2.9 environment, which could lead to issues while taking the exam. This we want to avoid at all costs, so we will be using the classic module names, and I will explain the differences to a degree so that you can understand what you will need to use in future versions of Ansible.

First, let’s start by installing Ansible 2.9 on server rhel3 as that is going to be what we consider the workstation server from our yum repository. Depending on your personal preferences, you can make rhel1 your classroom server and rhel2 and rhel3 your test servers, but in our case, we have already set up rhel1 with iSCSI and rhel2.

First, we will enable the needed repos:

[emcleroy@rhel3 ~]$ sudo subscription-manager repos --enable ansible-2.9-for-rhel-8-x86_64-rpms
Repository 'ansible-2.9-for-rhel-8-x86_64-rpms' is enabled for this system.

Next, we will install Python 3:

[emcleroy@rhel3 ~]$ sudo dnf install python3 -y

Then, we will install Ansible 2.9:

[emcleroy@rhel3 ~]$ sudo dnf install ansible -y

Let’s check and ensure that the right version of Ansible is installed:

[emcleroy@rhel3 ~]$ ansible --version
ansible 2.9.27
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/emcleroy/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Oct 11 2019, 15:04:54) [GCC 8.3.1 20190507 (Red Hat 8.3.1-4)]

Next, we are going to start writing a playbook using the Yet Another Markup Language (YAML) Ansible language. This is a simple module-based function that will allow you to write up a playbook that will accomplish your task quickly and efficiently. I recommend a good editor when writing up these playbooks. JetBrains' PyCharm is my go-to and is what you will see me write my playbooks in when you see example screenshots of the finished results. Do also note that the finished playbooks can be found in the GitHub repository of this book, as mentioned in the Technical requirements section for each chapter.

The first thing you will want to create is a directory where you want to run the playbooks from:

[emcleroy@rhel3 ~]$ mkdir iscsi_mount

Once in the directory, we will create an inventory file with a default group that will have both the rhel1 and rhel2 servers in them:

[emcleroy@rhel3 ~]$ cd iscsi_mount
[emcleroy@rhel3 ~]$ vi inventory
[defaults]
rhel1 ansible_host=192.168.1.198
rhel2 ansible_host=192.168.1.133
[iscsi_block]
rhel1 ansible_host=192.168.1.198
[iscsi_user]
rhel2 ansible_host=192.168.1.133

As you can see, I added ansible_host and the IP address. This is in case there is no host file set up or the name is not DNS routable. I added the default group with all of the hosts, and there are two additional groups that allow me to limit what my playbooks make changes to. That way, I can tell my playbook to mount the storage on rhel2 using the iscsi_user group.

Next, we are going to write the block storage playbook named mount_iscsi.yml, and I will break it down after showing you what that playbook looks like:

---
- name: Ensure /data is mounted from rhel1 iSCSI target that was created manually onto rhel2
  hosts: iscsi_user
  become: true
  become_method: sudo
  tasks:
    - name: the targetcli package is installed
      yum:
        name: targetcli
        state: present
    - name: the IQN is set for the initiator
      template:
        dest: /etc/iscsi/initiatorname.iscsi
        src: templates/initiatorname.iscsi.j2
        mode: '644'
        owner: root
        group: root
    - name: Create mount directory for /data
      file:
        path: /data
        state: directory
        mode: '0755'
    - name: Restart iscsiadm
      command:
        cmd: systemctl restart iscsid.service
    - name: Mount new drive
      command:
  cmd: iscsiadm -m node –T iqn.2022-05.com.example:rhel1  -p 192.168.1.198 -l

The module name for this instance is yum, and that is used to install the iscsi-initiator-utils package that will install the utilities. Next, we have the different flags of the modules, such as dest: for the destination of the source file that is in your playbook’s templates folder. In the template folder location within your playbook directory, you will have the file/templates/initiatorname.iscsi.j2, which contains the initiator name to pass to the playbook. It will contain the following code:

InitiatorName=iqn.2022-05.com.example:rhel1

You can find out more about each module that you’re using by looking at the equivalent of a man page, as follows:

[emcleroy@rhel3 ~]$ ansible-doc yum

You can also list the files with the following command, but keep in mind there are thousands of modules, so try to grep the names if possible:

[emcleroy@rhel3 ~]$ ansible-doc –-list

The following screenshot shows what a normal ansible-doc page looks like for the different modules:

Figure 1.19 – Example of the yum module documentation page

We will use the following command to run the ansible-playbook -i inventory mount_iscsi.yml -u emcleroy -k --ask-become –v playbook. This will be executed from the rhel3 server and make changes to the rhel2 server. This concludes our automated approach to mounting a LUN for iSCSI block storage. We learned a little about Ansible and how it works, from modules to templates. We will learn a lot more about Ansible and all of its inner workings in the upcoming chapters in greater detail, so stick around.

This brings us to the end of the first chapter, where we went into details about RHEL block storage, setting up a hands-on environment for testing purposes, and getting the first taste of Ansible. In the coming chapters, we will be digging deeper into how to use Ansible with further examples and more hands-on exercises that will help hone your abilities as a systems admin and help ensure you pass the EX358 exam. In the next chapter, we will be continuing our journey into network storage, talking about network file storage and how we can use that to share information across our organizations and make our jobs faster. Please join me as we continue our road to gaining the EX358 certification that you want to achieve and that I want to help you obtain.