On Thu, 2020-07-09 at 16:14 -0400, Rob Crittenden wrote:
I guess I'd start with looking to see if 389-ds is dropping core or
hanging in some way, both of which would be surprising if it has
virtually no data in it.
I'd suggest doing some ldapsearch's to see if the LDAP server is up.
Some simple ipa cli commands can be used instead: ipa user-find, etc.
For a hanging server see:
https://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs
To debug a core:
https://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-cra...
rob
Hi Rob,
So, I decided to reinstall and redeploy FreeIPA. The issue is still
there.
I looked closer at the java traces, and thought it looked like
something was preventing tomcat from accessing resources. SELinux is in
enforcing mode, so that's the first place I checked.
And lo and behold, /var/log/audit/audit.log was full of SELinux
denials:
type=AVC msg=audit(1594398227.752:942): avc: denied { remove_name }
for pid=10241 comm="java" name="10241" dev="dm-0"
ino=3448
7066 scontext=system_u:system_r:tomcat_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1594398227.752:942): avc: denied { unlink }
for pid=10241 comm="java" name="10241" dev="dm-0"
ino=34487066
scontext=system_u:system_r:tomcat_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0
And so on..
audit2why -b shows:
[root@fipa001 log]# audit2why -b
type=AVC msg=audit(1594398139.436:901): avc: denied { read }
for pid=8351 comm="java" name="hsperfdata_pkiuser"
dev="dm-0"
ino=34487069 scontext=system_u:system_r:tomcat_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
type=AVC msg=audit(1594398139.436:902): avc: denied { create }
for pid=8351 comm="java" name="8351"
scontext=system_u:system_r:tomcat_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
type=AVC msg=audit(1594398139.436:902): avc: denied { add_name }
for pid=8351 comm="java" name="8351"
scontext=system_u:system_r:tomcat_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
type=AVC msg=audit(1594398139.436:902): avc: denied { write }
for pid=8351 comm="java" name="hsperfdata_pkiuser"
dev="dm-0"
ino=34487069 scontext=system_u:system_r:tomcat_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
type=AVC msg=audit(1594398139.437:903): avc: denied { map }
for pid=8351 comm="java" path="/tmp/hsperfdata_pkiuser/8351"
dev="dm-
0" ino=34487070 scontext=system_u:system_r:tomcat_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0
Was caused by:
The boolean domain_can_mmap_files was set incorrectly.
Description:
Allow domain to can mmap files
Allow access by executing:
# setsebool -P domain_can_mmap_files 1
type=AVC msg=audit(1594398156.219:904): avc: denied { read }
for pid=8578 comm="java" name="hsperfdata_pkiuser"
dev="dm-0"
ino=34487069 scontext=system_u:system_r:tomcat_t:s0
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
type=AVC msg=audit(1594398156.219:905): avc: denied { create }
for pid=8578 comm="java" name="8578"
scontext=system_u:system_r:tomcat_t:s0
tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module
to allow this access.
etc. etc...
So, I reinstalled the OS, set SELinux to permissive and tried again.
It still complains in the audit log of course, but it seems that the
java errors are only in the /var/log/pki/pki-tomcat/ca/debug log file
for the first few minutes during and after install.
It's been running for 10 minutes now without anything reported in the
pki-tomcat debug log. All IPA commands I've tried work as expected.
The cause of this is a mystery to me, but it looks like something might
be missing in the installation procedure. The error is there regardless
of install method (by hand or ansible).
I can put the log files on our nextcloud server if you'd like to have a
look at them.
/tony
--
Tony Albers - Systems Architect - IT Development
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark
Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142