Description of problem: A iSCSI target not discovered due to a permission error in VDSM. Version-Release number of selected component (if applicable): 4.14 How reproducible: Always Steps to Reproduce: 1. Properly configure a Data Center, Cluster, Host and Storage 2. Create a new VM 3. Try to add an External Direct Lun of the iSCSI type into the VM as a virtual disk 4. Put the address of the iscsi target, the port, the username and the password of where the target is. 5. Click "Discover" Actual results: Nothing appears. Expected results: The target gets listed in the window. Additional info: The VDSM log shows this: Thread-220::INFO::2014-01-24 16:26:10,761::logUtils::44::dispatcher::(wrapper) Run and protect: discoverSendTargets(con={'connection': '10.10.27.68', 'password': '******', 'port': '3260', 'user': 'iscsi'}, options=None) Thread-220::DEBUG::2014-01-24 16:26:10,762::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /usr/sbin/iscsiadm -m discoverydb -t sendtargets -I default -p 10.10.27.68:3260 --op=new' (cwd None) Thread-220::DEBUG::2014-01-24 16:26:10,791::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) FAILED: <err> = 'iscsiadm: Could not make dir /var/lib/iscsi/send_targets/10.10.27.68,3260 err 13\n\niscsiadm: Could not open /var/lib/iscsi/send_targets/10.10.27.68,3260: Permission denied\n\niscsiadm: Could not add new discovery record.\n'; <rc> = 6 Thread-220::DEBUG::2014-01-24 16:26:10,792::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) '/usr/bin/sudo -n /usr/sbin/iscsiadm -m iface' (cwd None) Thread-220::DEBUG::2014-01-24 16:26:10,821::iscsiadm::92::Storage.Misc.excCmd::(_runCmd) SUCCESS: <err> = ''; <rc> = 0 Thread-220::ERROR::2014-01-24 16:26:10,821::hsm::2934::Storage.HSM::(discoverSendTargets) Discovery failed Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2932, in discoverSendTargets targets = iscsi.discoverSendTargets(iface, portal, cred) File "/usr/share/vdsm/storage/iscsi.py", line 212, in discoverSendTargets addIscsiPortal(iface, portal, credentials) File "/usr/share/vdsm/storage/iscsi.py", line 183, in addIscsiPortal iscsiadm.discoverydb_new(discoverType, iface.name, portalStr) File "/usr/share/vdsm/storage/iscsiadm.py", line 177, in discoverydb_new raise IscsiDiscoverdbError(rc, out, err) IscsiDiscoverdbError: (6, [], ['iscsiadm: Could not make dir /var/lib/iscsi/send_targets/10.10.27.68,3260 err 13', '', 'iscsiadm: Could not open /var/lib/iscsi/send_targets/10.10.27.68,3260: Permission denied', '', 'iscsiadm: Could not add new discovery record.']) Thread-220::ERROR::2014-01-24 16:26:10,830::dispatcher::67::Storage.Dispatcher.Protect::(run) {'status': {'message': 'Failed discovery of iSCSI targets: "portal=IscsiPortal(hostname=\'10.10.27.68\', port=3260), err=(6, [], [\'iscsiadm: Could not make dir /var/lib/iscsi/send_targets/10.10.27.68,3260 err 13\', \'\', \'iscsiadm: Could not open /var/lib/iscsi/send_targets/10.10.27.68,3260: Permission denied\', \'\', \'iscsiadm: Could not add new discovery record.\'])"', 'code': 475}}
Setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.
This looks like selinux issue - iscsiadm running as root cannot created directory at /var/lib. Please try to run the discovery command manually - does it fail with the same error? /usr/sbin/iscsiadm -m discoverydb -t sendtargets \ -I default -p 10.10.27.68:3260 --op=new' Then try to run selinux in permissive mode - does it fix the issue? If fixed, please check /var/log/messages for selinux warnings. See https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html Which system is this? are you using latest selinux packages? Please provide the output of "rpm -qa | grep selinux"
The output of "rpm -qa | grep selinux": libselinux-devel-2.1.13-15.fc19.ppc64 libselinux-2.1.13-15.fc19.ppc64 libselinux-python-2.1.13-15.fc19.ppc64 selinux-policy-targeted-3.12.1-74.16.fc19.noarch selinux-policy-3.12.1-74.16.fc19.noarch libselinux-utils-2.1.13-15.fc19.ppc64 Running the command manually works ok. Setting selinux to permissive fix this.
Yaniv, can you check this issue?
Check bug 694256, it seems quite the same to me. Check what policies are required and open bug for selinux-policy if that's the case.
Dan, do you know this issue with selinux policy? Do you know how a workaround it other then using permissive mode?
@Vitor: Could you please do: grep iscsiadm /var/log/audit/audit.log | audit2allow -M iscsiadm.pol semodule -i iscsiadm.pp Then setenforce 1. Then try again. If that works, we should move the bug to selinux-policy and having an attachment of /var/log/audit/audit.log would be very helpful for that.
Created attachment 861768 [details] audit.log
Created attachment 861769 [details] audit2allow output
@Antoni The audit2allow command failed, I've attached the output in a file. The audit.log was attached too.
? type=AVC msg=audit(1391611792.808:5745): avc: denied { create } for pid=10045 comm="iscsiadm" name="st_config" scontext=system_u:system_r:iscsid_t:s0 tcontext=system_u:object_r:iscsi_var_lib_t:s0 tclass=file libsepol.context_from_record: user system_u is not defined
commit 7bb6be6b0944bec39badd804a9e329d08bca14f1 Author: Miroslav Grepl <mgrepl> Date: Tue Feb 11 17:08:23 2014 +0100 Allow iscsid to manage iscsi lib files
(In reply to Miroslav Grepl from comment #13) > commit 7bb6be6b0944bec39badd804a9e329d08bca14f1 > Author: Miroslav Grepl <mgrepl> > Date: Tue Feb 11 17:08:23 2014 +0100 > > Allow iscsid to manage iscsi lib files where is this patch? is there a bug to track it?
(In reply to Ayal Baron from comment #14) > (In reply to Miroslav Grepl from comment #13) > > commit 7bb6be6b0944bec39badd804a9e329d08bca14f1 > > Author: Miroslav Grepl <mgrepl> > > Date: Tue Feb 11 17:08:23 2014 +0100 > > > > Allow iscsid to manage iscsi lib files > > where is this patch? is there a bug to track it? Miroslav, if *this* is the bug then assign to yourself? Thanks.
BZ 1011193
This bug is blocking oVirt 3.4.0 final release. ETA for fixing it?
Changes have been back ported to F19. Lukas, could you do a new F19 build with these changes.
(In reply to Sandro Bonazzola from comment #17) > This bug is blocking oVirt 3.4.0 final release. ETA for fixing it? This is selinux bug, we can do nothing about it until selinux fix is available.
yes, I'll do it today
selinux-policy-3.12.1-74.19.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-74.19.fc19
Can you verify that the submmited package (see comment 21) solve your issue?
(In reply to Nir Soffer from comment #22) > Can you verify that the submmited package (see comment 21) solve your issue? I have tested here and can confirm with selinux-policy/selinux target 3.12.1-74.19 the error is gone. The funny thing is that the error only shows using ovirt-engine via VDSM, if I try to execute the same command via shell it works (as already reported in the comment #4). Anyway, the error is gone. Added karma to package.
Package selinux-policy-3.12.1-74.19.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-74.19.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3030/selinux-policy-3.12.1-74.19.fc19 then log in and leave karma (feedback).
*** Bug 1070430 has been marked as a duplicate of this bug. ***
selinux-policy-3.12.1-74.19.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.