Xvnc not listening on port 6000

[Luveh Keraph]

I am running TigerVNC 1.12.0 under Slackware64 15.0. After launching it as 

$ vncserver :1

(which launches an XFCE session) I notice that it does not seem to be listening on port 6000 - in the output from netstat -tpln I have

tcp        0      0 0.0.0.0:5901            0.0.0.0:*               LISTEN      17096/Xvnc

tcp6      0      0 :::5901                       :::*                          LISTEN      17096/Xvnc

but nothing on port 6000. Is it possible to get TigerVNC to listen for TCP connections on port 6000?

[Michael Williams]

The team that supports tigerVNC and noVNC client do not support an actual "production" deployment of the client or the server. So It's not clear of what use, either the noVNC client  the tiger VNC client, nor the tigerVNCserver really is.

--
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/a086c2b1-0ec0-45d1-b4b5-97b401ec5b86n%40googlegroups.com.

[Michael D. Setzer II]

vncserver :100

Port starts at base of 5900 so would need to use 100.
vncserver :1 is for port 5901


On 22 Oct 2022 at 21:23, Michael Williams wrote:

From: Michael Williams <michael.gle...@totalvu.tv>
Date sent: Sat, 22 Oct 2022 21:23:42 -0700
Subject: Re: [tigervnc-users] Xvnc not listening on port 6000
To: Luveh Keraph <1.4...@gmail.com>
Copies to: "TigerVNC User Discussion/Support" <tigervn...@googlegroups.com>

>
> The team that supports tigerVNC and noVNC client do not support an actual

> "production" deploymentof the client or the server. So It's not clear of what

> https://groups.google.com/d/msgid/tigervnc-users/CAPJOi9C%3DiJxnEpKf2T
> xSD1pfW%3D302pqQTs%3DqrZK37-MdLZ-R5A%40mail.gmail.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/
+------------------------------------------------------------+

[Luveh Keraph]

My understanding is that listening on port 6000 is what is needed in order for the xhost operation to do the right thing. Xorg does that; TigerVNC does not, at least by default. If this cannot be somehow enabled when launching the Xvnc then it would seem to be a regression - an online search reveals that TigerVNC dealt with this issue in previous versions.

You received this message because you are subscribed to a topic in the Google Groups "TigerVNC User Discussion/Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tigervnc-users/VRhSEYSj_ao/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tigervnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/6354D077.23450.1182D1EA%40mikes.guam.net.

[DRC]

I think the OP is referring to listening for X11 connections on Port 6000, not RFB connections. (So the comment below about using Display :100 is incorrect.) With Xvnc, I think you can pass ‘-listen tcp’ to accomplish that, but note that it will listen on Port 6001 if it is using Display :1, not port 6000. Then you could use xhost to grant access to the display, and it would be accessible using {host}:1 from a remote machine.

This isn’t a “regression.” Listening on TCP ports for X11 connections is a security risk, so every Linux distribution of which I’m aware disables that capability in the root X server by default, and recent releases of popular Xvnc implementations have followed suit. If you need to access the X server from a remote computer, SSH tunneling is the modern, secure way of accomplishing that. But you should be able to reenable listening for X11 connections using TCP by passing an argument to Xvnc, if you are on a secure network and understand the security ramifications of opening up that port.

On Oct 23, 2022, at 5:11 AM, Luveh Keraph <1.4...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/CAFy1yb2rL7w-28BWLAPVs9UNveiZuAZq%2BY1qnSyGvhpu5Zysqw%40mail.gmail.com.

[Luveh Keraph]

The vncserver command shipped with TigerVNC does not seem to take any command line options - in particular, -listen tcp. While I understand that doing what I want to do may be a security risk, I still would like to be able to make the decision myself. 

To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/BD7358F2-D96A-450E-9955-57CB54028C12%40virtualgl.org.

[DRC]

I am not a TigerVNC developer these days, but I was one of the project’s founders in 2009. (Red Hat and Cendio AB, the makers of ThinLinc, were the other two, but Red Hat is no longer active AFAIK.) From my point of view, this project is best viewed as an incubator. It feeds directly into hybrid open/closed-source production implementations (ThinLinc and KasmVNC are two I can name off the top of my head) but also indirectly into TurboVNC, which is an open source production implementation that adopts TigerVNC features where it makes sense to do so. (Our server code base derives from TightVNC, as does the LibVNCServer code base, so adopting TigerVNC features usually requires back-porting them from C++ to C and using X.org linked list primitives and such rather than TigerVNC’s base classes. Thus, it is a slow process.)

