TigerVNC 1.10.x minimum Perl, Xorg, and is HP-UX still supported?

[Mark Mielke]

Hi all:

I was reviewing the unix/vncserver script and noted several problems in it, that likely explain some mysterious issues users (including me) have faced in the past. But, before I submit issues and fixes, including some clean up code, can you please answer:

1. Perl... can we assumed Perl 5.x yet? If so, can we assume at least 5.006?
2. Xorg... what is the minimum version supported here? I see a "17" patch, however I see other code that makes me doubt 1.7 still works.
3. HP-UX... is HP-UX still supported, or was that completely removed with commit 31e5aa3ddd282a4b0339d948b9461a1035ba891b?

--

Mark Mielke <mark....@gmail.com>

[Pierre Ossman]

On 20/10/2019 12:39, Mark Mielke wrote:
> Hi all:
>
> I was reviewing the unix/vncserver script and noted several problems in it,
> that likely explain some mysterious issues users (including me) have faced
> in the past. But, before I submit issues and fixes, including some clean up
> code, can you please answer:
>

> 1. Perl... can we assumed Perl 5.x yet? If so, can we assume at least
> 5.006?

Not something we've really considered. We generally look at RHEL 6 for a
baseline. Which Perl does it ship?

> 2. Xorg... what is the minimum version supported here? I see a "17"

> patch, however I see other code that makes me doubt 1.7 still works.

You're probably right. We don't regularly test anything too old. But if
someone reports an issue we try to add the relevant checks.

> 3. HP-UX... is HP-UX still supported, or was that completely removed
> with commit 31e5aa3ddd282a4b0339d948b9461a1035ba891b?
>

Unknown. If it supports standard POSIX stuff then it should work. But if
it requires some special handling then likely not.

Also note that vncserver is in the process of being revamped to handle
modern Linux systems. Please see this PR:

https://github.com/TigerVNC/tigervnc/pull/838

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?

[Mark Mielke]

On Mon, Oct 21, 2019 at 5:06 AM Pierre Ossman <oss...@cendio.com> wrote:

On 20/10/2019 12:39, Mark Mielke wrote:
> I was reviewing the unix/vncserver script and noted several problems in it,
> that likely explain some mysterious issues users (including me) have faced
> in the past. But, before I submit issues and fixes, including some clean up
> code, can you please answer:
>
>     1. Perl... can we assumed Perl 5.x yet? If so, can we assume at least
>     5.006?
Not something we've really considered. We generally look at RHEL 6 for a
baseline. Which Perl does it ship?

RHEL 6 comes with Perl 5.10.1.

RHEL 5 comes with Perl 5.8.8.

Perl 5.000 was released in 1994. Perl 4 is very ancient.

In particular for Xvnc, this means that "use Socket;" can be presumed to work, and should be done up top, and the extra code that tries to use the .ph files should be ripped out as entirely obsolete.

 

>     2. Xorg... what is the minimum version supported here? I see a "17"
>     patch, however I see other code that makes me doubt 1.7 still works.
You're probably right. We don't regularly test anything too old. But if
someone reports an issue we try to add the relevant checks.

For example, one of the problems I see with the current method, which I think explains some of the strange behaviour, is that the .pid file tracked by the "vncserver" script is different from the .pid file tracked by Xvnc. There is at least one scenario where "vncserver" will blindly overwrites the .pid file even if there is already a running Xvnc at which point it loses track of the running service. There is another scenario where Xvnc will fail in some way (either system restart without proper shutdown, or perhaps Xvnc just abruptly fails for some reason?), and the .pid file still contains the old number. Initially the .pid file contains a number that does not match any process. However, there are two cases where it might: 1) If the PID wrap-around occurs for a running system, or 2) If the Xvnc is set to start at boot, there is actually a pretty high chance that it will always be a "lower" number, and this also makes it a high chance it will overlap with some other service started such that a left-over .pid file still appears to point to a process, but the process is something else. Worse, if you use "-kill" on it, it will kill some random process that is not Xvnc!

X/Xvnc starts the pid in /etc/.X<n>-lock, but only as of 1.9, so I wanted to know whether it was safe to rely on this or not. If you support to 1.7, then this would not help. But, I'm wondering which real life systems have 1.7, where it would be expected that TigerVNC 1.10 will work on it today? RHEL 6.10 is using Xorg 1.17. Earlier versions of RHEL 6.x did use older versions of Xorg. RHEL 6.6 used Xorg 1.15.

This ties into your comment below about redesigning vncserver, where I will continue...

 

>     3. HP-UX... is HP-UX still supported, or was that completely removed
>     with commit 31e5aa3ddd282a4b0339d948b9461a1035ba891b?
Unknown. If it supports standard POSIX stuff then it should work. But if
it requires some special handling then likely not.

