I'll try that - presumably on the paths it is complaining about, and the qemu binarys?It shouldn't hurt on /, it should only help:)And if it complains e.g. on attached nfs, the i suppose you need to run it there tooOn Wed, May 25, 2016 at 4:59 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:On 25 May 2016, at 17:35, Cam Mac <iucounu@gmail.com> wrote:Hi Michal,I chose the 'reinstall node' option from the GUI menu, which appeared to go ok, however, I still cannot create or migrate a VM on that node. I can see selinux 'denied' messages relating to qemu-kvm, e.g.:type=AVC msg=audit(1464189232.136:251): avc: denied { read } for pid=4019 comm="qemu-kvm" name="650000ab-b33a-483a-af46-76f7305e2ae5" dev="sda2" ino=35401 scontext=system_u:system_r:svirt_t:s0:c720,c927 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_fileThere are a number of errors in the vdsm log but I assume that relates to selinux blocking it. So perhaps I need to remove all the ovirt packages manually, or perhaps re-install the OS as well? I guess either of those options involves complications with certificates and WWIDs for the attached SAN.Or could I somehow generate selinux labels?yeah, I think it didn’t happen. I though we do relabelling as part of deployHow about running "restorecon -r” now?These nodes + engine are not yet production, though I'd prefer to fix than restart entirely from scratch.Thanks for any help.regards,
CampbellOn Wed, May 11, 2016 at 3:13 PM, Cam Mac <iucounu@gmail.com> wrote:Ah, ok that makes sense. For the node, is it enough to use the 'reinstall node' option from the GUI, or is it better to reinstall the OS and then deploy it again?Thanks,
CamOn Wed, May 11, 2016 at 2:40 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:On 11 May 2016, at 15:24, Cam Mac <iucounu@gmail.com> wrote:Thanks Michal, if reinstalling the engine, (which also had SELinux disabled at install), would the best way be to backup the engine and then restore just the ovirt config?for engine..well, VM security is not related to that, those are running on hypervisors, not the engine. So for any functionality/security it’s irrelevant what SELinux state it’s inI’m not sure if relabeling with restorecon is not enough (it sould work also on nodes, but as I said, it’s likely more safe to reinstall just to be really really sure:)Simone, am I right about the restorecon for engine?Cheers,Cam_______________________________________________On Wed, May 11, 2016 at 2:14 PM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
> On 11 May 2016, at 15:02, Cam Mac <iucounu@gmail.com> wrote:
>
> Hi,
>
> In the oVirt guide, it says that "SELinux is being used by default on oVirt Node", but then goes on to say that if you have problems you should set it to permissive mode. I have had a few things fail due to being blocked by SELinux on a node I later enabled SELinux on, as it was off at install time. The other node which has had SELinux on from the start and so far has not had any oVirt operations blocked. I am guessing that the oVirt install process creates the necessary rules to allow vdsm to run under SELinux. So if you want to set SELinux to enforcing after installation, is there a script to do this, or is it better to just reinstall the node or engine, rather than trying to work out the individual exceptions?
For oVirt node it’s easier to reinstall it, it doesn’t persist much and it’s the easies way how to get the labelling right
Thanks,
michal
>
> Thanks,
>
> Cam
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users