Configuring the TigerVNC-Server on Fedora 21

For some reason, I had a hell of a time finding good documentation regarding this simple subject matter, so here you go:

Installing tigervnc-server

If you want merely to view VNC sessions on another system, install the tigervnc package.

If you want to run a VNC server on your system so that you can connect to it from other systems, you may choose to install only the tigervnc-server-minimal package or both it and the tigervnc-server package, which depends and builds on the minimal package.  The former package contains these files:

$ rpm -q --filesbypkg tigervnc-server-minimal
tigervnc-server-minimal   /usr/bin/Xvnc
tigervnc-server-minimal   /usr/bin/vncconfig
tigervnc-server-minimal   /usr/bin/vncpasswd
tigervnc-server-minimal   /usr/share/man/man1/Xvnc.1.gz
tigervnc-server-minimal   /usr/share/man/man1/vncconfig.1.gz
tigervnc-server-minimal   /usr/share/man/man1/vncpasswd.1.gz

The latter adds:

$ rpm -q --filesbypkg tigervnc-server
tigervnc-server           /etc/sysconfig/vncservers
tigervnc-server           /usr/bin/vncserver
tigervnc-server           /usr/bin/x0vncserver
tigervnc-server           /usr/lib/systemd/system/vncserver@.service
tigervnc-server           /usr/share/man/man1/vncserver.1.gz
tigervnc-server           /usr/share/man/man1/x0vncserver.1.gz

If you’re reading this guide, you will definitely want to install the tigervnc-server package.  Here’s a quick breakdown of the contents:

  • tigervnc-server-minimal
    • The Xvnc file provided in the tigervnc-server-minimal package is the actual server software.
    • The vncconfig file is a helper aqpplication for Xvnc which is used to configure and control a running instance of Xvnc.
    • The vncpasswd file allows the user to create a password file (in $HOME/.vnc/passwd by default) which can then be used by Xvnc to authenticate users based on the password file provided.
  • tigervnc-server
    • The vncservers file simply points to the new vncserver@.service file used by systemd.
    • The vncserver@.service file is a template systemd service unit file which can be quickly modified by the user and placed in the /etc/systemd/system/ directory to cause the vncserver application to start automatically when the system enters the multi-user.target.
      • This will start a separate desktop to which one might connect using a VNC client – to learn how to share your current desktop instance (the one you use at your physical desk), see the x0vncserver entry below and later the superior tigervnc-server-module solution.
    • The vncserver binary file is a helper application which takes a simplified list of parameters and uses vncconfig and Xvnc to launch an instance of the VNC server more easily and conveniently than requiring the user to manually use vncconfig and Xvnc.
    • The x0vncserver binary is an application which can be used to share the current X session (session 0) by leveraging XDamage to scrape the screen contents of X session 0 at a specified interval and present them via VNC.
      • This had worked for me up until very recently where it may be the case that firegl (the proprietary AMD Catalyst driver) is preventing its functioning – when I remotely connect to a VNC server spawned by x0vncserver, I receive the first screen draw but it is frozen until I manually refresh the screen (though it does respond to interaction between refreshes).  I now use the module described later.

So, once you have installed tigervnc-server, it is simple to set up once you know what you’re doing (which is not readily understood by the available documentation, if you ask me).

Configuring tigervnc-server

If you’d like to start a vncserver instance automatically, you may follow the instructions at the top of the vncserver@.service file (just open it with vim and follow the directions).  Don’t forget to enable it (systemctl enable vncserver@.service) and start it (systemctl start vncserver@.service) as your intentions may require.  If you do want this to happen, I recommend instead employing the tigervnc-server-module I will explain below.