I'm fairly sure HP-UX support is dead as of that commit, as HP-UX code was removed. Also, HP-UX in general is nearly dead, and unlikely to be used for Xvnc. I think we finally killed our last HP-UX machines a year or two ago, and they never ran Xvnc on them.

The reference to /usr/spool/sockets/X11 is likely a reference to HP-UX, although I'm curious why /usr/spool/sockets and not /var/spool/sockets? I don't have any system still handy to check though. I'm raising this point because this is left-over code that is basically impossible to test, and therefore likely to be broken at this point, and after so many code iterations where it wasn't tested. HP-UX is more like Sys V (R4?) as I recall, and "POSIX" typically refers to some newer capabilities with many people incorrectly believing "Linux" = "POSIX", including capabilities which HP-UX may not implement. Things like "shared libraries" and "threads" were implemented late in HP-UX life. HP-UX 11i might have caught up in some respects, but I'm doubtful that any modern "POSIX" code would run on HP-UX witjout modifications. :-) So, I think the references to /usr/spool/sockets/X11 among other aspects should be ripped out.

 

Also note that vncserver is in the process of being revamped to handle
modern Linux systems. Please see this PR:

https://github.com/TigerVNC/tigervnc/pull/838

Wow, that is a really big change. I'm not sure sure how receptive the user communities will be to this, as they are somewhat invested in crafting their xstartup files. The instructions we provide the users tell them how to set up xstartup for various purposes to tune their environment. I suspect that it will need to be supported at least as backwards-compatible model.

I have a slightly tweaked service file which uses runuser to create a PAM session for the user. This seems to work fine?

The idea of eliminating xstartup and making the Xvnc start up similar to the console seems like a reasonable idea to me. If it had been this way from the start, we wouldn't have needed to come up with custom xstartup in the first place. But, in coming up with these recipes, people have learned to take advantage of this capability, and it's not clear to me right at the moment that any xstartup can be converted into the regular system scripts for startup.

My gut says that "vncserver" needs to basically stay as-is, and a *new* interface should be created that implements the new systemd-integrated model of starting Xvnc. This would allow us to continue to distribute "vncserver" ("us" = whoever... could include distributions like Fedora or RHEL too) to use the legacy interface, but also permit use of the new systemd-ified model. This would give users the ability to cut over from the legacy "vncserver" model to the systemd-ified model by changing their configuration.

But, I have to look at what you have done closer to have a more informed opinion on the matter...

--

Mark Mielke <mark....@gmail.com>

[Pierre Ossman]

On 21/10/2019 12:06, Mark Mielke wrote:
>
> RHEL 6 comes with Perl 5.10.1.
>
> RHEL 5 comes with Perl 5.8.8.
>
> Perl 5.000 was released in 1994. Perl 4 is very ancient.
>
> In particular for Xvnc, this means that "use Socket;" can be presumed to
> work, and should be done up top, and the extra code that tries to use the
> .ph files should be ripped out as entirely obsolete.
>

Sure. Feel free. We don't really have anyone with Perl expertise working
on the project right now, so there are probably lots of improvements
that could be made.

>
> X/Xvnc starts the pid in /etc/.X<n>-lock, but only as of 1.9, so I wanted
> to know whether it was safe to rely on this or not. If you support to 1.7,
> then this would not help. But, I'm wondering which real life systems have
> 1.7, where it would be expected that TigerVNC 1.10 will work on it today?
> RHEL 6.10 is using Xorg 1.17. Earlier versions of RHEL 6.x did use older
> versions of Xorg. RHEL 6.6 used Xorg 1.15.
>

Support for the really old stuff is very much a "best effort" kind of
thing. So don't let it get in your way if you want to improve things.
Just make sure it has a reasonable chance of working on stuff a couple
of years old.

If it breaks something older than that, then we'll deal with it when bug
reports are filed. Chances are no one using such old systems will use a
modern version of TigerVNC anyway.

>> Also note that vncserver is in the process of being revamped to handle
>> modern Linux systems. Please see this PR:
>>
>> https://github.com/TigerVNC/tigervnc/pull/838
>>
>
> Wow, that is a really big change. I'm not sure sure how receptive the user
> communities will be to this, as they are somewhat invested in crafting
> their xstartup files. The instructions we provide the users tell them how
> to set up xstartup for various purposes to tune their environment. I
> suspect that it will need to be supported at least as backwards-compatible
> model.
>

Unfortunately it is impossible for us to support xstartup. There's just
too many cases of us having to say "we know it's broken. tough luck." So
we're switching to a model where we can reasonably aim for things
working for most users.

Note that Xvnc is still fully supported as its own thing. vncserver is
not mandatory so people can do their own session startup however they
please. But it's up to them to deal with things breaking in the desktop
environment in that case.

