Lock screen hangs with xrdp set-up to enable a remote session AND a concurrent local session

[apmcgh]

I use Fedora 38, up to date.

I cannot find authoritative documentation on how to set-up Fedora 38 to enable the same user to both log in physically on the workstation (wayland/gnome) and remotely (xrdp).

Below is the configuration changes that enable me to mostly achieve my goals, however trying to unlock a screen lock on the remote session hangs almost always for ever, although it randomly un-hung twice (I have not been able to identify the trigger).

With the configuration below, I can disconnect and reconnect at will so long as I do not lock the screen. The same behaviour can be observed with a variety of clients (Samsung smart TV, Android, Remmina on host system).

Install:

dnf install -y xrdp xorgxrdp
systemctl enable xrdp
systemctl start xrdp

gvim /usr/libexec/xrdp/startwm.sh (modified parts, no deletion):

pre_start()
{
  if [ -r /etc/profile ]; then
    . /etc/profile
  fi
  if [ -r ~/.bash_profile ]; then
    . ~/.bash_profile
  else
    if [ -r ~/.bash_login ]; then
      . ~/.bash_login
    else
      if [ -r ~/.profile ]; then
        . ~/.profile
      fi
    fi
  fi

  export SESSION_ID_FILE="/tmp/xrdp_session_${XRDP_SESSION}"
  if [ -f "$SESSION_ID_FILE" ]; then
    export DBUS_SESSION_BUS_ADDRESS=$(cat "$SESSION_ID_FILE")
    f=${DBUS_SESSION_BUS_ADDRESS/,*/}
    if [ ! -f ${f/*=/} ]; then
      unset DBUS_SESSION_BUS_ADDRESS
    fi
  else
    unset DBUS_SESSION_BUS_ADDRESS
  fi
  export XDG_RUNTIME_DIR="/run/user/${UID}/xrdp_session_${XRDP_SESSION}"
  mkdir -p $XDG_RUNTIME_DIR

  return 0
}


post_start()
{
  if [ -r ~/.bash_logout ]; then
    . ~/.bash_logout
  fi
  rm $SESSION_ID_FILE
  return 0
}

gvim /usr/libexec/xrdp/reconnectwm.sh:

#!/usr/bin/sh

# Write procedures here you want to execute on reconnect
if [ -r /etc/profile ]; then
  . /etc/profile
fi
if [ -r ~/.bash_profile ]; then
  . ~/.bash_profile
else
  if [ -r ~/.bash_login ]; then
    . ~/.bash_login
  else
    if [ -r ~/.profile ]; then
      . ~/.profile
    fi
  fi
fi

export SESSION_ID_FILE="/tmp/xrdp_session_${XRDP_SESSION}"
export DBUS_SESSION_BUS_ADDRESS=$(cat "$SESSION_ID_FILE")
export XDG_RUNTIME_DIR="/run/user/${UID}/xrdp_session_${XRDP_SESSION}"

(
  ls -al /run/user/
  ls -al /run/user/*/bus
  set 2>&1 
) >/tmp/xrdp.reconnectwm.log

gvim /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh:

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
        eval `dbus-launch --sh-syntax --exit-with-session`
        echo $DBUS_SESSION_BUS_ADDRESS > "$SESSION_ID_FILE"
fi

I also have nomachine installed, causing issues with smartcard access, changing the following solves these issues.
gvim /etc/polkit-1/localauthority/55-org.nomachine.d/10-org.nomachine.allow.pcsc-lite.pkla:

ResultAny=yes
ResultInactive=yes

I also played with this. Choosing password-auth or gdm-password seems to have no noticeable impact.
gvim /etc/pam.d/xrdp.sesman:

#%PAM-1.0
# Generic Fedora config
#auth       include      password-auth
#account    include      password-auth
#password   include      password-auth
#session    include      password-auth

# Gnome specific Fedora config
auth       include      gdm-password
account    include      gdm-password
password   include      gdm-password
session    include      gdm-password

When changing the above or to exit any locked xrdp sessions, do:

systemctl daemon-reload
systemctl restart xrdp

Reproducing the problem:

1. log on via rdp
2. lock the rdp screen
3. unlock the rdp session (input the password)

Problem:

• The (hidden by bullets) password is now greyed out in the password entry screen, hanging there for hours or more, until sometimes, it unexpectedly unlocks for no apparent reason or until the xrdp service is restarted (killing the xrdp session).
• Disconnecting and reconnecting the client brings back the same "hung" screen.
• The "hung" screen can be resized dynamically.

Ideal outcome: the unlock screen works without any undue delay.

Any help to achieve this appreciated.

[matt335672]

@apmcgh - the short answer is it isn't supported on systemd. This is in the FAQ

Longer answer; you can try running a separate systemd --user instance as a separate service under the existing one. Have a look at #2491 and also https://github.com/matt335672/nest-systemd-user. This may work well enough for you.

All of these workarounds suffer from the same problem; this isn't a supported use-case for systemd and so anything you get working can break at the next update. If you really have to use the same user on the console and remotely you can't use a systemd-based distro.

[matt335672]

Give it a go and see if it works for you.

Fedora uses pipewire, so you'll need to build the pipewire module which isn't packaged yet:-

https://github.com/neutrinolabs/pipewire-module-xrdp

I suspect you won't need to mask anything when you've done that.

[apmcgh]

After some finger trouble, it appears to be working as expected:
Lockscreen/unlock works.
Disconnect/reconnect client works.
Thank you.

I have not tried pipewire. I'll pass compiling for now.

One small niggling problem: the interface defaults to a US keyboard, how can I make it use the client's system default?

[matt335672]

I'm not really up to helping with the keyboard I'm afraid. At least not yet; learning about those code paths is on the todo list for me. xrdp isn't a big code base, but it's got lots of wrinkles.

The keyboard should be selected OK on an initial connect - it's the reconnects that don't currently seem to work well. There are some options in xrdp.ini you can use to override the default keyboard settings. It's a bit of a sticking plaster, but works well for many.

[apmcgh]

Fair enough.
What I don't understand is why the keyboard is an issue at all in the first place.
Shouldn't it be entirely managed and controlled by the client?
I have different clients with different keyboards - how can this be managed by the server?
Or is it a profound lack of understanding on my part?

Again, thank you, you solved the key problem I was trying to solve.

[matt335672]

The way it's supposed to work (as I understand it) is that when the connection is set up, information on the client keyboard is normally sent to the server.

I've just run up a connection to a devel build of xrdp from a UK-English Windows 10 VM. From [MSFT-DIL] you can see that a United Kingdom layout has an identifier of 0x809.

Within xrdp.log, I've got the following messages:-

2023-10-13T09:55:53.906+0100] [INFO ] [xrdp_load_keyboard_layout(xrdp_sec.c:378)] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000809]
. . .
[2023-10-13T09:55:58.255+0100] [INFO ] [km_load_file(lang.c:290)] Loading keymap file /etc/xrdp/km-00000809.ini
[2023-10-13T09:55:58.400+0100] [WARN ] [get_keymaps(lang.c:269)] local keymap file for 0x00000809 found and doesn't match built in keymap, using local keymap file

which shows the keyboard map file for the UK has been loaded into xrdp.

The keyboard map file maps the key scancodes send over the RDP link (Windows scancodes] into X11 keysyms and characters. This information is used to generate X11 keyboard events.

That's the general design. There are clearly a few issues with it though and that's what I don't understand at the moment. Also, RDP provides a PDU for direct input of Unicode and currently I can't see a way to map that onto X11.

I hope that's a bit useful.