Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1637927 - iSCSI Reverse CHAP authentication not working
iSCSI Reverse CHAP authentication not working
Status: NEW
Product: Fedora
Classification: Fedora
Component: iscsi-initiator-utils (Show other bugs)
29
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Chris Leech
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeExcepti...
: CommonBugs
Depends On: 1632656
Blocks: 1635569 F29FinalFreezeException
  Show dependency treegraph
 
Reported: 2018-10-10 06:50 EDT by Vojtech Trefny
Modified: 2018-11-01 09:10 EDT (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1632656
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vojtech Trefny 2018-10-10 06:50:00 EDT
+++ This bug was initially created as a clone of Bug #1632656 +++

Description of problem:
create an iscsi target use targetcli,and set discovery and login authentication as following:
/iscsi> set discovery_auth enable=1
Parameter enable is now 'True'.
/iscsi> set discovery_auth userid=IncomingUser
Parameter userid is now 'IncomingUser'.
/iscsi> set discovery_auth password=SomePassword1
Parameter password is now 'SomePassword1'.
/iscsi> set discovery_auth mutual_userid=OutgoingUser
Parameter mutual_userid is now 'OutgoingUser'.
/iscsi> set discovery_auth mutual_password=AnotherPassword2
Parameter mutual_password is now 'AnotherPassword2'.
/iscsi> cd iqn.2018-02.com.example:target/
/iscsi/iqn.20...xample:target> cd tpg1/
/iscsi/iqn.20...e:target/tpg1> set attribute authentication=1
Parameter authentication is now '1'.
/iscsi/iqn.20...e:target/tpg1> set auth userid=IncomingUser2
Parameter userid is now 'IncomingUser2'.
/iscsi/iqn.20...e:target/tpg1> set auth password=SomePassword3
Parameter password is now 'SomePassword3'.
/iscsi/iqn.20...e:target/tpg1> set auth mutual_userid=OutgoingUser2
Parameter mutual_userid is now 'OutgoingUser2'.
/iscsi/iqn.20...e:target/tpg1> set auth mutual_password=AnotherPassword4
Parameter mutual_password is now 'AnotherPassword4'.
/iscsi/iqn.20...e:target/tpg1> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

As shown in the attached screenshots,the installer failed to discover the target,and after I set  discovery_auth enable=0,the installer can discover the target but failed to login

Version-Release number of selected component (if applicable):
Fedora-Server-dvd-x86_64-29_Beta-1.5.iso

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from lnie on 2018-09-25 06:17 EDT ---



--- Additional comment from lnie on 2018-09-25 06:17 EDT ---



--- Additional comment from lnie on 2018-09-25 06:18 EDT ---



--- Additional comment from lnie on 2018-09-25 06:19 EDT ---



--- Additional comment from Fedora Blocker Bugs Application on 2018-09-30 06:35:02 EDT ---

Proposed as a Blocker for 29-final by Fedora user lnie using the blocker tracking app because:

 Seems to affect the criteria:
The installer must be able to detect (if possible) and install to supported network-attached storage devices

--- Additional comment from Geoffrey Marr on 2018-10-01 15:40:52 EDT ---

Discussed during the 2018-10-01 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"The installer must be able to detect (if possible) and install to supported network-attached storage devices" - The criterion does not explicitly say whether auth is blocking, but we believe it is sufficiently commonly used in the real world that we should accept the bug.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-01/f29-blocker-review.2018-10-01-16.00.txt

--- Additional comment from Radek Vykydal on 2018-10-03 05:31:00 EDT ---

Seems that reverse (target) CHAP authentication is not working both for discover and login. Initiator authentication should work fine for both.

The same issue is present in F28 GA.
On RHEL 7 reverse CHAP works.

--- Additional comment from Radek Vykydal on 2018-10-03 05:36:36 EDT ---

Reassigning to blivet storage library for investigating.

--- Additional comment from Vojtech Trefny on 2018-10-03 08:45:07 EDT ---

Upstream PR: https://github.com/storaged-project/blivet/pull/728

--- Additional comment from Fedora Update System on 2018-10-08 09:47:04 EDT ---

python-blivet-3.1.1-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d610e2461a

--- Additional comment from Fedora Update System on 2018-10-08 13:41:48 EDT ---

python-blivet-3.1.1-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d610e2461a

--- Additional comment from Adam Williamson on 2018-10-08 14:05:33 EDT ---

lnie, can you please test the fix? Thanks!

--- Additional comment from lnie on 2018-10-09 00:40:19 EDT ---

The discovery authentication works fine now,but still unable to login and use the iscsi targets when Reverse CHAP authentication is set. After click the Login button you will see the error shown in the attached screenshot.

--- Additional comment from lnie on 2018-10-09 00:40 EDT ---



--- Additional comment from lnie on 2018-10-09 00:41 EDT ---



--- Additional comment from lnie on 2018-10-09 00:42 EDT ---



--- Additional comment from Vojtech Trefny on 2018-10-09 06:39:15 EDT ---

I've tested this again and both discovery and login works for me.

My configuration:
- updates.img: https://vtrefny.fedorapeople.org/img/iscsi1632274.img
- targetcli config: https://vtrefny.fedorapeople.org/misc/iscsi-discover-auth-mutual.json
- initiator name: "iqn.1994-05.com.redhat:iscsi-test"
- discovery credentials: "mytargetuid", "mytargetsecret", "mymutualuid", "mymutualsecret"
- login credentials: "udisks-user", "udisks-password", "udisks-mutual-user", "udisks-mutual-password"

lnie: Can you please share your targetcli config? Maybe I'm testing something different.

--- Additional comment from lnie on 2018-10-09 07:08 EDT ---



--- Additional comment from lnie on 2018-10-09 07:09:58 EDT ---

unable to open your configuration file,mine is attached.

--- Additional comment from Vojtech Trefny on 2018-10-09 08:44:58 EDT ---

Thank you, I can confirm that the login doesn't work with your configuration. It works on Fedora 28 (with latest blivet and udisks), but doesn't on Fedora 29. The same happens when using iscsiadm manually, so I think it is a different problem:

On Fedora 28:
$ sudo iscsiadm --mode node --targetname iqn.2018-02.com.example:target --portal 10.37.176.17:3260 --login --name node.session.auth.authmethod --value=CHAP --name node.session.auth.username --value="IncomingUser2" --name node.session.auth.password --value="SomePassword3" --name node.session.auth.username_in --value="OutgoingUser2" --name node.session.auth.password_in --value="AnotherPassword4"
Logging in to [iface: default, target: iqn.2018-02.com.example:target, portal: 10.37.176.17,3260] (multiple)
Login to [iface: default, target: iqn.2018-02.com.example:target, portal: 10.37.176.17,3260] successful.

On Fedora 29:
$ sudo iscsiadm --mode node --targetname iqn.2018-02.com.example:target --portal 10.37.176.17:3260 --login --name node.session.auth.authmethod --value=CHAP --name node.session.auth.username --value="IncomingUser2" --name node.session.auth.password --value="SomePassword3" --name node.session.auth.username_in --value="OutgoingUser2" --name node.session.auth.password_in --value="AnotherPassword4"
Logging in to [iface: default, target: iqn.2018-02.com.example:target, portal: 10.37.176.17,3260] (multiple)
iscsiadm: Could not login to [iface: default, target: iqn.2018-02.com.example:target, portal: 10.37.176.17,3260].
iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
iscsiadm: Could not log into all portals
Comment 1 Vojtech Trefny 2018-10-10 06:53:18 EDT
Targetcli config that can be used to reproduce this is in https://bugzilla.redhat.com/show_bug.cgi?id=1632656#c18

I was able to login using iscsiadm on f28, but not on f29 so i assume this is not a installer specific issue. (We had a bug in our code, so I'm not changing component of the original bug.)
Comment 2 Adam Williamson 2018-10-11 16:39:11 EDT
AcceptedBlocker here was just transferred from the original bug, but this seems to be a slightly different thing, so we should discuss it on its own merits.

Basically it seems the situation now is that a specific iSCSI config with discovery and login auth does not work, but another tested config does work? Do we know yet precisely what triggers the failure?
Comment 3 Zbigniew Jędrzejewski-Szmek 2018-10-15 03:58:16 EDT
Let's please not use 'clone bug'. It transfers the CC's from the original bug (and it's likely that all those people don't care) and other metadata that does not apply to the new bug.
Comment 4 Zbigniew Jędrzejewski-Szmek 2018-10-15 04:01:55 EDT
The original bug wasn't really fixed, the fix was for some related problem. Although at this point, it's probably better to keep #1632656 closed and continue the discussion here.
Comment 5 Geoffrey Marr 2018-10-15 15:10:27 EDT
Discussed during the 2018-10-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as we believe enough iSCSI configs now work that this remaining problematic one should not be considered a blocker, but it would be great to fix it for the release if we can.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-15/f29-blocker-review.2018-10-15-16.00.txt

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