First, ensure that your configuration files for the vncserver binary are in order.  If you’re using GNOME, you should be fine.  However, I use KDE on account of the current AMD Catalyst driver limitations, so I needed to ensure that vncserver starts a KDM/KDE session and not a GDM/GNOME session.  This required me to track down the following configuration file chain:

  1. $HOME/.vnc/xstartup executes /etc/X11/xinit/xinitrc
  2. /etc/X11/xinit/xinitrc executes /etc/X11/xinit/Xclients
  3. /etc/X11/xinit/Xclients references /etc/sysconfig/desktop
  4. If /etc/sysconfig/desktop exists and directs the system to run a particular desktop environment, then it will.  Otherwise, Fedora 21’s Xclients file runs GNOME.  If GNOME is not installed, KDE is attempted, and then LXDE.

I happen to have GNOME installed, so I need to create /etc/sysconfig/desktop and modify its contents to be:

DESKTOP=KDE
DISPLAYMANAGER=KDE

To start up a vncserver instance, simply execute the vncserver binary like so:

vncserver :1 -geometry 1920X1080

You can check the man page for other options, but defining the display (: and a number) and the resolution should suffice for most uses.  Just make sure the resolution lines up with the system you’ll be using to view this desktop.

Once the command succeeds, you can check on the server instances currently in operation with:

vncserver -list

And you can kill them off with syntax such as:

vncserver -kill :1

And that’s about it!  Mega-simple.  However, my guess is that you’ll want a workstation which you can remotely access in the condition in which you left it.  For that, you could use:

x0vncserver

That will share your current desktop at its current resolution, etc., as display 0.  It can be killed with vncserver -kill :0.

But I recommend that you use the tigervnc-server-module, which I explain below, but for those who don’t want to follow us there yet, here’s how to connect to your new server:

Connecting to tigervnc-server on Fedora 21 Workstation

Unless otherwise specified, the vncserver displays pop up on ports 59XX, where each display value fills in the XXs. So, a server instance started with x0vncserver would be shared on port 5900 by default.  A server instance started with vncserver :1 would be on port 5901, and so on.  You could modify your firewalld configuration to include the vnc-server service  and that will open up ports 5900 through 5903 for your use.  You could also manually add the ports as you feel appropriate.

I prefer, however, to simply use SSH port forwarding to connect to the system first over port 22 and then use the sshd server to proxy port 5900 on my client system to locahost:5900 on the server system.  If you need a primer on SSH port forwarding, see my post on that subject.  This way, you don’t have to expose your VNC server to the network directly, and you limit your attack surface.  Plus, you get the added bonus of relying on historically solid SSH encryption and the portability of the SSH protocol rather than TigerVNC encryption extensions.

Configuring tigervnc-server-module

So this is the better way to automatically share your current X session via TigerVNC.  I don’t know why it isn’t well advertised or documented (maybe my Google skills are failing me?) but this package provides:

$ rpm -q --filesbypkg tigervnc-server-module
tigervnc-server-module    /etc/X11/xorg.conf.d/10-libvnc.conf
tigervnc-server-module    /usr/lib64/xorg/modules/extensions/libvnc.so

The 10-libvnc.conf file is a template which can have its comments removed to provide the functionality I am about to explain if your system will work with the defaults (mine would not on account of the AMD Catalyst driver).  I recommend modifying the /etc/X11/xorg.conf file yourself or modifying the 10-libvnc.conf file based on the contents of the xorg.conf file as I explain below.

The libvnc.so module can be loaded by X when your system boots.  I run the AMD Catalyst driver, so my xorg.conf file looks like this:

Section "ServerLayout"
        Identifier     "aticonfig Layout"
        Screen      0  "aticonfig-Screen[0]-0" 0 0
EndSection

Section "Module"
EndSection

Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection

Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:0:1:0"
EndSection

Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        Monitor    "aticonfig-Monitor[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

I need to add a line to the Module section to load the vnc module.  I then need to add options to my Screen section to allow the vnc module to work properly.  If you’re bad at remembering what changes you apply to a file, feel free to copy the current xorg.conf to another location as a backup.  The new xorg.conf file looks like so:

Section "ServerLayout"
        Identifier     "aticonfig Layout"
        Screen      0  "aticonfig-Screen[0]-0" 0 0
EndSection

Section "Module"
        Load        "vnc"
