Configure ISCSI Target and Initiator using Ansible

Meher Askri
6 min readAug 2, 2024

--

Hello and welcome again,

Today, we’ll dive into one of the most popular storage technologies that has been around for a while and is still used today, especially in enterprise and data center environments. Can you guess what it is? Yes, it’s iSCSI

We’ll talk about how to configure ISCSI initiator and target and how we can improve security using the CHAP authentication protocol . But before we start , let’s understand what is ISCSI .

What is ISCSI ?

Well in simple term , iSCSI is a way for computers to share and use hard disks over the network , means It’s like making a remote hard drive act as if it’s connected directly to your computer, even though it’s physically somewhere else. And This is helpful for sharing and managing storage resources in a enterprise environment .

Of course target which is the tool used for configuring iSCSI targets on a Linux system is no longer used in enterprise environment because typically the management and configuration of storage resources, particularly the block storage are often handled at the firmware or hardware level provided by storage solutions from companies like EMC, Dell ….

So why do we still need it ?

There are few scenarios that comes to my mind but I think the most important one is in case of emergency as a temporary solution . Because not all companies have moved to the cloud , even when they do there will be always a legacy apps running on this old infrastructure . Beside that we’re doing it using Ansible , So it’s like breathing new life into this older technology in a more modern way .

How do we do it ?

In this scenario , the ansible control node will act as a ISCSI target device and the ansible managed node will be the initiator .

I’ve already set up the ansible config file and the inventory which are the key components in ansible and also I’ve already setup the ssh keys between the target and the initiator .

Now when it comes to ansible , there are good news and bad news , the good one is that we have an ansible module to configure the initiator part , the bad one is we don’t have a module for the target part for the reason I mentioned before that storage vendors took care of that part .

But don’t worry , if we don’t have a solution , we’ll return to our origin which is bash . So to make this work, I will create a bash script , then I will incorporate this script into the ansible playbook and use the script module to execute it .

I know it seems to be complicated and challenging , but don’t worry we’ll break down this complexity step by step :

In this scenario the ansible control node will act as a ISCSI target device and the ansible managed node will be the initiator .

So, this script will install the targetcli package which the CLI utility to configure the target framework on Linux system . Of course this utility has a nice interface but we’re doing it from a script not interactive mode .

Once it’s installed , then it will create a LUN (LUN0) stands for logical unit number. A LUN is essentially a unique label that represents a specific portion of storage space.

To keep things simple in this demo, Think of a LUN as similar to a partition . ( LUNs are used in storage area network (SAN) environments on data centers when configuring RAID , long story we’ll leave it for another day ) .

After the creation of the LUN , the script create the IQN which is the unique identifier for the iSCSI device (target) and don’t ask me why is it like that because that’s the syntax 😁 :

iqn.yyyy-mm.reverse.domain:unique_name

Next the script will create the Acess list , This list is like the guest list to an exclusive party where only the IQN of the initiator ( the one granted access to this disk ) . And under the tpg1 ( target portal group ) , in portals the script will delete the default portal config auto generated because I don’t want my target to listen on all the interfaces ( I have double NICs on the servers ) and it will add the ip add of my specific interface ( 10.1.1.100/24) . Of course it’s not necessary if you have a server with one Network card , so you can remove those 3 lines from the script .

Finally , the script will set the CHAP credentials for authentication , In this case, it’s a one way authentication method, where only the initiator authenticates to the target ( which is a good way to ensure a secure connection ) .

Now, let’s move to the second part of the ansible playbook :

So the playbook has two plays : the first one will run the previous bash script and then open the firewall port to allow the connection .

The second play , contain five tasks , the first task will set the initiator IQN using the template module . Then , the second task will modify the iscsid.conf file by enabling CHAP and adding the credentials ( username + password ) using the lineinfile module , Of course I used a loop here to iterate through those items where each item is a dictionary of key value pairs ( regexp and line ) . You can separate these key value pairs into a list format if you want but as they say in french “Chacun voit midi à sa porte “ 😊 .

Moving to the third task which will restart the iscsid service because anytime we made a change to config file of a service in Linux we need to reload for the changes to take effect . And Finally the fourth task will discover the target disk and The fifth task will connect to it using the open_iscsi module ( Again you can combine them together in one task if you want ) .

And that’s it , a very simple playbook .

Before we run it , let me show you the template , the ansible config and the inventory file .

Okay , let me run this playbook and see what’s happen :

As you can see the playbook executed without errors , Please ignore the warning about the Python interpreter because I’m using ansible 2.9 , which relies on the traditional Python interpreter /usr/bin/python ( no longer used in new version) , of course I can add the deprecation_warnings=False under the default section in the ansible config file if I don’t want to see the deprecation warning . The second warning due to the missing quotes , I forget them 😁 .

let’s verify the appearance of the disk in the initiator :

Et voilà , The CHAP authentication was successfully established between the target and initiator and that’s it for today .

Thank you for reading , I hope you enjoyed it , please don’t forget to like and share if you find it helpful. and If you have any question , let me know in the comment below .

Thank you for reading and I’ll see you in the next one .

--

--

Meher Askri
Meher Askri

Written by Meher Askri

Linux System Engineer || RHCA

No responses yet