Hide Forgot
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:
Raising the severity - because I't affects every deployment using iSCSI.
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.
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).
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.
I actually added a patch to the blocked bug which is pointing out the idea (and which we use as a workaround).
Thoughts?
Is this problem still occurring in rhel7.7?
Hah. You got me! I don't know. But Yuval, do you happen to know?
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
stale bug and lacking info to resolve in z-stream. removing z-request
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.