Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Some version context first:
# rpm -q iscsi-initiator-utils
iscsi-initiator-utils-6.2.0.872-10.el6.x86_64
Description of problem:
While playing with iscsiadm in the vdsm (rhev) environment
we discovered that it is too easy to damage/destroy your existing
configuration without any notification from iscsiadm.
Here is the example:
Create new iface and assign an initiatorname to it:
[root@nari10 ut]# iscsiadm -m iface -o new -I i1
New interface i1 added
[root@nari10 ut]# iscsiadm -m iface -o update -I i1 -n iface.initiatorname -v iqn.1994-05.com.redhat:01234567
i1 updated.
Make sure it is ok:
[root@nari10 ut]# iscsiadm -m iface
default tcp,<empty>,<empty>,<empty>,<empty>
iser iser,<empty>,<empty>,<empty>,<empty>
i1 tcp,<empty>,<empty>,<empty>,iqn.1994-05.com.redhat:01234567
Now, say, by mistake I am trying to create the iface with the same name again:
[root@nari10 ut]# iscsiadm -m iface -o new -I i1
New interface i1 added
iscsiadm happily does so and removes the original configuration:
[root@nari10 ut]# iscsiadm -m iface
default tcp,<empty>,<empty>,<empty>,<empty>
iser iser,<empty>,<empty>,<empty>,<empty>
i1 tcp,<empty>,<empty>,<empty>,<empty>
There is neither error code, nor other indication that destructive
action just happened. There is also no safety knob to tell iscsiadm
to avoid creating a new entry when there is one already (with the
same name).
While it may be quite ok for casual CLI use, this is hard to cope
with if iscsiadm is used non-interactively from some other utilities.
In such case some form of feedback (exit code) or CLI option is needed
in order to reliably call iscsiadm.
P.S. while this issue uses iface as an example, the issue itself
is not limited to the iface objects definitions, but rather is more general.
We can add some checks and messages. I am not sure if it will make 6.1. The beta cut off is Fri and I do not have time to do this by then. 6.2 will be fine.
One question. When you do discovery iscsiadm will read iscsid.conf and use those for the default record settings that get stored for each portal found in /var/lib/iscsi/nodes. If you do discocvery again then iscsiadmm will default to overwriting what is there iscsid.conf values. You can pass in the -o new/delete/update to control this behavior.
This default behavior is known and people use it to reset the settings. I am not sure if I can change this behavior in the middle of a RHEL release.
Comment 3RHEL Program Management
2011-04-04 02:09:17 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 6RHEL Program Management
2012-05-03 05:20:55 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
The official life cycle policy can be reviewed here:
http://redhat.com/rhel/lifecycle
This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:
https://access.redhat.com/