1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-22 14:03:09 +00:00
os-autoinst-distri-fedora/tests/freeipa_client.pm

49 lines
1.8 KiB
Perl
Raw Permalink Normal View History

add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
use base "installedtest";
use strict;
use testapi;
use utils;
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
sub run {
my $self = shift;
# switch to tty1 (we're usually there already, but just in case
# we're carrying on from a failed freeipa_webui that didn't fail
# at tty1)
send_key "ctrl-alt-f1";
wait_still_screen 1;
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# check domain is listed in 'realm list'
validate_script_output 'realm list', sub { $_ =~ m/domain-name: test\.openqa\.fedoraproject\.org.*configured: kerberos-member/s };
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# check we can see the admin user in getent
assert_script_run 'getent passwd admin@TEST.OPENQA.FEDORAPROJECT.ORG';
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# check keytab entries
add a cockpit realmd FreeIPA join test Summary: This requires a few other changes: * turn clone_host_resolv into clone_host_file, letting you clone any given host file (cloning /etc/hosts seems to make both server deployment and client enrolment faster/more reliable) * allow loading of multiple POSTINSTALL tests (so we can share the freeipa_client_postinstall test). Note this is compatible, existing uses will work fine * move initial password change for the IPA test users into the server deployment test (so the client tests don't conflict over doing that) * add GRUB_POSTINSTALL, for specifying boot parameters for boot of the installed system, and make it work by tweaking _console_wait _login (doesn't work for _graphical_wait_login yet, as I didn't need that) * make the static networking config for tap tests into a library function so the tests can share it * handle ABRT problem dirs showing up in /var/spool/abrt as well as /var/tmp/abrt (because the enrol attempt hits #1330766 and the crash report shows up in /var/spool/abrt, don't ask me why the difference, I just work here) * specify the DNS servers from the worker host's resolv.conf as the forwarders for the FreeIPA server when deploying it; if we don't do this, rolekit defaults to using the root servers as forwarders(!) and thus we get the public, not phx2-appropriate, results for e.g. mirrors.fedoraproject.org, some of which the workers can't reach, so PackageKit package install always fails (boy, was it fun figuring THAT mess out) Even after all that, the test still doesn't actually pass, but I'm reasonably confident this is because it's hitting actual bugs, not because it's broken. It runs into #1330766 nearly every time (I think I saw *one* time the enrolment actually succeeded), and seems to run into a subsequent bug I hadn't seen before when trying to work around that by trying the join again (see https://bugzilla.redhat.com/show_bug.cgi?id=1330766#c37 ). Test Plan: Run the test, see what happens. If you're really lucky, it'll actually pass. But you'll probably run into #1330766#c37, I'm mostly posting for comment. You'll need a tap-capable openQA instance to test this. Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D880
2016-06-07 20:00:39 +00:00
my $hostname = script_output 'hostname';
my $qhost = quotemeta($hostname);
validate_script_output 'klist -k', sub { $_ =~ m/$qhost\@TEST\.OPENQA\.FEDORAPROJECT\.ORG/ };
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# check we can kinit with the host principal
assert_script_run "kinit -k host/$hostname\@TEST.OPENQA.FEDORAPROJECT.ORG";
# Set a longer timeout for login(1) to workaround RHBZ #1661273
assert_script_run 'echo "LOGIN_TIMEOUT 180" >> /etc/login.defs';
# switch to tty2 for login tests
send_key "ctrl-alt-f2";
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
# try and login as test1, should work
console_login(user => 'test1@TEST.OPENQA.FEDORAPROJECT.ORG', password => 'batterystaple');
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
type_string "exit\n";
# try and login as test2, should fail. we cannot use console_login
# as it takes 10 seconds to complete when login fails, and
# "permission denied" message doesn't last that long
sleep 2;
assert_screen "text_console_login";
type_string "test2\@TEST.OPENQA.FEDORAPROJECT.ORG\n";
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
assert_screen "console_password_required";
type_string "batterystaple\n";
assert_screen "login_permission_denied";
}
sub test_flags {
return {fatal => 1};
add FreeIPA server role deploy and kickstart enrolment tests Summary: These require openQA tap networking to allow the server and client boxes to communicate, and require masquerading (NAT) so the server at least can reach a repository (dnf/rolekit really, really do not want to work without a repo connection). They use the 'parallel' test support to have the server deploy run first while the client enrol test waits at the grub menu until the server is done before it goes ahead. This is all deployed and working on stg. The really tricky bit was getting all the openvswitch and firewall config right in ansible. We *could* do the server deploy test as a follow-on from the default install test to save the install, but then we'd have to teach it to change the hostname and set up static networking post-install. I'm not sure if it's worth doing that. This requires the corresponding openqa_fedora_tools commit that adds the hard disks (containing the kickstarts - it's possible to get them from remote during install, but we have to set up name resolution or hard code the IP of the server). Test Plan: Deploy this and the openqa_fedora_tools commit, generate the disks, configure the networking (good luck! See the docs in openqa_fedora_tools) and see if you can run the tests. If you're using Docker, uh...sorry. You somehow need to set things up so the workers can use tap interfaces that can talk to each other and are NATed to the outside world. Have fun. I can talk you through it on IRC... Reviewers: jskladan, garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 18:53:11 +00:00
}
1;
# vim: set sw=4 et: