I just wanted to say it's available.
In a portage-tree near of ... ? I don't see it here in my tree.
Uhm, this was meant to be a version bump for sys-block/open-iscsi. Now, even open-iscsi-2.0-865.15.tar.gz is available. That version fixes http://bugs.gentoo.org/show_bug.cgi?id=197136 Maybe http://bugs.gentoo.org/show_bug.cgi?id=200355 should be included? I'd really glad to see it in portage! :) Sorry for my bad english.
*** Bug 202085 has been marked as a duplicate of this bug. ***
Created attachment 140592 [details] open-iscsi-2.0.865.15.ebuild
Comment on attachment 140592 [details] open-iscsi-2.0.865.15.ebuild the open-iscsi kernel module has been merged into the mainstream kernel, so we should skip compile kernel modules here.
Created attachment 140595 [details] open-iscsi-2.0.865.15.ebuild the open-iscsi kernel module has been merged into the mainstream kernel, so we should skip compile kernel modules here.
kingtaco: yours now.
Created attachment 141566 [details] sys-block/open-iscsi-2.0.865.15.ebuild changelog: - use CONFIG_CHECK="SCSI_ISCSI_ATTRS ISCSI_TCP" from linux-info.class to check the kernel configuration - install some other utilities from open-iscsi, (iscsi-iname, fwparam_ibft, ...)
from http://www.open-iscsi.org/: the iscsi support in the kernel before (April 11, 2005) is linux-iscsi, and after that linux-iscsi and open-iscsi merged! so a better approache to package this is auto detect the kernel version: 1) if the kernel lower than 2.6.23, compile and use the modules shipped with open-iscsi tarball; 2) the kernel version (up with 2.6.23), use the modules from the kernel; But I have no much machines to test.
(In reply to comment #9) > from http://www.open-iscsi.org/: > > the iscsi support in the kernel before (April 11, 2005) is linux-iscsi, and > after that linux-iscsi and open-iscsi merged! > > so a better approache to package this is auto detect the kernel version: > > 1) if the kernel lower than 2.6.23, compile and use the modules shipped with > open-iscsi tarball; > 2) the kernel version (up with 2.6.23), use the modules from the kernel; > > But I have no much machines to test. > It seems that this package is ALSA like, the modules inside are generally more up to date than the kernel variants.
Denis, you patch fails for me: * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /root/OVERLAY/sys-block/open-iscsi/files/remove-kernel-and-init-to-makefile.patch * ( remove-kernel-and-init-to-makefile.patch ) * * ERROR: sys-block/open-iscsi-2.0.865.15 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 3135: Called epatch 'src_unpack' * environment, line 1432: Called die * The specific snippet of code: * die "Cannot find \$EPATCH_SOURCE!"; * The die message: * Cannot find $EPATCH_SOURCE! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portagelog/sys-block:open-iscsi-2.0.865.15:20080305-221438.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-block/open-iscsi-2.0.865.15/temp/environment'. * This ebuild is from an overlay: '/root/OVERLAY/' Would you attach it? Also, your version should be based on open-iscsi-2.0.865.12.ebuild and not an older version, Robins version looks much different. Kingtaco is in away status "on hiatus until sometime in april." :( Could we get this to run on 2.6.24 at least? I've got several machines & some time for testing... http://www.open-iscsi.org/bits/open-iscsi-2.0-868-rc1.tar.gz works flawless for me, an ~x86 ebuild would be extremly cool...
No one interested in helping out? I hereby offer 25€ (as a private person, not from my company - we don't use/plan to use iSCSI) via IBAN to the one writing/integrating an ebuild for open-iscsi-2.0.865.15 (or open-iscsi-2.0-868-rc1?) that works with kernel 2.6.24-r3 within 4 weeks from now. (Yes, I really WANT to try it and don't like to manually install the package, this systems runs for years without reinstalling and I don't want to start messing around with manually installed packages...I know, 25€ is not much - it's just meant to be some kind of "thank you for your help/time" present because I am unable to write that ebuild and integrate it myself. This is a bit unusual though, I confess...) kingtaco is in devaway status so he can't do it and I'd really like to play around with it, though.
(In reply to comment #12) > No one interested in helping out? > I hereby offer 25€ (as a private person, not from my company - we don't > use/plan to use iSCSI) via IBAN to the one writing/integrating an ebuild for > open-iscsi-2.0.865.15 (or open-iscsi-2.0-868-rc1?) that works with kernel > 2.6.24-r3 within 4 weeks from now. (Yes, I really WANT to try it and don't like > to manually install the package, this systems runs for years without > reinstalling and I don't want to start messing around with manually installed > packages...I know, 25€ is not much - it's just meant to be some kind of > "thank you for your help/time" present because I am unable to write that ebuild > and integrate it myself. This is a bit unusual though, I confess...) > > kingtaco is in devaway status so he can't do it and I'd really like to play > around with it, though. > Do you want the kernel modules or only the tools provided by the package itself?
AFAIK I need the (newer?!) modules in the package for 868-r1 and the modules shipped with 2.6.24-r3 work fine with open-iscsi-2.0.865.15? I'd prefer open-iscsi-2.0.865.15 with "normal" kernel modules then. I'm not sure though - I just want to get it to work...
Created attachment 145697 [details] open-iscsi-2.0.868-r1.ebuild
Created attachment 145699 [details] iscsid-conf.d for open-iscsi-2.0.868-r1.ebuild
Created attachment 145700 [details] init.d script for open-iscsi-2.0.868-r1.ebuild
Ok, I confess that it took me a few hours (I'm not writing ebuild that often and ran into very strange problems because of fwparam_ibft), but I guess: I DID IT! - use flags "modules utils debug": you compile without modules and without utils if you don't set the use-flags! - changed init.d script a lot, now also uses conf.d/iscsid - deleted dump() in init.d script - corrected wrong path for iscsid.conf and initiatorname.iscsi in ebuild - cleaned up ebuild a lot - fixes bugs #212402 and #195609
(In reply to comment #18) > Ok, I confess that it took me a few hours (I'm not writing ebuild that often > and ran into very strange problems because of fwparam_ibft), but I guess: I DID > IT! > > - use flags "modules utils debug": you compile without modules and without > utils if you don't set the use-flags! > - changed init.d script a lot, now also uses conf.d/iscsid > - deleted dump() in init.d script > - corrected wrong path for iscsid.conf and initiatorname.iscsi in ebuild > - cleaned up ebuild a lot > - fixes bugs #212402 and #195609 > Looks good Craig. Now that we're building iscsi-iname, maybe the ebuild can generate an initiator name using that utility and the hostname as template if one doesn't exist already? Most other distros such as Debian do this.
*** Bug 212402 has been marked as a duplicate of this bug. ***
Created attachment 145703 [details] init.d script for open-iscsi-2.0.868-r1.ebuild
Created attachment 145704 [details] init.d script for open-iscsi-2.0.868-r1.ebuild
The new init.d fixes #200355.
Kamil, I didn't see your post, I also integreted it in a new ebuild. iscsi-iname says for my host: iqn.2005-03.org.open-iscsi:bd76d419c2e And I have no clue where it gets that from. >the hostname as template What do you mean`
Uhm, I meant "in a new init.d script", not "in a new ebuild".
Nevermind, I just looked at the init.d file, the way it does it is fine as is. Thanks :)
Added base-system@gentoo.org, maybe one of them can have a look and add it to portage?
*bump*
If I can make a recommendation to the config files and the ebuild: append -${PV} to the iscsid-conf.d and iscsid-init.d files, and make the same modification in the ebuild.
One more correction, regarding my previous comment of the automatically generated IQN. I finally got to testing this ebuild today, and the way it generates the IQN is incorrect and does not match the standard. If you read the relevant section of RFC3720: http://tools.ietf.org/html/rfc3720#section-3.2.6.3 , you will see that an IQN should be generated with the year the domain name was registered, and then the domain name in reverse. I think this is probably too difficult to implement in the init script as this information may not necessarily be available or accessible through DNS at time of install. The way Debian has solved this problem is that they use the DNS for debian.org, eg: iqn.YYYY-DD.org.debian:<random string> or something to that effect, since they're the ones shipping the initiator.
(In reply to comment #30) > One more correction, regarding my previous comment of the automatically > generated IQN. I finally got to testing this ebuild today, and the way it > generates the IQN is incorrect and does not match the standard. > > If you read the relevant section of RFC3720: > http://tools.ietf.org/html/rfc3720#section-3.2.6.3 , you will see that an IQN > should be generated with the year the domain name was registered, and then the > domain name in reverse. I think this is probably too difficult to implement in > the init script as this information may not necessarily be available or > accessible through DNS at time of install. > > The way Debian has solved this problem is that they use the DNS for debian.org, > eg: iqn.YYYY-DD.org.debian:<random string> or something to that effect, since > they're the ones shipping the initiator. > So what is wrong with the way we (/I) did it now? It takes your hostname and the day you first start the service... if you want to be clever you should have set it yourself and not trust an automatic (out of the box working) name.
Well, the problem is that the auto generated IQN is not RFC compliant. The date is supposed to be the date in which the domain was first registered, and the name should be the reversed domain. So if I registered example.com in June of 2006, the IQN would start as: iqn.2006-06.com.example Since it's probably too hard to determine this information automatically, I think we should follow Debian's example and have the auto-generated IQN reflect that of the Gentoo.org domain and begin with the prefix iqn.1999-10.org.gentoo
(In reply to comment #32) > Well, the problem is that the auto generated IQN is not RFC compliant. The date > is supposed to be the date in which the domain was first registered, and the > name should be the reversed domain. So if I registered example.com in June of > 2006, the IQN would start as: iqn.2006-06.com.example There is no registration date of example.local, only date of first use. Anyway implement what you want :) I think this is the most clean vendor independent solution.
* "IQN-Issue": >Since it's probably too hard to determine this information automatically It's not. My solution for generating the IQN did not work correctly, FIXED now (RFC3720 compatible), please note that we're the initiator, not the target. * Naming of the ebuild was wrong (r1 instead of rc1). FIXED. * Naming of iscsid-conf.d and iscsid-init.d changed, see #29.
Created attachment 147185 [details] open-iscsi-2.0.869.ebuild
Created attachment 147186 [details] iscsid-2.0.869.init.d
Created attachment 147187 [details] iscsid-2.0.869.conf.d
I've added 2.0.868_rc1 to the tree and package.masked it for testing. When I get my hardware back, I'll test and remove from p.mask then. Thanks for the ebuild and conf/init.d.
Thanks! Fixed topic from -r1 to _rc1.
From http://www.open-iscsi.org/: "The current semi-stable release: open-iscsi-2.0-869.tar.gz" I've confirmed that the above ebuild for 2.0.868_rc1 which I had modified earlier, works flawlessly for open-iscsi-2.0.869 with Kernel 2.6.25-r1 if re-named accordingly! This shows that I've written a not-so-crappy ebuild. =) Mike, it would be cool if you could put this into portage (masked) instead of 2.0.868_rc1! It would be also very cool, if you had your gear back and some time for testing, so we can make people happy! :)
I noticed that it's possible to rename the attachments, so I did that. :)
Topic changed accordingly (forgot it yesterday, sorry for the bugspam).
Comment on attachment 147187 [details] iscsid-2.0.869.conf.d ><HTML><HEAD/><BODY><PRE># /etc/conf.d/iscsid > ># config file to use >CONFIG_FILE=/etc/iscsi/iscsid.conf > ># you need to specify an initiatorname in the file >INITIATORNAME_FILE=/etc/iscsi/initiatorname.iscsi > ># options to pass to iscsid >OPTS="-i ${INITIATORNAME_FILE} -c ${CONFIG_FILE}" > ></PRE></BODY></HTML>
Created attachment 152853 [details] iscsid-2.0.869.conf.d CONFIG_FILE was not used in OPTS (which is the parameter for iscsid in the init.d script)
FYI - the init script fails to start if... scsi_transport_iscsi libiscsi iscsi_tcp are built into the kernel rather than as modules. I rebuilt the kernel with these as modules and so far so good, but originally had them built in to the kernel and the init script fails - dmesg was reporting that the module "scsi_transport_iscsi" could not be found when built as kernel, so something is actually looking for this to be a module. Thanks for the ebuild!
Created attachment 159650 [details] iscsid-2.0.869.2.conf.d
Created attachment 159652 [details] iscsid-2.0.869.2.init.d
Created attachment 159654 [details] open-iscsi-2.0.869.2.ebuild
New version, Changelog: open-iscsi-2.0.869.2.ebuild: - versionator change iscsid-2.0.869.2.init.d: - uses now modprobe -l to check if a modules exists, if so, it tries to load it (I had to use grep, because modprobe -l does always return 0), should fix #45.
I've talked to Mike a few days ago on IRC, we can hope that 2.0.869.2 hits the tree in the near future. :)
Uhm, could you update it in the tree? The current version is broken! :(
This is not an enhancement, open-iscsi from the tree is broken. Changing to "major loss of function" (I guess a package that does not work at all fits into that category).
Version 2.0-870-rc3 available.
I'll release an ebuild when it's not -rc anymore.
The maintainer does not seem to be active anymore: :( http://cia.vc/stats/author/kingtaco base-system or anyone else: Can this be changed to maintainer-wanted (or what would have to happen so that it can)?! I'm going to provide new ebuilds as attachment here, anyone might feel free to bump this bug, if a new stable version is out.
Created attachment 170907 [details] iscsid-2.0.869.2.init.d changelog: add support for autologin to iscsi-targets as in debian-init-file
Created attachment 170952 [details] open-iscsi-2.0.870.ebuild
Created attachment 170953 [details] iscsid-2.0.870.conf.d Added a switch for starting automatic targets when iscsid is started
Created attachment 170955 [details] iscsid-2.0.870.init.d - lots of small fixes - additional error handling when loading modules - added switch for starting automatic targets when iscsid is started - when stopping iscsid, all targets are sync()ed and disconnected - new status() method - Thanks to Marcel!
Well, open-iscsi-2.0-870 is out, the 2.0.869.2 ebuild works fine for 2.0.870 on 2.6.25-gentoo-r8 and 2.6.27-r2 (both x86). Please test! Quickinstall guide for the lazy ones: Disable iscsi in the Kernel export PORTAGE_OVERLAY="~/OVERLAY" mkdir -p ~/OVERLAY/sys-block/ cp -r /usr/portage/sys-block/open-iscsi ~/OVERLAY/sys-block/ cd sys-block/open-iscsi wget "http://bugs.gentoo.org/attachment.cgi?id=170955" -O files/iscsid-2.0.870.init.d wget "http://bugs.gentoo.org/attachment.cgi?id=170953" -O files/iscsid-2.0.870.conf.d wget "http://bugs.gentoo.org/attachment.cgi?id=170952" -O open-iscsi-2.0.870.ebuild USE="modules utils" ebuild open-iscsi-2.0.870.ebuild digest merge Have fun!
Created attachment 171049 [details] iscsid-2.0.870.conf.d changed AUTOSTARTTARGETS from "true/false" to "yes/no" as is customary
Created attachment 171050 [details] iscsid-2.0.870.init.d uses AUTOSTARTTARGETS from conf.d-file in init-script
2.0.870 is finally in CVS. Thanks to $everyone :)
Created attachment 174253 [details] iscsid-2.0.870.init.d init-script including check if /etc/conf.d/iscsid and INITIATOR_FILENAME is not empty exists. if you did not check this and INITIATOR_FILENAME is empty then grep did not get an file to grep through, which cause an deadlock.
if [[ "x${INITIATORNAME_FILE}" = "x" ]]; then Will match, even if ${INITIATORNAME_FILE} does not exist. -e might be better than -f for the filechecks.
Created attachment 174255 [details] iscsid-2.0.870.init.d
Could "someone" *cough* commit the new init.d? ;)
(In reply to comment #67) > Could "someone" *cough* commit the new init.d? ;) > tested the changes and committed as -r1. Thanks guys! :)
Created attachment 185469 [details] open-iscsi-2.0.870.3.ebuild Clean up with the files/*.init.d and files/*.conf.d situation: if there is a special version for the ${PV}, use that (for downwards compatibility). Also, do not update /etc/iscsi/initiatorname.iscsi, it's no use.
Created attachment 185471 [details] iscsid-2.0.870.3-init.d Just create ${INITIATORNAME_FILE}, if it's not there or does not contain the needed ^InitiatorName=iqn... line.
Created attachment 185472 [details] iscsid-2.0.870.3.init.d Sorry, wrong $Header: line.
files/iscsid-2.0.870.init.d-r1 needs to be moved to files/iscsid-2.0.870-r1.init.d http://bugs.gentoo.org/attachment.cgi?id=185472 has to be saved as files/iscsid-init.d (or files/iscsid-2.0.870.3.init.d but that will fill the filesdir on longterm...)
2.0.870.3 in CVS. Next time file a fresh'n'shiny new bug - please! ;)
