Bug 437195 - ibft boot: pick up chap values dynamically
ibft boot: pick up chap values dynamically
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: iscsi-initiator-utils (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Mike Christie
:
Depends On:
Blocks: RHEL5u2_relnotes 437891 RHEL5u3_relnotes
  Show dependency treegraph
 
Reported: 2008-03-12 15:56 EDT by Mike Christie
Modified: 2009-01-11 19:12 EST (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2008-0424
Doc Type: Bug Fix
Doc Text:
(all architectures) The use of Challenge Handshake Authentication Protocol (CHAP) during installation is not supported. As such, CHAP should only be enabled after installation. If your system boots through an iBFT device, configure CHAP in the iBFT BIOS/firmware setup screen. Your CHAP settings will then be used in the next boot. If your system boots through PXE iSCSI, configure CHAP through iscsiadm. After configuring, use mkinitrd to ensure that your CHAP settings are used in the next boot.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 13:22:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
use chap values from sysfs during iscsid sync up (1.55 KB, patch)
2008-03-12 16:02 EDT, Mike Christie
no flags Details | Diff

  None (edit)
Description Mike Christie 2008-03-12 15:56:53 EDT
Description of problem:

When we boot using ibft the CHAP values may be different than what is in the
iscsi node db. We do not want to use the node db for any dynamic values that can
be set in ibft.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Mike Christie 2008-03-12 16:02:43 EDT
Created attachment 297836 [details]
use chap values from sysfs during iscsid sync up

This the patch to fix the problem. We just use the sysfs values instead of node
db ones.

The patch will only affect this resync up boot path and the case where iscsid
died and had to be restarted manually, so the chance for a regression is small.


QE: this can be tested by booting with ibft, first with no chap, then reboot
and set some chap values in the ibft BIOS setup screen. Without the patch the
login by iscsid will fail.
Comment 2 Rob Kenna 2008-03-12 22:25:51 EDT
pm-ack.  This looks to be a worthwhile patch for this new software on 5.2
Comment 3 IBM Bug Proxy 2008-03-13 01:16:29 EDT
------- Comment From mike.anderson@us.ibm.com 2008-03-13 01:12 EDT-------
I applied the "use chap values" patch to a iscsi-initiator-utils-6.2.0.868-0.4
src rpm and install it on my test system.

I booted with no chap, one way chap, and mutual chap values set in iBFT. The
system booted fine.

Hardware Info:
Blade: LS21 -[7971AC1]-
Storage: Netapp FAS250 OnTap 7.2

#iBFT data w/mutual chap
iscsiadm -m fw
iface.initiatorname = iqn.2007-10.com.redhat: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
node.session.auth.username = redhat
node.session.auth.password = abc123
node.session.auth.username_in = netapp
node.session.auth.password_in = 123abc

Mike C. Everything worked fine on the boot, but in reviewing the dmesg log I am
getting some error messages from iscsid indicating that a connection already
exists. Are these expected?

"iscsid (pid 4422 4421) is running...
Setting up iSCSI targets: Logging in to [iface: default, target:
iqn.1992-08.com.netapp:sn.84183797, portal: 9.47.67.152,3260]
iscsiadm: Could not login to [iface: default, target:
iqn.1992-08.com.netapp:sn.84183797, portal: 9.47.67.152,3260]:
iscsiadm: initiator reported error (15 - already exists)
iscsiadm: Could not log into all portals. Err 15.
[  OK  ]"
Comment 4 Mike Christie 2008-03-13 11:17:57 EDT
Thanks for teesting.

(In reply to comment #3)
> Mike C. Everything worked fine on the boot, but in reviewing the dmesg log I am
> getting some error messages from iscsid indicating that a connection already
> exists. Are these expected?


Yeah, well sort of expected :) When the iscsi scripts are run, they will run
over the node records and start up the session marked as automatic. If there is
a record for the root node, because we are already logged in, we will see that
error message if the record startup values are not set to manual or on boot.

If you run iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84183797 -p
9.47.67.152,3260, what are the node.startup values (red hat does not use the
conn[0].startup value so you can ignore that)?
Comment 5 Mike Christie 2008-03-13 11:20:03 EDT
(In reply to comment #4)
> If you run iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84183797 -p
> 9.47.67.152,3260, what are the node.startup values (red hat does not use the
> conn[0].startup value so you can ignore that)?

Oh yeah, in RHEL 5.1 I thought it was getting set to on_boot by the installer. I
will check on that.
Comment 6 IBM Bug Proxy 2008-03-13 11:48:36 EDT
------- Comment From mike.anderson@us.ibm.com 2008-03-13 11:48 EDT-------
Here is the node output of iscsiadm

# iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84183797 -p 9.47.67.152,3260
node.name = iqn.1992-08.com.netapp:sn.84183797
node.tpgt = 1001
node.startup = manual
iface.hwaddress = default
iface.iscsi_ifacename = default
iface.net_ifacename = default
iface.transport_name = tcp
node.discovery_address = 9.47.67.152
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 4
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.auth.authmethod = None
node.session.auth.username = <empty>
node.session.auth.password = <empty>
node.session.auth.username_in = <empty>
node.session.auth.password_in = <empty>
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.host_reset_timeout = 60
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 9.47.67.152
node.conn[0].port = 3260
node.conn[0].startup = automatic
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 30
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
Comment 7 Mike Christie 2008-03-13 12:17:06 EDT
(In reply to comment #6)
> ------- Comment From mike.anderson@us.ibm.com 2008-03-13 11:48 EDT-------
> Here is the node output of iscsiadm
> 
> # iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84183797 -p 9.47.67.152,3260
> node.name = iqn.1992-08.com.netapp:sn.84183797
> node.tpgt = 1001
> node.startup = manual



> node.conn[0].startup = automatic

let me look through the code. For RHEL we always set the conn startup to manual
and just used the node.startup, so I am not sure how that got set.
Comment 8 Mike Christie 2008-03-13 12:26:11 EDT
Oh shoot. Maybe someone actually read the README. The patch that tells the user
to use the node.startup got dropped. Maybe someone read the README and is having
anaconda set the node.conn[0].startup value.

I will fix the documentaion with this bugzilla too.

I am not sure who is setting the node.conn[0].startup value yet though.
Comment 9 Mike Christie 2008-03-17 18:21:51 EDT
(In reply to comment #8)
> I am not sure who is setting the node.conn[0].startup value yet though.

Oh man, I am so mad. The first time I forget to update the README and someone
reads it :) It looks like it is anaconda that is setting this.

    def startNode(self, node):
        argv = [ "-m", "node", "-T", node, "-p", self.portal,
                 "-o", "update", "-n", "node.conn[0].startup",
                 "-v", "automatic" ]
        log.debug("iscsiadm %s" %(string.join(argv),))
        iutil.execWithRedirect(ISCSIADM, argv,
                               stdout = "/dev/tty5", stderr="/dev/tty5")

I will clone this bug, so that gets removed. Removing that is probably not
critical for 5.2 since it works whether we set that value or not. It would
probably reduce confusion.
Comment 13 Tom Coughlan 2008-03-20 11:21:20 EDT
We will need a release note that says "You can not use CHAP in iBFT during
install. You may enable CHAP after the installation is done." Mike, would you
fill that in a little and post it here for Don?
Comment 15 Mike Christie 2008-03-20 14:22:39 EDT
Here is is:

CHAP is not supported during installation, but can be turned on later. When
using iBFT, you can set the CHAP settings in the iBFT BIOS/firmware setup
screen, and they will be used during the next boot. When using PXE iSCSI boot,
you can set the CHAP settings with iscsiadm. In this case, you must also run
mkinitrd, so the new settings are picked up for the next boot.
Comment 16 Mike Christie 2008-03-25 04:19:03 EDT
Merged in iscsi-initiator-utils-6.2.0.868-0.5.el5.
Comment 18 Don Domingo 2008-03-25 22:39:59 EDT
added to RHEL5.2 release notes under "Installation-related notes":

<quote>
The use of Challenge Handshake Authentication Protocol (CHAP) during
installation is not supported. As such, CHAP should only be enabled after
installation.

If your system boots through an iFBT device, configure CHAP in the iFBT
BIOS/firmware setup screen. Your CHAP settings will then be used in the next boot.

If your system boots through PXE iSCSI, configure CHAP through iscsiadm. After
configuring, use mkinitrd to ensure that your CHAP settings are used in the next
boot.
</quote>

Mike, is there a *specific* mkinitrd command users should run after configuring
CHAP if they use PXE iscsi? i'm not sure if this information is obvious enough
to users. please advise, thanks!
Comment 20 Mike Christie 2008-03-26 12:10:23 EDT
(In reply to comment #18)
> added to RHEL5.2 release notes under "Installation-related notes":
> 
> <quote>
> The use of Challenge Handshake Authentication Protocol (CHAP) during
> installation is not supported. As such, CHAP should only be enabled after
> installation.
> 
> If your system boots through an iFBT device, configure CHAP in the iFBT
> BIOS/firmware setup screen. Your CHAP settings will then be used in the next boot.
> 
> If your system boots through PXE iSCSI, configure CHAP through iscsiadm. After
> configuring, use mkinitrd to ensure that your CHAP settings are used in the next
> boot.
> </quote>
> 
> Mike, is there a *specific* mkinitrd command users should run after configuring
> CHAP if they use PXE iscsi? i'm not sure if this information is obvious enough
> to users. please advise, thanks!

Users should run mkinitrd like how they normally would. I am not sure how to
word this. They just need to run

# mkinitrd /boot/initrd-their-kernel-version their-kernel-version

So if we have a standard way of telling users how to run mkinitrd in other cases
like if they change what modules should be loaded, then we can use the same
wording here since it is the same command.
Comment 22 Don Domingo 2008-04-01 22:17:29 EDT
Hi,
the RHEL5.2 release notes will be dropped to translation on April 15, 2008, at
which point no further additions or revisions will be entertained.

a mockup of the RHEL5.2 release notes can be viewed at the following link:
http://intranet.corp.redhat.com/ic/intranet/RHEL5u2relnotesmockup.html

please use the aforementioned link to verify if your bugzilla is already in the
release notes (if it needs to be). each item in the release notes contains a
link to its original bug; as such, you can search through the release notes by
bug number.

Cheers,
Don
Comment 23 Barry Donahue 2008-05-01 09:24:42 EDT
Verified by partner
Comment 24 Don Domingo 2008-05-01 18:31:47 EDT
Barry, Mike, can we now document this in the RHEL5.2 release notes updates as
RESOLVED? please advise (proposed release note to replace old one quoted in
Comment#18):

<quote>
The distribution version of the release notes stated that the use of Challenge
Handshake Authentication Protocol (CHAP) during installation was not supported.
This meant that CHAP should only be enabled after installation.

As of general availability of Red Hat Enterprise Linux 5.2, this issue is now
fixed. The use of CHAP during installation is now supported.
</quote>
Comment 25 Mike Christie 2008-05-05 13:14:01 EDT
(In reply to comment #24)
> Barry, Mike, can we now document this in the RHEL5.2 release notes updates as
> RESOLVED? please advise (proposed release note to replace old one quoted in
> Comment#18):
> 

I think we should use the comment in #18. The bugzilla topic and comments are
confusing. We wanted to support CHAP during boot and for install. We were only
able to support boot and were not able to make the necessary changes to the
installer. For this bugzilla I fixed some bugs so we could support CHAP + boot.

Barry, that is right, right? :) You guys did not fix the installer did you.

I am going to download and try it out just to make sure.
Comment 26 IBM Bug Proxy 2008-05-05 14:16:58 EDT
------- Comment From mike.anderson@us.ibm.com 2008-05-05 14:12 EDT-------
Mike C, My blade is in use for another day. Please let me know what you find out
with your install or I will try an install if I do not see an update once the
blade resource is available. I was under the impression that the installer was
not going to be updated for chap support in 5.2 so I have not tested this since
the issue was previously discussed.
Comment 28 errata-xmlrpc 2008-05-21 13:22:28 EDT
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 the 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-2008-0424.html
Comment 29 Ryan Lerch 2008-08-06 22:13:18 EDT
Tracking this bug for the Red Hat Enterprise Linux 5.3 Release Notes.
Comment 30 Ryan Lerch 2008-08-06 22:13:18 EDT
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.
Comment 31 Tom Coughlan 2008-09-23 11:46:30 EDT
Change "iFBT" to "iBFT" in the release note.
Comment 32 Tom Coughlan 2008-09-23 11:46:30 EDT
Release note updated. 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.

Diffed Contents:
@@ -1,6 +1,6 @@
 (all architectures)
 The use of Challenge Handshake Authentication Protocol (CHAP) during installation is not supported. As such, CHAP should only be enabled after installation.
 
-If your system boots through an iFBT device, configure CHAP in the iFBT BIOS/firmware setup screen. Your CHAP settings will then be used in the next boot.
+If your system boots through an iBFT device, configure CHAP in the iBFT BIOS/firmware setup screen. Your CHAP settings will then be used in the next boot.
 
 If your system boots through PXE iSCSI, configure CHAP through iscsiadm. After configuring, use mkinitrd to ensure that your CHAP settings are used in the next boot.

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