Bug 432819 - RHEL 5.1 seemingly has no CHAP support on install
RHEL 5.1 seemingly has no CHAP support on install
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.1
All Linux
high Severity high
: rc
: ---
Assigned To: Peter Jones
Release Test Team
:
: 432820 437201 (view as bug list)
Depends On:
Blocks: 420841 432381 445721
  Show dependency treegraph
 
Reported: 2008-02-14 11:35 EST by Supreeth
Modified: 2010-03-14 17:27 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:35:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Add CHAP support to Anaconda (20.07 KB, text/plain)
2008-04-18 10:28 EDT, IBM Bug Proxy
no flags Details
Patch that adds needed functionality to iscsi-initiator-utils (1.10 KB, patch)
2008-09-08 14:13 EDT, Peter Jones
no flags Details | Diff
nochap anaconda log (711.83 KB, application/octet-stream)
2008-11-05 04:41 EST, IBM Bug Proxy
no flags Details
anaconda log iscsi w/chap (710.27 KB, application/octet-stream)
2008-11-05 04:41 EST, IBM Bug Proxy
no flags Details
iSCSI CHAP 16 character iscsiadm output (565 bytes, application/octet-stream)
2008-11-05 04:41 EST, IBM Bug Proxy
no flags Details
anaconda log 5.3 snap5 (18.40 KB, text/plain)
2008-12-10 15:52 EST, IBM Bug Proxy
no flags Details
anaconda exception dump 5.3 snap5 (59.98 KB, text/plain)
2008-12-10 15:52 EST, IBM Bug Proxy
no flags Details
The PATCH in the updates.img fixing this (1005 bytes, patch)
2008-12-11 14:08 EST, Hans de Goede
no flags Details | Diff

  None (edit)
Description Supreeth 2008-02-14 11:35:13 EST
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.
Comment 1 Chris Lumens 2008-02-15 16:33:46 EST
*** Bug 432820 has been marked as a duplicate of this bug. ***
Comment 2 Joel Andres Granados 2008-04-18 10:24:22 EDT
*** Bug 437201 has been marked as a duplicate of this bug. ***
Comment 3 IBM Bug Proxy 2008-04-18 10:28:47 EDT
=Comment: #0=================================================
L. C. McDermott <mcdermoc@us.ibm.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@us.ibm.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@us.ibm.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@redhat.com) 	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 ***
Comment 4 IBM Bug Proxy 2008-04-18 10:28:50 EDT
Created attachment 302887 [details]
Add CHAP support to Anaconda
Comment 5 RHEL Product and Program Management 2008-06-12 16:28:54 EDT
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.
Comment 7 IBM Bug Proxy 2008-08-27 09:31:46 EDT
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.)
Comment 8 Peter Jones 2008-09-04 17:28:13 EDT
Committed in git's "rhel5-branch", should be in 11.1.2.122 .
Comment 9 Peter Jones 2008-09-08 14:13:23 EDT
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.
Comment 10 Peter Jones 2008-09-08 14:14:59 EDT
Mike, how do you want to handle the patch in comment #9 ?
Comment 11 Mike Christie 2008-09-08 14:47:17 EDT
(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?
Comment 12 Peter Jones 2008-09-08 15:40:21 EDT
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.
Comment 13 Mike Christie 2008-09-08 17:22:55 EDT
(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.
Comment 14 Mike Christie 2008-09-17 19:58:52 EDT
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?
Comment 16 IBM Bug Proxy 2008-11-05 04:41:00 EST
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.
Comment 17 IBM Bug Proxy 2008-11-05 04:41:08 EST
Created attachment 322554 [details]
nochap anaconda log

Successful iSCSI install w/no_chap
Comment 18 IBM Bug Proxy 2008-11-05 04:41:16 EST
Created attachment 322555 [details]
anaconda log iscsi w/chap

Failed iSCSI install w/chap
Comment 19 IBM Bug Proxy 2008-11-05 04:41:21 EST
Created attachment 322556 [details]
iSCSI CHAP 16 character iscsiadm output

iSCSI CHAP 16 character iscsiadm output
Comment 21 Mike Christie 2008-11-05 10:59:47 EST
(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?
Comment 22 Mike Christie 2008-11-05 13:58:22 EST
(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.
Comment 23 IBM Bug Proxy 2008-11-05 15:32:18 EST
(In reply to comment #29)
> ------- Comment From mchristi@redhat.com 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,
Comment 24 Mike Christie 2008-11-06 15:57:28 EST
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?
Comment 25 Peter Jones 2008-11-10 17:43:25 EST
I'm pretty sure we still need the patch, but it's not fresh in my mind, so I'll investigate further tomorrow.
Comment 28 Peter Jones 2008-11-13 18:20:41 EST
(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.
Comment 29 Mike Christie 2008-11-16 22:20:54 EST
(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.
Comment 31 Peter Jones 2008-11-19 18:20:15 EST
(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.
Comment 33 Denise Dumas 2008-11-25 12:02:44 EST
Mike, I'm cloning this BZ so you have a 5.3 one to submit the iscsi patch against.
Comment 34 Denise Dumas 2008-11-25 12:06:12 EST
OK, the companion BZ for the anaconda part of this is 472927, assigned to pjones
Comment 36 Mike Christie 2008-11-30 23:29:45 EST
The iscsi parts are in iscsi-initiator-utils-6.2.0.868-0.16.
Comment 39 Denise Dumas 2008-12-02 15:11:17 EST
The anaconda fix for this problem is found in anaconda 11.1.2.160-1
Comment 40 IBM Bug Proxy 2008-12-10 15:52:19 EST
Created attachment 326547 [details]
anaconda log 5.3 snap5
Comment 41 IBM Bug Proxy 2008-12-10 15:52:25 EST
Created attachment 326548 [details]
anaconda exception dump 5.3 snap5
Comment 42 IBM Bug Proxy 2008-12-10 16:02:09 EST
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
Comment 43 Mike Christie 2008-12-10 18:45:24 EST
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.
Comment 50 Hans de Goede 2008-12-11 09:22:57 EST
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.
Comment 52 Denise Dumas 2008-12-11 12:06:20 EST
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!
Comment 54 Hans de Goede 2008-12-11 14:08:22 EST
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.
Comment 55 IBM Bug Proxy 2008-12-11 18:51:54 EST
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.
Comment 56 David Cantrell 2008-12-12 16:03:56 EST
Patch in anaconda-11.1.2.164-1.
Comment 61 IBM Bug Proxy 2009-01-06 02:22:20 EST
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.
Comment 62 Chris Ward 2009-01-06 03:35:47 EST
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.
Comment 63 Suzanne Yeghiayan 2009-01-07 18:35:45 EST
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.
Comment 64 IBM Bug Proxy 2009-01-08 13:02:39 EST
(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@redhat.com> may be able to comment also.

Thanks.
Comment 65 Hans de Goede 2009-01-08 14:11:58 EST
(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@redhat.com> 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.
Comment 66 Ryan Lerch 2009-01-11 19:11:08 EST
Deleted Release Notes Contents.

Old Contents:
See comment 60.
Comment 68 IBM Bug Proxy 2009-01-13 13:02:29 EST
(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
Comment 69 Hans de Goede 2009-01-14 07:54:49 EST
(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).
Comment 70 errata-xmlrpc 2009-01-20 16:35:10 EST
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

Note You need to log in before you can comment on or make changes to this bug.