os-autoinst-distri-rocky-mi.../tests/_vncconnect_client_setup_pre.pm

use base "installedtest";
use strict;
use tapnet;
use testapi;
use utils;

sub run {
    my $self = shift;
    boot_to_login_screen(timeout => 300);
    $self->root_console(tty => 3);
    setup_tap_static('172.16.2.117', 'vnc004.test.openqa.fedoraproject.org');
    # install tigervnc (Boxes doesn't do reverse VNC)
    assert_script_run "dnf -y install tigervnc", 180;
    # take down the firewall
    assert_script_run "systemctl stop firewalld";
    desktop_vt;
}

sub test_flags {
    return {fatal => 1};
}

1;

# vim: set sw=4 et:
Split VNC client steps in two for aarch64 timing issue So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's active. When we're in the tap case, it's usually not going to actually work out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2020-10-30 18:27:45 +00:00			`use base "installedtest";`
			`use strict;`
			`use tapnet;`
			`use testapi;`
			`use utils;`

			`sub run {`
			`my $self = shift;`
			`boot_to_login_screen(timeout => 300);`
enforce standard coding on all Perl files 2023-02-12 22:59:37 +00:00			`$self->root_console(tty => 3);`
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2020-12-15 20:43:53 +00:00			`setup_tap_static('172.16.2.117', 'vnc004.test.openqa.fedoraproject.org');`
Split VNC client steps in two for aarch64 timing issue So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's active. When we're in the tap case, it's usually not going to actually work out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2020-10-30 18:27:45 +00:00			`# install tigervnc (Boxes doesn't do reverse VNC)`
			`assert_script_run "dnf -y install tigervnc", 180;`
			`# take down the firewall`
			`assert_script_run "systemctl stop firewalld";`
			`desktop_vt;`
			`}`

			`sub test_flags {`
enforce standard coding on all Perl files 2023-02-12 22:59:37 +00:00			`return {fatal => 1};`
Split VNC client steps in two for aarch64 timing issue So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's active. When we're in the tap case, it's usually not going to actually work out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2020-10-30 18:27:45 +00:00			`}`

			`1;`

			`# vim: set sw=4 et:`