> I have a slightly tweaked service file which uses runuser to create a PAM
> session for the user. This seems to work fine?
>

runuser should do some of the necessary pieces, as long as it's run as a
service and not by hand in a terminal. So you're probably already
getting many of the improvements from that PR.

[DRC]

On 10/21/19 5:32 AM, Pierre Ossman wrote:

Unfortunately it is impossible for us to support xstartup. There's just too many cases of us having to say "we know it's broken. tough luck." So we're switching to a model where we can reasonably aim for things working for most users.

And yet I manage to support xstartup with the most common WMs, running on all of the currently-supported enterprise Linux distributions/releases, with only one developer (myself.)  It isn't a perfect solution, but giving users what they want is never an exercise in perfection.  At some point, we have to admit that the primary purpose for Xvnc is to enable legacy software, given that X11 is itself a legacy technology at this point.  We're all going to have to rebase on Weston to get to the next level.

In a less philosophical and more pragmatic vein:
Most commercial deployments of my spin on Xvnc (TurboVNC) are starting Xvnc sessions on demand via a web portal or an SSH-based mechanism, and I assume that that is true of ThinLinc as well.  Is that method of starting/stopping sessions still going to be applicable with this new systemd-based vncserver?  Is there any way it could re-use the SSH PAM session?

[Mark Mielke]

On Mon, Oct 21, 2019 at 6:32 AM Pierre Ossman <oss...@cendio.com> wrote:

On 21/10/2019 12:06, Mark Mielke wrote:
>> Also note that vncserver is in the process of being revamped to handle
>> modern Linux systems. Please see this PR:
>> https://github.com/TigerVNC/tigervnc/pull/838
> Wow, that is a really big change. I'm not sure sure how receptive the user
> communities will be to this, as they are somewhat invested in crafting
> their xstartup files. The instructions we provide the users tell them how
> to set up xstartup for various purposes to tune their environment. I
> suspect that it will need to be supported at least as backwards-compatible
> model.
Unfortunately it is impossible for us to support xstartup. There's just
too many cases of us having to say "we know it's broken. tough luck." So
we're switching to a model where we can reasonably aim for things
working for most users. 

Note that Xvnc is still fully supported as its own thing. vncserver is
not mandatory so people can do their own session startup however they
please. But it's up to them to deal with things breaking in the desktop
environment in that case.

Understood, although I may have ideas and concerns about the new model that I will try to share. :-)

Given that this sort of change will break backwards compatibility for users and consequenly many distributions will likely preserve "vncserver" in its current form, particularly including RHEL 7 until 2024, and probably RHEL 8 until much later...

What do you think of the idea of "vncserver" being a legacy interface that you propose removing, separate from your proposal to add a new systemd-inspired interface? This would make a clean separation between old and new, and allow co-existence?

In any case... until "vncserver" is either removed (as obsolete once the new interface is stable) or replaced (in the case you use the existing "vncserver" as the front-end for the new systemd-inspired interface)...

What branch would "vncserver" be removed or replaced in, and would it be acceptable to continue to post changes to "vncserver" against the branch prior to this? For example, I think "1.10-branch" exists now. Would "vncserver" be removed in "master" in the future, but "1.10-branch" would be stable, and you would accept changes against "1.10-branch"? Or can I continue to post changes against "master" until the final branch is created before "vncserver" is removed, at which point changes would need to be against the branched version?

My alternative is to keep a growing set of local patches to vncserver, and not share them.

I'll be happy to evaluate the systemd-inspired interface in the future, and both migrate our users and provide feedback on the evaluation and migration. This would be most effective if the old and new could co-exist and be used optionally side-by-side on a per machine basis.

> I have a slightly tweaked service file which uses runuser to create a PAM
> session for the user. This seems to work fine?
runuser should do some of the necessary pieces, as long as it's run as a
service and not by hand in a terminal. So you're probably already
getting many of the improvements from that PR.

I have the same question about vncserver.service as vncserver above, although this one is more difficult to maintain side-by-side. But, I would like to suggest updates to the existing "vncserver.service" prior to your Pull Request, and I'd like to consider options for deploying these side-by-side as well, such as by using different service names.

In my case I have some 2000+ users who rely on both vncserver.service and /usr/bin/vncserver working the way it does today. It's possible to migrate them to something better, but anything that doesn't allow for optional cut-over will require me to come up with something that achieves this on my own, and I can't imagine I'm the only person in this boat. I imagine the rest of the community is in the same boat, and I'd hate to see us have to fork or stay on some older branch due to a change in direction which cannot be migrated to, and then adopted.

In terms of requirements for the new interface... once I have some time, and can review what you are working on, I'll try to explain some of the user cases for "xstartup" and vncserver.service that exist today that might break with the change.

Thanks!

--

Mark Mielke <mark....@gmail.com>