EndSection

Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection

Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:0:1:0"
EndSection

Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        Monitor    "aticonfig-Monitor[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
        Option     "SecurityTypes"  "VncAuth"
        Option     "UserPasswdVerifier" "VncAuth"
        Option     "PasswordFile" "/home/myaccount/.vnc/passwd"
EndSection

The added lines being:

        Load        "vnc"      
        ...
        Option     "SecurityTypes"  "VncAuth"
        Option     "UserPasswdVerifier" "VncAuth"
        Option     "PasswordFile" "/home/myuser/.vnc/passwd"

If this is successful, you should be able to reboot your system (or simply sudo systemctl isolate graphical.target) and note:

$ sudo netstat -luntap | grep 59
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      1355/Xorg.bin

Your X server started up a VNC server instance for you!  And it’s the exact same session that you’re using right now.  Try connecting to it and enjoy!

If this was unsuccessful, you will probably be faced with a dark, cold black screen when you reboot.  Try using Ctrl+Alt+F2 to reach a terminal, log in, and cat /var/log/Xorg.0.log to see what’s going on.  Try searching for “vnc” if you are unsure of where to look, but the log does tell you pretty plainly what has happened, usually.  If it’s a syntax error in your xorg.conf file, try figuring it out, but if you can’t, revert your changes or restore the backup file you may have made as suggested above, and I’d be glad to work on it with you.

Advertisements
This entry was posted in Information Technology and tagged , , , , . Bookmark the permalink.

