action #88247
closedmanage password for multiple test users in os-autoinst for openQA tests
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¶
- We can easily set new password for user in openQA and don't need touch passwords for other users.
- 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.
Updated by okurz almost 4 years 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
Updated by leli almost 4 years 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 withtype_password
by giving the password variable as an argument aftertype_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.
Updated by okurz almost 4 years 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
Updated by leli almost 4 years 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';
Updated by leli almost 4 years ago
Created a new ticket following the "feature request" template from https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests. https://progress.opensuse.org/issues/88297
Updated by okurz almost 4 years ago
- Has duplicate action #88297: Manage password for multiple test users in os-autoinst for openQA tests added
Updated by okurz almost 4 years 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};
Updated by leli almost 4 years 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.
Updated by okurz almost 4 years 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.
Updated by okurz almost 4 years 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.
Updated by leli almost 4 years 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.
Updated by okurz almost 4 years 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.
Updated by leli almost 4 years 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.