Bug 1627757 - The installer failed to use an iscsi target create by targetcli
Summary: The installer failed to use an iscsi target create by targetcli
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F29FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-09-11 12:02 UTC by lnie
Modified: 2018-09-25 11:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-25 11:02:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot (108.55 KB, image/png)
2018-09-11 12:02 UTC, lnie
no flags Details
anaconda.log (13.18 KB, text/plain)
2018-09-11 12:02 UTC, lnie
no flags Details
storage.log (41.23 KB, text/plain)
2018-09-11 12:03 UTC, lnie
no flags Details
screenshot (135.96 KB, image/png)
2018-09-12 07:40 UTC, lnie
no flags Details
anaconda.log (14.08 KB, text/plain)
2018-09-12 07:41 UTC, lnie
no flags Details
storage.log (64.48 KB, text/plain)
2018-09-12 07:41 UTC, lnie
no flags Details

Description lnie 2018-09-11 12:02:16 UTC
Created attachment 1482339 [details]
screenshot

Description of problem:
create a iscsi target using targetcli
/iscsi> ls
o- iscsi .............................................................................................................. [Targets: 1]
  o- iqn.2018-01.com.example:target ...................................................................................... [TPGs: 1]
    o- tpg1 ................................................................................................. [no-gen-acls, no-auth]
      o- acls ............................................................................................................ [ACLs: 1]
      | o- iqn.1994-05.com.redhat:71fc25b8ad3 ..................................................................... [Mapped LUNs: 1]
      |   o- mapped_lun0 ............................................................................... [lun0 fileio/testfile (rw)]
      o- luns ............................................................................................................ [LUNs: 1]
      | o- lun0 .......................................................... [fileio/testfile (/tmp/testiscsi.img) (default_tg_pt_gp)]
      o- portals ...................................................................................................... [Portals: 1]
        o- 0.0.0.0:3260 ....................................................................................................... [OK]


[root@192 lnie]# iscsiadm -m node -T iqn.2018-01.com.example:target -l
Logging in to [iface: default, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] (multiple)
Login to [iface: default, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] successful.
[root@192 lnie]# iscsiadm -m node -T iqn.2018-01.com.example:target -u
Logging out of session [sid: 1, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260]
Logout of [sid: 1, target: iqn.2018-01.com.example:target, portal: 10.66.128.196,3260] successful.

As shown in the attached packaging.log,tough iscsiadm can login the target, the installer claims::48:51,344 WRN blivet: iSCSI: could not log into iqn.2018-01.com.example:target: Failed to call Login method on /org/freedesktop/UDisks2/Manager with ('iqn.2018-01.com.example:target', 1, '10.66.128.196', 3260, 'default', {'node.startup': <'automatic'>}) arguments: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Login failed: initiator reported error (24 - iSCSI login failed due to authorization failure)

Version-Release number of selected component (if applicable):
Fedora-Server-dvd-x86_64-29-20180909.n.0.iso

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 lnie 2018-09-11 12:02:40 UTC
Created attachment 1482340 [details]
anaconda.log

Comment 2 lnie 2018-09-11 12:03:26 UTC
Created attachment 1482341 [details]
storage.log

Comment 3 Fedora Blocker Bugs Application 2018-09-12 02:58:36 UTC
Proposed as a Blocker for 29-final by Fedora user lnie using the blocker tracking app because:

 This  affects the final criteria:
The installer must be able to detect (if possible) and install to supported network-attached storage devices.

Comment 4 Adam Williamson 2018-09-12 04:36:03 UTC
openQA iSCSI test is working:

https://openqa.fedoraproject.org/tests/277611

it 'fails' because networking doesn't work post-install in that test for some reason, but the actual iSCSI install and boot works...

