See the SELinux error message attached. I am not a 100% sure whether this is a bug or specific to my installation, however, I don't know how to verify it. The installation is a new gridengine installation from F17 on a notebook with the qmaster and the execd at the same machine. I use the system mainly to execute jobs in a row. Since there is an issue with running a gridengine on a machine with no fixed network interface (localhost is not allowed), I setup manually a dummy0 interface and then start the gridengine services via #> systemctl start sgemaster.service #> systemctl start sge_execd.service The SELinux message appears when starting the execd. However, the gridengine seems to be operational and accepts and executes jobs.
Created attachment 594947 [details] SELinux message
I think most sge denials are just informative at this point. I'm reassigning to selinux-policy to get their comments. You do want to run: /sbin/restorecon -v /var/spool/gridengine/pc0x/jobs as suggested by the message. Dan - I suppose the sge_execd daemon should do this automatically when creating this directory. I'm still pretty green on the C api for doing this, hint please?
running restorecon had no effect. these are the SELinux properties of the files and directories below the node-specific folder pc0x. Seems inconsistend since all are var_spool_t except of jobs, which is sge_spool_t. [root@pc0x ~]# ls -aZ /var/spool/gridengine/pc0x drwxr-xr-x. sgeadmin sgeadmin system_u:object_r:var_spool_t:s0 . drwxr-xr-x. sgeadmin sgeadmin unconfined_u:object_r:var_spool_t:s0 .. drwxr-xr-x. sgeadmin sgeadmin system_u:object_r:var_spool_t:s0 active_jobs -rw-r--r--. sgeadmin sgeadmin system_u:object_r:var_spool_t:s0 execd.pid drwxr-xr-x. sgeadmin sgeadmin system_u:object_r:sge_spool_t:s0 jobs drwxr-xr-x. sgeadmin sgeadmin system_u:object_r:var_spool_t:s0 job_scripts -rw-r--r--. sgeadmin sgeadmin system_u:object_r:var_spool_t:s0 messages
You need to run # restorecon -R -v /var/spool/gridengine Orion, so the /var/spool/gridengine is created by sge_execd?
/var/spool/gridengine is created by the package, but the <hostname> sub-directory and everything under that is created by sge_execd.
Hmm, the /var/spool/gridengine get the proper labeling on install due to rpm magic and all files should be labeled correctly then. Any chance the directory is re-created?
Indeed, the directory might have been re-created. The gridengine setup process (after installing the packets) is very tricky and error prone. The smallest mistake breaks the installation and you have to re-start at the beginning. Examples for such mistakes are when the interface to which hostname points to is not up or when ssh cannot connect to the qmaster server without a password. Then (according to tool instructions) you have to manually delete /var/spool/gridengine and /usr/share/gridengine/default folders. I guess, I did this at least once.
gridengine-2011.11p1-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gridengine-2011.11p1-2.fc17
In this update I removed the one place in the install/uninstall scripts that I found the removes /var/spool/gridengine. If there are any other comments, etc. that instruct you to do so, please point them out and I'll remove those too.
Package gridengine-2011.11p1-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gridengine-2011.11p1-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10479/gridengine-2011.11p1-2.fc17 then log in and leave karma (feedback).
Miroslav - can you confirm for me that all sge denials are just informative at this point, that nothing is actually blocked. This appears to have to be the case otherwise nothing would work.
Okay... I ran the update. Then, when starting the execd, I still got SELinux notifications. Next, I removed my whole gridengine installation including manually deleting all gridengine folders and files in /etc/sysconfig, /var/spool/gridengine and /usr/share/gridengine). After that, I did a new installation from the testing repository ran the gridengine setup procedure (without mistakes or any further manual interactions). Now, when starting the sge_execd via sysctl, I get four new SELinux notifications about sge_execd accessing name_bind, name_connect, read cpuset.cpus, and getattr cpuset.cpus aside of the SELinux messages, the setup seems to be okay (right number of queues and cpus). Also, a quick test with one job going through the queue was successful.
(In reply to comment #12) > Okay... I ran the update. Then, when starting the execd, I still got SELinux > notifications. > > Next, I removed my whole gridengine installation including manually deleting > all gridengine folders and files in /etc/sysconfig, /var/spool/gridengine > and /usr/share/gridengine). After that, I did a new installation from the > testing repository ran the gridengine setup procedure (without mistakes or > any further manual interactions). Now, when starting the sge_execd via > sysctl, I get four new SELinux notifications about sge_execd accessing > name_bind, name_connect, read cpuset.cpus, and getattr cpuset.cpus > Could you add raw AVC msgs?
gridengine-2011.11p1-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.