Project

General

Profile

action #88247

manage password for multiple test users in os-autoinst for openQA tests

Added by leli 9 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Support
Target version:
Start date:
2021-01-27
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

User story

As a QA engineer, I need to add a user change password test during migration process, that is to change password of bernhard and create a new user before migration, check the new password still worked and switch user after migration then. After I changed the bernhard's password in base system, I need to make sure the later Authority pass with correct password, while the later modules such as first_boot, system_prepare, prepare_test_data etc., they require input different password for different users. OpenQA only holds one password and doesn't distinguish users, that's why I file this ticket.

Acceptance criteria

  1. We can easily set new password for user in openQA and don't need touch passwords for other users.
  2. Do not affect existing test.

Tasks

Store password for each users in os-autoinst, and use different password for type_password according to different users.

Further details

For example, when use type_password without parameter, it will use the $testapi::password which doesn't distinguish user. This will make us hard to deal with password in openQA if I changed the password of bernhard in system, we have to update the openQA password with $testapi::password= after that to match different password requirement(sometimes need login bernhard, sometimes need login root).
I would say why type_password with parameter doesn't work for my requirement. Let use the handle_login as example, it check user by console type, then type_password, so the user and password are dealed separately, I can't simply just type_password with my new password to fix the issue.

Refer to my ticket #70342 then you may know my pain.

So could we manage password for each user in openQA? So we can just set the new password for bernhard in openQA if changed the bernhard's password in system and do not need to touch other users's password.


Related issues

Has duplicate openQA Project - action #88297: Manage password for multiple test users in os-autoinst for openQA testsRejected2021-01-28

History

#1 Updated by okurz 9 months ago

  • Description updated (diff)

#2 Updated by okurz 9 months ago

  • Subject changed from OpenQA need manage password for each user to manage password for multiple test users in os-autoinst for openQA tests
  • Category changed from Feature requests to Support
  • Status changed from New to Feedback
  • Assignee set to okurz
  • Priority changed from Normal to Low
  • Target version set to Ready

Hi,

leli wrote:

Now it seems openQA holds one password for all users include root, bernhard, etc.
For example, when use type_password without parameter, it will use the $testapi::password which doesn't distinguish user.

True. But if you use type_password with parameter then you can use any password, see https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#L1464 . So I see no problem when you want to manage additional users you create them and either use the same password or store the different password in a test variable that can even be used with type_password by giving the password variable as an argument after type_password. If I did not get your meaning it might help if you fill the ticket description following the "feature request" template from https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests

#3 Updated by leli 9 months ago

okurz wrote:

Hi,

leli wrote:

Now it seems openQA holds one password for all users include root, bernhard, etc.
For example, when use type_password without parameter, it will use the $testapi::password which doesn't distinguish user.

True. But if you use type_password with parameter then you can use any password, see https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#L1464 . So I see no problem when you want to manage additional users you create them and either use the same password or store the different password in a test variable that can even be used with type_password by giving the password variable as an argument after type_password. If I did not get your meaning it might help if you fill the ticket description following the "feature request" template from https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests

I know I can type_password with parameter, but the type_password invoked in public functions, so I can't simplely change it to type_password with parameter for my test.

#4 Updated by leli 9 months ago

  • Status changed from Feedback to New

#5 Updated by okurz 9 months ago

leli wrote:

I know I can type_password with parameter, but the type_password invoked in public functions, so I can't simplely change it to type_password with parameter for my test.

Sorry, I don't understand. Please rephrase

#6 Updated by leli 9 months ago

Let me summary it, I need to add a user change password test during migration process, that is change password of bernhard and create a new user before migration, check the new password still worked and switch user after migration then. After I changed the bernhard's password in base system, I need to make sure the later Authority pass with correct password, while the later modules such as first_boot, system_prepare, prepare_test_data etc., they require input different password for different users. OpenQA only holds one password and doesn't distinguish users, that's why I file this ticket.

I would say why type_password with parameter doesn't work for my requirement. Let use the handle_login as example, it check user by console type, then type_password, so the user and password are dealed separately, I can't simply just type_password with my new password to fix the issue. My suggestion is to store password for each users in os-autoinst, and use different password for type_password according to different users. If so, I just need save the new password for bernhard to testapi is ok.

