Description of problem: I tried to upgrade from RHEL4.4/x86/Satellite5.2.1 to RHEL6.2/x86_64/Satellite5.4.1. While following the upgrade procedure I was unable to complete the schema upgrade due to SELinux. Entries appeared in my logs similar to the following: Mar 1 14:58:11 sat setroubleshoot: SELinux is preventing sqlplus from search access on the directory /var/log/audit. For complete SELinux messages. run sealert -l edb75d6b-faa7-4cdb-8eab-0c4e275928c1 Mar 1 14:58:11 sat setroubleshoot: SELinux is preventing oracle from read access on the file ora_2526.aud. For complete SELinux messages. run sealert -l e340a5f6-3d51-487b-921d-5a7f4f16b27d This manifested in the oracle logs thusly: Starting Oracle DB instance "rhnsat" ... SQL*Plus: Release 10.2.0.4.0 - Production on Thu Mar 1 14:44:50 2012 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. SQL> Connected to an idle instance. SQL> ORA-09925: Unable to create audit trail file Linux-x86_64 Error: 13: Permission denied Additional information: 9925 Temporarily disabling SELinux allowed the database upgrade to complete. For a more permanent fix, I created an SELinux module with audit2allow. Version-Release number of selected component (if applicable): 5.4.1 (?) How reproducible: I was able to make this happen every time when trying to perform the DB migration/upgrade Steps to Reproduce: 1. Back up database on old Satellite system 2. Restore database on new RHEL6.2-based Satellite system 3. Follow the DB upgrade instructions Actual results: Permissions failure due to SELinux Expected results: No failure Additional info:
Please contact Red Hat support to help you with the Satellite upgrade issues you are experiencing and whether or not those issues are valid bug(s) in RHN Satellite product.
Has this issue been escalated to Red Hat support and / or resolved successfully? Thank you -Milan Zázrivec
I did not escalate this to support. We created a module w/ audit2allow and moved on. The problem manifested every time I set up a new instance of RHEL6.2 and tried to install Satellite, so it should not be difficult to reproduce.
All right, what did the denials (those showing during spacewalk-schema-upgrade) look like exactly?
I'll see if I can reproduce it again.
Alternatively, you can paste the source of the new SELinux modules here.
module RHNSatellite 1.0; require { type oracle_common_log_t; type oracle_db_t; class file read; } #============= oracle_db_t ============== allow oracle_db_t oracle_common_log_t:file read;
On the Satellite 5.2.1 installation -- has auditing been enabled in the embedded Oracle database?
I have no idea - we don't have the 5.2.1 installation anymore to check against, either. As far as 5.4.1 goes, everything is default as far as I know. We really just tried to follow the upgrade instructions included w/ Satellite, to the letter.
You can find out for example by running the following command as root: # rhn-db-stats - |grep audit
(In reply to comment #10) > You can find out for example by running the following command as root: > > # rhn-db-stats - |grep audit Forgot to mention -- this should be run on the 5.4 Satellite.
audit_file_dest string /rhnsat/admin/rhnsat/logs audit_sys_operations boolean FALSE audit_syslog_level string audit_trail string NONE
We were able to reproduce the problem described in the initial comment during upgrades; the fix (updated SELinux policy) will be available in Satellite 5.5. Thank you for your report & sorry for the trouble. Fixed in spacewalk.git master: 025063c2dbef237ed89166f64735da1897856419