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 -~----------~----~----~----~------~----~------~--~---