14 Responses to Configuring the TigerVNC-Server on Fedora 21

  1. John says:

    I appreciate the time you took detailing / documenting this. I’ve struggled, and continue to struggle, with VNC, X, and Display Managers. This article helped me. Recently I’ve been looking for a way to connect to gdm via VNC. I’m stuck thinking that with systemd, the -inetd option being passed to Xvnc (and creating xinetd service files) may not be the most appropriate solution. It seems to me that a systemd unit file of type socket might be a slick way to create the VNC server when needed… Have you ever thought about this?

    • I would not use xinetd; that’s an old super-server daemon initially designed to permit servers lacking the resources to simultaneously operate all of the services they provide the ability to dynamically start and stop services on demand so as to limit the consumption of system resources. Though it also provides some service management capabilities which can be kind of cool (like controlling access to a service so that only one connection at a time can be established), the daemon is rarely used in my experience, and definitely not at home.

      I can’t tell exactly what you’re trying to do, but is the tigervnc-server-module not sufficient for your needs? That’ll start up a VNC server sharing your desktop when your computer boots, and you’d be able to remotely access the initial GDM login screen through it.

      • John says:

        Thanks again! I’m glad that I’m not alone in my hesitation about using xinetd. My initial thoughts were for a headless system, hence my on-demand / socket-based / xinetd theory. I wasn’t aware of x0vncserver or tigervnc-server-module, but I like it…

        I haven’t hacked around with an xorg.conf file in about 10 years, so I’m apprehensive about doing that — I don’t even see one listed on my system (RHEL 7.) I’ll go out on a limb here and try putting the VNC-specific bits into my own file at /etc/X11/xorg.conf.d/90-vnc.conf

        Thanks for your advice!

  2. John says:

    Terribly sorry, after re-reading your post, I realize my 90-vnc.conf is superfluous because the tigervnc-server-module RPM provides a 10-libvnc.conf file. Too bad I have to give up dynamically scaling windows though. I did like being able to resize the VNC session…

  3. Roman says:

    Hi, the xvnc solution described above works for me since decades … but after upgrading to F23 it doesn’t anymore. The VNC server starts and opens a port on 5900, but if i connect the client and enter the password i get Authentication failure. In the server log i see “SVncAuth: opening password file ‘/var/lib/gdm/.vnc/passwd’ failed”.
    The passwd file exists, of course, and gdm has sufficient access rights.
    Any clues?

  4. Roman says:

    [root@blackmamba ~]# ll /var/lib/gdm/.vnc/passwd
    -rw-r–r–. 1 gdm gdm 8 Jan 18 15:12 /var/lib/gdm/.vnc/passwd

    • What user is that passwd file supposed to support? Root? Why is it in that location? Also, the mode on these files should be 600, not 644 as yours is. And why does the gdm user account own it?

  5. Roman says:

    I would like remote control capabilities of display 0, to achieve this i use vnc server module included in Xorg. This is a solution independend from any user profile.
    I think that the vnc module loaded by Xorg runs under control of gdm in F23. The home directory of gdm is /var/lib/gdm. I tried all this with /root/.vnc/passwd and corresponding options in /etc/X11/xorg.conf.d/10-libvnc.conf but got the same failure. Playing with different access rights of passwd file makes no differences.

    • Ah, I see, so actually I believe the VNC module is executed in the root user context, and the root context is what will be used to access your passwd file for the module. What does your relevant 10-libvnc.conf stanza look like? If you’ve specified for the module the passwd file you are using, and you generate a fresh passwd file using the simple command “sudo vncpasswd” (or simply execute “vncpasswd” as root), I’m not sure what could be causing the permission issue.

      Have you ruled out an SELinux issue? Have you checked for AVC denials in your journal or tried disabling SELinux temporarily to test and confirm that the permission issue persists with SELinux disabled?

  6. Roman says:

    [root@blackmamba ~]# cat /etc/X11/xorg.conf.d/10-libvnc.conf
    Section “Module”
    Load “vnc”
    EndSection
    Section “Screen”
    Identifier “Screen0”
    Option “IdleTimeout” “600”
    Option “deferUpdate” “100”
    Option “CompareFB” “on”
    Option “Protocol3.3” “on”
    Option “rfbwait” “5000”
    Option “SecurityTypes” “VncAuth”
    Option “UserPasswdVerifier” “VncAuth”
    # Option “passwordFile” “/root/.vnc/passwd”
    Option “passwordFile” “/var/lib/gdm/.vnc/passwd”
    EndSection

    I run vncpasswd as root and moved passwd file in .vnc/passwd under gdm home directory and set owner to gdm and read access to world. No magic so far. Before i start struggling with this behavior, i did setenforce permissive.
    Thank you for your patience … 😉

  7. Roman says:

    [root@blackmamba ~]# ps al |grep Xorg
    4 42 31331 31329 20 0 223132 22516 poll_s Sl+ tty1 0:00 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3

    While 42 could be the answer on everything, in this case it is the user number of gdm.

  8. Roman says:

    I fiddled about wayland on/off, because in F23 gdm uses wayland natively by default. gdm + wayland, but no Xorg ==> no VNC support for the login screen.
    If i switch off wayland (WaylandEnable=false in /etc/gdm/custom.conf), gdm uses Xorg for the login screen. This Xorg process runs under the gdm user (42) and get valid access to /var/lib/gdm/.vnc/passwd, so i’m able connect vnc to 5900 and enter my password to gain access to the login screen. After logging in, gdm creates a second process, which runs under the current user, i.e. 1000, and opens port 5901 for the vnc server.
    If i try to connect my vnc client to 5901 the same things happens as before, authentication failure … For this reason i gave world read access to /var/lib/gdm/.vnc/passwd, but no success.
    Now we come to the point of change.
    I placed the passwd file in a more public location: /etc/X11/passwd, set owner to root and read access to everyone (600). Voila – it works like a charm! Don’t know why /var/lib/gdm/.vnc isn’t suitable.
    But this scenario isn’t really ergonomic :-/
    First i have to connect to 5900, login to vnc, login to desktop (invisible), and then connect a second vnc session to 5901, login to vnc a second time and get access to the desktop.
    I think this is the only solution for F23 to control the session of the physical desktop.

    • Well good work changing variables until something worked, but my guess is that the location isn’t the issue (unless SELinux is to blame here), but rather the ownership of the passwd file. I’m not sure, though; I may try replicating this failure in a lab machine to learn more about the issue. Thanks for your notes!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s