Bug 1301050 - SELinux context problem on pre generated overcloud images causing journald fail to start
SELinux context problem on pre generated overcloud images causing journald fa...
Status: CLOSED DUPLICATE of bug 1293942
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
x86_64 Linux
urgent Severity high
: y3
: 7.0 (Kilo)
Assigned To: Ben Nemec
Udi Shkalim
:
Depends On: 1293942
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-22 07:46 EST by Ofer Blaut
Modified: 2016-02-04 10:00 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1293942
Environment:
Last Closed: 2016-02-04 09:36:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 Hugh Brock 2016-01-22 08:43:01 EST
I originally assigned this to Ryan Hallisey, but mburns tells me we need to either add restorecon to the image build process or move openstack-selinux install earlier.
Comment 2 Ben Nemec 2016-01-22 18:36:24 EST
The original bug was opened against OSP 8.  Has this actually been reproduced on OSP 7?  I'm not seeing it on images built against the latest 7.3 poodle:

[root@overcloud-compute-0 etc]# ls -lZ machine-id 
-r--r--r--. root root unconfined_u:object_r:machineid_t:s0 machine-id

And systemd-journald is running fine:

[root@overcloud-compute-0 heat-admin]# systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since Fri 2016-01-22 18:18:00 EST; 8min ago

The deployment completed fine and a quick sanity check shows the major services working fine.  I guess it's possible something is broken only in the Brew builds, but if that's the case then I need to know which specific images have the problem.
Comment 3 Mike Burns 2016-01-27 10:00:27 EST
Ofer, can you comment please?
Comment 4 Udi Shkalim 2016-02-02 08:12:23 EST
Hi Ben,

We encountered this bug on an earlier 7.3 puddle during IPv6 tests: https://bugzilla.redhat.com/show_bug.cgi?id=1300800 which was verified.
Comment 5 Ben Nemec 2016-02-03 09:24:18 EST
Okay, so the bug (https://bugzilla.redhat.com/show_bug.cgi?id=1300800) was verified as fixed.  That indicates to me that this problem did not block them from deploying anymore.  Are there any ongoing instances of this bug?  I haven't been able to reproduce it, so I would have no way to verify whether any changes fix the problem.  Without a reproducer I don't know what we can do about this.
Comment 6 Udi Shkalim 2016-02-04 08:14:26 EST
We manged to solve it due to https://bugzilla.redhat.com/show_bug.cgi?id=1293942
workaround.

I think the disk image builder added a restorecon so we will not encounter this.

Mike, can you confirm/reject?
Comment 7 Ben Nemec 2016-02-04 09:04:17 EST
diskimage-builder has always done a restorecon at the end of the build.  Based on the fact that Rhys is seeing this in a packstack install I'm 99% sure this isn't an image problem.  I suspect something in the puppet modules we use to install both was causing the issue.  Beyond that speculation I can't say much more though.  In any case, if this is not reproducible in the latest images I'm inclined to say it should not be a blocker.  If somebody is able to reproduce it then we can look further.
Comment 8 Mike Burns 2016-02-04 09:36:22 EST
Since the other bug is verified, marking this as a duplicate.  If this reproduces, please reopen.

*** This bug has been marked as a duplicate of bug 1293942 ***
Comment 9 Udi Shkalim 2016-02-04 09:53:08 EST
I agree. I'll keep my eyes open for this one.
Comment 10 Raoul Scarazzini 2016-02-04 10:00:28 EST
(In reply to Ben Nemec from comment #5)
> Okay, so the bug (https://bugzilla.redhat.com/show_bug.cgi?id=1300800) was
> verified as fixed.  That indicates to me that this problem did not block
> them from deploying anymore.  Are there any ongoing instances of this bug? 
> I haven't been able to reproduce it, so I would have no way to verify
> whether any changes fix the problem.  Without a reproducer I don't know what
> we can do about this.

Hi Ben, just for completeness, I've just deployed a Mitaka environment generating images from scratch and the problem is still there:

[root@overcloud-controller-1 ~]# ls -lZ /etc/machine-id 
-rw-r--r--. root root system_u:object_r:unlabeled_t:s0 /etc/machine-id

So without the workaround I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1293942.

Note You need to log in before you can comment on or make changes to this bug.