On Tue, 2013-10-08 at 23:35 +0200, Thomas Glanzmann wrote: > Hello Nab, > > > Ok, I'm now getting more confused as to what your trying to accomplish > > with these patches. > > > The original discussion was to restrict SendTargets discovery > > information for specific TargetName+TargetPortalGroupTag endpoints, > > based upon how the endpoint was configured using TPG attributes. > > > Thus far it has included the following criteria: > > > - If demo-mode (generate_node_acls=1) is enabled on the TargetName+TargetPortalGroup > > endpoint, always return TargetName regardless of other settings > > - If demo-mode (generate_node_acls=0) is disabled, only return TargetName if NodeACL > > exists that matches the InitiatorName for the discovery session. > > > So from what I can tell the changes in your PATCH-v3 achieve these > > points. > > I agree with the above. The PATCH-v3 accomplishes that and works > perfectly fine for me. I run it on top of everything else that you have > sent me and I'll report back by the end of the week when I have finished > my class. > Ok, good. Just making sure the objective for the first patch series is mutually understood. ;) > > Where I'm getting confused is where portals and subnets are now involved > > in the discussion. The above criteria will not restrict SendTargets > > discovery based on which portal the initiator is connecting to, but only > > restricts SendTargets discovery based upon how each of the endpoints are > > configured. > > While I was working on the patch, I noticed, that I wanted more: I also > wanted to not expose demo mode luns from other portals. This is > currently a pending task since I have not accomplished that yet. As I > see it I have two options here: > > - Drop the demo mode and set explicit access permissions (I > don't want that) > > - Write a patch that only returns targets which are bound to the > portal > > > Eg: The initiator will always see the same restricted set of SendTargets > > discovery information based on the above criteria, regardless of which > > network portal it's actually connecting to. > > I can confirm that. Would you be willing to take a patch that changes > that or do you consider it fundamentally broken? > Mmm, so far I've avoided NodeACLs based on IP address entirely, so adding this specifically for in-band sendtargets discovery is something that I'd rather avoid. Coding this up for your internal use is fine, but it's most likely something that I'll not be merging. > Do you have an alternative? I have the following scenario: > > I have 10 VLANs. They're seperated by a firewall so that one VLAN can > not access the other VLAN. Each VLAN has 12 ESX Servers in it. I have one storage. > This storage is used by all 10 VLANs. On the storage I have two IPs in > every VLAN. I want to be able to provide 'LUNs which can only be > accessed by the ESX server' and I want LUNs which can be accessed by > everyone in the VLAN not taking the iqn into account. Before PATCH-v3 > all LUNs were discovered which LED to many unsucessfull logins and long > reboot times, because the ESX initiators tried to log in into every > single target. With PATCH-v3 this is now much better, but the ESX still > try to login to all demo mode LUNs, two they can reach all other fail > because they do not reach them over layer 3 because of the firewall. > OK, this exactly what explicit NodeACLs are intended for, and given how the PATCH-v3 demo_mode_discovery logic now works, correctly hides TargetNames from Initiators who don't have an explicit NodeACL set. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
