TigerVNC + XRDP on RHEL 7 (this shouldn't be so hard!)
A couple years back I set up an XRDP server on one of our RHEL 6 timeshare hosts for general desktop use by a few Windows users who wanted a RHEL GUI desktop on rare occasions. This was before systemD and I remember it being mildly annoying to set up but once it was put into place we achieved something resembling feature parity with Microsoft Windows wrt RDP capability.
Now that we are chucking our RHEL 6 timeshares I've started looking into the state of XRDP and TigerVNC on RHEL 7 and I am sad. XRDP is luckily heading to EPEL 7 proper (from testing) within a few days it looks like (https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8153), but when I install that and tigervnc-server on my EL7 timeshare nothing but sadness and woe ensues.
The underlying problem is that I can't seem to get tigervnc-server to "just work", so xrdp-sesman can't connect the login session to a tigervnc session.
I've checked the latest guidance in the system administrators guide for TigerVNC and it's all oriented toward the most user-unfriendly implementation only* - having individual systemD unit files for each named user etc etc.
I tried creating a service account 'tigervnc' for the systemD unit file and that didn't get me where I was hoping - here's my unit file for reference:
$cat /etc/systemd/system/vncserver@.service
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l tigervnc -c "/usr/bin/vncserver %i"
PIDFile=/home/tigervnc/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
[Install]
WantedBy=multi-user.target
Which isn't even recognized by systemD as valid
$systemctl start vncserver@.service
Failed to issue method call: Unit name vncserver@.service is not valid.
...despite guidance that the :# portion of the unit file isn't needed**
Is there any chance that someone less dim than I could please get TigerVNC and XRDP playing nicely on RHEL 7 and doc it so that I can regain feature parity with Windows?
Thanks!
*https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-TigerVNC.html
**https://access.redhat.com/discussions/1149233#comment-883903
Responses
Hello
Could you try, as root user:
~]# systemctl start vncserver@:display_number.service
I worked on that chapter and made the comment you linked to. I did test the procedures at the time. All feedback on how the docs can be improved is most welcome. Suggestions to improve the software are best made in bugzilla.
Expert
1004 points
Hi Stephen, thanks very much for the reply!
So I gave your code a shot, both with no display number specified, then iterated over all the possible displays - all to no avail:
186 [2015-10-23 13:48] root@teece /etc/systemd/system:
$systemctl start vncserver@.service
Failed to issue method call: Unit name vncserver@.service is not valid.
187 [2015-10-23 13:48] root@teece /etc/systemd/system:
$for i in {0..18}; do systemctl start vncserver@:$i.service; done
Job for vncserver@:0.service failed. See 'systemctl status vncserver@:0.service' and 'journalctl -xn' for details.
Failed to issue method call: Access denied
Job for vncserver@:2.service failed. See 'systemctl status vncserver@:2.service' and 'journalctl -xn' for details.
Job for vncserver@:3.service failed. See 'systemctl status vncserver@:3.service' and 'journalctl -xn' for details.
Job for vncserver@:4.service failed. See 'systemctl status vncserver@:4.service' and 'journalctl -xn' for details.
Job for vncserver@:5.service failed. See 'systemctl status vncserver@:5.service' and 'journalctl -xn' for details.
Job for vncserver@:6.service failed. See 'systemctl status vncserver@:6.service' and 'journalctl -xn' for details.
Job for vncserver@:7.service failed. See 'systemctl status vncserver@:7.service' and 'journalctl -xn' for details.
Job for vncserver@:8.service failed. See 'systemctl status vncserver@:8.service' and 'journalctl -xn' for details.
Job for vncserver@:9.service failed. See 'systemctl status vncserver@:9.service' and 'journalctl -xn' for details.
Job for vncserver@:10.service failed. See 'systemctl status vncserver@:10.service' and 'journalctl -xn' for details.
Job for vncserver@:11.service failed. See 'systemctl status vncserver@:11.service' and 'journalctl -xn' for details.
Job for vncserver@:12.service failed. See 'systemctl status vncserver@:12.service' and 'journalctl -xn' for details.
Job for vncserver@:13.service failed. See 'systemctl status vncserver@:13.service' and 'journalctl -xn' for details.
Job for vncserver@:14.service failed. See 'systemctl status vncserver@:14.service' and 'journalctl -xn' for details.
Job for vncserver@:15.service failed. See 'systemctl status vncserver@:15.service' and 'journalctl -xn' for details.
Job for vncserver@:16.service failed. See 'systemctl status vncserver@:16.service' and 'journalctl -xn' for details.
Job for vncserver@:17.service failed. See 'systemctl status vncserver@:17.service' and 'journalctl -xn' for details.
Job for vncserver@:18.service failed. See 'systemctl status vncserver@:18.service' and 'journalctl -xn' for details.
I've started looking into this but I think the underlying problem is that TigerVNC as-deployed simply cannot be a useful tool for general access to terminal services via xrdp, because we can't be in the business of maintaining a separate systemd unit file for each of 700+ different users (even if that would work). With the RHEL 6 version of TigerVNC all of the xrdp and tigervnc files could be left bone stock and "just work". I've spent a couple hours today messing with various things but haven't gotten any closer to figuring out how to get TigerVNC to answer when XRDP comes a knocking. Not sure if this is a use-case that you / Red Hat can help with or is interested in helping with, but it's certainly something I can file a support case on and hassle my account rep and SA about.
Thanks again!
Hello
Is it possible you have a password problem? I just tested it and if I omit the step about creating a password for the VNC user then I get an error when I try to start the service. Please check steps 4 and 5 of the procedure as per your link [1].
By all means discuss this with your account representative. In the meantime I pass on your feedback to the software maintainer.
When I was working on the VNC chapter, I also tested vino-server. It was not working properly and I filed this bug:
Bug 1192548 - Cannot create Remote Desktop (RDP) session, no prompt to accept connection
It was recently marked as VERIFIED. GNOME has built-in help for desktop sharing (using vino).
Hi, I am also experiencing an issue with TigerVNC-Server and xRDP. I am able to establish a connection and receive the logon prompt from xRDP. I input proper credentials but it just sits on the logon screen. If i let it sit long enough the connection will just timeout and drop. Also, when I view a netstat I do see a good connection, just cannot authenticate it appears? Any input is appreciated.
Hi,
I had similar issues with EPEL xrdp and tigervnc-server-minimal on RHEL7.3. I originally went down this rabbit hole due to the seeming impossibility nowadays of having gdm/lightdm on a server without a local display and just serve remote users with XDMCP.
Anyway, there were two issues causing problems:
1) The user I was using for testing had a custom session set up, referring to a window manager not available on the host where xrdp was running. This resulted in the connection to the VNC session failing. The client (rdesktop in this case) would get a message "error: problem connecting" [to the VNC server]. On the server side you'd see messages in the xrdp logs like:
Sep 28 12:44:10 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[INFO ] An established connection closed to endpoint: NULL:NULL - socket: 12
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC Error after security negotiation
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC error before sending share flag
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC error before receiving server init
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC error before receiving pixel format
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC error before receiving name length
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[DEBUG] VNC error before receiving name
Sep 28 12:44:11 azog.bioss.ac.uk XRDP[80468]: (80468)(140280593737792)[INFO ] An established connection closed to endpoint: NULL:NULL - socket: 12
2) Once the above was fixed (removed the .Xclients file from the user home dir) the second problem arose - I could log in but GNOME would refuse to start with the oh-so-useful "oops, something went wrong" message. This seemingly occurs because GNOME3 requires hardware acceleration to function. Acceleration is not available within sessions started by xrdp. Replacing GNOME with xfce4 by putting
PREFERRED=/usr/bin/startxfce4
in /etc/sysconfig/desktop allows me to start an RDP session and get a desktop without needing to mess with systemd.
Indeed, the stock configs "just work" for me.
This approach needs more testing as
1) Slight strangeness occurs if a user has more than one xfce session open accessing the same profile (e.g. logged in on their workstation, also using rdp) 2) using /etc/sysconfig/desktop overrides any per-user customisation
However for our usecase it is working "OK" at the moment.
Thanks,
-david
For me at least, it appeared to be down to a timing issue: the Xclient program (usually the Window Manager) was trying to connect to the Display too quickly, basically before Xvnc was ready to start listening. Adding a "sleep 5" in my .Xclients file before the rest was enough to deal with that. There should be a better fix in the Xrdp session manager code though.
EDIT: I decided to put the wait loop into /etc/xrdp/startwm-bash instead, since the problem is specific to Xrdp:
#!/bin/bash -l
TZ=UTC
DEADLINE="5 seconds"
ENDTIME=$(date -d "${DEADLINE}" -Ins)
STARTTIME=$(date -Ins)
echo "Began: $STARTTIME"
while [[ $(date -Ins) < "${ENDTIME}" ]]
do
if ( /usr/bin/xrandr 2>/dev/null )
then
break
fi
sleep 0.1
done
echo "Ended: $(date -Ins)"
. /etc/xrdp/startwm.sh
This still does not work. I have the "supported" tigervnc setup without xrdp and I cannot get Windoes RDClient to connect at all. I got as close as being asked for my password, but it refused my shell password and my vncpassword.
Now, my only grouch with xrdp is that it renders certain colors as "transparent" ans stuff from windows underneath (or background) show through. Than and fonts get all pixelated when the get too small.
XRDP and TigerVNC would not connect for us. It accepted password and then the Mircrsoft Rdp client would exit back to login. We ended up setting color depth to 24-bit and turning off clipboard under resources. We could then attach and see the gnome desktop. We still have problems with random disconnects though and icons render too large. When you look at the properties of those icons you immediately crash out of your session.
Something is very unstable with the whole configuration. Anyone have more details?
This is with the latest RHEL 7.4 as of this posting.
I'm using xrdp-0.9.5 from Fedora EPEL (compiled 12.30.2017) with a somewhat minimal RHEL 7.3 Desktop install, then updated to RHEL 7.4 - so I don't think it has the full 7.4 Graphical set.
I was able to get XRDP working on RHEL 7.4. Yes, the Desktop icons are too big, and plenty of other annoyances, but it is functional, and the "transparent" (firefox menu bar) issues I had experienced have disappeared.
I have to do it as an off-line install /update from xrdp.0.9.0-4
yum remove xrdp
yum install xorgxrdp-0.2.5-1.el7.x86_64.rpm xrdp-0.9.5-1.el7.x86_64.rpm
xrdp-keygen xrdp auto 2048
# This is the missing piece that makes it work!
# https://serverfault.com/questions/51005/how-to-use-xauth-to-run-graphical-application-via-other-user-on-linux
cat <<EOF > /etc/profile.d/xauth.sh
#!/sbin/bash
export XAUTHORITY=~/.Xauthority
EOF
- which creates the /etc/profile.d/xauth.sh file containing the two lines:
export XAUTHORITY=~/.Xauthority
To disable that Color Profile pop-up dialog, modify /usr/share/polkit-1/actions/org.freedesktop.color.policy, change all of the auth_admin to no