RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1393833 - Initiator IQN should be generated at first boot
Summary: Initiator IQN should be generated at first boot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iscsi-initiator-utils
Version: 7.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Chris Leech
QA Contact: Martin Hoyer
URL:
Whiteboard:
Depends On:
Blocks: 1393661
TreeView+ depends on / blocked
 
Reported: 2016-11-10 12:32 UTC by Fabian Deutsch
Modified: 2021-09-03 13:47 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-15 07:28:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.