action #33868
closed[sle][functional][u]test fails in execute_test_run - setup issue or /usr/share/qa/qa_test_apparmor/wrapper.sh: line 9: ./aa_exec.sh: No such file or directory
0%
Description
Observation¶
openQA test in scenario sle-15-Installer-DVD-s390x-qa_userspace_cracklib@s390x-kvm-sle12 fails in
execute_test_run
Reproducible¶
Fails since (at least) Build 522.1
Expected result¶
Last good: 509.1 (or more recent)
Suggestions¶
- Understand what the test case is doing
- Crosscheck manually
- If necessary reopen bsc#1086254 but only when you can provide better information to the developers where they need to look further
Further details¶
Always latest result in this scenario: latest
Please see reference bug report bsc#1086254.
comment from Kristoffer:
Hi, I have not looked at cracklib before but was asked to have a look at this issue, so forgive me if I'm misunderstanding something that I'm seeing... I find the following in the logs:
Mar 21 06:18:21 susetest passwd[2357]: pam_cracklib(passwd:chauthtok): conversation failed
Mar 21 06:18:21 susetest passwd[2357]: pam_cracklib(passwd:chauthtok): pam_get_authtok_verify returned error: Authentication token manipulation error
Mar 21 06:18:22 susetest passwd[2381]: pam_unix(passwd:chauthtok): authentication failure; logname= uid=1001 euid=0 tty= ruser= rhost= user=testcrypt
"Authentication token manipulation error" is an output from pam_chauthtok:
https://linux.die.net/man/3/pam_chauthtok
PAM_AUTHTOK_ERR, A module was unable to obtain the new authentication token.
Comparing the output of the failing run with the previous successful run, it looks to me like the current password (that was set before running the test) does not match what openqa is passing in:
success:
su testcrypt -c passwd¶
Changing password for testcrypt.
Current password:
New password:
BAD PASSWORD: is too similar to the old one
PASSED: cracklib - similar passwd
failure:
su testcrypt -c passwd¶
Changing password for testcrypt.
Current password:
passwd: Authentication failure
passwd: password unchanged
The new password is never even passed in, so cracklib is presumably never invoked. So it looks like this problem is not really related to cracklib, but the password that was passed to it.