Sorry: the test is good not just if nautilus is shown, but if it's possible to interact with nautilus by doing something, e.g. creating a new folder or switching to a different folder. The goal is to make sure the window isn't frozen.

Hi Michael,

I've attached to this mail a PDF containing a basic test case for g-r-d.
This covers setting up g-r-d, connecting to g-r-d and opening +
interacting with g-c-c.
It is quite basic (so far). It could probably be extended in the future
with the other functionality that g-r-d provides, that is btw currently
(among other things):

• Audio output redirection (user can hear sound from the remote session)
• Audio input redirection (microphone redirection)
• Dynamic resolution (virtual monitors in the headless session can be
  resized during the session on-the-fly by just resizing the window of the
  RDP client)
• Partial multi-monitor support (g-r-d can currently create, resize,
  and destroy virtual monitors (also on-the-fly during the session), but
  currently cannot position them or set display scales (mutter is
  currently missing support for that))
• Full clipboard support (copy pasting text, images, files, or
  folders (containing files) between client and server

These other parts require the client side obviously to also support
these features to be able to make use of them.
But the PDF - so far - only covers the basic login part and interacting
(and thus reproducing the libadwaita-freeze issue).

Pascal

apparently the next problem is going to be that libadwaita applications are broken in remote sessions with some particular version of libadwaita

This was an issue with Wayland explicit sync combined with no physical monitors, and is fixed in GNOME 46 (not yet in a release AFAICS) and the coming GNOME 47.

@catanzaro

so I tried to set it up before we could start working on the test itself, but I am not able to make it.

Prerequisites

• Fedora Workstation VM with RDP port opened
• Shared desktop and RDP login enabled in Gnome Settings
• Connections on the host system that I will use to make the RDP connection

Desktop Sharing

Works as expected, I can set up both shared and view-only connections.

Remote login

I cannot establish any connection
- whatever the SElinux status is (enforcing, permissive, disabled)
- with password set up and not used when connecting it says that "the connection transport layer failed"
- with password set up and used when connection it says "An authentication error aborted the connection"
- with no password set up and not used when connecting it says "the connection transport layer failed"
- with no password set up but using the user's system password it also claims "an authentication error".

It looks like the password set up in the dialogue does not have any influence on the connection at all.

Resolution

In my opinion, the RDP remote login does not currently work, but before I start filing bugs, I would like to know if there is a mistake I am making. Could you give me some more info?

Please go ahead and report a bug.

• with no password set up and not used when connecting it says "the connection transport layer failed"
• with no password set up but using the user's system password it also claims "an authentication error".

It looks like the password set up in the dialogue does not have any influence on the connection at all.

Resolution

In my opinion, the RDP remote login does not currently work, but before I start filing bugs, I would like to know if there is a mistake I am making. Could you give me some more info?

Please go ahead and report a bug.

The issue tracker in GNOME is explicitly for issues in g-r-d, not support questions. (g-r-d works here fine on Arch btw) First of all, please follow the test document step by step (also that in the initial situation g-r-d is deactivated in g-c-c), because otherwise it is hard to follow what you actually did (the "with no password set up" in your response seems to suggest, that you did not follow the order in the document).

Regarding SELinux, that seems more a Fedora specific thing, I can't say much about it, but considering https://bugzilla.redhat.com/show_bug.cgi?id=2271661, I suggest you to set it to permissive for now.

Another thing: Please test with a supported client first. I.e. for MS Windows mstsc, on Linux xfreerdp, or Remmina. This is important to rule out client issues. Only when that succeeds, you can proceed with other clients.
For xfreerdp, and Remmina please note, which options you set. This can help troubleshooting.

For reference, this is what a successful run looks like (used FreeRDP version is here 3.8.0):

The issue tracker in GNOME is explicitly for issues in g-r-d, not support questions. (g-r-d works here fine on Arch btw) First of all, please follow the test document step by step (also that in the initial situation g-r-d is deactivated in g-c-c), because otherwise it is hard to follow what you actually did (the "with no password set up" in your response seems to suggest, that you did not follow the order in the document).

I figured it out already. Indeed, the login and password must be set up first, otherwise the connection gets refused. However, this fact should be immediately recognizable from the remote desktop dialogue that should not be able to let you "not set the password" if it is required.

Another thing: Please test with a supported client first. I.e. for MS Windows mstsc, on Linux xfreerdp, or Remmina. This is important to rule out client issues. Only when that succeeds, you can proceed with other clients.

I am not touching Windows, not even with a three-feet-long stick when there are Linux tools. The request however mentions Connections as a preferred method to connect. FreeRDP is another option to check.

However, this fact should be immediately recognizable from the remote desktop dialogue that should not be able to let you "not set the password" if it is required.

Do you mean the remote desktop panel in g-c-c on the server side here? In any case, would be good to provide the UX feedback at the respective component (t)here.

The request however mentions Connections as a preferred method to connect. FreeRDP is another option to check.

I never mentioned to Michael to use Connections, that was not communicated by me. What client is used shouldn't matter in case of everything runs successfully. However, in case of an error, the reference client needs to be used as a base, that follows the documentation correctly.
Remote Desktop is a field, where the whole experience completely depends on both server and client side. In case of an error, there are many places, where things could go wrong, and to investigate errors properly the reference client (currently xfreerdp, in the future sdl-freerdp) needs to be used. Otherwise, this results in a huge waste of time, just to find out, that the different client did not follow the spec or common behaviour (that is not rare).
A well established client (e.g. Remmina) is okay for most cases too, though not always.

So, you can use Connections as long everything goes fine, but in case of an error you need to use the reference client or if applicable a well established one. That is what I require for a report in g-r-d upstream.

This is a Fedora Workstation test though. We want to test the RDP client we ship, which is Connections. If it doesn't work, test should fail.

This is a Fedora Workstation test though. We want to test the RDP client we ship, which is Connections. If it doesn't work, test should fail.

This is not an answer to what I wrote above, nor does it justify the implication, that I would have wanted a test with a nonstandard client for any case.

The reason of my request for the test was the following: As a free time contributor in g-r-d, I put a lot of work, and especially (my free) time in that project. Over the past years though, there were always backlashes in that project, but mostly induced not by g-r-d itself, like https://gitlab.gnome.org/GNOME/mutter/-/issues/2282, https://gitlab.gnome.org/GNOME/mutter/-/issues/1614, or https://gitlab.gnome.org/GNOME/mutter/-/issues/2473.

Remote Desktop requires huge amount of work to get things (even tiny ones) done. These backlashes here robbed a lot of time investigating those, and prevented me to work on actually improving g-r-d. For 47 we had that situation again. While the issue here was quickly fixed (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3946), this is not always the case.

The reason for my test request here was, that Fedoras QA team tests the remote desktop scenario too, so that RH employees have an incentive to work on those issues too even when the respective regression is tedious. In other words: to lower that regression investigation load from me.

To ensure, that the actual test doesn't itself wastes time on the upstream end in the case of an error, the test needs to be properly done and external factors need to be eliminated or if not possible reduced. This also includes the client situation, the way I described it in https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/333#comment-930146. I won't take care of upstream reports, that violate that, because it works against the actual test and to what the actual test was intended to solve.

OK, let's just not test gnome-remote-desktop then. People who care about it can report bugs when it doesn't work.

It's just not reasonable to expect Fedora QA to test extra RDP clients in addition GNOME Connections, which is the one that we ship and support.

It's just not reasonable to expect Fedora QA to test extra RDP clients in addition GNOME Connections, which is the one that we ship and support.

@catanzaro I think you should get rid of your ideological view and actually face the reality instead. What makes remote desktop stand out is its interoperability with other systems. Systems that are different than the one that is controlled (other distro, Mac, MS Windows, mobile OS (Android, iOS)). And only by enforcing protocol conform behaviour it is possible to do that.

These (different) systems are also the ones, that primarily use (connect to) g-r-d with RDP, because RDP is widely spread and has clients for these different platforms. So if you think handling Connections is the primary objective for g-r-d, you are dead wrong.

Your wishful thinking won't help here and just introduces nonsensical behaviour, which in the end does neither help GNOME, nor Fedora. I think you should approach this more rationally, but without understanding remote desktop in the first place, this is impossible.

@lruzicka what does grdctl --system status say, and what does systemctl status gnome-remote-desktop.service say?

I think it'd be valuable to test first with Remmina during the development of the test first, to make sure it's not a client issue. There is no need to test with Windows.

@pnowack the problem here is that we are looking from different perspectives. You are looking from the perspective of "upstream g-r-d developer". But this test is not primarily being written to serve the needs of upstream g-r-d development, though that would be a helpful byproduct. The Fedora openQA tests are specifically intended to be functional and integration tests for Fedora as a product. The remote desktop client that's part of Fedora Workstation as a product is Connections, so that's what we want to test.

We could consider "g-r-d should work as a server for any arbitrary client" as part of the requirements for Fedora as a product, but that's fairly strenuous to test.

@jadahl we can do that, but be aware it means writing a chunk of the test twice, given how openQA works. First we have to script the client interactions using remmina, then whenever someone says "OK now use Connections instead" we have to redo them with Connections. It's not impossible, just extra work.

@jadahl we can do that, but be aware it means writing a chunk of the test twice, given how openQA works. First we have to script the client interactions using remmina, then whenever someone says "OK now use Connections instead" we have to redo them with Connections. It's not impossible, just extra work.

I was thinking more of a way to determine whether the current issue is a client issue or not, by taking a short cut for testing the test, so to say. Perhaps xfreerdp is easier for this, since it'd "only" involve running a command with a bunch of arguments.

@jadahl

As I said, I was able to set up the host machine so that it allows the remote desktop connection via RDP for the time's being. I could make the status commands part of the test, so that there will be some info ready when troubleshooting is necessary. I can also provide the status results, when I am back at the computer in which I have set this up.

@pnowack

When the host machine is RDP capable and works, I guess it is good if we test with at least two clients, one being Connections, but we also need another one to be able to see, if, in case of problems, the problemls lie within the server part or the connection part. I assume that if Connections are broken, xfreerdp should still be able to connect, providing the server part works.

However, I am not an RDP expert so I do not know which options you would like to support on that connection, currently I am using xfreerdp /u: user /p: password /v: 192.168.124.424. If you want additional options, please let me know.

And also, as @adamwill says, with two different clients, the test will take longer to write.

Anyway, I am going to start on the server side, once it is done, you can provide a review. Thanks.

I now have the server part ready. Will continue with the client path as well.

I have a very basic client test and I have started to play with the parallel running of two VM machines.

So, now I have created:
server test that serves the RDP connection to a desktop, the RDP is set up through the Settings on Workstation.
a freerdp client test that connects to the server
* a Connection client test that connects to the server

I also covered the mechanism to run both test simultaneously in openQA so that one waits for the other one.

Testing in Staging still shows some issues, trying to figure it out.