The 1.12.0 version of TigerVNC which is present in Slackware 15.0, is quite different from earlier versions such as the 1.6.0 version in Slackware 14.2 and even the previous iterations of this software in Slackware-current ( up to 1.11). It has ‘evolved‘ in a way that it has become dependent on systemd, or so the developers claim.
And indeed, the most prominent change is that the old ‘vncserver‘ script has been rewritten and should not be run directly any longer. In previous versions, as a user you could run ‘vncserver :1‘ to start a VNC server on port “5900 + 1” aka TCP Port 5901, and if needed you could kill that VNC server session with ‘vncserver -kill :1‘.
Fast forward to current-day. You are now expected to start the VNC server via the new command ‘vncsession‘ which will look in a couple of places to find out who you are and what desktop session you want to start. No longer will it install a “${HOME}/.vnc/xstartup” script for you to customize, instead it will look first in ‘/usr/share/xsessions‘ for *.desktop files like graphical login managers also do (SDDM, LightDM). Slackware applied a patch here for convenience, so that the names of sessions to look for also include "/etc/X11/xinit/Xsession", "/etc/X11/Xsession", "${HOME}/.vnc/xstartup", "${HOME}/.xinitrc", "/etc/X11/xinit/xinitrc" in that order.
The new TigerVNC expects to be launched from a systemd service and it can no longer be started as a non-root user.
Accepting that as a given (we can argue all we want with these developers but it looks that they are not interested), I looked for a way to make life easy for me and other VNC users on Slackware and other non-systemd distros.
In this article I will describe the solution I came up with. It’s a hack, I don’t think it is the best, but it works for me and only needs a one-time configuration by the root user. Let me know in the comments section how you were affected and dealt with the changes in TigerVNC!
- The new TigerVNC uses a user-to-displayport mapping file, ‘
/etc/tigervnc/vncserver.users‘ with lines that contain “port=user” mappings.
For instance, a line containing “:9=alien” means that a VNC server session which is started for user “alien” will be running at VNC port “:9” which corresponds to TCP port 5909. - If a VNC session can only be started as root, then I will use ‘
sudo‘ to allow regular users to start a ‘/usr/local/sbin/vncsession-start‘ wrapper script. - I have written that wrapper script ‘
/usr/local/sbin/vncsession-start‘ which checks your username via the${SUDO_USER}variable, looks up the VNC display mapping for that useraccount in ‘/etc/tigervnc/vncserver.users‘ and starts the vncsession program with the user and port as parameters.
What needs to be done?
Wrapper script:
The script ‘/usr/local/sbin/vncsession-start‘ for which I took inspiration out of the tigervnc repository looks like this:
#!/bin/bash
USERSFILE=/etc/tigervnc/vncserver.users
if [ ! -f ${USERSFILE} ]; then
echo "Users file ${USERSFILE} missing"
exit 1
fi
VNCUSER=${1:-"$SUDO_USER"}
if [ -z "${VNCUSER}" ]; then
echo "No value given for VNCUSER"
exit 1
fi
DISPLAY=$(grep "^ *:.*=${VNCUSER}" "${USERSFILE}" 2>/dev/null | head -1 | cut -d= -f1 | sed 's/^ *//g')
if [ -z "${DISPLAY}" ]; then
echo "No display configured for user ${VNCUSER} in ${USERSFILE}"
exit 1
fi
exec /usr/sbin/vncsession ${VNCUSER} ${DISPLAY}
Don’t forget to make that script executable:
# chmod +x /usr/local/sbin/vncsession-start
Sudo:
I then create a ‘sudoers‘ rule in the file ‘/etc/sudoers.d/vncsession‘ (the filename does not really matter as long as it’s in that directory and has “0440” permissions) with the following single line of content:
%vnc ALL = (root) NOPASSWD: /usr/local/sbin/vncsession-start
This sudoers rule expects that your VNC users are a member of group ‘vnc‘, so create that group and add your account(s) to it. In this example I add my own account ‘alien‘ to the new group ‘vnc‘:
# groupadd vnc # gpasswd -a alien vnc
In order to have ‘/usr/local/sbin‘ in the $PATH when using ‘sudo‘, you must un-comment the following line in the file ‘/etc/sudoers‘ (remove the “#” at the beginning of the line):
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
TigerVNC:
The VNC user mappings have to be added on separate lines in ‘/etc/tigervnc/vncserver.users‘. Note that each user requires a different port mapping:
:1=kenny :2=bob :9=alien
In order to have a sane out-of-the-box behavior for our VNC users, edit the global defaults file ‘/etc/tigervnc/vncserver-config-defaults‘ which by the way can be overruled per-user by a similarly formatted file named ‘${HOME}/.vnc/config‘ (the user would have to create it):
session=plasma # securitytypes=vncauth,tlsvnc # geometry=2000x1200 # localhost # alwaysshared
The above session type “plasma” is valid because a file ‘/usr/share/xsessions/plasma.desktop‘ exists. The TigerVNC default session type “gnome” does not exist in Slackware.
Tell new VNC users to run ‘vncpasswd‘ before starting their first VNC server session, so that their sessions are at least somewhat protected.
That’s all.
Now, if you want to start a VNC server session, all you need to run as a regular user is:
$ sudo vncsession-start
and then connect to the VNC session with any ‘vncviewer‘ program. Look for my article about NoVNC if you want to give your users a web-based access to their VNC sessions. In that case you can make it mandatory for the VNC session to only bind to localhost address so that VNC sessions can not be accessed un-encrypted over the network. You can enforce this by adding a line only containing “localhost” to ‘/etc/tigervnc/vncserver-config-mandatory‘.
Good to know, it is no longer possible – but there is no longer a need – to kill the VNC server when you are done with it as was required in the past. Logging out from your graphical desktop will terminate your login session and stop the VNC server.
An additional bonus of my ‘vncsession-start‘ script is that root can run it for any user, and this makes it easy for instance to start the users’ VNC sessions in your computer’s ‘/etc/rc.d/rc.local‘ script. You just need to add the following command to start a VNC session for user ‘alien‘ – as long as a port mapping has been configured for ‘alien‘ of course:
/usr/local/sbin/vncsession-start alien
Caveat:
A TigerVNC session can only be started for/by a user if that user is not already running an interactive desktop session. This means that the root user cannot use “vncsession-start alien” to snoop my existing login session, the program will simply refuse to launch.
Thoughts?
Eric
You choose a hard way.
For my needs (and I wanted a quick-fix) I just downloaded 1.10.1 binaries from sf.net and that’s it. Tried to build it, but it went sour (fltk is too new in 15.0)
Your way is not my way, I’d like to go with that which Slackware offers, but thanks for sharing anyway 🙂
Old Slackware packages for fltk and tigervnc can also be downloaded from https://slackware.uk/cumulative/slackware64-current/extra/ or https://taper.alienbase.nl/cumulative/slackware64-current/extra/ by the way. No need for god-knows-what binaries from a shady site like sourceforge…
Thank you Eric for this info. I have been running NoVNC that I implemented following your article, on a Raspberry Pi with Slackware 14.2-current, so it is not affected at the moment, but it will be once I upgrade it to Slackware 15.0.
Karl
Hi Eric!
You don’t specify it but I believe the file /etc/sudoers.d/vncsession must have permissions 0440 for sudo not to break.
As a rule, when in doubt I run ‘visudo -c’ as root, e.g.:
# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/vncsession: bad permissions, should be mode 0440
Cheers!
Ricardo, you are right. I will update the article, and thanks for mentioning that “-c” parameter, that one is new to me.
How is your way of starting tigerVNC working with elogind? E.g. Log out of the remote machine from whatever account you used to start tigervnc. Then reconnect via a tigervnc client and see if that registers a session with ‘loginctl list-sessions’, and/or see if the $XDG_RUNTIME_DIR is created and set. This can be problematic for desktop sessions that use these resources.
The ‘/etc/pam.d/tigervnc’ pam config has the entry to register an elogind session, but it fails to work because starting it at the command line usually means you are in an already registered elogind session. I think this is one of the reasons that only systemd would be supported, since it does init/servicemanager/etc. I suspect it would be able to start the vncsession outside of elogind/systemd session scope, allowing logging into the vncsession to properly register with session management.
You could create a user or group that skipped starting elogind on a conventional pam entry method like ‘ssh’. E.g. Edit ‘/etc/pam/sshd’ using a ‘pam_succeed_if.so’ to return success before pam_elogind is run for an identified user or group. Then that user could start the ‘vncsession’, exit, and log back in with tigervnc to have a proper elogind session. I tried running my root user outside of elogind on one of my machines and that account can start vncsessions that elogind properly registers and manages. I am not recommending root but it but it does work, although inconvenient.
— Another possible alternative for regular users:
Tigervnc also comes with ‘x0vncserver’, which starts a vncserver attached to the local xsession. On a remote machine with a display, a user could ssh into the machine, startx, and start ‘x0vncserver’. Then that same user can also login with a vnc client and use the remote machine. Elogind will de-register the session after exiting ssh so it probably should be left open. If the remote machine were headless, you could try configuring a ‘dummy’ display in ‘/etc/X11/xorg.conf.d/’. To run get X running before attaching ‘x0vncserver’.
The only upside here is that a regular user can run ‘x0vncserver’. That could be used for machines around the house but security would probably be a concern anywhere else with sshing in and starting an X session on some remote machine.
There are just a few things I’ve putzed around with while trying to figure out how systemd dependent tigervnc is. So far everything seems pretty hacky but it can be made to work. The logind/elogind part is annoying but most things generally still work (or use a simpler WM). The starting as root change seems to have bitten a lot of people on the LQ thread as well. I wonder if there are any decent alternatives?
Cheers, and thanks for all your articles 😉
Hi Bob, I mostly see what you are seeing, and finding a way for the user to avoid root to start a VNC session is still a challenge for me.
What does not register a new elogind session, is when the user runs “sudo vncsession-start” while logged on at a terminal.
What does work, even when the user is logged into a terminal, is when root runs “vncsession-start alien”. That does register a second elogind session:
# loginctl list-sessions SESSION UID USER SEAT TTY 13 0 root 23 1000 alien pts/6 24 1000 alien 3 sessions listed.And in my VNC session I see :
What about https://www.linuxquestions.org/questions/slackware-14/elogind-and-vncserver-incompatible-on-current-4175703228/page2.html#post6304675 ?
If you are interested I can re-upload my package.
Regards, Dick
I don’t participate in LinuxQuestions.org anymore after a fall-out with some members of the community there. But if there’s a patch for tigervnc which is interesting or relevant for Slackware, it’s always good to share. I am afraid that anything we do to patch away the systemd stuff will only turn us into Don Quixote if the developers don’t care.
Perhaps I’ll just revert to the pre-systemd tigervnc sources if it keeps annoying me,
This is my package: https://drive.google.com/file/d/1wJmNCGCMfF4OCTrlYnj5_HKa_zteFFbZ/view?usp=sharing
😀
Eric,
Thank-you for your effort on getting vncserver running as a regular user.
I ran into two problems, that I spent several hours sorting out.
I followed your instructions to the letter. It would help less experienced users to add a not to make vncsession-start script executable. I overlooked that. Not a biggie, I should have known.
Second problem, sudo is not configured on a clean install. I know that, however, I have had more problems with visudo than you can shake a stick at. I hate it with a passion, and avoid it. It would have helped me if you added a note on setting up sudo, simply point us to SlackDocs article. https://docs.slackware.com/howtos:misc:enabling_sudo_on_slackware
That worked for me.
Once again, thank-you for your endless help!
That sudo article on the SlackDocs wiki is factually incorrect. A “sudo” group is not needed on Slackware, and my own instructions in the post above were tested on a default un-modified installation of Slackware. I will see to it that that article gets updated or else removed from the Wiki.
Also, I have setup many systems and never encountered an issue with ‘visudo’. You need to run that program as root of course.
Forgetting to make a script executable… well I have my thoughts about that, but let me suffice by telling you that you don’t blindly follow your car navigation instructions either 🙂
A couple of typos in In the text below:
‘/usr/share/xsessions/plasma.desktop‘
and
‘vncpasswd‘
————-
The above session type “plasma” is valid because a file ‘/user/share/xsessions/plasma.desktop‘ exists. The TigerVNC default session type “gnome” does not exist in Slackware.
Tell new VNC users to run ‘vncpassword‘ before starting their first VNC server session, so that their sessions are at least somewhat protected.
Check. And fixed.
Hi Eric.
Please check the link where you mentioned “developers but it looks that they are not interested”,
It is repeated: https://github.com/TigerVNC/tigervnc/issues/1096
Thanks for the article.
Francicso, I don’t know what you are asking? Repeating what?
Sorry Eric.
There was a wrong link in your article. It was fixed. Thanks.
Hmm I did not fix anything.
Thanks Eric, it works ok with xfce&fluxbox or plasma+kde on a fresh slackware 15.0 installation with no adjustments in $HOME/.vnc.
However starting “vncsession myuser :2” from the /etc/rc.d/rc.local works best when xwmconfig sets /etc/X11/xinit/xinitrc to something other than xinitrc.kde.
Is it expected that xwmconfig defines the window manager that will be started through the vncsession ?
-settings made by xwmconfig have precedence over the session’s statements in the files /etc/tigervnc/
the xsession desktop files are also confusing, supposedly they define the list of options on the sddm login screen that can be re-used by the tigervnc ?
-plasma.desktop
-xfce.desktop
-xwmconfig.desktop
Hi Alienbob
Thank you for this and all the other work you do for Slackware.
I’ve missed something in your instructions as i can’t fathom out why I can’t get vncviewer to connect to the server.
To test I’ve got the vncserver running in a slackware 15.0 instance of virtualbox.
When calling vncviewer It fails to connect with this output –
TigerVNC Viewer 64-bit v1.12.0
Built on: 2021-11-23 19:25
Copyright (C) 1999-2021 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Fri Apr 29 14:27:25 2022
DecodeManager: Detected 8 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
Fri Apr 29 14:27:28 2022
CConn: unable to connect to socket: No route to host (113)
4972 darkstar.example.net: /home/alex $ vncviewer
TigerVNC Viewer 64-bit v1.12.0
Built on: 2021-11-23 19:25
Copyright (C) 1999-2021 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Fri Apr 29 14:47:17 2022
DecodeManager: Detected 8 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
Fri Apr 29 14:47:20 2022
CConn: unable to connect to socket: No route to host (113)
Any thoughts as to how i get this working?
Alex
You would have to share the specifics of your VBox setup before I can try and answer this.
Does the VM connect to your LAN through NAT? Is its IP address and are its TCP ports available on your LAN? Are you trying to access the VNC server from the host that is running VBox guest, or from another computer in the LAN?
What is the exact command you use to try and connect? If you type “vncviewer” then you will get an input box asking for a network address and port… what did you type there? Usually it will be something like “ipadddress:1” where “:1” means: the first available port for the VNC server.
Thanks.
The VirtualBox configuation works out of the box when using KRDC.
Anyway pressed on and tried vncserver on my Sackware box and vncviewer from a friends borrowed Ubuntu laptop. That worked. So all I need now, is a laptop, install Slackware 15.00 on it, with the knowledge that vncserver/vncviewer should work and I’ll be able to access my desktop from anywhere in the house.
I’ll give some further thought as to why the VirtualBox vncserver/vncviewer combination didn’t work. Having said that nobody would want to do that in a real situation.
Thanks again
Alex
A VNC connection between two VirtualBox guests should work. Can you ping? Have a look at your VB network settings.
Hi Eric,
placing the script inside the following file to obtain a running vnc server upon boot for a given user is still an issue for me – only with plasma –
/etc/rc.d/rc.local
placing the following line in the rc.local file works for your kde session ? [yes/no/of-course]
/usr/local/sbin/vncsession-start alien
Thanks,
I understand your question _peter because I have the same issue. I can not get a decent KDE Plasma session, no matter what I try. Other Desktop Environments work without issue.
noted,
thanks Eric.
Hi Eric,
I have been using Tigervnc server since your original post back in 2019, and I find it very useful. There is just one thing that bothers me that I could not figure out: how do I make ~/.bashrc to be sourced when I start an xterm? I am using XFCE in the vnc session.
Karl
Make sure you run “xterm -ls” instead of just “xterm”.
Caution, the latest tigervnc upgrade overrides your /etc/tigervnc/vncserver.users and /etc/tigervnc/vncserver-config-defaults files WITHOUT warning, resetting them to default, so your vnc server will not function as intended.