Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
|
|
|
use utils;
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
|
|
|
# deploy a zezere (Fedora IoT provisioning server) instance
|
|
|
|
assert_script_run "dnf --enablerepo=updates-testing -y install zezere", 180;
|
|
|
|
# write config file
|
2023-03-04 03:05:26 +00:00
|
|
|
assert_script_run "printf '[global]\nsecret_key = SECRET_KEY\ndebug = yes\nallowed_hosts = localhost, localhost.localdomain, 172.16.2.118\nsecure_cookie = no\nauth_method = local\n\n[oidc.rp]\nsign_algo = RS256\n\n[database]\nengine = django.db.backends.sqlite3\nname = /var/local/zezere.sqlite3' > /etc/zezere.conf";
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
# write systemd unit file
|
|
|
|
assert_script_run "printf '[Unit]\nDescription=Zezere provisioning server\n\n[Service]\nExecStart=/usr/bin/zezere-manage runserver 172.16.2.118:80\n\n[Install]\nWantedBy=multi-user.target' > /etc/systemd/system/zezere.service";
|
|
|
|
assert_script_run "systemctl daemon-reload";
|
|
|
|
# open firewall port
|
|
|
|
assert_script_run "firewall-cmd --add-service=http";
|
|
|
|
# update DB schema
|
|
|
|
assert_script_run "zezere-manage makemigrations";
|
|
|
|
assert_script_run "zezere-manage migrate";
|
|
|
|
# load DB fixtures
|
|
|
|
assert_script_run "zezere-manage loaddata fedora_iot_runreqs";
|
|
|
|
assert_script_run "zezere-manage loaddata fedora_installed";
|
|
|
|
# create admin user
|
2020-12-15 20:43:53 +00:00
|
|
|
assert_script_run 'zezere-manage createsuperuser --username admin --email zezere@test.openqa.fedoraproject.org --no-input';
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
# set admin password (can't find a non-interactive way sadly)
|
|
|
|
type_string "zezere-manage changepassword admin\n";
|
2023-03-29 22:45:17 +00:00
|
|
|
wait_still_screen 5;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
type_string "weakpassword\n";
|
2023-03-29 22:45:17 +00:00
|
|
|
wait_still_screen 5;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
type_string "weakpassword\n";
|
2023-03-29 22:45:17 +00:00
|
|
|
wait_still_screen 5;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
# check DB exists
|
|
|
|
assert_script_run "ls -l /var/local/zezere.sqlite3";
|
|
|
|
# start server
|
|
|
|
assert_script_run "systemctl start zezere.service";
|
|
|
|
# check it seems to be running
|
|
|
|
assert_script_run "curl http://172.16.2.118";
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
2022-07-28 20:32:57 +00:00
|
|
|
return {fatal => 1};
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|