Xorg server removal plus grd

[M4rtinK]

Very preliminary PR that replaces Tiger VNC with GNOME remote desktop running in RDP mode.

Lets make it work first, then make it look nice. ;-)

At the moment built on top of @jexposit Xorg replacement PR & we will se how to actually land all this eventually.

[pep8speaks]

Hello @M4rtinK! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file pyanaconda/display.py:

Line 135:1: E302 expected 2 blank lines, found 1 Line 157:1: E302 expected 2 blank lines, found 1 Line 356:100: E501 line too long (100 > 99 characters)

• In the file pyanaconda/gnome_remote_destop.py:

Line 33:1: E402 module level import not at top of file

Comment last updated at 2024-06-11 08:58:49 UTC

[M4rtinK]

I just realized that pipewire is not installed. I believe that it'll be a required dependency as well and maybe another service you need to initialize.

I've checked the image that gets generated & it contains pipewire & pipewire-libs as gnome-remote-desktop does have a dependency on pipewire.

But good point about the initialization, that could be the tricky part, as our installation environment is unfortunately quite different & cut down to the usual desktop environment in which pipewire is normally used. :P

[Conan-Kudo]

I just realized that pipewire is not installed. I believe that it'll be a required dependency as well and maybe another service you need to initialize.

I've checked the image that gets generated & it contains pipewire & pipewire-libs as gnome-remote-desktop does have a dependency on pipewire.

But good point about the initialization, that could be the tricky part, as our installation environment is unfortunately quite different & cut down to the usual desktop environment in which pipewire is normally used. :P

You'll need my lorax change for this, since I had the same issue for Weston for similar reasons. https://github.com/weldr/lorax/pull/1364

[jexposit]

Aha, that was why! Thanks Neal. Maybe we should reopen and merge your PR? (https://github.com/weldr/lorax/pull/1364)

[Conan-Kudo]

For the moment, you should cherry-pick this from my PR: https://github.com/rhinstaller/anaconda/pull/5401/commits/ae3889c7db5d01950f514bd1caf5e32639faa82b

[Conan-Kudo]

If the above doesn't work, let me know and I can revise the patch to lorax.

[jexposit]

Hey @M4rtinK,

I tested your branch a bit more and you were missing a couple of things. Here is the diff to make g-r-d work :tada:

I'm not sure if Requires: gnome-keyring is required for --headless, try to remove it, because I don't think we need it.

The main mystery I had to solve was related to the $HOME env var set to /tmp. I pruned it, but there might be a better solution, I'll let you investigate it.

[M4rtinK]

I tested your branch a bit more and you were missing a couple of things. Here is the diff to make g-r-d work 🎉

Nice, thanks! :)

I'm not sure if Requires: gnome-keyring is required for --headless, try to remove it, because I don't think we need it.

Sure, I'll look into that. :)

The main mystery I had to solve was related to the $HOME env var set to /tmp. I pruned it, but there might be a better solution, I'll let you investigate it.

Yep, I will see what can be done about that. We notoriously don't have a regular usable user account in the installation environment, though I'm more and more thinking about if this is not a problem, given how many things seem to expect one to exist these days. :P

As we run everything as root anyway, I'll try what happens if $HOME is set to point to /root. :)

[Conan-Kudo]

I'd turn it around and say maybe Anaconda should run as a dedicated user? We have polkit policies now, so we can also just make it auto-elevate properly, no?

[M4rtinK]

/build-image --boot.iso

[M4rtinK]

I'd turn it around and say maybe Anaconda should run as a dedicated user? We have polkit policies now, so we can also just make it auto-elevate properly, no?

Yeah, even though we have so far managed to work around it somehow, the root-only, cut-down-on-file-level minimal image concept really seems to be getting more problematic by the day. :P

It certainly made much more sense when it was first created in the ~ RHEL 7 timeframe, but seems really rather problematic in the modern day.

It would be good if we could move the image closer to the way modern distros are build, I am just afraid if we can still keep it minimal if we did that & if we actually have the capacity to pull it off. In any case, definitely not something we could tackle in this PR. :P

[github-actions[bot]]

Images built based on commit b56922265f564f8762e0503319364e30a9920416:

• boot.iso: success

Download the images from the bottom of the job status page.

[M4rtinK]

Substantial update for the PR:

• inst.rdp, inst.rdp.username and inst.rdp.password have been added & work
• interactive RDP username and password configuration in text mode is now possible
• VNC related boot options are still in place, but ineffective & just print a warning to the journal
• VNC options have been marked as deprecated in anaconda --help output and in the boot option documentation
• the inst.resolution boot option can be used to set RDP virtual screen resolution

