On 09/30/2009 01:32 AM, Hannes Reinecke wrote:
> Mike Christie wrote:
>> On 09/29/2009 08:46 AM, Hannes Reinecke wrote:
>>> Some iSCSI implementations (eg HP) is using an empty username for
>>> CHAP negotiations. So we should be allowing the same.
>>>
>>
>> Do we need this support for discovery? There is one other one auth
>> setup function in discovery.c:setup_authentication(). Not sure why we
>> have two almost identical functions there. Probably due to how it is
>> all compiled. Do not worry about the duplication in this patch. We can
>> just fix up discovery.c:setup_authentication().
>>
> Yes, we also need to support an empty username for discovery.
> And I seriously think if we shouldn't redesign the discovery node
> database:
> Currently we're storing the _detected_ target names under
> /etc/iscsi/send_targets,
> ie we have to preset the CHAP variables in /etc/iscsid.conf.
> But this makes it impossible to have different settings for different

It is not impossible. You have to modify iscsid.conf every time you do 
discovery to a different target. I agree it is not ideal or user 
friendly or nice :( It is due to a bug. See below. I was not sure how to 
handle it.


> portals;
> one iSCSI portal might require CHAP authentication discovery, the next
> might
> not, and another one might have a different username/password.
>
> It would be far more sensible to store the settings for the _portal_
> under /etc/iscsi/send_targets, too; this would allow us to modify
> them via -o update and have different settings for different targets.
>

So you saw, we store discovery settings. Your patch to set them is fine. 
I will merge it. There is still one problem. We currently cannot use the 
discovery record settings. If you do

iscsiadm -m discovery -t st -p ip
iscsiadm -m discovery -o update -n some_setting -v value
iscsiadm -m discovery -t st -p ip

we are not using the updated setting.


Currently

iscsiadm -m discovery -p ip

will just print out the discovery record:

iscsiadm -m discovery  -p 20.15.0.7
  BEGIN RECORD 2.0-871
discovery.startup = manual
discovery.type = sendtargets
discovery.sendtargets.address = 20.15.0.7
discovery.sendtargets.port = 3260
discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = username
discovery.sendtargets.auth.password = ********
discovery.sendtargets.auth.username_in = <empty>
discovery.sendtargets.auth.password_in = <empty>
discovery.sendtargets.timeo.login_timeout = 15
discovery.sendtargets.reopen_max = 5
discovery.sendtargets.timeo.auth_timeout = 45
discovery.sendtargets.timeo.active_timeout = 30
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
# END RECORD

And
iscsiadm -m discovery -t st -p ip

will do discovery using iscsid.conf settings.

And I think this command:
iscsiadm -m discovery st -p ip -l
was meant to use the discovery record settings (the -l was supposed to 
indicate to login into the discovery address and do discovery), but it 
actually uses the iscsid.conf settings, does discovery and then logs 
into the targets found from discovery.


So the issue is what command do we use to do discovery using the send 
targets record settings?


Do you think we should do:

1.
# This will search for a record at IP and if found will use it.
iscsiadm -m discovery -t st -p ip
# We also add a new op OP_RESET_DISC_SETTINGS which will
# use iscsid.conf settings
iscsiadm -m discovery -t st -p ip -o OP_RESET_DISC_SETTINGS

The problem with #1 is that we will be changing the default behavior.

2.
# Like #1 this will search for a record at IP and if found will use it.
iscsiadm -m discovery -t st -p ip

# The difference will be that we do not add a new op. Instead we
# say that if you want to use the iscsid.conf settings for an
# discovery address, you just have to delete the old one first
iscsiadm -m discovery -o delete -p ip
iscsiadm -m discovery -t st -p ip

This has the draw backs that we change the default behavior and we if 
you delete a discovery record it will delete all the records for portals 
that were found through it.


3.
Right now
iscsiadm -m discovery  -p 20.15.0.7
works like in node mode where
iscsiadm -m ndoe -T target -p ip
would print out the record.

But you can also print out the record by doing

iscsiadm -m discovery  -p 20.15.0.7 -o show
iscsiadm -m ndoe -T target -p ip -o show

I am not sure why we have two ways to print out the record.

But for discovery we could say that doing
iscsiadm -m discovery  -p 20.15.0.7
will instead perform discovery using the record for 20.15.0.7.

The problem is again that we are changing the behavior and we are also 
making discovery and node mode a little different.

4.
Do nothing. Just set the iscsid.conf setting every time you want to use 
different discovery settings.

5.
???
Give me a new idea.




>> Can you have a empty incoming username? If so I think we need to
>> modify acl_chap_auth_request like how you did to acl_set_user_name.
> No, not what I've seen so far; but I haven't been exactly successful
> here. I'll dig further here.
>
> BTW, would it be sensible to support both methods if CHAP is enabled?
> Currently we're only setting the auth method to either 'CHAP' or 'None'.
> We means we cannot login to a target which just supports 'None' when
> we set the record to 'CHAP'.
> Any specific reason? Methinks it'd be far more sensible to announce
> 'CHAP,None' whenever CHAP is selected. And to allow login with no
> credentials, too, in this case.

I do not know why this was done. I think your idea would simplify setup 
for users.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to