vncserver missing, unable to use latest 1.11.x as non-root

[LucienMP]

Describe the bug
There is no way for a non-root user to start the vnc server in a simple fashion.
vncserver binary is missing, and replaced with systemd infrastructure that assumes install to /usr.

The people using tigervnc are non-root users and do not get access to any of these folders.
The IT group also wont install to /usr rather /opt/usr which none of the scripts anticipate.
I currently recommend people don't use latest ones, and continue with 1.10 or older

To Reproduce
Steps to reproduce the behavior:

1. Download latest tgz
2. Note there is no vncserver
3. download 1.10.0
4. Not there is a vncserver, start binary this way

Expected behavior
Simple, legacy way for non-root users to start the binary

Screenshots
NONE

Server (please complete the following information):

• OS: RHEL7/CentOS7
• VNC server version: tigervnc 1.11.0
• Server downloaded from: tiger vnc releases page
• Server was started using: [e.g. vncserver] <-- I wish! no such legacy command to launch exists

Additional context
N/A

[CendioOssman]

I'm afraid this is functionality we have not reasonable way of supporting. The old way was very unreliable so now we start things the same way as a local login does.

We'd like to support the old use case, but right now we don't see a practical way to do that. Hopefully that can change eventually.

[LucienMP]

How does this address the non-boottime and non-root user use case?
(ie manual command line startup as a non-elevated non-root user)

Was the "vncserver" tool that existed before no address the above?

Also can you explain how this use case was not reliable?

[CendioOssman]

How does this address the non-boottime and non-root user use case?

Non-boottime should still work fine. Simply start the service as needed and don't configure it to start on boot.

As for non-root we don't have a good way of doing that right now. The only suggestion I have right now is setting up sudo.

Also can you explain how this use case was not reliable?

We saw various problems with the desktop environment not starting, or misbehaving. There could be missing window decorations, or a screen saver that didn't work, or other things.

In the end we had to give up trying to patch around issue after issue and change our approach to mimic a local login, since that is what the desktop environments have been tested with and expect. We cannot help users who have problems with the vncserver script and the clearest way of showing that was to stop including it.

[LucienMP]

Non-boottime should still work fine. Simply start the service as needed and don't configure it to start on boot.

Is there a way to start it without installing the systemd service as thats the use case I have seen a large number of people using. They start it directly from their user session multiple times in the same login shell to obtain various sessions for their tasks.

If so can it be documented in the wiki or via a script as I tried starting the binaries manually but it seemed far from simple.

eg. ./vncserver

[CendioOssman]

No, I'm afraid there is not.

[LucienMP]

Could you amend this issue to reflect this use case is now no longer supported somewhere in your documentation please?

I found a lot of people asking, and several on the forum were confused by this change and I couldn't find any clear documentation on the change either.

[jfrkuska]

@CendioOssman is there a bug ticket or technical discussion regarding the problems with actually keeping the non-elevated user stand-alone server? I would like to be to bind to a non-elevated port in the manner mentioned by @LucienMP for remote operating in on a LAN.

[CendioOssman]

Sorry no, I don't think there is any place we gathered the bug reports. We had several issues here, as well as many reports on the mailing lists. They should still be there but might be difficult to dig out.

The technical design was largely taken from ThinLinc, where we (Cendio) had already had to deal with these issues and come up with a way to handle them.

The basic problem though is you want to start things in a new systemd/logind user session scope. If you can find a way to do that as a normal user then things should hopefully work fine.

[hildred]

If I recall correctly systemd broke the assumptions that underpin the vncserver script, specifically it introduced the idea of login sessions and other such nonsense as such the desktop environments taking advantage of these new concepts break when using the vncserver script. The wokraround is to let systemd setup the sessions. This is a systemd issue caused by systemd and does not exist in a universe without systemd. If you are not using systemd the vncserver script works. (I just don't like it. I use xdm to start multiple vnc instances much like systemd without the "unity")

[MarkMielke]

All sessions run within systemd within a systemd system. So, I wouldn't say that vncserver breaks specifically... however you get in to create the session (such as SSH) will actually create a session, and vncserver works fine from within this context. The difficulty is only in creating multiple VNC servers per systemd session. This mostly works still, although it can have some interesting effects. But, it's easily resolved by just opening a second SSH session, so it's not as real a problem as portrayed.

Also, I wouldn't say systemd caused this. Freedesktop chose to integrate with systemd. It's not a bad thing necessarily. But, there is a whole set of use cases that vncserver worked for that are being discarded with the recent changes. We are still using the vncserver script in our environment, although I have heavily modified it so that it is compatible with both the old way and the new way. I'm still not sure what to do with this - as it works for us, but sharing it in conflict with the TigerVNC project is an uncomfortable position. So far I've just deferred addressing this.

[ruixingw]

Am I right to say that TigerVNC has officially dropped the support to run as a non-root (and non-sudoer) user? I have also tried to make a user systemd script but still the program tells me I have to be root. (I was also trying to workaround with setuid, but it was not very successful).

[CendioOssman]

Am I right to say that TigerVNC has officially dropped the support to run as a non-root (and non-sudoer) user?

Pretty much. We'll still support Xvnc with other startup methods, but our vncserver/vncsession does currently require root.

I have also tried to make a user systemd script but still the program tells me I have to be root.

The current approach pretty much requires root as we use PAM to get a new user session. If there is a different method available then we could update things to support that. I'm not aware of any right now though.

[ruixingw]

Am I right to say that TigerVNC has officially dropped the support to run as a non-root (and non-sudoer) user?

Pretty much. We'll still support Xvnc with other startup methods, but our vncserver/vncsession does currently require root.

I have also tried to make a user systemd script but still the program tells me I have to be root.

The current approach pretty much requires root as we use PAM to get a new user session. If there is a different method available then we could update things to support that. I'm not aware of any right now though.

Thanks for the response :)

[imc0]

If I am understanding correctly, the reason why the 'vncserver' script has been retired is that some aspects of GNOME (and other desktops) don't work properly inside a VNC session unless it was started with systemd.

But not every desktop environment relies on systemd, and using the new systemd setup is not an option in corporate environments where users don't have root access - besides, even if you do have root access, not everyone wants to be editing multiple config files to get this to work.

I guess those of us who want the vncserver script (regardless of whether it breaks GNOME) could pull it out of the 1.10.x tarball. But here's a suggestion: put it back in, and make it print out a message that says "your desktop environment may not work properly inside a standalone VNC server - please use the systemd setup instead." If you want it to be "legacy" and unsupported, make that clear in the documentation. But simply removing the script altogether was not friendly and breaks a lot of applications that were still working.