Developing code is hard, but productizing that code— making it production-ready— is a lot harder. In most cases, productization will exceed the skill sets, desires (it’s not fun), and time constraints of hobbyist developers, so you need a business model in order to pay for it. TigerVNC is primarily developed by a company that sells a product based on it, so their product revenue pays for productization. With that business model, the open source community doesn’t directly see benefits from productization, but productization indirectly pays for the development of the open source code base. TurboVNC, as a counterexample, is a single-developer project, and I pay for productization via funded development and patronage. Thus, the community directly sees benefits from productization, and the product remains fully open source. However, my business model would be difficult to scale beyond a single developer. (It would probably require starting a foundation, a la Mozilla.) It doesn’t support the kind of monetary and human resources necessary to develop at the pace at which TigerVNC has been developed. (Because everything is open, the only way to prevent a fork is to develop features and fixes more quickly, thoroughly, and inexpensively than any other developer could or would, so that means running a really lean operation. Sometimes it means speculatively adding features on a pro bono basis in order to move the project forward and encourage future funded development. Also, I rely on income from VirtualGL and libjpeg-turbo as well, so I can’t develop VNC code full-time.)

Funding open source development is hard. Either you have to be a huge corporation that can subsidize it in the name of R&D, or you have to be able to sell a product based on it (which usually requires proprietary/closed-source value-added features, because otherwise why would someone buy the cow when they can get the milk for free?), or you have fund it through patronage/funded development (which is, at best, an inconsistent and unpredictable funding model, so it’s really hard to plan releases and such.) There is no magic solution that would allow all of us to spend 40 hours a week developing production-ready open source code.

On Oct 22, 2022, at 11:23 PM, Michael Williams <michael.gle...@totalvu.tv> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/CAPJOi9C%3DiJxnEpKf2TxSD1pfW%3D302pqQTs%3DqrZK37-MdLZ-R5A%40mail.gmail.com.

[DRC]

vncserver in recent TigerVNC releases isn’t designed to be invoked directly. You might be able to set up the Xvnc arguments in the tigervnc.users file, but I am no expert.

On Oct 23, 2022, at 10:13 AM, Luveh Keraph <1.4...@gmail.com> wrote:



[Luveh Keraph]

I found the following  bug report, which seems to imply that, in older versions, TigerVNC did indeed listen on port 6000. It then stopped doing so, somebody pointed it out, and apparently the issue was fixed - until it was introduced again, be it accidentally or deliberately.

To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/C14B8F02-6B11-4C6D-945A-903F874B1A54%40virtualgl.org.

[Brian Hinz]

Hmm.  According to that bug report, it’s a build flag.  For el7 our build flags differ from RedHat/CentOS but for el8 neither includes that switch.  Are you using a package provided by Slackware or the “cross-compatible” binaries from our releases?

To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/CAFy1yb0E2KSLXdmNjuy35sTVVRAwt%2B3fhSue%2BCFstsZ%3Dh2SpYA%40mail.gmail.com.

--

Sent from Gmail Mobile

[Luveh Keraph]

The former.

[Brian Hinz]

Try rebuilding the slackware package from src but add the “--enable-listen-tcp” flag to configure when building Xvnc and see if that works.  If so then you’ll have to request slackware to make the same change to their package

[Luveh Keraph]

I had just done so when I saw your message - thanks very much; that was very useful feedback. Indeed, Slackware 15.0 builds TigerVNC without --enable-listen-tcp. After rebuilding with this option, the resulting server launched with vncserver does indeed listen at port 6000, and the xhost mechanism works as expected. One can't help but wonder why this is a build-time option, rather than a built-in capability disabled by default, that can be explicitly enabled when launching the server?

[Pierre Ossman]

On 23/10/2022 18:33, 'DRC' via TigerVNC User Discussion/Support wrote:
> vncserver in recent TigerVNC releases isn’t designed to be invoked directly. You might be able to set up the Xvnc arguments in the tigervnc.users file, but I am no expert.
>

It is indeed controlled through config files. Luveh, you likely want to
modify /etc/tigervnc/vncserver-config-defaults and add "listen=tcp".

Details are in "man vncsession".

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?

[Luveh Keraph]

