No tigervncserver command in 1.13.1 on ubuntu 20.04

[Σ ω]

Hello Team,

I'm an end user of tigervnc on ubuntu 20.04. Due to the high CPU issue of 1.10.1, I tried to install the 1.13.1 binary from source forge. But after installation, I did not find the perl wrapper 'tigervncserver' or 'vncserver' that I use to launch the vnc server. How can I bring the perl wrapper back?

I appreciate any help you can provide.

Wei

[Pierre Ossman]

On 11/20/23 08:46, Σ ω wrote:
> Hello Team,
>
> I'm an end user of tigervnc on ubuntu 20.04. Due to the high CPU issue

> <https://github.com/TigerVNC/tigervnc/issues/1077> of 1.10.1, I tried to

> install the 1.13.1 binary from source forge. But after installation, I did

> not find the perl wrapper '*tigervncserver*' or '*vncserver*' that I use to

> launch the vnc server. How can I bring the perl wrapper back?
>
> I appreciate any help you can provide.
> Wei
>

I'm afraid the startup of sessions has changed in modern versions of
TigerVNC. Please see this howto to get started:

https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/HOWTO.md

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Michael D. Setzer II]

On 19 Nov 2023 at 23:46, Σ ω wrote:

Date sent: Sun, 19 Nov 2023 23:46:31 -0800 (PST)

From: Σ ω <shengy...@gmail.com>

To: TigerVNC User Discussion/Support <tigervn...@googlegroups.com>

Subject: [tigervnc-users] No tigervncserver command in 1.13.1 on ubuntu 20.04

I'd give up on tigervnc completely, and look at TurboVNC.

For a long time they have been talking about vncserver going away and I've found in a test upgrade to Fedora 39 that it broke things, so finally looked at the TurboVNC.

There are some difference, since it installs in /opt/TurboVNC

After install have to enable and start service.

systemctl status tvncserver.service

· tvncserver.service - LSB: Starts and stops the TurboVNC Server

Uses /etc/sysconfig/tvncserver to cofigure it

add lines like these without # and it will start sessions.

# VNCSERVERS="1:myusername"

# VNCSERVERARGS[1]=""

for VNCSERVERARGS[] I use "-wm xfce -geometry 1600x845"

had tighervnc use xfce with Fedora 38, but after upgrade to 39, it was using gnome even though the xfce was still stated in xstartup file?

The vncvierer is in /opt/TurboVNC/bin so either have to specify it, or put a link in bin directory to have it work.

So rather than trying the systemd setup that tigervnc seems to want to force users with, the TurboVNC seems a better option.

Worth a look at. Been using vnc going back to Redhat 9, and all the Fedora versions up to 39.

Hope that at least gives an option. Tigervnc seems to be change to what we want rather than what works.

> --

> You received this message because you are subscribed to the Google Groups

> "TigerVNC User Discussion/Support" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to tigervnc-user...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/tigervnc-users/9b804de2-9d05-408d-a7eb-

> a0b89a4adf13n%40googlegroups.com .

+------------------------------------------------------------+

 Michael D. Setzer II - Computer Science Instructor (Retired)    

 mailto:mi...@guam.net                           

 mailto:mset...@gmail.com

 Guam - Where America's Day Begins                       

 G4L Disk Imaging Project maintainer

 http://sourceforge.net/projects/g4l/

+------------------------------------------------------------+

[DRC]

On 11/20/23 3:32 AM, 'Michael D. Setzer II' via TigerVNC User Discussion/Support wrote:

I'd give up on tigervnc completely, and look at TurboVNC.

For a long time they have been talking about vncserver going away and I've found in a test upgrade to Fedora 39 that it broke things, so finally looked at the TurboVNC.

There are some difference, since it installs in /opt/TurboVNC

After install have to enable and start service.

systemctl status tvncserver.service

· tvncserver.service - LSB: Starts and stops the TurboVNC Server

Uses /etc/sysconfig/tvncserver to cofigure it

add lines like these without # and it will start sessions.

# VNCSERVERS="1:myusername"

# VNCSERVERARGS[1]=""

for VNCSERVERARGS[] I use "-wm xfce -geometry 1600x845"

had tighervnc use xfce with Fedora 38, but after upgrade to 39, it was using gnome even though the xfce was still stated in xstartup file?

The vncvierer is in /opt/TurboVNC/bin so either have to specify it, or put a link in bin directory to have it work.

So rather than trying the systemd setup that tigervnc seems to want to force users with, the TurboVNC seems a better option.

Worth a look at. Been using vnc going back to Redhat 9, and all the Fedora versions up to 39.

Hope that at least gives an option. Tigervnc seems to be change to what we want rather than what works.

You don't even need to go to that trouble.  TurboVNC 3.0 and later includes a session manager, so you can start, stop, and manage TurboVNC sessions remotely from the TurboVNC Viewer via SSH.  (The session manager is also secure by default, since it tunnels the RFB connection through SSH and uses one-time passwords, also sent through SSH, for authentication.)  But we also still support using the vncserver script or the tvncserver service to manually start/stop TurboVNC sessions.

The TigerVNC developers decided to do things in the manner that is officially sanctioned by systemd and GNOME, which (to the best of my understanding) limits TigerVNC to a single session per user, prevents you from having a simultaneous TigerVNC session and local session, and requires that sessions be started by root and statically assigned a display number.  It also prevents TigerVNC from running on non-systemd platforms, including FreeBSD.  I have instead decided to retain the vncserver/multi-session approach and work around systemd, but that requires me to comprehensively test popular O/S distributions and window managers (https://turbovnc.org/Documentation/Compatibility30) to ensure that they work properly with the TurboVNC Server.  This highlights a basic philosophical difference between TigerVNC and TurboVNC that has existed all along.  TigerVNC is intended to be a system-supplied VNC implementation, so the integration and compatibility issues are at least partly delegated to O/S distributors.  TurboVNC is intended to be a cross-platform/cross-distribution VNC implementation (which is why it is installed under /opt/TurboVNC), so I have to deal with integration and compatibility issues myself.  There is no guarantee that systemd or GNOME won't screw me in the long term, since I am not doing things in the sanctioned way.  To the best of my understanding, there isn't an officially sanctioned way of running multiple simultaneous instances of GNOME or other WMs (KDE?) that are tied to systemd at the hip.  TurboVNC is able to do so by creating a separate D-Bus instance for each TurboVNC session, but that may work more out of luck than by design.  However, Xfce and MATE and other window managers that aren't tied to systemd at the hip should continue to work with vncserver regardless.  I track Fedora and other bleeding-edge distros, so I can hopefully discover and react to WM compatibility issues before they affect enterprise/LTS distros (which are used by most large-scale TurboVNC deployments.)  My philosophy is that it works because I verified that it works, regardless of whether it's supposed to work.  If GNOME or other WMs stop working with the vncserver/multi-session approach, then I may have to adopt TigerVNC's approach for those window managers, but I also intend to keep supporting the vncserver/multi-session approach for all WMs that it continues to work with.

On another note, I am not trying to compete with TigerVNC.  TurboVNC and TigerVNC are different solutions with different strengths.  I just want people to know that TurboVNC exists, is actively maintained, and is a viable alternative for people who prefer the vncserver/multi-session approach or some of the other features that we have and TigerVNC doesn't, including one-time passwords, client-side remote desktop scaling, the TurboVNC Session Manager, user access control lists, direct integration with noVNC (without the need for a Websocket proxy), direct integration with VirtualGL, a built-in SSH client, independent viewer options for each VNC host, etc.