I was asked to run a DSET report on a Red Hat 6.4 machine and it just wasn’t running. Here is the error that was being generated when the report would try to run:
Unable to continue the process, because the certificate could not be successfully validated. For further information about Certificate validation process see “Credential-less CIMOM authentication” section of the Release Notes. To continue the process, enter Linux password and retry. Do you want to continue [y/n]?
So, I enter the root password and it’s immediately followed by “Cleaning up DSET deployed components …. [ Please wait ]”
The DSET report does not generate.
I wanted to see if putting in the incorrect password would yield different results, like a “incorrect credentials error” or something.
-I tried the incorrect password and got the exact same results as above.
Ok, fine… let’s try a different version of DSET (we are currently trying v3.7).
-Same results for DSET v3.4 and v3.6
Next we tried generating a DSET report on a similar system and got the same result. This isn’t an issue with DSET, it’s environmental with the Operating System.
Checked the audit.log and saw that DSET was being denied by selinux
Ran the command: getenforce this revieled that selinux is running or “enforcing”
Turned selinux off by running the command: setenforce 0
-This will put selinux in Permissive mode. Meaning it will still audit but allow access
The DSET report is now running and not prompting for the the root password.
To re-enable selinux, type: setenforce 1