[Pierre Ossman]

On 21/10/2019 19:55, DRC wrote:
>
> In a less philosophical and more pragmatic vein:
> Most commercial deployments of my spin on Xvnc (TurboVNC) are starting
> Xvnc sessions on demand via a web portal or an SSH-based mechanism, and
> I assume that that is true of ThinLinc as well.  Is that method of
> starting/stopping sessions still going to be applicable with this new
> systemd-based vncserver?  Is there any way it could re-use the SSH PAM
> session?
>

ThinLinc actually starts sessions in the same manner as what is
suggested here. We arrived at that design because of issues reported and
investigations in to what the desktop environments required these days.

And we have our own session startup. That's why we haven't paid much
attention to vncserver and things have gotten this out of date.

[Pierre Ossman]

On 22/10/2019 06:11, Mark Mielke wrote:
>
> What do you think of the idea of "vncserver" being a legacy interface that
> you propose removing, separate from your proposal to add a new
> systemd-inspired interface? This would make a clean separation between old
> and new, and allow co-existence?
>

I'm afraid the situation is beyond that. We have lots of reports of
vncserver failing to start sessions and we do not have the resources to
try and support that. So it needs to go.

> What branch would "vncserver" be removed or replaced in, and would it be
> acceptable to continue to post changes to "vncserver" against the branch
> prior to this? For example, I think "1.10-branch" exists now. Would
> "vncserver" be removed in "master" in the future, but "1.10-branch" would
> be stable, and you would accept changes against "1.10-branch"? Or can I
> continue to post changes against "master" until the final branch is created
> before "vncserver" is removed, at which point changes would need to be
> against the branched version?
>

It would be removed for an upcoming feature release. So given that 1.10
is now branched, 1.11.0 would be the earliest version with this change.

Feel free to post fixes for the current vncserver script on master until
then though. The timeline for getting the new stuff in place is unknown,
and I don't want that to block fixes we can have until then.

We generally try to avoid fixes on branches as we don't have time to
maintain them. Generally we only use them for security issues or other
critical problems.

> I have the same question about vncserver.service as vncserver above,
> although this one is more difficult to maintain side-by-side. But, I would
> like to suggest updates to the existing "vncserver.service" prior to your
> Pull Request, and I'd like to consider options for deploying these
> side-by-side as well, such as by using different service names.
>

You can always tweak the packaging at your end. The names aren't really
fixed in code.

> In my case I have some 2000+ users who rely on both vncserver.service and
> /usr/bin/vncserver working the way it does today. It's possible to migrate
> them to something better, but anything that doesn't allow for optional
> cut-over will require me to come up with something that achieves this on my
> own, and I can't imagine I'm the only person in this boat. I imagine the
> rest of the community is in the same boat, and I'd hate to see us have to
> fork or stay on some older branch due to a change in direction which cannot
> be migrated to, and then adopted.

Unfortunately I don't see it as a good option of us keeping multiple
implementations around (one of which we know has major issues). But
finding other ways to ease migration is definitely interesting. A
migration guide on the wiki would be one thing.

>
> In terms of requirements for the new interface... once I have some time,
> and can review what you are working on, I'll try to explain some of the
> user cases for "xstartup" and vncserver.service that exist today that might
> break with the change.
>

Sound great.

[DRC]

> On Oct 22, 2019, at 2:29 AM, Pierre Ossman <oss...@cendio.com> wrote:

> ThinLinc actually starts sessions in the same manner as what is suggested here. We arrived at that design because of issues reported and investigations in to what the desktop environments required these days.
>
> And we have our own session startup. That's why we haven't paid much attention to vncserver and things have gotten this out of date.

I guess I don’t understand, then, how a service can be used to start sessions on demand on a per-user basis.

[Alan Coopersmith]

On 10/21/19 2:06 AM, Pierre Ossman wrote:
> Also note that vncserver is in the process of being revamped to handle modern
> Linux systems. Please see this PR:
>
> https://github.com/TigerVNC/tigervnc/pull/838

Is this dropping support for non-Linux/non-systemd systems?

--
-Alan Coopersmith- alan.coo...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc

[Pierre Ossman]

On 22/10/2019 21:16, Alan Coopersmith wrote:
> On 10/21/19 2:06 AM, Pierre Ossman wrote:
>> Also note that vncserver is in the process of being revamped to handle
>> modern Linux systems. Please see this PR:
>>
>> https://github.com/TigerVNC/tigervnc/pull/838
>
> Is this dropping support for non-Linux/non-systemd systems?
>

That wasn't the immediate plan at least. I'm trying to get a SysV
service script functional as part of this.

But long term, I don't know. It's the general problem of things lacking
a maintainer tend to rot and get discarded. And we're only developing
and testing on the major Linux systems.

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