vncserver command not found

[mad2moons]

Hi,

Was quite happyily using TigerVNC server on a fedora 32 box which im using as a test machine.

Just gone to log on to the server from my mac and also tried a windows machine and it was dead.  So i ssh on to the fedora box, typed in 'vncserver' and it says command not found.

Tried grepping the processes to see if it was running already and nothing.  So i thought i would remove it

dnf remove tigervnc-server

and then reboot and reinstall it.  Says it reinstalled ok but when i type vncserver in the terminal it still says command not found.

Any advice would be highly appreciated.

Thanks

[Michael Setzer II]

I just discovered the same thing. Seems they decided in their wisdom to eliminate the vncserver program and force one to go thru a complete systemd setup??

I was able to do a dnf downgrade on tigervnc-server and it restored the working version..

Put a bug report in,  but there solution is to have the vncserver tell you to go thru the systemd process. So, they broke something that was working, and have opted to not fix it in a manner that makes it work.

I've currently added --excludepkgs=tigervnc-server to my dnfup script, so will run the older version.

I've also created a start-vnc script that has the Xvnc command that the current script ends up running.

https://bugzilla.redhat.com/show_bug.cgi?id=1879739 is the bug report

[Michael Setzer II]

tigervnc-server-1.10.1-3.fc32.x86_64 is the version that works. 1.11 is broken without the vncserver

On Thursday, September 17, 2020 at 11:12:51 PM UTC+10 mad2moons wrote:

[mad2moons]

Excellent reply and thank you.  Will go see what i can do with it now.

[Greg]

This is unfortunate. I am able to use a Fedora Core 32 VM at work on the condition that I don't make too many demands on the admins to do configuration and support, particularly for VNC. For years, my teams have been able to use the vncserver command to launch individual servers, which gives us remote access without requiring any system configuration. This has worked for us for many years, but now with the loss of the vncserver command and the requirement to configure the server through systemd, we either have a new thing to figure out or we have to give up on this VNC implementation because it requires system configuration our admins don't want to deal with. Not progress.

[DRC]

TurboVNC will continue to support vncserver.  We're invested in that approach, because the next generation of our software includes an SSH-based remote session manager and noVNC integration, both of which rely upon vncserver.  I asked the TigerVNC devs previously but didn't get a response, so I'll ask again:  given that large-scale VNC portal/session manager environments rely upon the dynamic X display allocation that vncserver provides, how are those environments supposed to integrate with the new systemd-based launcher, which requires static X display allocation (not to mention root access)?  I'm not trying to troll, here.  It's an honest question, and I ask it not as a potential competitor but as someone who is just trying to give users what they want-- the same thing I've been doing since 2004, years before TigerVNC even existed.  I frankly wonder how Cendio intends to work around those issues in their own product (ThinLinc), since my understanding is that ThinLinc also has an SSH-based session manager (but I could be wrong about that.)

At the moment, I don't see how the systemd-based launcher can work with most commercial multi-user on-demand Linux remote desktop environments, which makes it a non-starter for most of my users.  There are certainly some issues with GNOME 3 when launched from vncserver, but I've never personally found those issues to be insurmountable, and most of my users prefer MATE or another non-compositing WM anyhow.  Our server works around several of the GNOME 3 issues automatically, a couple of others can be worked around by setting an environment variable, and the others fall into the category of "annoying but not show-stopping."  But I don't claim to know everything.  I'd genuinely like to have a conversation about this.  Maybe there is some way to solve the problem without the limitations that the current TigerVNC solution imposes.

--
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/25ffff08-c468-4289-96c5-06feafbf5484n%40googlegroups.com.

[Pierre Ossman]

