Re: iSNS discovery error (login)
As far as I know, your transactions/sessions with the iSNS server and those with the iSCSI target should be independent. The iSNS can give you target information and you can use it to connect to target and login. Targets themselves are iSNS clients like your initiator. They register the information with the iSNS server that you as an iSNS client can use to connect to the target. If there is a descrepency, your login can fail. However, once way chap authentication is a minimum according to the standard and if your initiator offer this and the target mandates this, then there could be trouble during login. Dheeraj On Mon, Jan 19, 2009 at 2:57 PM, Nikhil Talpallikar nikhil.talpalli...@gmail.com wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. Why is this so? Does the iSNS server interfere with the login PDU??? -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) -- Simplicity of character is the natural result of profound thought. --~--~-~--~~~---~--~~ 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: iSNS discovery error (login)
I agree .. that is why I am having trouble (unable to connect the dots) .. and need some explanation if anyone has come across this kind of situation and solved it. Afterall what effect can iSNS discovery have on Login PDU ?? Just unable to connect and reason what I have observed. On Mon, Jan 19, 2009 at 3:23 PM, Dheeraj Sangamkar dheera...@gmail.comwrote: As far as I know, your transactions/sessions with the iSNS server and those with the iSCSI target should be independent. The iSNS can give you target information and you can use it to connect to target and login. Targets themselves are iSNS clients like your initiator. They register the information with the iSNS server that you as an iSNS client can use to connect to the target. If there is a descrepency, your login can fail. However, once way chap authentication is a minimum according to the standard and if your initiator offer this and the target mandates this, then there could be trouble during login. Dheeraj On Mon, Jan 19, 2009 at 2:57 PM, Nikhil Talpallikar nikhil.talpalli...@gmail.com wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. Why is this so? Does the iSNS server interfere with the login PDU??? -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) -- Simplicity of character is the natural result of profound thought. -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ 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: make open-iscsi userspace tools functionality available as a library
On Mon, Jan 19, 2009 at 2:07 PM, Hans de Goede hdego...@redhat.com wrote: Therefore we would like to export (some) of the functionality of iscsiadm as a C-library. Great ! I've got documentation of the proposed API here: http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html Not so great: libiscsi_get_error_string() This function can be called to get a human readable error string when a libiscsi function has returned an error. This function uses a static buffer thus the result is only valid as long as no other libiscsi calls are made after the failing function call. This makes it impossible to use libiscsi_get_error_string() in a safe way in multithreaded software. Furthermore, there are some minor spelling issues, e.g. cleanups. Shouldn't this be cleans up ? Bart. --~--~-~--~~~---~--~~ 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: make open-iscsi userspace tools functionality available as a library
Bart Van Assche wrote: On Mon, Jan 19, 2009 at 2:07 PM, Hans de Goede hdego...@redhat.com wrote: Therefore we would like to export (some) of the functionality of iscsiadm as a C-library. Great ! I've got documentation of the proposed API here: http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html Not so great: libiscsi_get_error_string() This function can be called to get a human readable error string when a libiscsi function has returned an error. This function uses a static buffer thus the result is only valid as long as no other libiscsi calls are made after the failing function call. That should read: This function uses a single buffer per context, thus the result is only valid as long as no other libiscsi calls are made on the same context after the failing function call. Actually this reminds me this function currently isn't even implemented. I'm planning on changing usr/log.c to make this possible. The idea is that dolog becomes a function pointer which can be pointer to either a function doing the current log_daemon behavior, or to one doing the current print to stderr behavior. Then the log_daemon variable can be removed, and libiscsi can supply its own logging function which can store the last error message. But before making these changes I first wanted to discuss this on this list, so are there any objections against this change? This makes it impossible to use libiscsi_get_error_string() in a safe way in multithreaded software. Well, as long as you use one context per thread, it should be safe, atleast API wise, unfortunately the used existing open-iscsi code is full of global variables. So thread safety will come as a future enhancement. Actually the only reason for the whole context paradigm in the current API is to allow a move over to thread safety in the future without breaking ABI. Furthermore, there are some minor spelling issues, e.g. cleanups. Shouldn't this be cleans up ? patches welcome :) Regards, Hans --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
WELCOME TO FREE WEB....................
FREE FREE FREE FREE FREE FREE http://freewebs.com/adolfsz/ *** --~--~-~--~~~---~--~~ 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: make open-iscsi userspace tools functionality available as a library
Boaz Harrosh wrote: Hans de Goede wrote: Hi All, The API currently offers pretty minimal functionality (just what we need in anaconda) I'm fine with extending this (patches welcome). But currently I would like to focus on the set of functionality as the current API offers and try to get that right. Most important here is to have a clean, clear and usable API which is also future proof, as I want to freeze the ABI of the available functions asap. WRT this I would especially like feedback on the futrue proofness of the libiscsi_node struct. First of all Thank you very much for doing this. I'm sure it will prove very useful in the future, the issue has been raised in the passed, multiple times. I can see that you have not attempted to refactor iscsiadm so to use the library. Which means you will be shipping the same exact code twice. If you look at the code you will see that there actually is not all that much duplication. Is your long term plan to do that once libiscsi is mature enough, or you would rather keep these two separate and duplicated? To keep them separate, see above. Regarding the API: - The overall state and division of labor looks very nice. :-) - libiscsi_discover_sendtargets - maybe (very maybe) the int port could be dropped and const char *address could be of the form address_or_host[:port]. Regarding defaults and all that. Nah, that is ok for a cmdline interface, but cumbersome for an API, we could do something where port == 0 would choose the default port though. - libiscsi_discover_isns - Looks like it is missing the actual input parameters usually a char *iqn I think? I've checked the (AFAIK currently incomplete) iscsiadm code and that does not have any parameters. Given that this is pretty much a pie in the sky, we could just remove this function completely for now. - libiscsi_discover_firmware - What is that for? Also missing an input parameter. This reads iscsi target info (portal and authentication info) from the BIOS of machines who support booting from iscsi, there is no input parameter, as machines tend to have only one BIOS (to query). - I can't help noticing the missing of query functions, Both query of DB of discovered Nodes, as well as info of logged-in nodes. Ack, those are not needed by anaconda, but should probably be added to make this more generally usefull, patches welcome :) - libiscsi_node_set_parameter - Question: (Sorry have not read the code) Is that persistent, gets saved in DB. Or is just for current session/login? Actually it only changes the database, so it will not influence parameters of the current session. I guess this needs better documentation making this clear. Regards, Hans --~--~-~--~~~---~--~~ 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: make open-iscsi userspace tools functionality available as a library
On Mon, Jan 19, 2009 at 4:35 PM, Hans de Goede hdego...@redhat.com wrote: - libiscsi_discover_sendtargets - maybe (very maybe) the int port could be dropped and const char *address could be of the form address_or_host[:port]. Regarding defaults and all that. Nah, that is ok for a cmdline interface, but cumbersome for an API, we could do something where port == 0 would choose the default port though. Have you considered to replace both const char *address and int port by const struct sockaddr *address, socklen_t address_len ? This would avoid having to figure out inside libiscsi_discover_sendtargets() whether the passed address is in IPv4 or in IPv6 format (if numeric). Bart. --~--~-~--~~~---~--~~ 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: Nodes and Sendtargets directories use after login?
HIMANSHU wrote: This is related to my this post. http://groups.google.com/group/open-iscsi/browse_thread/thread/40166b414bbda322/66ff12bbb I want to confirm my observations.If I am wrong,forgive me. Can I delete nodes and sendtargets once the discovery and login are done with 'target' from 'targetmachine1'? I am asking this for 'loginall' option. Suppose I want to login to all targets from ip say 192.168.30.56.Once discovery and login is done with previous machine 192.168.30.52,I wish to delete entries from nodes and sendtargets.then I will discover 192.168.30.56 where I may select 'loginall' option.At this time if I kept 30.52's entries still here,targets from it also get logged in which is not desired. Means after login to targets from 30.52,are these entries required at any instance?Then I cannot delete them. You cannot delete the dirs if you are logged in to them. If you use iscsiadm to delete the dirs (like doing iscsiadm -m node -T your_target -o delete), then in the current version it should check this for you and not let you do it. If you logged in and then logged out, then you can delete the dirs. Again iscsiadm checks this for you. --~--~-~--~~~---~--~~ 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: iSNS discovery error (login)
Nikhil Talpallikar wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do Are you doing iscsiadm -m discovery -t isns discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. It might be a bug in the open-iscsi setup code. Do you have the CHAP settings in /etc/iscsi/iscsid.conf ? Then when you do iscsiadm -m discovery -t isns for the targets found if you do iscsiadm -m node -T your_target -p ip:port When it spits out the node info do you see the CHAP settings that should get used? What version of the open-iscsi tools are using? Are then from open-iscsi.org or from a distro? Why is this so? Does the iSNS server interfere with the login PDU??? --~--~-~--~~~---~--~~ 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: iSNS discovery error (login)
Check your CHAP setting in your configure file. Vaibhav Pol On Tue, Jan 20, 2009 at 12:03 AM, Mike Christie micha...@cs.wisc.eduwrote: Nikhil Talpallikar wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do Are you doing iscsiadm -m discovery -t isns discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. It might be a bug in the open-iscsi setup code. Do you have the CHAP settings in /etc/iscsi/iscsid.conf ? Then when you do iscsiadm -m discovery -t isns for the targets found if you do iscsiadm -m node -T your_target -p ip:port When it spits out the node info do you see the CHAP settings that should get used? What version of the open-iscsi tools are using? Are then from open-iscsi.org or from a distro? Why is this so? Does the iSNS server interfere with the login PDU??? --~--~-~--~~~---~--~~ 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: iSNS discovery error (login)
hi, On Tue, Jan 20, 2009 at 12:03 AM, Mike Christie micha...@cs.wisc.eduwrote: Nikhil Talpallikar wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do Are you doing iscsiadm -m discovery -t isns yes discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. It might be a bug in the open-iscsi setup code. Do you have the CHAP settings in /etc/iscsi/iscsid.conf ? yes Then when you do iscsiadm -m discovery -t isns for the targets found if you do iscsiadm -m node -T your_target -p ip:port When it spits out the node info do you see the CHAP settings that should get used? yes What version of the open-iscsi tools are using? Are then from open-iscsi.org or from a distro? Its from a distro. RPM is open-iscsi-2.0.707-0.19.i586.rpm. Why is this so? Does the iSNS server interfere with the login PDU??? It can be a bug as you say. But where does the iSNS play a role in this bug. What I want to know is whether the initiator keeps some kind of mapping or a flag for targets discovered via iSNS??? -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ 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: iSNS discovery error (login)
hi, On Tue, Jan 20, 2009 at 12:03 AM, Mike Christie micha...@cs.wisc.edu wrote: Nikhil Talpallikar wrote: Hi, I cannot login to a target if I do a discovery via iSNS server, but if I do Are you doing iscsiadm -m discovery -t isns yes discovery using SendTarget method I can login I could figure out something.but i am not able to resolve it. When I do discovery via ST the req-flags (Login PDU flags) are set to ISCSI_FLG_CSG_SECURITY, which calls CHAP authentication method. But when I do a discovery via iSNS server req-flags are set to ISCSI_FLG_CSG_LOGIN due to which it does not use CHAP authentication. It might be a bug in the open-iscsi setup code. Do you have the CHAP settings in /etc/iscsi/iscsid.conf ? yes Then when you do iscsiadm -m discovery -t isns for the targets found if you do iscsiadm -m node -T your_target -p ip:port When it spits out the node info do you see the CHAP settings that should get used? yes What version of the open-iscsi tools are using? Are then from open-iscsi.org or from a distro? Its from a distro. RPM is open-iscsi-2.0.707-0.19.i586.rpm. Why is this so? Does the iSNS server interfere with the login PDU??? It can be a bug as you say. But where does the iSNS play a role in this bug. What I want to know is whether the initiator keeps some kind of mapping or a flag for targets discovered via iSNS which later interferes with the login PDU's CSG and NSG flags??? cheers, Nikhil -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ 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: make open-iscsi userspace tools functionality available as a library
On 19 Jan 2009 at 17:16, Boaz Harrosh wrote: [...] - libiscsi_discover_sendtargets - maybe (very maybe) the int port could be dropped and const char *address could be of the form address_or_host[:port]. Regarding defaults and all that. [...] I'd like to comment that I feel the libiscsi_ prefix is a bit too long. Wouldn't just iscsi_ or iSCSI_ be long enough? 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-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 -~--~~~~--~~--~--~---
