fd1fe3424a
102 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Adam Williamson
|
66fc3cc7d4 |
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 |
||
|
Adam Williamson
|
aba2814611 |
add cockpit_default and cockpit_basic tests
Summary: This adds tests for the Server_cockpit_default and cockpit_basic test cases. Some notes: I was initially thinking of combining these into a single test with multiple test modules and coming up with a system for doing wiki reporting based on individual test module status, but because we'll also want to do a cockpit FreeIPA enrol test, I decided against it. We don't really want to combine all three because then we would skip the cockpit tests whenever FreeIPA server deployment failed, which isn't ideal. So since we'll need a separate FreeIPA enrolment test anyway it doesn't really make sense to go to the trouble of designing a system for loading multiple postinstall tests (though I have an idea for that!) and a per-module wiki reporting system. This was the most minimal and hopefully reliable method for running Cockpit from a stock Server install that I could think of. An alternative approach would be to have, say, the most recent stable Workstation live as a 'stock' asset and have two tests, one which runs a stock Server install and just waits and another which boots the live image and accesses the cockpit running on the other box, but that seems a bit over-complex. It is not possible to have dependencies between tests for different ISOs, in case you were wondering about having a Workstation live test which runs parallel with a Server DVD test, we can't do that. One funny thing is the font that winds up getting used for the desktop, but I don't *think* that should be a problem. Picking needles was a bit tricky; any improvement suggestions are welcome. I'm hoping it turns out to be safe to rely on some dbus log messages being present; I think logging into Cockpit triggers activation of the realmd dbus interface, so there *should* always be some messages related to that. An alternative would just be to match on a sliver of the dark grey table header and the light grey row beneath it and assume that'll always be the first message (whatever the message is), but then we have to find some area of the message details screen which is always present for any message, and it just seems a tad more likely to result in false passes. Similary I'm making an assumption that auditd is always going to show up on the first page of the Services screen and the details screen will always show that 'loaded...enabled' text. Test Plan: Run the tests and see if they work! See https://openqa.stg.fedoraproject.org/tests/21373 and https://openqa.stg.fedoraproject.org/tests/21371 for my tests. Reviewers: garretraziel Reviewed By: garretraziel Subscribers: tflink Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D874 |