sub handle_login {
my ($myuser, $user_selected) = @_;
$myuser //= $username;
$user_selected //= 0;

save_screenshot();
# wait for DM, avoid screensaver and try to login
# Previously this pressed esc, but that makes the text field in SDDM lose focus
send_key_until_needlematch('displaymanager', 'shift', 30, 3);
if (get_var('ROOTONLY')) {
    if (check_screen 'displaymanager-username-notlisted', 10) {
        record_soft_failure 'bgo#731320/boo#1047262 "not listed" Login screen for root user is not intuitive';
        assert_and_click 'displaymanager-username-notlisted';
        wait_still_screen 3;
    }
    type_string "root\n";
}
elsif (match_has_tag('displaymanager-user-prompt') || get_var('DM_NEEDS_USERNAME')) {
    type_string "$myuser\n";
}
elsif (check_var('DESKTOP', 'gnome')) {
    if ($user_selected || (is_sle('<15') || is_leap('<15.0'))) {
        send_key 'ret';
    }
    # DMs in condition above have to select user
    else {
        select_user_gnome($myuser);
    }
}
assert_screen 'displaymanager-password-prompt';
type_password;
send_key 'ret';

#7 Updated by leli 9 months ago

#8 Updated by okurz 9 months ago

  • Has duplicate action #88297: Manage password for multiple test users in os-autoinst for openQA tests added

#9 Updated by okurz 9 months ago

  • Description updated (diff)

incorporated description from #88297 here

#10 Updated by okurz 8 months ago

  • Status changed from New to Feedback

leli I think I understand your requirements but still I consider it a rather specific requirement which I don't think needs to be or should be handled within os-autoinst. What you could use is to store a password per user in a hash of the test modules themselves, e.g. the following might just work:

    $self->{$user}{password} = $testapi::password;
    ...
    type_password $self->{$user}{password};
    ...
    $self->{$user}{password} = $testapi::password . 'new';
    ...
    type_password $self->{$user}{password};

#11 Updated by okurz 8 months ago

leli does the above suggestion help?

#12 Updated by leli 8 months ago

okurz wrote:

leli does the above suggestion help?

In fact, I think the suggestion give me more methods to deal with password inside the service check test, but this won't help since the mainly concern is outside of the test.
For there is a long process for migration test, take the https://openqa.nue.suse.com/tests/5554771 as an example: we will change the password of Bernhard in install_service of 'before migration', then after migration we will test the new password in check_upgraded_service, there are many test modules during migration process between the two modules such as first_boot,system_prepare, etc need input the password of 'Bernhard' or 'root' and finial call the type_password without any parameters. So the issue is here, openQA don't manage passwords for multiple test users so can't deal with such situation.

#13 Updated by okurz 8 months ago

leli wrote:

So the issue is here, openQA don't manage passwords for multiple test users so can't deal with such situation.

Sorry, I don't understand. Maybe you can explain to me what would be missing in #88247#note-10 so that it can handle a more generic problem? We could of course fill that hash within os-autoinst already but as long as you are only using os-autoinst-distri-opensuse and no other test distribution it should not make a difference to you if that code is only in os-autoinst-distri-opensuse or more upstream.

#14 Updated by okurz 7 months ago

  • Status changed from Feedback to Resolved

No response. I hope I could help you. Other than that I do not see yet how os-autoinst can help with password management.

#15 Updated by leli 7 months ago

Sorry, I missed the last comments from you. The password management should be a hash such as root - rootpw, bernhard - bernhard password, the type_password without parameter will use the $password in testapi simply for all users. I just hope the function type_password will enhance to type correct password according current user, then the issue will gone.

#16 Updated by okurz 7 months ago

Again, we could of course fill that hash within os-autoinst already but as long as you are only using os-autoinst-distri-opensuse and no other test distribution it should not make a difference to you if that code is only in os-autoinst-distri-opensuse or more upstream.

#17 Updated by leli 7 months ago

okurz wrote:

Again, we could of course fill that hash within os-autoinst already but as long as you are only using os-autoinst-distri-opensuse and no other test distribution it should not make a difference to you if that code is only in os-autoinst-distri-opensuse or more upstream.

Ok, understood. We have changed test now to avoid such issue, so no problem for now.

Also available in: Atom PDF