Re: [PATCH] Allow empty username for CHAP
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 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. 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. Comments? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] Allow update of discovery records.
We should allow updating of discovery records, too.
This enables open-iscsi to use different settings during
discovery to different targets.
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/usr/idbm.c b/usr/idbm.c
index ee38e64..ca5479e 100644
--- a/usr/idbm.c
+++ b/usr/idbm.c
@@ -2097,6 +2097,35 @@ free_info:
return rc;
}
+int idbm_discovery_set_param(void *data, discovery_rec_t *rec)
+{
+ struct db_set_param *param = data;
+ recinfo_t *info;
+ int rc = 0;
+
+ info = idbm_recinfo_alloc(MAX_KEYS);
+ if (!info)
+ return ENOMEM;
+
+ idbm_recinfo_discovery((discovery_rec_t *)rec, info);
+
+ rc = idbm_verify_param(info, param-name);
+ if (rc)
+ goto free_info;
+
+ rc = idbm_rec_update_param(info, param-name, param-value, 0);
+ if (rc)
+ goto free_info;
+
+ rc = idbm_discovery_write((discovery_rec_t *)rec);
+ if (rc)
+ goto free_info;
+
+free_info:
+ free(info);
+ return rc;
+}
+
int idbm_init(idbm_get_config_file_fn *fn)
{
/* make sure root db dir is there */
diff --git a/usr/idbm.h b/usr/idbm.h
index ed8badd..0609c47 100644
--- a/usr/idbm.h
+++ b/usr/idbm.h
@@ -139,6 +139,7 @@ extern int idbm_rec_read(node_rec_t *out_rec, char
*target_name,
int tpgt, char *addr, int port,
struct iface_rec *iface);
extern int idbm_node_set_param(void *data, node_rec_t *rec);
+extern int idbm_discovery_set_param(void *data, discovery_rec_t *rec);
/* lower level idbm functions for use by iface.c */
extern void idbm_recinfo_config(recinfo_t *info, FILE *f);
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index 9d2ce71..c9f9a88 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -1912,7 +1912,7 @@ main(int argc, char **argv)
name, value);
break;
case MODE_DISCOVERY:
- if ((rc = verify_mode_params(argc, argv, SIPdmtplo, 0))) {
+ if ((rc = verify_mode_params(argc, argv, SIPdmntplov, 0))) {
log_error(discovery mode: option '-%c' is not
allowed/supported, rc);
rc = -1;
@@ -1991,6 +1991,19 @@ main(int argc, char **argv)
record!);
rc = -1;
}
+ } else if (op == OP_UPDATE) {
+ struct db_set_param set_param;
+
+ if (!name || !value) {
+ log_error(Update requires
+ name and value);
+ rc = -1;
+ goto out;
+ }
+ set_param.name = name;
+ set_param.value = value;
+ if
(idbm_discovery_set_param(set_param, drec))
+ rc = -1;
} else {
log_error(operation is not
supported.);
rc = -1;
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: SD Driver incrementing on every snapshot.
On 09/29/2009 06:58 PM, Matthew Schumacher wrote: Group, I'm using linux to backup an ISCSI target. My backup script calls the snapshot function on my iscsi server, then uses open-iscsi to connect to a snapshot target on that server. The target is backed up, then I logoff the target until the next backup. The problem is that the scsi device number in linux keeps incrementing: scsi13 : iSCSI Initiator over TCP/IP scsi14 : iSCSI Initiator over TCP/IP scsi15 : iSCSI Initiator over TCP/IP Is this cause for concern? Will it quit on me at some point? Is there It is expected behavior. The X in scsiX is a host number. The linux scsi layer will increment it every time we create a new host. We end up doing a host per session and in your case it looks like your target is doing a session device. It will quit at some point. The host number is a unsigned 32 bit int, so once you go through 2^32, the scsi layer will roll over. When that happens the scsi layer's host number allocation algorithm is not very smart and could fail. So in practice you probably would not login/logout a of a target 2^32 times. But it is possible if you just did loop test and let it run over night. a way to make open-iscsi reuse an old scsi device number? No. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] Allow empty username for CHAP
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
Re: [PATCH] Allow update of discovery records.
On 09/30/2009 03:56 AM, Hannes Reinecke wrote: We should allow updating of discovery records, too. This enables open-iscsi to use different settings during discovery to different targets. Signed-off-by: Hannes Reineckeh...@suse.de Thanks. Merged in 3bb88ea9be814a2f598cf6f1d1fcdbc2f57ff0a8. See my mail in the Allow empty username for CHAP thread about adding a iscsiadm command to take advantage of this without having to log into every target found (only iscsiadm -m discovery -p ip -l will use the existing record settings right now). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[bug-report] no error reporting when network interface was changed
Hi, during a reconfiguration of our servers, I removed a networkinterface (br2). This networkinterface was previously used by open-iscsi (iface.net_ifacename = br2). I didn't remember having set this interface in the open-iscsi configuration and so I ran into an error not being able to reconnect to the iscsi target over and over with a message like this: Logging in to [iface: hrstor001, target: iqn. 2004-08.jp.buffalo:HRSTOR001-001D73267640:volume002, portal: 192.168.1.3,3260] iscsiadm: Could not login to [iface: hrstor001, target: iqn. 2004-08.jp.buffalo:HRSTOR001-001D73267640:volume002, portal: 192.168.1.3,3260]: iscsiadm: initiator reported error (8 - connection timed out) iscsiadm: Could not log into all portals. Err 8. I looked at /var/log/messages and couldn't find the reason for it, even raising the debug level of iscsid didn't help. Finally I noticed, I had the old network interface (br2) in several configuration files of open-iscsi. After changing the interface it worked again. open-iscsi should have better error handling in this case - it should check whether the configured network interface exists at all and display an error if it doesn't exist. Regards, Elias P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Suse 10.2 install of open-iscsi 2.0-871
On 09/30/2009 11:07 AM, Taylor wrote: I am getting compile errros when running make KSRC=/usr/src/linux KBUILD_OUTPUT=/usr/src/linux-obj/x86_64/smp on a Suse 10.2 machine. I made sure the Cryptographic API and CRC32 options were set to Yes in kernel. I believe the problem is the 2.6.16-suse.patch isn't being run before the compile problems occur. The SUSE patch does not work with the current modules. It needs to be updated. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
