Description of problem: Anaconda does not seem to have fields in the UI where the user can enter CHAP information to connect to an iSCSI target and install the OS onto a LUN. Since RHEL 5.1 provides native support for iSCSI boot/install without iBFT support, the user must be allowed to input CHAP/Mutual CHAP parameters via the installer GUI. Version-Release number of selected component (if applicable): RHEL 5.1 Server How reproducible: Since the UI in the anaconda installer has no fields for CHAP UserName and Password, this issue is reproducibe whenever someone tries to connect to a target LUN that expects CHAP authentication. Steps to Reproduce: 1. Enable CHAP on an iSCSI target. 2. Ensure iscsi adapter makes a connection to the target (Before int 13 via Option ROM) 3. Attempt to add an iscsi disk during install observe install fails. Actual results: Install to remote LUN fails (CHAP authentication fails, and the target LUN does not show up in the list of HDs to install) Expected results: It is expected that the user will be given a way to enter CHAP information by Anaconda for authentication to proceed, and upon success the user will be able to see the target LUN. Additional info: If Anaconda can pull information from the iBFT (iSCSI Boot Firmware Table) in future releases, the CHAP information (if any) can be retrieved from there to send to the target at time of install.
*** Bug 432820 has been marked as a duplicate of this bug. ***
*** Bug 437201 has been marked as a duplicate of this bug. ***
=Comment: #0================================================= L. C. McDermott <mcdermoc.com> - 2008-03-12 15:46 EDT See Red Hat BZ 307761. This BZ is being opened to track inclusion of patch attached to 307761, which missed RHEL5.2. ===================================================================================================== Redhat BTW, this patch is missing kickstart support. We need the community to help us out here so that we don't regress anything. =Comment: #3================================================= L. C. McDermott <mcdermoc.com> - 2008-03-12 15:59 EDT This bug was opened because of the confusion surrounding multiple issues being addressed by Red Hat feature bugzilla 307761 - iSCSI Boot Firmware Table tool support [anaconda]. iBFT support was added to RHEL5.2, however, CHAP support was missing. Red Hat decided that adding the Anaconda CHAP support was too risky and deferred this to RHEL5.3. Comments from original bug: [edit] latest version of the anaconda patch Comment #39 From Mark Hamzy (hamzy.com) on 2008-02-19 15:59 EST [reply] All that is missing from the anaconda patch on 2/12 is support for the reverse chap username/password in kickstart. I was asking for help from redhat/kickstart community because I didn't want to break anything. Comment #40 From Martin Sivák (msivak) on 2008-02-20 04:46 EST [reply] Unfortunately it is too late to push the reverse CHAP stuff into 5.2. The best way how to push it into 5.3 is to fill a new bug, which will get approval for next release. After that we can start working on incorporating it into the RHEL tree. *** This bug has been marked as a duplicate of 432819 ***
Created attachment 302887 [details] Add CHAP support to Anaconda
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Red Hat - Due to timing it looks like this missed RHEL 5.2. Is this going to be fixed in RHEL 5.3? (It doesn't look like this has been updated since 6/12/08.)
Committed in git's "rhel5-branch", should be in 11.1.2.122 .
Created attachment 316110 [details] Patch that adds needed functionality to iscsi-initiator-utils This patch to iscsi-initiator-utils is also needed to fully support this feature.
Mike, how do you want to handle the patch in comment #9 ?
(In reply to comment #10) > Mike, how do you want to handle the patch in comment #9 ? I can merge it. I was about to do a update today so I will just merge this too. Do you need the patch because anaconda parses the iscsiadm output when it logs in? I thought IBM's patch did not need any iscsiadm changes. Is the anaconda git tree on git.engineering.redhat.com?
Well, this patch to iscsiadm basically just keeps feature parity between systems using iBFT and systems /not/ using it. Without it, we can still do the actual feature, but iBFT systems won't work right if CHAP is being used. With the patch, both ways work.
(In reply to comment #12) > Well, this patch to iscsiadm basically just keeps feature parity between > systems using iBFT and systems /not/ using it. Without it, we can still do the > actual feature, but iBFT systems won't work right if CHAP is being used. With > the patch, both ways work. Can you send a link to the git tree, so I can clone it and check out the code? I was thinking that for ibft/open-firmware + CHAP, we were going to do something like is done for the initiator name where the anaconda _queryFirmware code would grab the CHAP info from the ibft/open-firmware, and then it was going to display it automatically like is done for the initiator name. This output example in anaconda/iscsi.py: def _queryFirmware(self): # Example: # [root@elm3b87 ~]# iscsiadm -m fw # iface.initiatorname = iqn.2007-05.com.ibm.beaverton.elm3b87:01 # iface.hwaddress = 00:14:5e:b3:8e:b2 # node.name = iqn.1992-08.com.netapp:sn.84183797 # node.conn[0].address = 9.47.67.152 # node.conn[0].port = 3260 actually also prints out: node.session.auth.username = some_string_if_set_in_fw node.session.auth.password = some_string_if_set_in_fw node.session.auth.username_in = some_string_if_set_in_fw node.session.auth.password_in = some_string_if_set_in_fw if chap is used. So for ibft/open-firmware you could get the chap settings from there and display them in the anconda dialog boxes if that is what you needed.
Peter, did you still need the patch in comment #9 or did you get the CHAP info from the firmware (iscsiadm -m fw) command like in comment #13?
I ran iSCSI testing on the RHEL5.1 Snap1 (RHEL5.3-Server-20081029.0-x86_64-DVD.iso) 1.) No CHAP iBFT worked fine as expected. 2.) CHAP with 12 character passwords (see comment below) allows the iSCSI device to be initialized and presented as a install device but on first boot the system fails to load the initrd. I retried the install and prior to the post install reboot I examine the contents of the /boot partition and noticed that it contained no initrd. 3.) There appears to be a minor issue with the iscsiadm output if the chap passwords are 16 characters. When I . I attached out of the iscsiadm -m fw output when the passwords where 16 characters. When the passwords where this long it caused the iscsi device to not be presented as an install device post iscsi initialization I have attached anaconda logs for the three cases.
Created attachment 322554 [details] nochap anaconda log Successful iSCSI install w/no_chap
Created attachment 322555 [details] anaconda log iscsi w/chap Failed iSCSI install w/chap
Created attachment 322556 [details] iSCSI CHAP 16 character iscsiadm output iSCSI CHAP 16 character iscsiadm output
(In reply to comment #16) > 3.) There appears to be a minor issue with the iscsiadm output if the chap > passwords are 16 characters. When I . I attached out of the iscsiadm -m fw > output when the passwords where 16 characters. When the passwords where this > long it caused the iscsi device to not be presented as an install device post > iscsi initialization > The 16 char limit is from: struct boot_context { char chap_name[127]; char chap_password[16]; char chap_name_in[127]; char chap_password_in[16]; The array is 16 chars so the max password is 15 (1 char is for terminating null). I think this code came with the initial ibft and ppc patches from IBM that added the initial ibft and ppc support. Is the IBM person that tested this in contact with the IBMer that did the devel by any chance?
(In reply to comment #21) > I think this code came with the initial ibft and ppc patches from IBM that > added the initial ibft and ppc support. Is the IBM person that tested this in > contact with the IBMer that did the devel by any chance? It looks like this was a mistake. I can easily increase the max password length for 5.3.
(In reply to comment #29) > ------- Comment From mchristi 2008-11-05 13:58:22 EDT------- > (In reply to comment #21) > > I think this code came with the initial ibft and ppc patches from IBM that > > added the initial ibft and ppc support. Is the IBM person that tested this in > > contact with the IBMer that did the devel by any chance? > > It looks like this was a mistake. I can easily increase the max password length > for 5.3. > Yes it looks like the sizing was carried forward from some past code and never validated against larger string sizes. Increasing to a more standard size would be good, Thanks Mike C,
Peter, Did you see my comment #14 and #13? What do you think? Did you find a different way to grab the chap info? If not I think this is IBM's #2 in comment 16. If you did change the anaconda code so it did not need the patch was there a regression or mismerge, because I think there is another bug that was readded in 5.3? If I am using ibft with a CD based install, when I get to the Partitioning stage should the network be setup and the iscsi disks found (disks found with the ibft info) already be in the "Select the drive(s) to use for the this installation" box? With RHEL5.3-Server-20081020.1, if I go to a cmdline when I see the Partition screen ifconfig prints out nothing and iscsiadm shows no sessions and in the logs it shows that iscsiadm tried to connect to the target ip from the ibft info but could not because the network is down. I have to go through the network setup page and then enter the ip address and chap info, and only the initiator name was grabbed from the ifbt info. However, if I am using ibft but doing a net install, then when I get to the Partitioning stage the network is already setup and the disks are found. I thought the network setup issue when using CD based install was fixed in 5.2? And why does the iscsi setup screen only show the initiator name from ibft and not the chap and target ip info? Is that because normally the ibft storage would be setup automatically so we should not have to go to the iscsi setup screen and so it does not matter?
I'm pretty sure we still need the patch, but it's not fresh in my mind, so I'll investigate further tomorrow.
(In reply to comment #24) > Peter, > > Did you see my comment #14 and #13? What do you think? Did you find a different > way to grab the chap info? If not I think this is IBM's #2 in comment 16. We definitely still need the patched iscsiadm to do chap+ibft. > If you did change the anaconda code so it did not need the patch was there a > regression or mismerge, because I think there is another bug that was readded > in 5.3? If I am using ibft with a CD based install, when I get to the > Partitioning stage should the network be setup and the iscsi disks found (disks > found with the ibft info) already be in the "Select the drive(s) to use for the > this installation" box? With RHEL5.3-Server-20081020.1, if I go to a cmdline > when I see the Partition screen ifconfig prints out nothing and iscsiadm shows > no sessions and in the logs it shows that iscsiadm tried to connect to the > target ip from the ibft info but could not because the network is down. I have > to go through the network setup page and then enter the ip address and chap > info, and only the initiator name was grabbed from the ifbt info. > > However, if I am using ibft but doing a net install, then when I get to the > Partitioning stage the network is already setup and the disks are found. I > thought the network setup issue when using CD based install was fixed in 5.2? I thought so as well... > And why does the iscsi setup screen only show the initiator name from ibft and > not the chap and target ip info? Is that because normally the ibft storage > would be setup automatically so we should not have to go to the iscsi setup > screen and so it does not matter? Well, you shouldn't see the iscsi setup screen at all if you're using ibft. If not using ibft, then you should see it, and it includes chap in/out name/password entry boxes.
(In reply to comment #28) > (In reply to comment #24) > > Peter, > > > > Did you see my comment #14 and #13? What do you think? Did you find a different > > way to grab the chap info? If not I think this is IBM's #2 in comment 16. > > We definitely still need the patched iscsiadm to do chap+ibft. > Is there another way? Upstream does not like it because they do not like the extra output in the login command (we should be using the existing commands that spit out this info already and not adding extra info if we can) and because it is the user's password that is getting spit out they are extra sensitive to what is getting spit out. Do you just need a way to tell if we are using CHAP or not? For ibft we should not care about the actual values because iscsiadm (iscsiadm in anaconda) /iscsistart (iscsistart in the initramfs) will dynamically read those values from the ifbt info when we those programs are run. And so the initramfs boot and code should not ever have to know that we are using chap and ibft. And the anaconda code would never have to know if we are using chap and ibft since we do not display that info. For non-ibft boot we need the chap info so we can pass it to iscsistart in the initramfs and we need it for install so anaconda can pass it to iscsiadm, but for just the boot part I thought that worked already in 5.2 (there was initramfs code). For 5.3 we just needed a way for anaconda to pass the chap values to the iscsi code didn't we or did we need more? I can add some other way to split out what you need that will make everyone happy if you want me to.
(In reply to comment #16) > 2.) CHAP with 12 character passwords (see comment below) allows the iSCSI > device to be initialized and presented as a install device but on first boot > the system fails to load the initrd. I retried the install and prior to the > post install reboot I examine the contents of the /boot partition and noticed > that it contained no initrd. I can replicate this here, and we're slowly making some progress in private mail with mchristie.
Mike, I'm cloning this BZ so you have a 5.3 one to submit the iscsi patch against.
OK, the companion BZ for the anaconda part of this is 472927, assigned to pjones
The iscsi parts are in iscsi-initiator-utils-6.2.0.868-0.16.
The anaconda fix for this problem is found in anaconda 11.1.2.160-1
Created attachment 326547 [details] anaconda log 5.3 snap5
Created attachment 326548 [details] anaconda exception dump 5.3 snap5
I attempted an install of rhel5.3 snap5 to an iSCSI target using iBFT data (no chap) and received an exception during the "Initializing iSCSI Initiator" message box prior to getting to the select appropriate keyboard selection. I have attached the log files. I will rerun with CHAP added to iBFT. I
I hit this here too with snap5. If chap is used it works fine. I am going to check out the nightly build to verify it was not fixed in some other anaconda version.
Thanks for the traceback. I've prepared an updates.img which should fix the non CHAP iBFT case: http://people.atrpms.net/~hdegoede/updates432819.img Add "updates=http://people.atrpms.net/~hdegoede/updates432819.img" to the boot commandline when starting anaconda to use this. Please let us know if this fixes things.
The attached updates.img fixes this problem in our local testing. Mike, Chris, if you have access to this hardware could you please also sanity-check this? And IBM, if you would like to try the updates.img and report here, we'd really appreciate it. This is the fix that we would plan for the 5.3 RC, which closes next Wednesday, so any early validation would be a huge help. Thanks!
Created attachment 326651 [details] The PATCH in the updates.img fixing this For those interested here is a patch with the actual changes in the updates.img fixing this.
I tried using the http method. I referenced both the atrpms site and and internal http site, but anaconda could not access the updates. Here is the log output for the local http "21:07:02 ERROR : no DNS servers, can't look up hostname 21:07:02 INFO : file location: http://9.47.56.70/~andmike/public/updates432 32819.img 21:07:02 INFO : transferring http://9.47.56.70//~andmike/public/updates4328 2819.img to a fd 21:07:02 INFO : redirecting to http://bvrgsa.ibm.com/~andmike/public/update es432819.img 21:07:02 DEBUG : url address bvrgsa.ibm.com 21:07:02 DEBUG : url prefix /~andmike/public/updates432819.img 21:07:02 ERROR : we don't have reverse DNS for IPv6 yet 21:07:02 ERROR : failed to retrieve http://9.47.56.70///~andmike/public/upda ates432819.img I am remote today so I cannot use the floppy method. I will be in the lab tomorrow so I can try the floppy update method.
Patch in anaconda-11.1.2.164-1.
I did a iSCSI install test using RHEL5.3-rc1 (RHEL5.3-Server-20081218.1-x86_64-DVD.iso). This iso appeared to contain anaconda-11.1.2.168-1 and iscsi-initiator-utils-6.2.0.868-0.18 A iSCSI install with CHAP values fails. A iSCSI install completed successfully when no CHAP was configured. The no CHAP installed system also picked up the correct CHAP values when I switched to one-way and mutual CHAP values. When I try to install with the CHAP values set I am presented with no install device in the installation drive selection box. Here is a snip from the anaconda log showing that the iBFT data was picked up, but then it appears the sendtargets method was used. I can attach the complete log if needed. 06:21:56 INFO : ISCSIADM is /usr/sbin/iscsiadm 06:21:56 DEBUG : Setting up /etc/iscsi/initiatorname.iscsi 06:21:56 INFO : iSCSI initiator name iqn.2008-06.com.ibm:bpx86 06:21:56 INFO : iSCSI startup 06:21:58 DEBUG : iscsiadm -m fw 06:21:58 DEBUG : iscsiadm result: # BEGIN RECORD iface.initiatorname = iqn.2008-06.com.ibm:bpx86 iface.hwaddress = 00:14:5e:b3:8e:b2 iface.bootproto = STATIC iface.ipaddress = 9.47.69.244 iface.subnet_mask = 255.255.255.0 iface.gateway = 9.47.69.1 iface.vlan = 0 iface.net_ifacename = eth1 node.name = iqn.1992-08.com.netapp:sn.84183797 node.conn[0].address = 9.47.69.151 node.session.auth.username = linuxhostout node.session.auth.password = 222222333333 node.session.auth.username_in = linuxhostin node.session.auth.password_in = 333333222222 node.boot_lun = 00000000 # END RECORD 06:21:58 DEBUG : iscsiadm -m discovery -t st -p 9.47.69.151 06:21:58 DEBUG : 06:21:58 WARNING : no record found! 06:21:58 WARNING : unable to find portal information As a debug step from the install shell prompt I ran "iscsiadm -m fw -l" then moved back a step in the installation before proceeding. The sd device attached by the previous iscsiadm operation was presented and I used it as an install device. The installation completed successfully but the first boot did not completed successfully.
IBM, thanks for the feedback. At this point, its too late to do anything to fix the issues you've encountered, unless you can argue that they're release blockers. In which case, you'll need to make your case strong and very quickly. Otherwise, please clone this bug and request that it be considered for inclusion in the 5.4 update.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: See comment 60.
(In reply to comment #50) > IBM, thanks for the feedback. At this point, its too late to do anything to fix > the issues you've encountered, unless you can argue that they're release > blockers. In which case, you'll need to make your case strong and very quickly. > Otherwise, please clone this bug and request that it be considered for > inclusion in the 5.4 update. > Chris, would it be possible to get feedback on the last anaconda patch if the behavior I descibed in my last comment is the correct expected behavior based on the changes. We went from the 5.2 behavior of no CHAP support in the install, to CHAP working but broken no CHAP support, back to pretty much 5.2 behavior. I believe Mike C was out sick so I do not know if he is back online yet, but he also mentioned that Hans de Goede <hdegoede> may be able to comment also. Thanks.
(In reply to comment #64) > (In reply to comment #50) > > IBM, thanks for the feedback. At this point, its too late to do anything to fix > > the issues you've encountered, unless you can argue that they're release > > blockers. In which case, you'll need to make your case strong and very quickly. > > Otherwise, please clone this bug and request that it be considered for > > inclusion in the 5.4 update. > > > > Chris, would it be possible to get feedback on the last anaconda patch if the > behavior I descibed in my last comment is the correct expected behavior based > on the changes. We went from the 5.2 behavior of no CHAP support in the > install, to CHAP working but broken no CHAP support, back to pretty much 5.2 > behavior. I believe Mike C was out sick so I do not know if he is back online > yet, but he also mentioned that Hans de Goede <hdegoede> may be able > to comment also. Yes I can comment. After seeing your comment 61, I immediately investigated. I didn't comment as my conclusion was the same as Chris' conclusion. About the chap going from non-working to working to non-working, things are a bit more complicated then this. As I do not have access to iBFT capable hardware (*) this is all from what I've learned by carefully reading the code. In 5.2 we did not have iBFT support, nor did we have support for chap authentication. It was possible to add iscsi disks by pressing the advanced storage button, then entering the IP address + port of an iscsi device. This device needs to support sendtargets discovery and have its portal on the same IP as it listens for discovery. In 5.3 we've added support for CHAP and reverse CHAP authentication to the iscsi support behind the advanced storage button. The implementation of this assumes that the username/password for the sendtargets discovery are the same as those for actually logging in to the disk (the portal to the target). Last time I tested (pretty recently) this still worked, so afaik this is still working. We also added support for automatically discovering and using iscsi disks through iBFT, this has the same constraints as the non iBFT case (must support sendtargets discovery, same IP for discovery and portal) and this initially did not support CHAP. Much work has been done to add CHAP support, but unfortunately something (what is not entirely clear yet) broke CHAP support in the last moment (**). Some last minute fixes also broke non CHAP iBFT, that cause of this was a "simple" python syntax error, which has been fixed. The fix for this is not what caused the iBFT CHAP support to break. Given the above I'm afraid we will have to live with a workaround for the CHAP using iBFT case for 5.3. I think the following will work, it would be much appreciated if you can test this, then we can make a release note describing this work around: On the partitioning options screen press "advanced storage" and then select "add iscsi disk", and then fill in the discovery IP and portal and the CHAP authentication information manually. As noted before: 1) The discovery and portal IP's must be the same 2) The discovery and portal authentication information must be the same *) That is being remedied, a card has been send by our supplier today and I'm expecting the postal services to deliver it to my office somewhere this week. **) Judging from you report, as said I do not have hardware so I've not reproduced this yet.
Deleted Release Notes Contents. Old Contents: See comment 60.
(In reply to comment #53) > Yes I can comment. After seeing your comment 61, I immediately investigated. I > didn't comment as my conclusion was the same as Chris' conclusion. > > About the chap going from non-working to working to non-working, things are a > bit more complicated then this. As I do not have access to iBFT capable > hardware (*) this is all from what I've learned by carefully reading the code. > > In 5.2 we did not have iBFT support, nor did we have support for chap > authentication. It was possible to add iscsi disks by pressing the advanced > storage button, then entering the IP address + port of an iscsi device. This > device needs to support sendtargets discovery and have its portal on the same > IP as it listens for discovery. > We do have iBFT support in 5.2. This bug was created as chap with iBFT support was postponed from 5.2 to 5.3 http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Release_Notes/singles/relnotesU2-x86_64.html http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/liaai/liaaiblueprint.htm&tocNode=toc%3Afront%2Ffront.cmb%2F0%2F2%2F7%2F > Given the above I'm afraid we will have to live with a workaround for the CHAP > using iBFT case for 5.3. I think the following will work, it would be much > appreciated if you can test this, then we can make a release note describing > this work around: > > On the partitioning options screen press "advanced storage" and then select > "add iscsi disk", and then fill in the discovery IP and portal and the CHAP > authentication information manually. As noted before: > > 1) The discovery and portal IP's must be the same > 2) The discovery and portal authentication information must be the same I tried using the advanced storage "add iscsi disk" screen. I entered the CHAP info for the target, but the discovery still would not authenticate with the target. In looking at the /etc/iscsi/iscsid.conf file which was created by filling out the add iscsi disk screen I do not see enteries for discovery chap (i.e. discovery.sendtargets.auth*). sh-3.2# cat iscsid.conf iface.net_ifacename = eth1 node.conn[0].port = 3260 node.session.auth.username = linuxhostout iface.ipaddress = 9.47.69.244 iface.bootproto = STATIC iface.hwaddress = 00:14:5e:b3:8e:b2 node.session.auth.username_in = linuxhostin iface.gateway = 9.47.69.1 node.session.auth.password_in = 333333222222 iface.subnet_mask = 255.255.255.0 iface.initiatorname = iqn.2008-06.com.ibm:bpx86 iface.vlan = 0 node.boot_lun = 00000000 node.conn[0].address = 9.47.69.151 node.name = iqn.1992-08.com.netapp:sn.84183797 node.session.auth.password = 222222333333 I added the "discovery.sendtargets.auth.*" entries and the send targets discovery worked properly. sh-3.2# iscsiadm -m discovery -t st -p 9.47.69.151 9.47.67.152:3260,1001 iqn.1992-08.com.netapp:sn.84183797 9.47.69.151:3260,1000 iqn.1992-08.com.netapp:sn.84183797
(In reply to comment #68) > (In reply to comment #53) > > Yes I can comment. After seeing your comment 61, I immediately investigated. I > > didn't comment as my conclusion was the same as Chris' conclusion. > > > > About the chap going from non-working to working to non-working, things are a > > bit more complicated then this. As I do not have access to iBFT capable > > hardware (*) this is all from what I've learned by carefully reading the code. > > > > In 5.2 we did not have iBFT support, nor did we have support for chap > > authentication. It was possible to add iscsi disks by pressing the advanced > > storage button, then entering the IP address + port of an iscsi device. This > > device needs to support sendtargets discovery and have its portal on the same > > IP as it listens for discovery. > > > > We do have iBFT support in 5.2. This bug was created as chap with iBFT support > was postponed from 5.2 to 5.3 > My mistake, sorry. > > Given the above I'm afraid we will have to live with a workaround for the CHAP > > using iBFT case for 5.3. I think the following will work, it would be much > > appreciated if you can test this, then we can make a release note describing > > this work around: > > > > On the partitioning options screen press "advanced storage" and then select > > "add iscsi disk", and then fill in the discovery IP and portal and the CHAP > > authentication information manually. As noted before: > > > > 1) The discovery and portal IP's must be the same > > 2) The discovery and portal authentication information must be the same > > I tried using the advanced storage "add iscsi disk" screen. I entered the CHAP > info for the target, but the discovery still would not authenticate with the > target. > > In looking at the /etc/iscsi/iscsid.conf file which was created by filling out > the add iscsi disk screen I do not see enteries for discovery chap (i.e. > discovery.sendtargets.auth*). > > sh-3.2# cat iscsid.conf > iface.net_ifacename = eth1 > node.conn[0].port = 3260 > node.session.auth.username = linuxhostout > iface.ipaddress = 9.47.69.244 > iface.bootproto = STATIC > iface.hwaddress = 00:14:5e:b3:8e:b2 > node.session.auth.username_in = linuxhostin > iface.gateway = 9.47.69.1 > node.session.auth.password_in = 333333222222 > iface.subnet_mask = 255.255.255.0 > iface.initiatorname = iqn.2008-06.com.ibm:bpx86 > iface.vlan = 0 > node.boot_lun = 00000000 > node.conn[0].address = 9.47.69.151 > node.name = iqn.1992-08.com.netapp:sn.84183797 > node.session.auth.password = 222222333333 > > I added the "discovery.sendtargets.auth.*" entries and the send targets > discovery worked properly. > This is strange, I looked at the code, and then tested this (because I couldn't find anything wrong with the code) and this is working fine for me. Note I do not have iBFT, so I tested adding an iscsi disk through the advanced storage button. The generated /etc/iscsi/iscsid.conf kad all the necessary lines, and my iscsi disk, which required both sendtargets and portal forward only CHAP authentication (with the same username and password for both) was successfully found. Which RHEL-5 version are you testing with? (I used our latest candidate tree, basicly RC1 AFAIK).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0164.html