QA » openQA Project » openQA Tests

Hi @tjyrinki_suse!
Could you provide some more clarifications regarding the acceptance criteria of this ticket?
If I have understood correctly, the point is to fix the sssd testing, but I miss some information like:

• The places that this test fails
• The new requirements for this test
• Link for the numbers in the description
• Acceptance criteria

Thanks :)

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12179

The removal of python-pam test cases will not reduce test coverage as they basically test the same functionalities.
In the future, we could add test cases for offline user authentication and information lookup. Junit is also used here incorrectly and should be removed to simplify the test.

I am rewriting the sssd test module based on discussion on the PR. https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12179
Below are some ideas for the new test cases:

1. local domain won't be tested as the feature is not recommended for use by sssd developer.
2. use "ssh -l" to test pam authentication instead of "su -l" as root because "su -l" actually does not go through PAM rules.
   
3. offline authentication and identity lookup will be covered.
4. use systemd to start ldap, sssd instead of on command line to test normal service start/stop.
   

Test plan:

SSSD includes PAM and NSS modules to allow remote users to login and be recognized as valid users, including group membership. It also can also cache this information to allow offline authentication.

Below are test cases:

1. nss_sss test: look up user information with getent/id.

2. pam_sss test: ssh login localhost as remote user.

3. offline authentication test: shutdown ldap server, ssh login localhost as remote user.

4. write permission test: change remote user password with passwd

5. sssd-sudo test: define a sudoers rule entries in ldap server which allow a remote user to open a file owned by another remote user (using /usr/bin/cat). The testing file can be created in testcase 2 above and only the remote owner has read permission.

The domain server can be either 389-ds or openldap, or both of them.

The major difference between this test and the sssd which is currently running in openQA is:

The test will cover more sssd functionalities and less connections with remote servers.

Thanks for clarifying Tony!

Please also consider: #13168 for your test plan

szarate wrote:

Thanks for clarifying Tony!

Please also consider: #13168 for your test plan

Ok, I will add sudo/sudoers testcases in this test plan.

How to automate these test cases:
The testcases will be running in a openQA job
Two options, both are doable:
Option 1. Setting up openldap/389-ds server in container and sssd in host. The testcases above are executed in host.
advantage: the test is self sufficient with no dependency

Option 2. Using/setting up dedicated openldap/389-ds server outside openQA. The test won't have to set up for itself.
advantage: make the test automation considerably easy
disadvantage: having dependency on dedicated external server

test cases and server configuration files are all placed in testopia
sssd openldap: https://bugzilla.suse.com/tr_show_case.cgi?case_id=1768711
sssd 389-ds: https://bugzilla.suse.com/tr_show_case.cgi?case_id=1768710

I'll look to setting up the instance in cloud.suse.de today

sssd automation plan:

1. As openldap will be discarded from sles. sssd automation test will be split into two test modules like sssd_openldap and sssd_389ds. Executing the two tests in one single openQA job. When openldap being discarded we just simply unscheduled sssd_openldap. We will not have to change code.

2. As there are already some sssd tests developed by some squads running in OSD, we could name the two modules sssd_openldap_functional, sssd_389ds_functional.

3. Setting up openldap/389-ds server in container and running the tests in single machine. It makes the automation development and maintenance much easier then multi-machines.

Below are verification run:
http://10.67.17.201/tests/1516
http://10.67.17.201/tests/1513
Note: The two modules require sshpass in Packagehub repo.

Hi Tony, can you use expect instead of sshpass? you can check tests/console/sshd.pm to see how it is being used there, as it doesn't depend on PackageHub.

For the rest, it's looking really good!

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12528

Before close this ticket.
I have some questions on the requirement of this ticket since we will base current implementation to integrate migration process.
1) what's the support status for following build version?
11sp4
12sp3
12sp4
2) what's support status for following platform?
s390
aarch
power
3) This ticket include sssd + Windows domain server scenario or not?(Or maybe we need another ticket?) Since i saw https://progress.opensuse.org/issues/34576 mention this scenario.

coolgw wrote:

Before close this ticket.
I have some questions on the requirement of this ticket since we will base current implementation to integrate migration process.
1) what's the support status for following build version?
11sp4
12sp3
12sp4

All versions newer than 12sp2 work.
I can not even find iso and repo for 11sp4.

2) what's support status for following platform?
s390
aarch
power
I don't have HW test. If you have you can try it. Just check out the latest code and schedule it as I told you. It will be done with 15 mins. It should work.

3) This ticket include sssd + Windows domain server scenario or not?(Or maybe we need another ticket?) Since i saw https://progress.opensuse.org/issues/34576 mention this scenario.

sssd + Windows is another ticket.

Again, the sssd test is designed for functional and maint update test, not for migration. It might not help as you expect. I suggest you no using it, but it's up to you.

The PR is now merged. I've created #93210 as a follow-up.

Tony, can you work on scheduling the test?

See https://gitlab.suse.de/openqa/all-yaml and do PRs against qam-openqa-yaml and from qa-sle-functional-userspace.

For Tumbleweed job group at https://openqa.opensuse.org/group_overview/1 can be edited directly, or you can paste eg here what to add there and on which line.

The Samba AD sssd work was actually started a long time ago, and that ticket is 72169.

sssd tests are already running in OSD.
12sp5 : https://openqa.suse.de/tests/overview?distri=sle&version=12-SP5&build=20210601-1&groupid=280
15sp3: https://openqa.suse.de/tests/overview?distri=sle&version=15-SP3&build=20210601-1&groupid=366

The PR was also tested on tumbleweed, and at least 389-ds testing should continue to be enabled for 15-SP4 and Tumbleweed, so I'd remove the sysauth/sssd.pm from functional/extra_tests_textmode_phub.yaml schedule and add sssd_389ds_functional to it (because using sshpass from packagehub) and to add also sssd_389ds_functional to functional/extra_tests_textmode.yaml under tumbleweed_tests.

Will openldap be removed off sle15sp4?
If openldap remain in sle15sp4 we can run both openldap_sssd and 389_ds sssd in a job.

A new PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12638

openLDAP server is already in Legacy module only in 15-SP3, but now I don't find authorative answer.

It's likely best to keep the test for now in 15-SP4 as well.

Opensuse TW aarch: https://openqa.opensuse.org/tests/1765683

Can we close this ticket?

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: extra_tests_textmode_phub
https://openqa.suse.de/tests/5989271

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: extra_tests_textmode_phub
https://openqa.suse.de/tests/5989271

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The label in the openQA scenario is removed

The failed sssd test was already removed off job schedule a while ago. The two new sssd functional tests take it's place.

cat schedule/functional/extra_tests_textmode_phub.yaml

name: extra_tests_in_textmode_phub
description: >
Maintainer: slindomansilla.
Extra tests about software in package hub
schedule:
- installation/bootloader_start
- boot/boot_to_desktop
- console/add_phub_extension
- console/python_scientific
- '{{wpa_supplicant}}'
- console/vmstat
- console/sssd_389ds_functional
- console/sssd_openldap_functional
- console/coredump_collect
conditional_schedule:
wpa_supplicant:
ARCH:
x86_64:
- console/wpa_supplicant

szarate wrote:

okurz wrote:

^{^}

If you are going to reopen a ticket, please state why, ^ to denote see previous test, when actual previous test corresponds to a product already released that hasn't had any changes is not one.

Sure but the reminder comment states what can be done in these cases. In the meantime after a longer time new builds for 15SP4 have been triggered so the problem is solved already.