Bug 437195

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.

pm-ack.  This looks to be a worthwhile patch for this new software on 5.2

------- Comment From mike.anderson.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  ]"

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)?

(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 From mike.anderson.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

(In reply to comment #6)
> ------- Comment From mike.anderson.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.

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.

(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.

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?

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.

Merged in iscsi-initiator-utils-6.2.0.868-0.5.el5.

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!

(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.

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

Verified by partner

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>

(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 From mike.anderson.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.

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

Tracking this bug for the Red Hat Enterprise Linux 5.3 Release Notes.

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.

Change "iFBT" to "iBFT" in the release note.

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.