Re: Help:insmod: error inserting ib_iser.ko
I don't want use th iser I want the open-iscsi run normally run,can you help me? 2009/12/16 Erez Zilber erezzi.l...@gmail.com On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue zhangxintaofi...@gmail.com wrote: There is a error with I inserting the ib_iser.ko module as following: [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ drivers/infiniband/ulp/iser/ib_iser.ko insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module my linux kernel 2.6.18-8.el5 who can help me? This is because your ib_iser module was built against open-iscsi from the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi modules that you took from open-iscsi.org. If you run 'dmesg -c', you'll see the list of symbols that it disagrees on. What can you do? Assuming that you want to use iSER, use the open-iscsi kernel modules from kernel + open-iscsi userspace tools from open-iscsi.org. Another (easier) option is to install OFED that has open-iscsi with iSER support. Erez -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: inserting error with start open-iscsi
I know your meaning because I start the open-iscsi with a error with symbol of ib_iser I don't want use the iser ,can you help me ? 2009/12/16 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de On 15 Dec 2009 at 18:18, Xintao Zhang wrote: Hey all Therer is a error with inserting the ib_iser.ko as following: == [r...@localhost init.d]# insmod Generally you should use modprobe instead of insmod. I have no idea on your specific problem, however. /lib/modules/2.6.18-8.el5/kernel/drivers/infiniband/ulp/iser/ib_iser.ko insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module == who can help me? -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: Help:insmod: error inserting ib_iser.ko
I guess that you want to run open-iscsi over iscsi_tcp which is the default open-iscsi transport. Assuming that all other modules were loaded successfully (libiscsi, iscsi_tcp, scsi_transport_iscsi and libiscsi_tcp (depends on the version of open-iscsi that you use)), you don't need to do anything. open-iscsi has multiple transport (iscsi_tcp, ib_iser, bnx2i, cxgb3i). The error that you got means that the ib_iser transport could not be loaded, but you don't need iSER anyway. Erez On Wed, Dec 16, 2009 at 11:47 AM, Xintao Zhang zhangxintaofi...@gmail.com wrote: I don't want use th iser I want the open-iscsi run normally run,can you help me? 2009/12/16 Erez Zilber erezzi.l...@gmail.com On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue zhangxintaofi...@gmail.com wrote: There is a error with I inserting the ib_iser.ko module as following: [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ drivers/infiniband/ulp/iser/ib_iser.ko insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module my linux kernel 2.6.18-8.el5 who can help me? This is because your ib_iser module was built against open-iscsi from the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi modules that you took from open-iscsi.org. If you run 'dmesg -c', you'll see the list of symbols that it disagrees on. What can you do? Assuming that you want to use iSER, use the open-iscsi kernel modules from kernel + open-iscsi userspace tools from open-iscsi.org. Another (easier) option is to install OFED that has open-iscsi with iSER support. Erez -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: Suggestion for new logging mechanism in open-iscsi
On Wed, Dec 2, 2009 at 10:55 AM, Erez Zilber erezzi.l...@gmail.com wrote: I'd like to make some changes in the logging in open-iscsi. The current status is as follows: kernel modules: * We use iscsi_cls_session_printk iscsi_cls_conn_printk in scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g. ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are controlled by module parameters. * We use iscsi_session_printk iscsi_conn_printk for the rest of the kernel code.These macros wrap iscsi_cls_session_printk iscsi_cls_conn_printk accordingly. They are sometimes wrapped by macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are controlled by module parameters. * We sometimes use printk calls. userspace: We use log_warning, log_error log_debug. They depend on the logging level that we use (0-8). if (log_level level), the log is sent to syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG). My motivation: with the current logging mechanism, if an error occurs, I'm unable to tell exactly what happened. The default logging level is too low. Increasing it affects performance. Another problem is that open-iscsi has too many logging mechanisms. I suggest that: 1. For kernel modules, we will have 'events' (or any better name that you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event, we will have a logging level. For example, the user may want to set the 'conn' event to 'DEBUG'. It means that we will print all conn related logs that are DEBUG and above (e.g. WARNING, ERROR). I suggest that each kernel module will have its own events. Each event will be represented by a module parameter (with some default value). 2. For userspace code, we could do the same (i.e. have events and a log level per event). Regarding the 'events' in userspace - we will have events A, B C for iscsid and events D, E F for iscsiadm. For each event, we will probably have a default logging level. The user may want to run with another logging level for each event. For iscsid, I suggest that we add this to iscsid.conf. For iscsiadm, the user will be able to do something like: iscsiadm -d some_level - this will set all events to 'some_level' iscsiadm -dE level_for_E -dF level_for_F - this will set the event 'E' to 'level_for_E' and the event 'F' to 'level_for_F'. The event 'D' will use the default logging level. Comments? Thanks, Erez -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
RE: minimum password length check
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Ulrich Windl
Sent: Wednesday, December 16, 2009 1:08 PM
To: open-iscsi@googlegroups.com
Subject: Re: minimum password length check
On 15 Dec 2009 at 22:47, shyam_i...@dell.com wrote:
From the spec:
CHAP secrets MUST be an integral number of bytes (octets). A
compliant implementation SHOULD NOT continue with the login step
in
which it should send a CHAP response (CHAP_R, Section 11.1.4
Challenge Handshake Authentication Protocol (CHAP)) unless it can
verify that the CHAP secret is at least 96 bits, or that IPsec
encryption is being used to protect the connection.
You picked up an interesting issue: The Microsoft Initiator limits
the length of
the secret to 16 characters (AFAIR). I wrote a lottle program that
generates
random secrets and estimated the entropy (i.e. number of bits):
With 16 random letters, you are at about 92 bits (e.g.
mMPuhxfKAYuIFTjZ)
With 16 random letters with digits you are at about 95 bits (e.g.
b3v4B8mRoiFWjpF9)
The bad thing is that some characters look quite similar so users,
like
'0'
and'O', or '1' and 'l'. When trying to omit those potentially
confusing
characters
(plus adding other punctuation characters, leaving out space for
obvious reasons),
I'm at about 83 bits (e.g. u\FphNwuuWCT74+h).
As a side note: Passwords with only six letters in one case only make
about 28
bits. Now if you think that most users will use words, you can guess
how poor
those passwords actually are.
Using the fully printable ASCII characterset without those characters
that are
considered unsafe in UNIX, 16 characters would have about 102 bits
of
entropy
(e.g. !)Zbl(p7%Hd88LT)
The spec suggests that a chap secret be at least 96bits or (12
characters) but I see that only the AUTH_STR_MAX_LEN of 256
characters
is used for error checking.
Even when just using digits, that would be 850 bits of entropy,
probably enough ;-
)
Regards,
Ulrich
Am I reading this correctly ?
-Shyam Iyer
--
You received this message because you are subscribed to the Google
Groups open-iscsi group.
To post to this group, send email to open-is...@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?hl=en.
Essentially what you are saying is that we haven't implemented the
secret's bit randomness calculation to check if has atleast 96bits of
entropy.
So I guess we should do some thing like this
If (check_96bit_entropy(secret) secret AUTH_MAX_STR_LEN) {
Use_secret
}
else {
Secret not strong enough ..throw error...
}
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@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?hl=en.
Re: Help:insmod: error inserting ib_iser.ko
I start open-iscsi with you method,but appear a problem. I use the tail -f /var/log/messages can't find iscis device. can you help me? 2009/12/17 Xintao Zhang zhangxintaofi...@gmail.com Thanks Erez 2009/12/16 Erez Zilber erezzi.l...@gmail.com I guess that you want to run open-iscsi over iscsi_tcp which is the default open-iscsi transport. Assuming that all other modules were loaded successfully (libiscsi, iscsi_tcp, scsi_transport_iscsi and libiscsi_tcp (depends on the version of open-iscsi that you use)), you don't need to do anything. open-iscsi has multiple transport (iscsi_tcp, ib_iser, bnx2i, cxgb3i). The error that you got means that the ib_iser transport could not be loaded, but you don't need iSER anyway. Erez On Wed, Dec 16, 2009 at 11:47 AM, Xintao Zhang zhangxintaofi...@gmail.com wrote: I don't want use th iser I want the open-iscsi run normally run,can you help me? 2009/12/16 Erez Zilber erezzi.l...@gmail.com On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue zhangxintaofi...@gmail.com wrote: There is a error with I inserting the ib_iser.ko module as following: [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ drivers/infiniband/ulp/iser/ib_iser.ko insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module my linux kernel 2.6.18-8.el5 who can help me? This is because your ib_iser module was built against open-iscsi from the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi modules that you took from open-iscsi.org. If you run 'dmesg -c', you'll see the list of symbols that it disagrees on. What can you do? Assuming that you want to use iSER, use the open-iscsi kernel modules from kernel + open-iscsi userspace tools from open-iscsi.org. Another (easier) option is to install OFED that has open-iscsi with iSER support. Erez -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.comopen-iscsi%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
open-iscsi 2.0.707-0.19 iface
Version 2.0.707-0.19 of open-iscsi which comes with SUSE SLES 10 SP1 with kernel 2.6.16.46-0.12-default does not seem to support the iface option or parameters. So how do you configure multiple NICs as iSCSI interfaces so that you can leverage devicemapper multipathing? -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
[PATCH] support multidisk iBFTs
Please could the attached patch be considered for inclusion in the open-iscsi
source.
Regards,
Alex Zeffertt
Changelog:
-
iSCSI Boot Firmware Tables are able to specify up to two iSCSI targets, but
until now open-iscsi has only been able to display/attach one of these.
This change enables open-iscsi to display/attach both targets when the iBFT
contains two valid entries. The following commands are affected:
iscsiadm -m fw [-l]
iscsistart -b
iscsistart -f
The primary benefit of this change is that it makes possible for initrds to
mount a multipath device, where the slave devices are iSCSI LUNs specified by
the iBFT.
Signed-off-by: alex.zeffe...@eu.citrix.com
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@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?hl=en.
diff -urN a/include/fw_context.h b/include/fw_context.h
--- a/include/fw_context.h 2008-07-01 02:14:03.0 +0100
+++ b/include/fw_context.h 2009-12-16 15:33:15.0 +
@@ -40,7 +40,17 @@
char isid[10];
};
-extern int fw_get_entry(struct boot_context *context, const char *filepath);
+/*
+ * Parse the firmware into context[] and return the number of entries written.
+ */
+extern int fw_get_entry(struct boot_context context[], int max_entries, const char *filepath);
+
+/*
+ * Print the contents of context.
+ */
extern void fw_print_entry(struct boot_context *context);
+/* PPC may have 1 entry, iBFT on x86 may have 1 or 2 entries */
+#define FWPARAM_MAX_ENTRIES 2
+
#endif /* FWPARAM_CONTEXT_H_ */
diff -urN a/usr/iscsiadm.c b/usr/iscsiadm.c
--- a/usr/iscsiadm.c 2008-07-01 02:14:03.0 +0100
+++ b/usr/iscsiadm.c 2009-12-16 15:33:15.0 +
@@ -1960,32 +1960,40 @@
static int exec_fw_op(discovery_rec_t *drec, int do_login, int info_level)
{
- struct boot_context context;
- struct node_rec *rec;
+ struct boot_context context[FWPARAM_MAX_ENTRIES];
+ struct boot_context *pcontext = context;
+ int entries = 0;
int ret = 0;
- memset(context, 0, sizeof(struct boot_context));
- ret = fw_get_entry(context, NULL);
- if (ret) {
- log_error(Could not read fw values.);
- return ret;
+ memset(context, 0, sizeof(context));
+ entries = fw_get_entry(context, FWPARAM_MAX_ENTRIES, NULL);
+ if (entries == 0) {
+ log_error(Could not find fw values.);
+ return -1;
}
+ while (entries-- ret == 0) {
+ struct node_rec *rec;
+ rec = fw_create_rec_by_entry(pcontext);
+ if (!rec)
+ return ENODEV;
+
+ /* if discovery, print nodes that were found. */
+ if (drec)
+ /* this looks wrong... aren't we supposed to do something
+ * with drec - like fill it out for example?
+ */
+ print_fw_nodes(rec, info_level);
+
+ if (do_login)
+ ret = login_portal(NULL, NULL, rec);
+ free(rec);
- rec = fw_create_rec_by_entry(context);
- if (!rec)
- return ENODEV;
-
- /* if discovery, print nodes that were found. */
- if (drec)
- print_fw_nodes(rec, info_level);
-
- if (do_login)
- ret = login_portal(NULL, NULL, rec);
- free(rec);
-
- /* print the fw node info if called in fw mode with no params */
- if (!do_login !drec)
- fw_print_entry(context);
+ /* print the fw node info if called in fw mode with no params */
+ if (!do_login !drec)
+ fw_print_entry(pcontext);
+
+ pcontext++;
+ }
return ret;
}
diff -urN a/usr/iscsistart.c b/usr/iscsistart.c
--- a/usr/iscsistart.c 2008-07-01 02:14:03.0 +0100
+++ b/usr/iscsistart.c 2009-12-16 15:35:20.0 +
@@ -49,8 +49,6 @@
struct iscsi_daemon_config daemon_config;
struct iscsi_daemon_config *dconfig = daemon_config;
-static node_rec_t config_rec;
-
static char program_name[] = iscsistart;
static int mgmt_ipc_fd;
@@ -120,7 +118,7 @@
return rc;
}
-static int setup_session(void)
+static int setup_session(node_rec_t *config_rec)
{
iscsiadm_req_t req;
iscsiadm_rsp_t rsp;
@@ -130,18 +128,18 @@
* For root boot we cannot change this so increase to account
* for boot using static setup.
*/
- config_rec.session.initial_login_retry_max = 120;
+ config_rec-session.initial_login_retry_max = 120;
/* we cannot answer so turn off */
- config_rec.conn[0].timeo.noop_out_interval = 0;
- config_rec.conn[0].timeo.noop_out_timeout = 0;
+ config_rec-conn[0].timeo.noop_out_interval = 0;
+ config_rec-conn[0].timeo.noop_out_timeout = 0;
- printf(%s: Logging into %s %s:%d,%d\n, program_name, config_rec.name,
- config_rec.conn[0].address, config_rec.conn[0].port,
- config_rec.tpgt);
+ printf(%s: Logging into %s %s:%d,%d\n, program_name, config_rec-name,
+ config_rec-conn[0].address, config_rec-conn[0].port,
+ config_rec-tpgt);
memset(req, 0, sizeof(req));
req.command = MGMT_IPC_SESSION_LOGIN;
- memcpy(req.u.session.rec, config_rec, sizeof(node_rec_t));
+ memcpy(req.u.session.rec,
Re: [PATCH] Maintain a list of nop-out PDUs that almost timed out
Erez Zilber wrote:
On Tue, Dec 15, 2009 at 10:34 AM, Mike Christie micha...@cs.wisc.edu wrote:
Erez Zilber wrote:
Maintain a list of nop-out PDUs that almost timed out.
With this information, you can understand and debug the
whole system: you can check your target and see what caused
it to be so slow on that specific time, you can see if your
network was very busy during that time etc.
Signed-off-by: Erez Zilber erezzi.l...@gmail.com
Sorry for the late reply. Thanks for doing this work!
@@ -88,11 +89,12 @@ static struct option const long_options[] =
{killiscsid, required_argument, NULL, 'k'},
{debug, required_argument, NULL, 'd'},
{show, no_argument, NULL, 'S'},
+ {noopinfo, required_argument, NULL, 'N'},
{version, no_argument, NULL, 'V'},
{help, no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
};
Do you think you want something more generic like a get-debug-info type
of feature? Maybe in the future we could also show how many times a scsi
command has timed out or almost timed out (user can adjust scsi timer
then) or how many times the scsi eh has fired and how many times a
abort, lu or target reset has timed out?
So maybe it would be get like get stats where then the noop info is the
first stat and in the future we will have more?
Sounds good. Let's change it to {debuginfo, required_argument, NULL, 'i'}.
OK?
Ok with me.
@@ -994,8 +997,25 @@ static int iscsi_nop_out_rsp(struct iscsi_task *task,
if (iscsi_recv_pdu(conn-cls_conn, (struct iscsi_hdr *)nop,
data, datalen))
rc = ISCSI_ERR_CONN_FAILED;
- } else
+ } else {
+ ping_delay = jiffies - conn-last_ping;
+
+ /* Check if the ping has almost timed out */
+ if (ping_delay =
+ (session-noop_threshold * (conn-ping_timeout * HZ)) /
+ 100) {
+ mutex_lock(conn-noop_info_mutex);
We annot use a mutex here, because we run from a bottom half (softirq
for iscsi and a tasklet for iser), and we cannot sleep in a bh since
there is no process context.
You're right. I'll replace the mutex with a spinlock.
+ idx = conn-noop_info_arr_idx;
+ conn-noop_info_arr[idx].tv = conn-tmp_noop_tv;
+ conn-noop_info_arr[idx].elapsed_time_msec =
ping_delay;
I think ping_delay is just in jiffies, so you have to do some sort of
jiffies_to_msec call (I cannot rememeber the name of the helper but
there is one).
I think it should be: conn-noop_info_arr[idx].elapsed_time_msec =
ping_delay * HZ / 1000
I think the function is jiffies_to_msecs()
+ conn-noop_info_arr[idx].init = 1;
+ conn-noop_info_arr_idx =
+ (conn-noop_info_arr_idx + 1) %
NOOP_INFO_ARR_LEN;
I am not getting the reason for the division?
Are you talking about conn-noop_info_arr_idx =
(conn-noop_info_arr_idx + 1) % NOOP_INFO_ARR_LEN? It's a cyclic
array.
Ah, nevermind :)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@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?hl=en.
Re: open-iscsi on SUSE 11
Stuart Little wrote: Hi, Using open-iscsi-2.0.869-8.1 (x86_64) on a SUSE 11.0 based machine, connecting to an HP D2D. Generally operation seems fine but I have some issues:- I cannot get the system to reconnect as start, if I configure open-isci to start at boot the system hangs, I have to do a force reboot and boot single user, configure open-iscsi to off. Starting open-iscsi by hand always works, but login appears to work on two interfaces only. Messages displayed during manual start:- etc/init.d/open-iscsi start Starting iSCSI initiator service: done Setting up iSCSI targets: Logging in to [iface: default, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, portal: 192.168.2.85,3260] Logging in to [iface: iser, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, portal: 192.168.2.85,3260] Logging in to [iface: default, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic s, portal: 192.168.2.85,3260] Logging in to [iface: iser, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic s, portal: 192.168.2.85,3260] Login to [iface: default, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, portal: 192.168.2.85,3260]: successful Login to [iface: default, target: iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic s, portal: 192.168.2.85,3260]: successful I can change the constraints in the startup to start open-iscsi after everything else and it will still hang. Could the failure to connect on the iser interfaces be a cause of the failure to start at boot? Yes. Is your system completely hung or does it just not proceed. It looks like we cannot log into the iser targets. With the default time outs, it could retry for around 5 minutes, so the system will look hung, but eventually it would proceed. Decrease node.conn[0].timeo.login_timeout and node.session.initial_login_retry_max. If so is there a way to disable the iser interfaces and stick with the tcp connections? Set the node.startup to manual for the iser ones. I think you would want to set things up so the infinniband stuff is tarted earlier or iscsi is started later. Then you can leave the node.startup values alone. Another problem was uncovered when a real local tape drive was added, while status messages suggsted that the open-iscsi interfaces hand changed from using /dev/st0 to /dev/st1 the system would not actually You lost me. So the tape device is local or accessed through iscsi? work correctly. I have not tried a reinstall yet, but removal of the offending local drive let the system work sensibly again. Cheers, Stuart -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: minimum password length check
shyam_i...@dell.com wrote:
So I guess we should do some thing like this
If (check_96bit_entropy(secret) secret AUTH_MAX_STR_LEN) {
Use_secret
}
else {
Secret not strong enough ..throw error...
}
We do not check. The only problem would be if we added one now lots of
people are going to get errors in existing set ups. Some might not boot.
Maybe add a error message for a while, then make it mandatory in a later
release.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@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?hl=en.
Re: [Open-FCoE] [fcoemon PATCH v2 00/11] rfcoemon restructuring
shyam_i...@dell.com wrote: Shouldn't the requirement to administer DCB be FCoE independent ? After all DCB is required for other protocols like iscsi as well. It is not required for iscsi. I think people are thinking it is going to be useful for iscsi though. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
Re: open-iscsi 2.0.707-0.19 iface
On 15 Dec 2009 at 21:45, Mark wrote: Version 2.0.707-0.19 of open-iscsi which comes with SUSE SLES 10 SP1 with kernel 2.6.16.46-0.12-default does not seem to support the iface option or parameters. So how do you configure multiple NICs as iSCSI interfaces so that you can leverage devicemapper multipathing? SLES 10 SP1 is out of support, and SP2 will be soon as well. You should try SP3 (or even SLES 11). -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
RE: minimum password length check
On 17 Dec 2009 at 0:55, shyam_i...@dell.com wrote: Essentially what you are saying is that we haven't implemented the secret's bit randomness calculation to check if has atleast 96bits of entropy. No, I just wanted to point out that the quality of a secret key cannot simply be measured with strlen(password), and that 96 bits of randomness may require a longer string as one might initially have guessed. Regards, Ulrich -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
