login
Search
Greetings all, I am happy to announce that the first ConfigFS configurable generic target engine (target_core_mod) and iSCSI Target Stack (iscsi_target_mod) are now able to use ConfigFS symlinks for the creation of Linux Storage Objects from drivers/scsi, block, or fs/ storage objects to iSCSI Target Port Endpoints. The code is available currently running on v2.6.27-rc7 and has been broken up into a number of commits at: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=summary Now that the primary configfs functionality is up and allowing iSCSI Initiator Traffic to the symlinked storage objects from a generic target engine, I will be continuing work on the complete logic for configfs enabled iscsi_target_mod, as well as removing the legacy IOCTL control path as equivalent functionality is added with ConfigFS. Also, one of the next major steps for the upstream generic target engine and iSCSI target stack is to include SCST's target mode API between Engine / Fabric to give target_core_mod a proper Fabric API to allow other SCST fabric modules to access target_core_mod's configfs enabled storage objects. Also, allowing STGT to use the configfs interface to allow for userspace fabrics to the same target_core_mod storage objects is also on the list, but I imagine interest from those communities will certainly help drive those efforts. Here are the shell variables required to make it all go: export CONFIGFS=/sys/kernel/config/ export TARGET=/sys/kernel/config/target/core/ export FABRIC=/sys/kernel/config/target/iscsi/ The storage objects registered with target_core_mod via $TARGET may be mapped from $TARGET/$HBA/$STORAGE_OBJECT any number of times to: $FABRIC/$IQN/tpgt_1/lun/lun_0/$PORT_LINK $FABRIC/$IQN/tpgt_1/lun/lun_1/$PORT_LINK $FABRIC/$IQN/tpgt_2/lun/lun_0/$PORT_LINK $FABRIC/$ANOTHER_IQN/tpgt_1/lun_0/$PORT_LINK .... .... Here are the shell commands to bring storage objects online.. # Create a IBLOCK HBA and virtual storage ...
Hi Nicholas, It's good, I like it. The only thing concerns me that, considering how much time *I* spent to understand it, for an average user understanding it can be an unbearable nightmare ;) In a few days I'll write a proposed configfs hierarchy for existing SCST /proc interface. Vlad --
Well, the idea is not necessarily making the configfs interface the easiest to use in the world by user directly through $CONFIGFS, but to make the CLI scripts that speak $CONFIGFS/target CLI, and of course the actual UIs for user that interact with generic target core and $FABRIC_MODs be as simple and elegent as possible. That is what I believe the balance that a configfs enabled generic target core provides to both the $CONFIGFS/target API and to $FABRIC_MOD maintainers looking to port their code to use a generic control Sounds good! Please let me know if you have questions. --
There's one unsolved problem. As I've already written, SCST core needs
an ability to provide to user space a large amount of data, which may
not fit to a single page. A list of connected initiators ("sessions"
file in /proc), for instance. Each initiator in that list has a number
of attributes: initiator name, target template name, count of
outstanding commands, etc. The logical way for that would be to create a
subdirectory for each initiator, like:
/sys/kernel/config/
`-- target
`-- sessions
`-- session1
| |-- initiator_name
| |-- template_name
| `-- commands
|
`-- session2
|-- initiator_name
`-- template_name
`-- commands
But looks like configfs requires each subdirectory to be created
manually by user via, e.g., mkdir command. It would be really strange if
we require user to manually create "sessions" subdirectory to be able to
see a list of connected initiators. Do I miss anything?
Vlad
--
The the Initiator Port ACLs need to go under /sys/kernel/config/target/$FABRIC because the struct fabric_acl * will always contain fabric dependent config items. For example, Since these struct fabric_acl_t do *NOT* symlink directly back to target_core_mod under /sys/kernel/config/target/core/$HBA/$DEV, but to fabric_lun_t (iscsi_lun_t in my case) to Symlink to a /sys/kernel/config/target/core/$HBA/$DEV that has been registered with the generic target configfs infrastructure. Here is what I am thinking wrt /sys/kernel/config/target/iscsi and iSCSI Initiator Node ACLs to iSCSI Portal Groups and iSCSI LUNs attached to those Portal Groups. There are two cases: *) The production case with with user creating those ACLs under $FABRIC (which is what I will focus on now). * And "Demo Mode" case where any Initiator logging into $FABRIC/$ENDPOINT/$PORTAL can have access to all $FABRIC/$ENDPOINT/lun/lun_*/*my_ports* The production ACL case would look like: export CONFIGFS=/sys/kernel/config/ export TARGET=/sys/kernel/config/target/core/ export FABRIC=/sys/kernel/config/target/iscsi/ TARGET_IQN=iqn.2003-01.org.linux-iscsi.ps3-cell.ppc64:sn.f8f651bd5fec INITIATOR_IQN=iqn.1993-08.org.debian:01.f82074ca555f <Setup $STORAGE_OBJECTs under $TARGET> # Create the LIO-target endpoint mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/np/172.16.201.137:3260" mkdir -p "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" <Setup Port Symlinks from $TARGET to $TARGET_IQN/tpgt_1/lun/lun_0> # Create the Initiator ACL under $TARGET_IQN/tpgt_1 mkdir -p $"FABRIC/$TARGET_IQN/tpgt_1/initiators/$INITIATOR_IQN" # Allow $INITIATOR_IQN access to tpgt_1/lun/lun_0/ ln -s "$FABRIC/$TARGET_IQN/tpgt_1/lun/lun_0" \ can simply use use: cat $FABRIC/iqn*/tpgt*/initiators/*/session to see which acl'ed iSCSI Initiators are logged in on all iSCSI Target Ports. Also I should add that I am currently using /proc/scsi_target/mib and /proc/iscsi_target_mib for READ-ONLY data with target_core_mod.ko and iscsi_target_mod.ko ...
Ok, here is the commit diff for adding Initiator ACLS to iscsi/$IQN/$TPGT/ under the acls/ subdirectory (instead of "initiators" in the example above). http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commitdiff;h=0a451aff... Other than the name change, everything is functioning in the commit as described in the example above. I am able to successfully mkdir(2) and rmdir(2) iscsi/$IQN/$TPGT/acls/$INITIATOR_IQN, as well as create the SymLinks from iscsi/$IQN/$TPGT/lun/lun_* to iscsi/$IQN/$TPGT/acls/$INITIATOR_IQN/lun_* to create the Initiator TPGT LUN Mappings. There are a couple of remaining items that I am still working on WRT the Initiator ACL code. One is that the CmdSN Queue Depth for the Initiator is hardcoded. This needs to be a configfs attribute under iscsi/$IQN/$TPGT/acls/$INITIATOR_NAME/, and then enabled with a attribute under the same $INITIATOR_NAME directory. Another is assigning READ-ONLY (its hardcoded to R/W for now) access to one of the initiator's TPG LUN mappings. I was thinking name in the TPG LUN Symlink destination name, we could include "lun_0:RO" in order to make this Initiator's LUN be READ-ONLY. Anyways, this are pretty minor and I should be commiting the remaining pieces over the weekend. --nab --
Sorry for the delay. I didn't have a chance to look at it sufficiently close. Basically the idea about how to manage ACLs is good, but I don't like, that with it *ALL* the target drivers would have to implement the necessary code. It shouldn't be so, management of all security stuff should be purely duty of the mid-layer. And this is exactly implemented in SCST. All what target drivers should do with it is to pass target's name on its registration in scst_register() and then while registering a session with remote initiator using scst_register_session() pass to it the initiator's name. Everything else is done by the SCST core. Thus, I believe, all the ACL management should be done not in $FABRIC/, but in $TARGET/. It would remove all the corresponding configfs headaches from the target drivers writers. But, in fact, I asked about completely different thing. SCSI target mid-layer in some cases needs to export in user space amount of data, which doesn't fit one page. /proc/scsi_tgt/sessions is one example. What --
By the "mid-layer" I assume you mean the generic target mode engine, and not the SCSI mid layer, yes..? Point taken however that $TARGET_MOD could, and probably should have some manner of generic ACL infrastructure available through FABRIC <-> TARGET API. I will have a look at scst_register() and scst_register_session() and see where it should be adapted to target_core_mod. Btw, saying that "management of all security stuff should be purely duty of the mid-layer" is incorrect however. The generic target engine needs to make it *EASIER* for $FABRIC to allow those initiator ports access to Mapped LUNs through fabric *DEPENDENT* endpoints, but trying to put all fabric depepdent ACL endpoint logic in target_core_mod is IMHO a bad idea. Since each SCSI fabric's method of attaching SCSI LUN to Initiator Port Endpoints in $FABRIC_MOD to SCSI Device (I have been calling this /sys/kernel/config/target/core/$STORAGE_OBJECT for target_core_mod) to create the SCSI Target Port is different. The reference I use for iscsi_target_mod (and hence wrt target_core_mod) is proper T10/SCSI terminlogy AFAIK. Lets reference the objects in http://www.haifa.il.ibm.com/satran/ips/EddyQuicksall-iSCSI-in-diagrams/portal_groups.pdf for the discussion so we can make sure we are on the same page.. For example, just because iSCSI uses TargetName + TargetPortalGroupTag to attach target_core_mod's $STORAGE_OBJECTs at iSCSI Logical Units to, does not mean that SAS, or another SCSI based target fabric know anything about TargetName or TargetPortalGroupTag. In iSCSI, this is defined in Section 2.1: The I_T nexus can be identified by the conjunction of the SCSI port names; that is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + ',t,'+ Portal Group Tag). Obviously the Initiator and Target Ports wrt iSCSI fabric are more "symbolic" than devices attached to say a legacy Parallel SCSI bus because of IP storage having multiple IP ...
On Tue, 2008-10-07 at 17:01 -0700, Nicholas A. Bellinger wrote: Ok, here is the commit: http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=commit;h=d1dc1c1da837... In the example I am using two iSCSI Initiators (one Debian and one OpenSuse) that both have TPG LUN 0 and 1 mapped to their Initiator LUN 0 and 1 under $FABRIC/$IQN/tpgt_1. Here is what it looks like from the CLI: export TARGET=/sys/kernel/config/target/core/ export FABRIC=/sys/kernel/config/target/iscsi/ <Setup target_core_mod storage objects..> DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0" # The first mkdir(2) to $FABRIC will load iscsi_target_mod mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260" # Create TPG LUN 0 and symlink $STORAGE_OBJECT from target_core_mod mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" ln -s $TARGET/iblock_0/lvm_test0 "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0/lio_west_port" # Create TPG LUN 1 and symlink $STORAGE_OBJECT from target_core_mod mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" ln -s $TARGET/pscsi_0/sdd "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1/lio_east_port" INITIATOR_DEBIAN="iqn.1993-08.org.debian:01:2dadf92d0ef" # Create Node and two LUN ACL Symlinks for Debian Initiator mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0" ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_0/." mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1" ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_DEBIAN/lun_1/." INITIATOR_SUSE="iqn.1996-04.de.suse:01:1661f9ee7b5" # Create Node and two LUN ACL Symlinks for Suse Initiator mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0" ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_0" "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_0/." mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/acls/$INITIATOR_SUSE/lun_1" ln -s "$FABRIC/$DEF_IQN/tpgt_1/lun/lun_1" ...
Nicholas A. Bellinger wrote: I don't like that limitation. It looks completely artificial for me. And this approach doesn't address what to do if there is a connection from initiator, for which there is no corresponding ACL entry. I again strongly suggest you to get familiar with SCST access control approach before making the next move. It's proved to be good and we --
Nicholas, you think too iSCSI centric. From access control POV only 2 thing matter: 1. Target name - to assign to it a default access control group (ACL, if you like that name), i.e. an ACL for initiators not listed in other ACLs 2. Initiator name - to assign it to the corresponding ACL. It doesn't matter if those names are IQNs for iSCSI or WWNs for FC, or bus:id:lun for parallel SCSI. For example, consider target "TTT", which has 2 ACLs: "Default" with Device1 as LUN 0 and "Group1" with "Device2" as LUN 0. "Group1" specified for initiator "III1". Then when initiator "III1" connected to target "TTT", it would be assigned to "Group1" and see "Device2". If then initiator "III2" connected, it would be assigned to "Default" ACL and see "Device1". "Default" group can be empty, if necessary. There's nothing transport specific in this approach at all. I strongly suggest you to look at SCST access control approach and make sure you understand it before reply. It would save us a lot of time and effort. Note, this approach isn't something theoretical. It's proved by 4 years of successful usage. Also, it would be good, if you shift your terminology to be less iSCSI specific and use the corresponding terms from SAM, where possible. We are discussing a config interface for a generic target engine, aren't we? Otherwise sometimes it's quite hard for me to understand you and I have strong suspicions that other people are getting or already got lost Hmm, I looked at the code and in lio_target_initiator_nacl_info() saw something like: rb += sprintf(page+rb, "LIO Session ID: %u " "ISID: 0x%02x %02x %02x %02x %02x %02x " "TSIH: %hu ", sess->sid, sess->isid[0], sess->isid[1], sess->isid[2], sess->isid[3], sess->isid[4], sess->isid[5], sess->tsih); rb += sprintf(page+rb, "SessionType: %s\n", (SESS_OPS(sess)->SessionType) ? "Discovery" : "Normal"); rb += sprintf(page+rb, "Cmds in Session Pool: %d ...
Not true. Thre is *NOTHING* in target_core_mod's configfs layout that is "iSCSI centric", or $FABRIC centric at all. We are talking about configfs symbolic links with /bin/ls from target_core_mod storage objects and $FABRIC_MOD portal group ports for $FABRIC LUNs. How Initiators logging into those $FABRIC_MOD endpoints (Node ACLs) and accessing those $FABRIC LUNs (LUN ACLs) is still $FABRIC dependent. There is nothing iSCSI, SCSI, ATA or NBD centric about it, it is UNIX centric and works generically across any fabric, that is the whole point of having target_core_mod. Why would we want to limit the generic Wrong. For iSCSI, Section 2.1 of RFC-3720 defines it as TargetName + TargetPortalGroupTag, and this is the method that all of my upstream work and any proper implemention of target node endpoint and target Your example limits all iSCSI ACLs to TargetName, instead of TargetName +TargetPortalGroupTag. That is why everything related to iscsi_target_mod operation is below /sys/kernel/config/target/iscsi/$IQN/$TPGT and not /sys/kernel/config/target/iscsi/$IQN. Obviously I am not going to limit my upstream iscsi_target_mod to an ACL structure that does not take into account a complete RFC-3720 implementation, but I would be more than happy to see you update your ACL code to reflect proper TargetName+TargetPortalGroupTag that RFC-3720 I don't really care about history, I care about code. Why don't you start breaking out which code you want to go upstream so that it makes my job easier or start integrating your own ACL control model into drivers/lio-core/target_core_configfs.c and post a patch and then we can discuss! In all honesty however, the ACL code is a small nit-pick compared to how we are going to merge your $FABRIC <-> $TARGET API with drivers/lio-core. Why don't you start there first while I consider what can be made generic for ACL code for the target_core_mod configfs Heh, why do you think I moved my upstream work to ConfigFS..? Being able to ...
Sorry, Nicholas, but it's pretty hard to discuss something with you. Your complicated manner to express yourself (this isn't a critic, just statement of fact, I'm also pretty much not an ideal in this area) requires from your interlocutor a lot of effort to simply understand you, but I don't feel that you put comparable effort to understand what's written to you. Let's restart our discussion and do it step by step. At first, some of terms you use are pretty confusing for me and, I suspect, many other people, as well as some terms I use seem confuse you. So, let's start from finding a common terminological ground. It will remove future misunderstandings and allow people to easier follow us. Below I'll propose some terms. I'll tried to make them as close to the regular Linux practice as possible, but if I'm not right somewhere everybody is welcome to correct me. 1. Let's use term "SCSI transport" instead of "fabric", which you use. This is well corresponding to the regular Linux practice as well as to SAM. Particularly, SAM doesn't have the word "fabric" anywhere. 2. Target name - an opaque string passed from target driver to SCSI target mid-layer. It contains whatever the target driver would like. For example, for iSCSI it can be Target Name, or Target Port Name + Target Portal Group Tag in string form. For Fibre Channel it can be WWN of the corresponding target port. For parallel SCSI it can be target's bus:id:lun numbers in string form. SCSI target mid-layer uses it to provide access control. 3. Initiator name - an opaque string passed from target driver to SCSI target mid-layer. It contains whatever the target driver would like. For example, for iSCSI it can be Initiator Name, or Initiator User Name @ Initiator Name in string form, like joe@iqn.1996-04.de.suse:01:1661f9ee7b5. For Fibre Channel it can be WWN of the corresponding initiator port. For parallel SCSI it can be initiator's bus:id:lun numbers in string form. SCSI target mid-layer ...
Ok, just added new commits to make target_core_mod be able to run independently of iscsi_target_mod. This means that all mkdir(2) calls under $TARGET do not require iscsi_target_mod to be loaded. Next, following Joel's advice from LPC, I made target_core_configfs.c:target_core_register_fabric(), call request_module() to load $FABRIC_MOD instead of using do_configfs_mkdir() to kick off the registration process. This means that $FABRIC_MOD's init_module() is responsible for calling target_fabric_configfs_init() and target_fabric_configfs_register() to complete $FABRIC_MOD's registration with the configfs generic target core. This means that startup now looks like: modprobe target_core_mod export CONFIGFS=/sys/kernel/config/ export TARGET=/sys/kernel/config/target/core/ export FABRIC=/sys/kernel/config/target/iscsi/ mkdir -p $TARGET/iblock_0/lvm_test0 echo iblock_major=254,iblock_minor=2 > $TARGET/iblock_0/lvm_test0/dev_control echo 1 > $TARGET/iblock_0/lvm_test0/dev_enable mkdir -p $TARGET/pscsi_0/sdd echo scsi_channel_id=0,scsi_target_id=3,scsi_lun_id=0 > $TARGET/pscsi_0/sdd/dev_control echo 1 > $TARGET/pscsi_0/sdd/dev_enable DEF_IQN="iqn.2003-01.org.linux-iscsi.target.i686:sn.e475ed6fcdd0" # The first mkdir(2) to $FABRIC will load iscsi_target_mod mkdir -p "$FABRIC/$DEF_IQN/tpgt_1/np/172.16.201.137:3260" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <snip> This line will modprobe iscsi_target_mod, create iscsi_tiqn_t, iscsi_portal_group_t, and iscsi_tpg_np_t objects with a single mkdir(2) call. So at this point, I believe all (or very close to all) iSCSI target related functions are now outside of target_core_mod. There are a few more file and function names that need to have their prefixes changed, but other that a handful of this minor bits, things are getting close installing the SCST Target API between $FABRIC_MOD <-> $TARGET_CORE_MOD. Also, I was thinking a bit more about how things show up under $TARGET, which is ...
This last part should be: ".. a special case between ConfigFS <-> SysFS in order to deliver struct scsi_device and struct block_device via SymLinks to $TARGET/pscsi_*/$STORAGE_OBJECT and ln -s $TARGET/$PLUGIN_HBA/$STORAGE_OBJECT $FABRIC/endpoint/lun/lun_0/lio_west_port --
