Bug 1637927

Summary:	iSCSI Reverse CHAP authentication not working
Product:	[Fedora] Fedora	Reporter:	Vojtech Trefny <vtrefny>
Component:	iscsi-initiator-utils	Assignee:	Chris Leech <cleech>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	29	CC:	anaconda-maint-list, awilliam, blivet-maint-list, cleech, extras-qa, gmarr, jkonecny, jonathan, kellin, kparal, lnie, lruzicka, mchristi, mkolman, robatino, rvykydal, sbueno, vanmeeuwen+fedora, vponcova, vtrefny, wwoods, zbyszek
Target Milestone:	---	Keywords:	CommonBugs
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	RejectedBlocker AcceptedFreezeException https://fedoraproject.org/wiki/Common_F29_bugs#iscsi-authentication
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1632656	Environment:
Last Closed:	2019-11-27 19:41:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1632656
Bug Blocks:	1517014, 1635569

Description Vojtech Trefny 2018-10-10 10:50:00 UTC

+++ 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 10:53:18 UTC

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 20:39:11 UTC

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 07:58:16 UTC

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 08:01:55 UTC

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 19:10:27 UTC

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

Comment 6 Ben Cotton 2019-10-31 20:35:44 UTC

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Ben Cotton 2019-11-27 19:41:56 UTC

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.