Skip to content

Follow-up from "Add a graphical remote login"

The following discussions from !139 (merged) should be addressed:

  • @pnowack started a discussion: (+1 comment)

    Something else that I thought about, but still don't know how in detail we can solve this, is the audio sink part.
    Basically, currently, every sound that is played in the headless session is currently played on the actual remote server (too).
    Solving that part is not required for this MR (I would already be glad, when we get this here in), but I'd like to share my thoughts on this:

    The current audio implementation mirrors the audio played on the server side onto the client side (which btw also means, that if there are no physical audio sink on the server side, no audio is played on the client side too).
    For remote assistance sessions, this would stay that way.

    For headless sessions, I have something in mind, where we add a class (something called grd-audio-sink), that adds an audio sink with PipeWire.
    The priority of that sink is very high, so it is automatically set as default in the headless user session (how and whether we can make the physical audio sinks unavailable is some other task for the future).
    In the headless session, this audio sink will then always be created, regardless of whether audio redirection is enabled or not (for privacy).
    The existing rdp-audio-playback class gets for its _new() function another argument for the sink.
    In headless sessions, this argument is non-NULL, in remote assistance sessions, this argument is NULL.

    When non-NULL, the rdp-audio-playback class won't look for the physical audio sinks on the system, but only create a stream for the passed audio sink.

    I don't know yet how the grd-audio-sink itself would need to be implemented. Likely, this would involve digging into the PipeWire source code (again).

  • @halfline started a discussion: (+17 comments)

    Well, that would be out-of-scope. The user would here just close the remote desktop client/close the remote desktop session and the reconnect with the "new"/other user.

    If we care about a hybrid desktop future where a session can have remote displays, local displays, or both, then the remote session is going to eventually need to outlive the rdp connection and only go away when a user logs out explicitly, not just disconnect. in that future, there's definitely a place for user switching without disconnecting.

    Currently, we use a separate set of credentials (username + password) for the system daemon. But the scope for the future is to eventually directly enter the username + password in the client and then get directly forwarded to the user session (no login screen).

    Might be a good idea to show a login screen even in that case so the user can select their session..maybe with a short timed login like work flow.

    This this not possible with NTLM and PAM, but maybe with Kerberos. See the discussion in !139 (comment 1752190) for more details.

    We could certainly have a pam_gnome_remote_desktop.so (or just add it to pam_gdm.so) that grabs the username and password from the system gnome-remote-desktop and passes it along to the other pam modules in a new gdm-remote-desktop pam service. There's no reason we couldn't get the username and password funneled through.

  • @pnowack started a discussion: (+3 comments)

    @halfline @jadahl There is one concern/potential problem, that I shared with Joan a few days ago regarding the new design (redirecting the client first to the login screen):

    (copy-pasting the message here from Matrix:)

    There is one concern, that I have: And that is before the redirection from the system daemon to the login session happens. When the login session is created, it needs to be created fast, because I guess the system daemon won't display anything until the login session is shown. So, we need to show something (some spinner or status message).

    There are two reasons for that:

    1. It provides feedback to the user. Because when for 10 or more seconds a black screen is shown (although we eventually redirect the client), the user could perceive that as an error, disconnect, reconnect, and eventually end up reporting an issue, because they did not realize that they just had to wait.
    2. If the client does not receive an initial graphics update, it might either disconnect or run into some bug in the (proprietary client), where the client just sends garbage, leading to a disconnect. The situation is unfortunately real: #161 (comment 1777072)

    These days, lots of systems have SSDs, so until the login screen is shown, things should be fast. But we don't necessarily have the situation on systems on HDDs, where loading gnome-shell takes longer (sometimes 30 seconds).
    Or other way to reproduce that: Having multiple VMs on the same drive, running at the same time, where one other VM uses extensively the HDD, while the other one loads gnome-shell.

    This is something, that I have been thinking for some time now. With the previous design it was not really an issue. (I was still thinking about it, because with Kerberos having some "starting session for user XYZ" (due to not using a login screen) might be needed there too (due to same two reasons from above)).
    But since we load now a login session, we actually already have that situation here. Considering the amounts of black-screen issues I see in the xrdp issue tracker, we should display some kind of status indicator here. Whether that status screen is another PW stream, or g-r-d renders that itself shouldn't matter, as long we have some status. Not sure how hard that would be (depends on design).

    Would it be possible to some kind of "dummy shell/dummy gdm", that plainly just exists for such transitions (PW stream to framebuffer with some spinner with status message)?

  • @joan.torres started a discussion: (+2 comments)

    Hi, @jadahl @pnowack @halfline !

    I've updated the other MRs after mutter!3093 (merged) has been merged.

    The last push here allows the handover of an RDP client between two daemon-handovers with daemon-system between them. Now you can have a headless user session, just like the state before @halfline suggestions.

    In this commit is explained my approach.

    An overview: A new RemoteDisplay is registered by GDM -> a new handover process will be started.

    Before moving forward on handovering from user session to login session and reopening an already started session (first would be headless), I would like to know your opinion if this makes sense or if you have some ideas.

    Maybe a different MR could be opened to handle persistent sessions. halfline> but yea just to summarize persistent session halfline> 1. add org.gnome.DisplayManager.RemoteDisplay.ActivateSession signal

    halfline> 2. fix gnome-remote-desktop system daemon to listen for signal and send RedirectClient signal upon getting it

    halfline> 3. fix gdm_manager_handle_open_reauthentication_channel to not error out

    halfline> 4. Fix switch_to_compatible_user_session to emit org.gnome.DisplayManager.RemoteDisplay.ActivateSession instead of calling org.freedesktop.login1.Manager.ActivateSessionOnSeat

    halfline> 5. Make grd handover daemon not call Logout on disconnect

    halfline> oh there is a missing piece...associating the new connection with the old session

    joantolo> I think with the ActivateSession it should inform the new remote_id to the g-r-d system daemon, so it knows which is the remote client that needs to get the Redirection PDU.

    halfline> yea i guess it could just pass it along as an argument

  • @halfline started a discussion: (+4 comments)

    (Creating a new thread just so there's a place to write this down, I don't think this should block the merge request from going in)

    Pascal mentioned a problem with Microsoft Terminal Services Client. It apparently has a bug when using NLA where it resends the original credentials when doing redirection instead of using the one time generated credentials. It can apparently use redirection with RDPTLS instead of NLA only if use redirection server name:i:1 is hand written into the connection config file.

    I think we should try to cope with this bug by:

    1. Using NLA for the initial dispatcher connection
    2. If the original system credentials are received instead of the one time generated credentials, still proceed but let the handover daemon know the connection is not completely secure
    3. have the handover daemon notify the user via a persistent notification bubble, explaining the situation, and allowing them to proceed. If they choose to proceed, the dispatcher daemon should also allow the original system credentials for the redirection to the user session. If they choose not to proceed, the connection should get cut.

    Fixed by: !222 (merged)

  • @joan.torres started a discussion:

    I'm creating a new thread about the RDP port conflict between g-r-d daemons.

    A system daemon might be listening to 3389 port and after it a user daemon might not be able to listen to it. This can happen in the opposite order.

    A solution to fix this is:

    • The system daemon has always a priority to listen to 3389 port.
    • If there is a conflict with the user daemon, the user daemon will stop listening to the 3389 port, and let the system daemon use it.
    • In that case, the user daemon will listen to the next available port and show a notification explaining what happened.

    The notification is enough to explain the disconnection because it will be seen by the user locally present at the screen (the user daemon is oriented to be used as a remote assistance in the presence of a local user).

    The starting of the system daemon is done by a sys admin, so if that makes the user daemon restart, it is responsibility of the sys admin.

    Fixed by: !224 (merged)

  • @pnowack started a discussion: (+2 comments)

    For some reason, when updating gnome-remote-desktop, the settings for the server-cert and the private-keyfile for the system daemon are lost. The server-cert and private-keyfile themselves are not lost, but the gsettings, where their path is stored. Not sure why, but this should not happen.

    Fixed by: !223 (merged)

  • When a user (let's say user A) is already logged in remotely, or logged in locally and that very same user A tries to remotely login again, while there is already a session, then they are after authentication presented with a plain gray screen without feedback. We should somehow handle this better, offering the user to kill the existing session, while hybrid sessions are not integrated yet.

    See also: gdm#900 (closed)

    Fixed by: gdm!233 (merged), and gnome-shell!3134 (merged)

  • The Remote Desktop panel in g-c-c needs to be adjusted to also handle the system daemon settings

    See also: gnome-control-center#2827 (closed)

    Fixed by: gnome-control-center!2182 (merged)

  • grdctl set-credentials should allow the password to be specified through stdin.

Edited by Pascal Nowack