Hi,
I have been trying to determine how to get a LIO Fiber Channel SAN target (qla2xxx) to work without making ACL initiator entries for the FC fabric. I am trying to replace a legacy fiber channel disk with a LIO target solution. Unfortunately, the application is such that human interaction is not feasible when the (portable) LIO-based storage system is attached to the legacy hardware. I need the LIO target system to be a plug-and-play solution like old (and current) Fiber Channel drives. Of course the FC disk drives I am trying to replace do not have any out of band interface so they can't have ACLs on their end. This means the legacy system has no provision for accessing the new storage system beyond the fiber optic interface.
I basically need to map a backstore/LUN to a target port fabric without a particular initiator WWPN being specified. There is a comment on the LIO web site that says "If ACLs are enabled, one NodeACL is required per authorized initiator." Maybe what I need is to _disable_ ACLs? I haven't seen a method to accomplish this. None of the targetcli global parameters appear to address this.
For those who think "ignoring" the security of an ACL is somehow sinful, please understand this application is a point-to-point optical Fiber Channel storage link in a stand-alone embedded system and the initiator system has significant safeguards. It's not like this is hanging out on a big enterprise SAN somewhere (or the Internet for that matter) for all the world to hack.
I have looked through the archives and googled this. I have found a couple similar inquiries but no answers. Is this even possible with targetcli/rtslib/LIO? Maybe I'm just missing something somewhere?
Thanks for any suggestions,
Craig Watson
On 07/11/2013 03:55 PM, Craig Watson wrote:
Hi,
I have been trying to determine how to get a LIO Fiber Channel SAN target (qla2xxx) to work without making ACL initiator entries for the FC fabric. I am trying to replace a legacy fiber channel disk with a LIO target solution. Unfortunately, the application is such that human interaction is not feasible when the (portable) LIO-based storage system is attached to the legacy hardware. I need the LIO target system to be a plug-and-play solution like old (and current) Fiber Channel drives. Of course the FC disk drives I am trying to replace do not have any out of band interface so they can't have ACLs on their end. This means the legacy system has no provision for accessing the new storage system beyond the fiber optic interface.
I basically need to map a backstore/LUN to a target port fabric without a particular initiator WWPN being specified. There is a comment on the LIO web site that says "If ACLs are enabled, one NodeACL is required per authorized initiator." Maybe what I need is to _disable_ ACLs? I haven't seen a method to accomplish this. None of the targetcli global parameters appear to address this.
For those who think "ignoring" the security of an ACL is somehow sinful, please understand this application is a point-to-point optical Fiber Channel storage link in a stand-alone embedded system and the initiator system has significant safeguards. It's not like this is hanging out on a big enterprise SAN somewhere (or the Internet for that matter) for all the world to hack.
I have looked through the archives and googled this. I have found a couple similar inquiries but no answers. Is this even possible with targetcli/rtslib/LIO? Maybe I'm just missing something somewhere?
Thanks for any suggestions,
Hi Craig,
Well if you were using iscsi, it would be easy.
These commands enable "demo mode":
set attribute authentication=0 set attribute demo_mode_write_protect=0 set attribute generate_node_acls=1 set attribute cache_dynamic_acls=1
Looking through the kernel code, it looks like this feature is specific to the iscsi fabric, so there's some refactoring needed to make it applicable to all fabrics with ACLs. I'll scope it out tomorrow, and then we can bring it up on target-devel (since it's a kernel issue).
Regards -- Andy
On 07/11/2013 03:55 PM, Craig Watson wrote:
Hi,
I have been trying to determine how to get a LIO Fiber Channel SAN target (qla2xxx) to work without making ACL initiator entries for the FC fabric. I am trying to replace a legacy fiber channel disk with a LIO target solution. Unfortunately, the application is such that human interaction is not feasible when the (portable) LIO-based storage system is attached to the legacy hardware. I need the LIO target system to be a plug-and-play solution like old (and current) Fiber Channel drives. Of course the FC disk drives I am trying to replace do not have any out of band interface so they can't have ACLs on their end. This means the legacy system has no provision for accessing the new storage system beyond the fiber optic interface.
I basically need to map a backstore/LUN to a target port fabric without a particular initiator WWPN being specified. There is a comment on the LIO web site that says "If ACLs are enabled, one NodeACL is required per authorized initiator." Maybe what I need is to _disable_ ACLs? I haven't seen a method to accomplish this. None of the targetcli global parameters appear to address this.
For those who think "ignoring" the security of an ACL is somehow sinful, please understand this application is a point-to-point optical Fiber Channel storage link in a stand-alone embedded system and the initiator system has significant safeguards. It's not like this is hanging out on a big enterprise SAN somewhere (or the Internet for that matter) for all the world to hack.
I have looked through the archives and googled this. I have found a couple similar inquiries but no answers. Is this even possible with targetcli/rtslib/LIO? Maybe I'm just missing something somewhere?
Thanks for any suggestions,
Craig Watson
I looked into this some more and qla2xxx already supports demo mode. So if you do:
qla2xxx/naa.whatever/ set attribute generate_node_acls=1 qla2xxx/naa.whatever/ set attribute demo_mode_write_protect=0 qla2xxx/naa.whatever/ set attribute cache_dynamic_acls=1
then anyone should be able to connect without having to explicitly create an ACL.
HTH -- Regards -- Andy
On 07/17/2013 02:59 PM, Andy Grover wrote:
On 07/11/2013 03:55 PM, Craig Watson wrote:
Hi,
I have been trying to determine how to get a LIO Fiber Channel SAN target (qla2xxx) to work without making ACL initiator entries for the FC fabric. I am trying to replace a legacy fiber channel disk with a LIO target solution. Unfortunately, the application is such that human interaction is not feasible when the (portable) LIO-based storage system is attached to the legacy hardware. I need the LIO target system to be a plug-and-play solution like old (and current) Fiber Channel drives. Of course the FC disk drives I am trying to replace do not have any out of band interface so they can't have ACLs on their end. This means the legacy system has no provision for accessing the new storage system beyond the fiber optic interface.
I basically need to map a backstore/LUN to a target port fabric without a particular initiator WWPN being specified. There is a comment on the LIO web site that says "If ACLs are enabled, one NodeACL is required per authorized initiator." Maybe what I need is to _disable_ ACLs? I haven't seen a method to accomplish this. None of the targetcli global parameters appear to address this.
For those who think "ignoring" the security of an ACL is somehow sinful, please understand this application is a point-to-point optical Fiber Channel storage link in a stand-alone embedded system and the initiator system has significant safeguards. It's not like this is hanging out on a big enterprise SAN somewhere (or the Internet for that matter) for all the world to hack.
I have looked through the archives and googled this. I have found a couple similar inquiries but no answers. Is this even possible with targetcli/rtslib/LIO? Maybe I'm just missing something somewhere?
Thanks for any suggestions,
Craig Watson
I looked into this some more and qla2xxx already supports demo mode. So if you do:
qla2xxx/naa.whatever/ set attribute generate_node_acls=1 qla2xxx/naa.whatever/ set attribute demo_mode_write_protect=0 qla2xxx/naa.whatever/ set attribute cache_dynamic_acls=1
then anyone should be able to connect without having to explicitly create an ACL.
HTH -- Regards -- Andy
Hi Andy,
Thanks for looking into this. Unfortunately, I tried it with no joy. :-(
On the target system in targetcli I did the following:
clearconfig confirm=true
cd /backstores/block create strg /dev/sdb
cd /qla2xxx create naa.XXXXXXXXXXXXXXX1 cd naa.XXXXXXXXXXXXXXX1 set attribute demo_mode_write_protect=0
cd luns create /backstores/block/strg 0 add_mapped_luns=true
cd ../.. create naa.XXXXXXXXXXXXXXX2 cd naa.XXXXXXXXXXXXXXX2 set attribute demo_mode_write_protect=0
cd luns create /backstores/block/strg 0 add_mapped_luns=true
cd /qla2xxx/naa.XXXXXXXXXXXXXXXX get attribute ATTRIBUTE CONFIG GROUP ====================== cache_dynamic_acls=1 -------------------- The cache_dynamic_acls attribute.
demo_mode_write_protect=0 ------------------------- The demo_mode_write_protect attribute.
generate_node_acls=1 -------------------- The generate_node_acls attribute.
prod_mode_write_protect=0 ------------------------- The prod_mode_write_protect attribute.
Then on the initiator, either unload/reload the FC module: rmmod celerity8fc, modprobe celerity8fc; or reboot.
Running fdisk -l (as root) after the above does not show a new drive available.
Going back to the target system and adding acl WWPN's does allow the initiator to see a target drive (after reloading the FC module).
So, unless I'm missing something, maybe we have a bug in the qla2xxx fabric?
Note /sys/class/fc_host/hostXX/port_state on both systems shows "Online".
Here's a copy of the config file. It might tell you something I have left out... demo_mode_write_protect=0
The only difference between what works and this are the two "demo_mode_write_protect=0" lines and the entries under the node_acls:[ ... ], section.
Thanks again for looking at this.
Craig Watson
{ "fabric_modules": [], "storage_objects": [ { "attributes": { "block_size": 512, "emulate_dpo": 0, "emulate_fua_read": 0, "emulate_fua_write": 1, "emulate_model_alias": 1, "emulate_rest_reord": 0, "emulate_tas": 1, "emulate_tpu": 0, "emulate_tpws": 0, "emulate_ua_intlck_ctrl": 0, "emulate_write_cache": 0, "enforce_pr_isids": 1, "fabric_max_sectors": 8192, "is_nonrot": 1, "max_unmap_block_desc_count": 1, "max_unmap_lba_count": 4194240, "max_write_same_len": 65535, "optimal_sectors": 8192, "queue_depth": 128, "unmap_granularity": 1, "unmap_granularity_alignment": 0 }, "dev": "/dev/sdb", "name": "strg", "plugin": "block", "readonly": false, "write_back": false, "wwn": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" } ], "targets": [ { "fabric": "qla2xxx", "tpgs": [ { "attributes": { "cache_dynamic_acls": 1, "demo_mode_write_protect": 0, "generate_node_acls": 1, "prod_mode_write_protect": 0 }, "enable": true, "luns": [ { "index": 0, "storage_object": "/backstores/block/strg" } ], "node_acls": [], "portals": [], "tag": 1 } ], "wwn": "naa.xxxxxxxxxxxxxxxx" }, { "fabric": "qla2xxx", "tpgs": [ { "attributes": { "cache_dynamic_acls": 1, "demo_mode_write_protect": 0, "generate_node_acls": 1, "prod_mode_write_protect": 0 }, "enable": true, "luns": [ { "index": 0, "storage_object": "/backstores/block/strg" } ], "node_acls": [], "portals": [], "tag": 1 } ], "wwn": "naa.yyyyyyyyyyyyyyyy" } ] }
targetcli-fb-devel@lists.fedorahosted.org