Description of problem: ----------------------- Followed the instructions in the doc: http://10.34.3.139:8080/view/Ceph/job/doc-Red_Hat_Ceph_Storage-Installation_Guide_RHEL%20%28html-single%29/lastSuccessfulBuild/artifact/index.html to install calamari server. Set the selinux to Enforcing mode. After the installation tried opening gui. GUI did not open. Hit the issue 1302466. Tried the workaround: sudo chown apache:apache /var/log/calamari/cthulhu.log Could not access calamari UI even after following the workaround. The httpd_error.log file showed: ValueError: Unable to configure handler 'log_file': [Errno 13] Permission denied: '/var/log/calamari/calamari.log'. [cephuser@magna003 calamari]$ ll total 740 -rw-r--r--. 1 apache apache 7691 Feb 2 22:24 calamari.log -rw-r--r--. 1 apache apache 618195 Feb 3 12:48 cthulhu.log -rw-r--r--. 1 apache apache 0 Feb 2 14:21 exception.log -rw-r--r--. 1 root root 11882 Feb 3 12:43 httpd_access.log -rw-r--r--. 1 root root 102442 Feb 3 12:43 httpd_error.log -rw-r--r--. 1 apache apache 2211 Feb 2 19:53 info.log Changed the permission to 666 for calamari.log. Restarted calamari. No success. With calamari.log having write permission, set the selinux mode to permissive. Ran calamari-ctl initialize. Was able to login to GUI. Version-Release number of selected component (if applicable):1.3.2 (Jan 26th Build) How reproducible:always Steps to Reproduce: ------------------ Refer to description above Actual results: --------------- GUI did not open Expected results: ------------------ GUI opening successfully Additional info:
You are hitting that because SELinux won't give the program permission to access the file. SELinux can do that no matter what the actual file permissions are. Could you post the output of the following two commands when that happens? * cat /var/log/audit/audit.log|grep denied * semodule -l |grep calamari
Boris, FYI in in bug 1302466 Gregory refactored some of the logging code to avoid having Apache write to cthulhu.log (that patch is not yet present in any Calamari build). It occurred to me that SELinux might also be denying Apache access to write to this file? If that's the case, it should be solved when bug 1302466 is fixed. Harish, if you could provide the info Boris is requesting above, that would be great.
Created attachment 1121027 [details] audit log
[cephuser@magna003 ~]$ sudo semodule -l |grep calamari calamaris 1.8.0
@Harish: Hm, OK, that means that the calamari SELinux policy is not being installed (or loaded). Do you use recent enough (1.3.2-2 or later) calamari-server package? You mentioned that the package was from Jan 26th, the SELinux got back-ported on Jan 25th. I'm not sure whether that build contained the changes but if it did then I'll take a look into it sometimes later this week @Ken: That might help us a bit. However, the issue we are seeing here seems to be that calamari SELinux policy was not enabled at all.
Harish's system (magna003.ceph.redhat.com) has the latest calamari-server package installed: [ubuntu@magna003 ~]$ rpm -qv calamari-server calamari-server-1.3.2-2.el7cp.x86_64 Feel free to SSH in and look around; your public key (https://github.com/ceph/keys/blob/master/ssh/branto.pub) is present for the "ubuntu" UID
Yes, I was afraid of that so I have already started investigating it. It looks like the %{selinux_variants} does not get expanded/populated properly so we end up creating paths like /usr/share/doc/calamari-server-1.3.2/calamari-server.pp.%{selinux_variants} /usr/share/selinux/%{selinux_variants}/calamari-server.pp and therefore the policy won't get installed properly and won't be active. It looks like even the upstream patch missed that part. I should be able to have new build within an hour.
dist-git commits related to build calamari-server-1.3.2-3.el7cp: http://pkgs.devel.redhat.com/cgit/rpms/calamari-server/commit/?h=ceph-1.3-rhel-7&id=24729079349f9f031d159f0ac3ac8993fad5fce5
FYI: This bugzilla was intended as a basic fix -- making sure the policy is installed. You might still hit some avc denials while testing this, though. It is better if you do these initial tests with SELinux in Permissive mode and gather as much denials as you can hit. This allows me to update the policy accordingly (and faster than if you have tested this in Enforcing mode). Afterwards, you can file a new bz, attach the audit.log with all the denials that you managed to hit and I'll update the SELinux policy for another iteration of testing.
GUI can now be opened with SELinux in enforcing mode. Moving this bz to verified state. Boris, we will test BZ https://bugzilla.redhat.com/show_bug.cgi?id=1190201 with the suggestions you provided in comment 11.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:0313