QA (public) » openQA Project (public) » openQA Tests (public)

just a quick note: for the verification runs you can create an iso as described here:
https://bugzilla.suse.com/show_bug.cgi?id=1230118#c7

Question: what's the best way to handle this ?

Seems like we need to support both selinux-tumbleweed and apparmor-tumbleweed.
Is there a special variable set somewhere to differentiate or we should rely on the build/test name ?

amanzini wrote in #note-5:

Question: what's the best way to handle this ?

Seems like we need to support both selinux-tumbleweed and apparmor-tumbleweed.
Is there a special variable set somewhere to differentiate or we should rely on the build/test name ?

if the default is changing in TW, that's what has to be supported, if I understand correctly and this was needed for staging: is_staging can be used, as for variables, check: https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/variables.md

In the end, apparmor should be dropped from TW's testing

szarate wrote in #note-6:

amanzini wrote in #note-5:

Question: what's the best way to handle this ?

Seems like we need to support both selinux-tumbleweed and apparmor-tumbleweed.
Is there a special variable set somewhere to differentiate or we should rely on the build/test name ?

if the default is changing in TW, that's what has to be supported, if I understand correctly and this was needed for staging: is_staging can be used, as for variables, check: https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/variables.md

In the end, apparmor should be dropped from TW's testing

As release manager I beg to differ!
Just as a sure can now switch to SELinux - and we have a test for that, once TW moves to SELinux by default, the option to switch to AppArmor will be present in the installer and we need to provide tests for that

dimstar wrote in #note-7:

szarate wrote in #note-6:

amanzini wrote in #note-5:

Question: what's the best way to handle this ?

Seems like we need to support both selinux-tumbleweed and apparmor-tumbleweed.
Is there a special variable set somewhere to differentiate or we should rely on the build/test name ?

if the default is changing in TW, that's what has to be supported, if I understand correctly and this was needed for staging: is_staging can be used, as for variables, check: https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/variables.md

In the end, apparmor should be dropped from TW's testing

As release manager I beg to differ!
Just as a sure can now switch to SELinux - and we have a test for that, once TW moves to SELinux by default, the option to switch to AppArmor will be present in the installer and we need to provide tests for that

yes, please do not remove the apparmor tests, they are still needed as dimstar said
apparmor should be tested as before, but just not set as default in the installer

dimstar wrote in #note-7:

szarate wrote in #note-6:

amanzini wrote in #note-5:

Question: what's the best way to handle this ?

Seems like we need to support both selinux-tumbleweed and apparmor-tumbleweed.
Is there a special variable set somewhere to differentiate or we should rely on the build/test name ?
In the end, apparmor should be dropped from TW's testing

As release manager I beg to differ!
Just as a sure can now switch to SELinux - and we have a test for that, once TW moves to SELinux by default, the option to switch to AppArmor will be present in the installer and we need to provide tests for that

Okash! so we're having two different install paths, with selinux and with apparmor; @dimstar question would be then: how far into the testing of apparmor we go?... i.e #138368 (thinking to drop apparmor support far into the future?)

szarate wrote in #note-9:

Okash! so we're having two different install paths, with selinux and with apparmor; @dimstar question would be then: how far into the testing of apparmor we go?... i.e #138368 (thinking to drop apparmor support far into the future?)

So far there is no plan to drop AppArmor from Tumbleweed - The community (mainly @cboltz) has been maintaining it for quite a while already and is very responsive on issues. I know of users that would really not like to migrate their existing, extensive AA policies over to SELinux (as some features cannot be mapped)

The 'default' should be switched; We have a few places int he code that 'imply' AA would be there, which are the most common issues. Then we need to have a create_hdd_apparmor installation (just as we now have a _selinux, which won't be needed anymore) to fire off the addon tests (like apache_changehat, to just name one coming to mind)

checking on latest test passes: https://openqa.opensuse.org/tests/4704343 ; is this ticket still relevant ?

amanzini wrote in #note-14:

checking on latest test passes: https://openqa.opensuse.org/tests/4704343 ; is this ticket still relevant ?

yes it is, the tests are currently not running with SELinux in enforcing mode, except the one that i linked in my first message (see the -SELinux suffix).

please refer to the context: https://bugzilla.suse.com/show_bug.cgi?id=1230118
you will need to have a custom image for verification runs: https://bugzilla.suse.com/show_bug.cgi?id=1230118#c7
@rfan1 created a test image that you can use: https://bugzilla.suse.com/show_bug.cgi?id=1230118#c8

if you have more questions, let me know

please note that current selinux tumbleweed test switches to enforcing mode right after setup : https://openqa.opensuse.org/tests/4704343#step/enforcing_mode_setup/73

so I wonder if we can avoid the need of a custom ISO, which is not so convenient on the test automation perspective, and test any needed packages or codestreams by switching to SELINUX enforcing after the OS installation. Of course we'd miss to test the installer itself, but I don't think that installer is run under SELINUX in any case.

The rfan_tw_selinux.qcow2, while still available, is too old for testing since packages cannot be installed anymore: https://openqa.opensuse.org/tests/4712111#step/selinux_setup/23

I've created a custom ISO, for creating custom HDD, but currently don't have rights to upload it to openqa.opensuse.org, so at the moment we have no way of reproducing the problem of the ticket.

tjyrinki_suse wrote in #note-17:

The rfan_tw_selinux.qcow2, while still available, is too old for testing since packages cannot be installed anymore: https://openqa.opensuse.org/tests/4712111#step/selinux_setup/23

I've created a custom ISO, for creating custom HDD, but currently don't have rights to upload it to openqa.opensuse.org, so at the moment we have no way of reproducing the problem of the ticket.

you can request access by asking in the openQA element channel

amanzini wrote in #note-16:

please note that current selinux tumbleweed test switches to enforcing mode right after setup : https://openqa.opensuse.org/tests/4704343#step/enforcing_mode_setup/73

so I wonder if we can avoid the need of a custom ISO, which is not so convenient on the test automation perspective, and test any needed packages or codestreams by switching to SELINUX enforcing after the OS installation. Of course we'd miss to test the installer itself, but I don't think that installer is run under SELINUX in any case.

then you would need to do this for every openqa test existing, i dont think that would be easier. the whole openqa test suite is the test for selinux since we want to make sure that selinux does not break any of the use cases.
my goal is to get the test suite ready enough that dimstar can accept my submission to switch the default iso to have SELinux selected in the installer.
then, you can assume that the tw iso already will lead to selinux enabled when using the default settings.

I have access now and I have uploaded openSUSE-Tumbleweed-DVD-x86_64-Snapshot20241216-Media-selinux.iso which could be possibly used for creating HDD with custom PUBLISH_HDD_1 setting and then that HDD for testing. The ISO was created according to the instructions in the bug.

@cahu if your plans includes a broad distro coverage, I guess would make sense to treat the new 'selinux-tumbleweed' as a separate flavor (until it becomes the default) so all tests can be scheduled to run over it; at that point there will be even no need for the initial selinux_setup step.

Back to this ticket actionable, if I get it right, we are asked to make module selinux_setup.pm not fail even if SELINUX is already enabled, but only if the system is one of those "selinux-by-default".

currently has_selinux returns 0 on this image: https://openqa.opensuse.org/tests/4719770#step/selinux_setup/33 ; should we detect it in another way ?

forcing SELINUX=1 the step passes, but other tests need some more work
PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20856