Comment 5 lnie 2018-09-12 07:39:55 UTC
(In reply to Adam Williamson from comment #4)
> openQA iSCSI test is working:
> 
> https://openqa.fedoraproject.org/tests/277611
> 
> it 'fails' because networking doesn't work post-install in that test for
> some reason, but the actual iSCSI install and boot works...
You are using the target created by tgtadm,right?
I can tell it as old tgtadm doesn't support discovery authentication,
and the openqa test dosen't test discovery authentication,while dose test login authentication.And I've checked,the tgtadm WFM too,as shown in the attached screenshot:)So...,I'm not sure this is whose fault(reported a targetcli bug earlier #1627995),but anaconda dose can't login the iscsi target created by targetcli.BTW,if I set discovery authentication for the targetcli target,anaconda will be unable to discover the target

Comment 6 lnie 2018-09-12 07:40:33 UTC
Created attachment 1482580 [details]
screenshot

Comment 7 lnie 2018-09-12 07:41:03 UTC
Created attachment 1482581 [details]
anaconda.log

Comment 8 lnie 2018-09-12 07:41:36 UTC
Created attachment 1482582 [details]
storage.log

Comment 9 Adam Williamson 2018-09-12 16:00:20 UTC
OK, thanks for the clarification :)

Comment 10 Geoffrey Marr 2018-09-17 20:10:23 UTC
Discussed during the 2018-09-17 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", iSCSI is a 'supported' network-attached protocol. We will look further into when this does and does not happen.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-09-17/f29-blocker-review.2018-09-17-16.02.txt

Comment 11 Radek Vykydal 2018-09-21 12:45:30 UTC
Connecting to target created by targetcli works for me.

I think the problem is target ACLs not being set for installer initiator (or not using initiator name defined in target's ACL in installer).

Target ACLs from the Description:

      o- acls 
............................................................................................................ [ACLs: 1]
      | o- iqn.1994-05.com.redhat:71fc25b8ad3 

don't contain installer's initiator name (from storage.log, comment #8):

14:56:12,048 INF blivet: Setting up iSCSI initiator name iqn.1994-05.com.redhat:c292a74a4b62


Unlike tgtadm, targetcli doesn't allow non-authenticated access to target without  setting ACLs for the initiator by default. (It can be achieved by using demo mode.)

So this seems like misconfiguration issue to me.

Comment 12 lnie 2018-09-25 10:33:18 UTC
(In reply to Radek Vykydal from comment #11)

> Unlike tgtadm, targetcli doesn't allow non-authenticated access to target
> without  setting ACLs for the initiator by default. (It can be achieved by
> using demo mode.)
My fault,I know of that,but failed to notice that anaconda's iscsi initiator name 
is different with the initiator system's /etc/iscsi/initiatorname.iscsi(The test installer is booted with VM),and I find it isn't owned by any package,is that the wanted behavior?
[root@192 lnie]# rpm -qf /etc/iscsi/initiatorname.iscsi
file /etc/iscsi/initiatorname.iscsi is not owned by any package

> Connecting to target created by targetcli works for me.

I've checked,if you change anaconda's iscsi initiator name to the 
/etc/iscsi/initiatorname.iscsi one manually(or create a target with anaconda's iscsi initiator name,presumably) anaconda will connect to the target,ALA you don't use the authentication,but if you want to apply authentication,you will see #bz1632656

Comment 13 Radek Vykydal 2018-09-25 11:02:38 UTC
(In reply to lnie from comment #12)
> (In reply to Radek Vykydal from comment #11)
> 
> > Unlike tgtadm, targetcli doesn't allow non-authenticated access to target
> > without  setting ACLs for the initiator by default. (It can be achieved by
> > using demo mode.)
> My fault,I know of that,but failed to notice that anaconda's iscsi initiator
> name 
> is different with the initiator system's /etc/iscsi/initiatorname.iscsi(The
> test installer is booted with VM),and I find it isn't owned by any
> package,is that the wanted behavior?

Yes, installer environment has its own initiator name generated (or defined in GUI or in kickstart).


> > Connecting to target created by targetcli works for me.
> 
> I've checked,if you change anaconda's iscsi initiator name to the 
> /etc/iscsi/initiatorname.iscsi one manually(or create a target with
> anaconda's iscsi initiator name,presumably) anaconda will connect to the
> target,ALA you don't use the authentication,but if you want to apply
> authentication,you will see #bz1632656

We'll look into it.


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