NOTE: VNC deprecation currently only targets RHEL, we have not yet decided how we will proceed with this once we port the Wayland migration patch se to Fedora, but will most likely want to keep RDP support in place, to keep RHEL feature parity.

There are also still some known issues/WiP:

• looks like gnome-kiosk tramples over TTY1 with its stdout/stderr output
• it is not easy to address due to the sophisticated way run-in-new-session.py starts the gnome-kiosk process & help of someone who knows more about those things might be needed
• there are apparently some more TUI overwriting/newline issues (see the screenshot demonstrating password entry), but this seems to happen also on a normal image when entering the VNC password

A boot.iso corresponding to this PR state can be downloaded from here: https://fedorapeople.org/groups/anaconda/wayland/gnome_remote_desktop/grd_mk5_boot.iso

[M4rtinK]

I added another batch of review comments. It is shaping up nicely. Let me know when the PR is in its final state and I'll review and test it again.

Perfect, thanks, will do! :)

[Conan-Kudo]

I would prefer we didn't completely gut the VNC support. I'd like to revive my Weston patch for consideration to be supported in Anaconda boot.iso and being able to plumb all these things through with the existing infrastructure would be nice.

(I can also use the new plumbing for RDP too, since Weston supports both.)

[M4rtinK]

I would prefer we didn't completely gut the VNC support. I'd like to revive my Weston patch for consideration to be supported in Anaconda boot.iso and being able to plumb all these things through with the existing infrastructure would be nice.

(I can also use the new plumbing for RDP too, since Weston supports both.)

I'm actually making the code a bit generic in places (eq. all those rd & remote desktop references) in case we might decide to keep VNC support in place in Fedora. I think it might be less hassle to just introduce the RDP options rather than drop VNC and introduce RDP support at the same time.

But this is not set in stone right now, just an idea.

[Conan-Kudo]

I would prefer we didn't completely gut the VNC support. I'd like to revive my Weston patch for consideration to be supported in Anaconda boot.iso and being able to plumb all these things through with the existing infrastructure would be nice. (I can also use the new plumbing for RDP too, since Weston supports both.)

I'm actually making the code a bit generic in places (eq. all those rd & remote desktop references) in case we might decide to keep VNC support in place in Fedora. I think it might be less hassle to just introduce the RDP options rather than drop VNC and introduce RDP support at the same time.

But this is not set in stone right now, just an idea.

It's a very good one! Let's do it!

[M4rtinK]

/kickstart-test --testtype smoke

[M4rtinK]

/kickstart-test --testtype ui,network,packaging,security,storage,method,raid,users,services,keyboard,mount,repo,selinux,luks,lwm,firewall,i18n,logs,bootloader,driverdisk,ostree

[M4rtinK]

/kickstart-test --testtype ui

[M4rtinK]

/kickstart-test --skip-testtypes knownfailure,manual,skip-on-fedora,gh576,gh595,gh640,gh641,gh680,gh740,gh769,gh774,gh777,gh910,gh890,gh871,rhbz1853668,gh975,gh1023

[M4rtinK]

/kickstart-test --testtype user-multiple

[M4rtinK]

/kickstart-test user-multiple

[rvykydal]

/kickstart-test user-multiple

[M4rtinK]

/kickstart-test user-multiple

[M4rtinK]

/kickstart-test --testtype users

[M4rtinK]

Looks like what we are seeing with the users-multiple test failing is a race condition - many tests use the keyboard command that likely triggers this, yet were unaffected in that run. So lets try again. ;-)

[M4rtinK]

/kickstart-test --skip-testtypes knownfailure,manual,skip-on-fedora,gh576,gh595,gh640,gh641,gh680,gh740,gh769,gh774,gh777,gh910,gh890,gh871,rhbz1853668,gh975,gh1023

[M4rtinK]

/kickstart-test --skip-testtypes knownfailure,manual,skip-on-fedora,gh576,gh595,gh640,gh641,gh680,gh740,gh769,gh774,gh777,gh910,gh890,gh871,rhbz1853668,gh975,gh1023

[M4rtinK]

/kickstart-test --skip-testtypes knownfailure,manual,skip-on-fedora,gh576,gh595,gh640,gh641,gh680,gh740,gh769,gh774,gh777,gh910,gh890,gh871,rhbz1853668,gh975,gh1023