On 30/09/2020 02:06, DRC wrote:
>
> At the moment, I don't see how the systemd-based launcher can work with
> most commercial multi-user on-demand Linux remote desktop environments,
> which makes it a non-starter for most of my users.  There are certainly
> some issues with GNOME 3 when launched from vncserver, but I've never
> personally found those issues to be insurmountable, and most of my users
> prefer MATE or another non-compositing WM anyhow.  Our server works
> around several of the GNOME 3 issues automatically, a couple of others
> can be worked around by setting an environment variable, and the others
> fall into the category of "annoying but not show-stopping."  But I don't
> claim to know everything.  I'd genuinely like to have a conversation
> about this.  Maybe there is some way to solve the problem without the
> limitations that the current TigerVNC solution imposes.
>

It works perfectly fine. You just need a privileged service that can
launch sessions for you. So the fixed user/display mapping is a
limitation caused by the current approach in TigerVNC, so it's not
fundamental. Getting rid of it would likely need something more complex
though and we probably can't piggyback on systemd's service handling
anymore in such a case.

Launching sessions as an unprivileged user is a fundamental limitation
though. Stuff needs a normal session scope or they will misbehave. GNOME
is the prime example of this, but they are a very big player so this
requirement will likely spread more, not less.

In some cases you can re-use the session created by your ssh login. But
in many cases you can not. For one thing you want different life times
on the VNC session and the SSH session.

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

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

[DRC]

On 9/30/20 12:28 AM, Pierre Ossman wrote:

It works perfectly fine. You just need a privileged service that can
launch sessions for you. So the fixed user/display mapping is a
limitation caused by the current approach in TigerVNC, so it's not
fundamental. Getting rid of it would likely need something more
complex though and we probably can't piggyback on systemd's service
handling anymore in such a case.

"It works perfectly fine" doesn't answer the question.  How does it
work?  The typical portal/session manager workflow is to start a new VNC
session on demand, usually through SSH (either invoked remotely by a
standalone VNC viewer or on the web server by the portal code), record
the display number, and provide an interface for the viewer to connect
to that specific host and display number.  There isn't any guarantee
that a user will use only a particular display number or even that a
user will use only one display number.  It's dynamic.  So please explain
how to make it work with the new systemd launcher.

Launching sessions as an unprivileged user is a fundamental limitation
though. Stuff needs a normal session scope or they will misbehave.
GNOME is the prime example of this, but they are a very big player so
this requirement will likely spread more, not less.

Care to discuss specifics?  I'm happy to show you every single issue I
and my users have personally found with GNOME 3 in a VNC environment. 
I'm pretty sure that at least one of those issues (whereby GNOME 3 moves
all applications to the first virtual display if the remote Xinerama
configuration is changed dynamically) is not related to how it was
launched-- it's just a fundamental problem with how GNOME 3 is
designed.  The spurious authentication dialogs, we worked around using a
PKLA rules file.  That leaves a couple of minor annoyances, like the
screen saver timer being independent of the VNC session.  Yeah, it's
messy.  So is life.

To be clear, I'm not saying that the systemd launcher is a bad idea.  I
think it was good to get that technology out there for evaluation, but
you should have retained the vncserver launcher as well, at least until
the new launcher could be implemented without feature regression.

[Pierre Ossman]

On 30/09/2020 21:05, DRC wrote:
>
> "It works perfectly fine" doesn't answer the question.  How does it
> work?  The typical portal/session manager workflow is to start a new VNC
> session on demand, usually through SSH (either invoked remotely by a
> standalone VNC viewer or on the web server by the portal code), record
> the display number, and provide an interface for the viewer to connect
> to that specific host and display number.  There isn't any guarantee
> that a user will use only a particular display number or even that a
> user will use only one display number.  It's dynamic.  So please explain
> how to make it work with the new systemd launcher.
>

Sorry, I misread your earlier mail and thought you talked about the
general concept rather the the specific current implementation of vncserver.

So no, you cannot currently start a vncserver session as a regular user
or on demand (unless there is some creative way of using systemd's
socket activation).

