New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement pam faillock test into openQA #13796
Conversation
assert_script_run("cp /etc/pam.d/common-auth /etc/pam.d/common-auth.back"); | ||
assert_script_run("cp /etc/pam.d/common-password /etc/pam.d/common-password.back"); | ||
assert_script_run("echo '$pam_config' >> /etc/pam.d/common-auth"); | ||
assert_script_run("echo '$pam_config' >> /etc/pam.d/common-password"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend you use variables to define files, such as /etc/pam.d/common-auth, /etc/pam.d/common-password
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the opposite option here, we don't need to set a variable for system configuration file, we used more lines but gain less benefit, and make code not friendly to be read. :)
If it is not a must one, I will keep current logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I understood what you mean, but defining a variable is really a good way, such as if file name changed in the future you only need to revise the definition line to update. Besides if the variable's name is well named it is also readable too :).
Anyway, it is optional you can “keep current logic". :)
a317498
to
af9cca6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
assert_script_run("cp /etc/pam.d/common-auth /etc/pam.d/common-auth.back"); | ||
assert_script_run("cp /etc/pam.d/common-password /etc/pam.d/common-password.back"); | ||
assert_script_run("echo '$pam_config' >> /etc/pam.d/common-auth"); | ||
assert_script_run("echo '$pam_config' >> /etc/pam.d/common-password"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I understood what you mean, but defining a variable is really a good way, such as if file name changed in the future you only need to revise the definition line to update. Besides if the variable's name is well named it is also readable too :).
Anyway, it is optional you can “keep current logic". :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the explanation.
https://openqa.suse.de/tests/7772350 -Full pam test run on SLE x86-64
https://openqa.suse.de/tests/7766999 - SLE s390x
https://openqa.suse.de/tests/7767003 - SLE aarch64
https://openqa.opensuse.org/tests/2065727 - TW x86_64
I didn't run VR on ppc64le, but I think it can pass the tests on it