Bug 1331081
Summary: | mitaka current-passed-ci fails to deploy on RHEL 7.2, galera not starting up on all controllers | ||
---|---|---|---|
Product: | [Community] RDO | Reporter: | Attila Darazs <adarazs> |
Component: | openstack-tripleo | Assignee: | James Slagle <jslagle> |
Status: | CLOSED EOL | QA Contact: | Shai Revivo <srevivo> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | trunk | CC: | adarazs, apevec, chris.brown, ggillies, michele, pasik, whayutin |
Target Milestone: | --- | Keywords: | Automation, AutomationBlocker |
Target Release: | Kilo | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-19 15:32:40 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Attila Darazs
2016-04-27 16:26:47 UTC
Likely a simple selinux relabel when building the image is missing: type=AVC msg=audit(1461646313.398:171): avc: denied { setpgid } for pid=12510 comm="mysqld" scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:system_r:mysqld_t:s0 tclass=process type=SYSCALL msg=audit(1461646313.398:171): arch=c000003e syscall=109 success=no exit=-13 a0=0 a1=0 a2=1 a3=8 items=0 ppid=12502 pid=12510 auid=4294967295 uid=27 gid=27 euid=27 suid=27 fsuid=27 egid=27 sgid=27 fsgid=27 tty=(none) ses=4294967295 comm="mysqld" exe="/usr/libexec/mysqld" subj=system_u:system_r:mysqld_t:s0 key=(null) Is this with tripleo-quickstart image or from-scratch custom built images? So I looked at the image building logs and it seems to set the selinux files: + echo dib-run-parts Tue Apr 26 00:15:04 EDT 2016 Running /tmp/in_target.d/finalise.d/90-selinux-fixfiles-restore dib-run-parts Tue Apr 26 00:15:04 EDT 2016 Running /tmp/in_target.d/finalise.d/90-selinux-fixfiles-restore + target_tag=90-selinux-fixfiles-restore + date +%s.%N + /tmp/in_target.d/finalise.d/90-selinux-fixfiles-restore + set -eu + set -o pipefail ++ which setfiles + SETFILES=/usr/sbin/setfiles + '[' -e /etc/selinux/targeted/contexts/files/file_contexts -a -x /usr/sbin/setfiles ']' + setfiles /etc/selinux/targeted/contexts/files/file_contexts / + target_tag=90-selinux-fixfiles-restore + date +%s.%N + output '90-selinux-fixfiles-restore completed' Could we do one of the two following steps to troubleshoot further? a) Add -v to 90-selinux-fixfiles-restore dib b) Call a virt-customize --selinux-relabel on the produced overcloud image and see if the issue is still there This bug is against a Version which has reached End of Life. If it's still present in supported release (http://releases.openstack.org), please update Version and reopen. Hi, We currently have an RDO mitaka environment experiencing this issue. Was the root cause ever accurately determined? It was closed as EOL but I'm not entirely sure that is accurate Regards, Graeme Graeme, did you observe the denials in comment 2? cheers, Michele I see some similar denials for mysql and haproxy type=AVC msg=audit(1467790984.329:131): avc: denied { name_bind } for pid=9632 comm="haproxy" src=3306 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket type=AVC msg=audit(1467790992.061:163): avc: denied { write } for pid=10505 comm="mysqld_safe" path="/tmp/tmp.c2XPC6oag1" dev="sda2" ino=16900546 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:cluster_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1467790992.061:163): arch=c000003e syscall=59 success=yes exit=0 a0=9aa610 a1=93a010 a2=976640 a3=7ffd526d34a0 items=0 ppid=10386 pid=10505 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/usr/bin/bash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) type=AVC msg=audit(1467790994.678:166): avc: denied { read } for pid=10865 comm="mysqld_safe" name="cores" dev="sda2" ino=19519726 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1467790994.678:166): arch=c000003e syscall=257 success=yes exit=3 a0=ffffffffffffff9c a1=4a9e9f a2=90800 a3=0 items=0 ppid=10864 pid=10865 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/usr/bin/bash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) type=AVC msg=audit(1467790994.679:167): avc: denied { write } for pid=10505 comm="mysqld_safe" path="/tmp/tmp.c2XPC6oag1" dev="sda2" ino=16900546 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:cluster_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1467790994.679:167): arch=c000003e syscall=1 success=yes exit=94 a0=1 a1=7fa2e2821000 a2=5e a3=5d items=0 ppid=10386 pid=10505 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/usr/bin/bash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) type=AVC msg=audit(1467791012.260:199): avc: denied { read } for pid=12255 comm="mysqld_safe" name="cores" dev="sda2" ino=19519726 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1467791012.260:199): arch=c000003e syscall=257 success=yes exit=3 a0=ffffffffffffff9c a1=4a9e9f a2=90800 a3=0 items=0 ppid=12254 pid=12255 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/usr/bin/bash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) but note that all nodes are running in selinux permissive mode, so this shouldn't affect anything right? Correct, if your systems are in permissive mode these do not apply. If we could get sosreports from all three nodes we can try and take a look and see what is going on there. |