Bug 1393833

Summary:	Initiator IQN should be generated at first boot
Product:	Red Hat Enterprise Linux 7	Reporter:	Fabian Deutsch <fdeutsch>
Component:	iscsi-initiator-utils	Assignee:	Chris Leech <cleech>
Status:	CLOSED WONTFIX	QA Contact:	Martin Hoyer <mhoyer>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	7.2	CC:	cleech, cshao, fsuba, huzhao, michal.skrivanek, revers, weiwang, yaniwang, ycui, yturgema
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-01-15 07:28:30 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:
Bug Depends On:
Bug Blocks:	1393661

Description Fabian Deutsch 2016-11-10 12:32:58 UTC

Description of problem:
On RHVH - which is an image based system like atomic - the initiator IQN s the same on all hosts, because the IQN is generated during the the build of the image.
To have unique IQNs across different hosts, the IQN needs to be generated at the first boot - or at least at runtime - and not during build time of the image (thus not in rpm %post).

Version-Release number of selected component (if applicable):
iscsi-initiator-utils-6.2.0.873-25.gitc9d830b.fc22.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Build an image which includes iscsi-initiator-utils-6.2.0.873-25.gitc9d830b.fc22.x86_64
2. 
3.

Actual results:
After 1 the image contains a initiator IQN in /etc/iscsi/initiatorname.iscsi

Expected results:
After 1 the image a service to generate a initiator IQN in /etc/iscsi/initiatorname.iscsi

Additional info:

Comment 1 Fabian Deutsch 2016-11-10 13:02:47 UTC

Raising the severity - because I't affects every deployment using iSCSI.

Comment 2 Chris Leech 2016-11-10 17:11:35 UTC

There's a few things I'd want to check before jumping on firstboot vs RPM install scripts.  Like what happens if you install the RPM after the first boot?  And is anaconda relying on the RPM install to generate an IQN for iSCSI boot installs.

Comment 3 Fabian Deutsch 2016-11-10 19:46:04 UTC

Right - What I rather meant with the "firstboot" is: On the first start of the service, if the file is non-existent, then generate a new file.
The service should actually have the condition to only run if the file does not exists.

That should cover two cases:

1. Generates a random name on the first start (of the service) after the rpm got installed
2. Would not touch a an empty name file (which IIUIC is needed to cove rthe hardware initiator case).

Comment 4 Fabian Deutsch 2016-11-13 12:58:44 UTC

To keep backwards compatibility the rpm %post could still be generating the file, but a service could be added to regenerate the file if it get's deleted.

We would then delete the name file in our builds, to get them generated on the first boot.
On RHEL nothing would happen, because the name file is still getting installed during rpm %post.

Comment 6 Fabian Deutsch 2016-11-13 15:34:27 UTC

I actually added a patch to the blocked bug which is pointing out the idea (and which we use as a workaround).

Comment 7 Fabian Deutsch 2016-11-16 14:14:18 UTC

Thoughts?

Comment 8 Rob Evers 2020-01-22 20:52:21 UTC

Is this problem still occurring in rhel7.7?

Comment 9 Fabian Deutsch 2020-01-23 09:56:35 UTC

Hah. You got me! I don't know.

But Yuval, do you happen to know?

Comment 10 Yuval Turgeman 2020-01-27 11:11:30 UTC

Not really sure about RHEL, but I don't think it was fixed.  For RHVH, we're handling this by ourselves - we delte the file in build time, and generate it on first boot with our service

Comment 11 Rob Evers 2020-01-27 19:30:49 UTC

stale bug and lacking info to resolve in z-stream.  removing z-request

Comment 15 RHEL Program Management 2021-01-15 07:28:30 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.