>
> Care to discuss specifics?  I'm happy to show you every single issue I
> and my users have personally found with GNOME 3 in a VNC environment.
> I'm pretty sure that at least one of those issues (whereby GNOME 3 moves
> all applications to the first virtual display if the remote Xinerama
> configuration is changed dynamically) is not related to how it was
> launched-- it's just a fundamental problem with how GNOME 3 is
> designed.  The spurious authentication dialogs, we worked around using a
> PKLA rules file.  That leaves a couple of minor annoyances, like the
> screen saver timer being independent of the VNC session.  Yeah, it's
> messy.  So is life.
>

I don't have a list readily available unfortunately, but one problem
area was the GNOME screen saver which got very upset when it couldn't
find a session number. Might have been more corners of GNOME with the
same requirement.

> To be clear, I'm not saying that the systemd launcher is a bad idea.  I
> think it was good to get that technology out there for evaluation, but
> you should have retained the vncserver launcher as well, at least until
> the new launcher could be implemented without feature regression.
>

I don't think that is possible. The main issue was that the vncserver
script allowed too much foot shooting and the support issue it caused
for us was an immediate concern. So for now any such scripts will have
to be the users' responsibility and not our.

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

[Dan Stromberg]

On Thursday, October 15, 2020 at 6:47:26 AM UTC-7 Pierre Ossman wrote:

Sorry, I misread your earlier mail and thought you talked about the
general concept rather the the specific current implementation of vncserver.

So no, you cannot currently start a vncserver session as a regular user
or on demand

So how is TigerVNC intended to work now?  I'm interested both in the commands I need to issue/not issue, and an overview of the behind-the-scenes sequence.

In the past I would vncserver on the remote host over ssh, set up an ssh tunnel, and vncviewer on the local host to the ssh tunnel.

Does this change mean I can no longer use non-tigervnc clients with a tigervnc server?

Are there security implications to the change?  It seems like we're running at least part of the chain as root now.

Thanks!

[Jim McNamara]

Dan,

I was checking out this about tigervnc:

$ systemtcl --user start service

Notice I put $ instead of #.

So there is a wrapper of /etc/X11 that you put something to the effect of any user can be used and they are essentially root.

The systemd manual warns it is not exactly safe doing this.

So I like your plan to use ssh. It seems as a user risky.

Just so yah know there is a ~/.config/systemd/user directory.

It is from memory where the service goes. I think you may be able to use for instance x0vncserver etc with execstart or whatever. 

It really threw me that you dont start with systemctl as root but I saw someone else use $ in their example. 

I am working on this tonight actually.

We will find out soon enough!

This is just a working theory as to what is going on as it pertains to regular user from systemd.

Later

Roboloki

--
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/b83852a1-bb0e-4358-a0e0-d029172a854bn%40googlegroups.com.

[Pierre Ossman]

On 29/10/2020 20:32, Dan Stromberg wrote:
>
> So how is TigerVNC intended to work now? I'm interested both in the
> commands I need to issue/not issue, and an overview of the
> behind-the-scenes sequence.
>

Please have a look in the service file for the basic steps needed to
start a session:

https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/vncserver%40.service.in

For the technical details you'll have to look at the programs and how
they call each other. It's not something that has been described in any
documentation.

> In the past I would vncserver on the remote host over ssh, set up an ssh
> tunnel, and vncviewer on the local host to the ssh tunnel.
>

I'm afraid that is no longer possible. You can still use Xvnc and your
own startup this way, but it's up to you to set that up. The session
startup maintained by us now requires you to run a service.

> Does this change mean I can no longer use non-tigervnc clients with a
> tigervnc server?
>

Nothing has changed in the protocol so you can still use any VNC client
you like.

> Are there security implications to the change? It seems like we're running
> at least part of the chain as root now.
>

Yes, but they should be minor. We only run as little as possible as
root, which is the PAM stuff to start up a user session. Everything
after that runs as the user with no extra privileges.

Regards
--
Pierre Ossman Software Development

Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/+CendioThinLinc