Thanks - that's very useful information. Where is that documented? The man page gives the locations of the relevant files and a few keywords (and values) that one can use, but not a list of legal keywords and values. It mentions the HOWTO.md file that is part of the source code distribution, but this file also does not give more details about the keywords supported. And similarly in the man page for Xvnc - in particular, the "listen" keyword does not seem to be mentioned anywhere.

[Pierre Ossman]

On 24/10/2022 14:49, Luveh Keraph wrote:
> Thanks - that's very useful information. Where is that documented? The man
> page gives the locations of the relevant files and a few keywords (and
> values) that one can use, but not a list of legal keywords and values. It
> mentions the HOWTO.md file that is part of the source code distribution,
> but this file also does not give more details about the keywords supported.
> And similarly in the man page for Xvnc - in particular, the "listen"
> keyword does not seem to be mentioned anywhere.
>

They are either VNC specific options, which are documented on Xvnc's man
page, or they are general X server options, which are documented on the
Xserver man page.

[Luveh Keraph]

Ok, thanks. 

[Michael Williams]

DRC,

I for one really appreciate this response. I can't imagine how hard it is to get by doing only open source.

We like noVNC because we can use https with the web client (one of our requirements is a web client access to the headless server.)

We don't have to run ssh instead. 

But we are finding some tough limitations too.

One thing that stands out for us is the need for a VNC connection to create a Linux Session, complete with PAM authentication.

Regarding alternatives like TurboVNC or TigerVNC, are either of them production level now?

Again, many thanks for your thoughtful and insightful sharing of the developer experience.

Michael

[DRC]

TurboVNC is managed more like an enterprise product (think RHEL or Ubuntu LTS), whereas TigerVNC and noVNC are managed more like a rolling release (think Fedora or Debian Unstable), so you have to pay for a commercial implementation of them (ThinLinc, Kasm, etc.) in order to have any assurances that the code is production-quality.  Ideally, enterprise O/S vendors like Red Hat and Ubuntu freeze a version of TigerVNC and provide long-term bug fixes for it, but there is a limit to what they can do, given that an upstream "stable" branch of TigerVNC is usually abandoned as soon as the .0 release from that branch drops.  As an example, RHEL 7 is still using TigerVNC 1.8.x, and any time someone posts up on here regarding a bug in that frozen release, the TigerVNC developers shrug and tell them to use a newer release.  The reality is that organizations with large-scale deployments of Linux remote desktop software don't want to upgrade their O/S or their remote desktop software unless they absolutely have to, which is why it makes sense to separate the two.  Thus, I tend to view O/S-supplied implementations of TigerVNC as basic remote desktop functionality for the O/S rather than as production-ready solutions in and of themselves.

All of that is IMHO, to be clear.  The TigerVNC developers may disagree, but the reality is that TigerVNC's release strategy is geared toward new feature releases rather than toward bug-fix releases, which makes it more like a rolling release.  That is evident in the fact that only two TigerVNC bug-fix releases have landed since 2015, and the last one was in 2019.  1.11.x, 1.9.x, 1.8.x, 1.6.x, and 1.5.x never had a bug-fix release, and 1.12.x hasn't seen one yet, despite 1.12.0 being released a year ago.  None of those branches saw any back-ported bug fixes after the .0 release dropped.  With TurboVNC, I try to put out bug-fix releases on more or less a three-month schedule, assuming there are enough unreleased bug fixes to make that worthwhile.  I will also spin extended support releases for prior branches of the code if a paid sponsor requests them, and I will always back-port current bug fixes into at least one prior branch of the code.

I'm not saying any of that in an accusatory manner.  The projects have a very different project management style that is, per below, necessitated by very different funding models.  I don't want to seem like I'm hijacking the TigerVNC Users group to promote my own project.  I just recognize that there are some use cases and deployment strategies that TigerVNC isn't suitable for, and I would rather inform users of the alternatives (including ones that I don't develop) so they can decide for themselves.  ThinLinc and KasmVNC are production-quality releases based on TigerVNC and noVNC, but they aren't free.  TurboVNC is free and production-quality, but since I'm a one-person shop, I can't provide the same support options that a company like Cendio or Kasm can provide.

DRC

To view this discussion on the web visit https://groups.google.com/d/msgid/tigervnc-users/22d15284-114d-4b47-aa14-62c271cf7330n%40googlegroups.com.

[Chen Bill]

vncserver -listen tcp