TigerVNC support for older RHEL platforms and the Bintray RPMs/repo

[Riot N]

Hello,

[This post is mostly directed to Pierre Ossman, but anyone can chime in.]

Background:

At my work, people often have the habit (especially in COVID-19 days) of logging into our CentOS/Red Hat Enterprise Linux 5/6/7 systems remotely and firing up vncserver.

This causes Xvnc to come up and by default listen on port 600X.  Our IT Security people have decided to crack down on open X11 ports so they told us to close them off.

Problem(s):

I looked into it and was shocked to find that older versions of vncserver (the RealVNC versions on RHEL 5) had all the command-line options embedded in the shell script itself.

It didn't look like they would look in any /etc file for config options.  I wanted to add a $cmd .= " -nolisten tcp"; - but to a config file rather than the script directly.

(Changing the script is non-optimal because it's not specified as a RPM config file and so upgrading the RPM could wipe out the shell script and lose our changes.)

Poking around some more, I discovered that the man page for vncserver on CentOS/RHEL 7 says that apparently it will read /etc/tigervnc/vncserver-config-defaults and /etc/tigervnc/vncserver-config-mandatory for options (as well as $HOME/.vnc/config).

But that doesn't help my RHEL 5.11 Server ELS systems (frozen by a long-running flight project in a CM freeze).

I thought, what if I could find TigerVNC for RHEL 5 that is recent enough to support /etc/tigervnc/vncserver-config-{defaults,mandatory}?

My first find was the TigerVNC repos on Bintray.  But there I noticed

(1) The binary versions for RHEL 7 were 1.10.1-4; the versions for RHEL 6 were 1.10.1-7.  But the versions for RHEL 5 were only 1.6.0-1.

     - Is the reason there are no post-1.6.0 RHEL 5 binaries simply due to lack of interest?  Does the 1.6.0 binary version support /etc/tigervnc/vncserver-config-{defaults,mandatory}?

(2) The RHEL 6/7 trees are set up as repos and can be used with "yum", but the RHEL 5 tree is missing the repodata directories & contents for the yum repo.

Bintray TIgerVNC stable el5 RPMs

     - Can the lack of repodata directories and the associated repo contents for the RHEL 5 tree be fixed?

Anyway, I brought down the RHEL 5 1.6.0-1 SRPM and started playing around with it.

I am unable to rebuild it from the SRPM on my RHEL 5.11 Server system due to numerous libtool-related errors.

I can't remember them all but some examples are:

(1) Multiple libtool errors in libdrm unless I used this kludge workaround: echo=echo; ECHO=echo; export echo ECHO

That got me a bit further but then I hit things like

(2) Lots of complaints down in the "building Mesa" stage down in the src sub-tree; one such example (repeated many times elsewhere in the tree) is

src/mesa/drivers/dri/common/Makefile.am:33: Libtool library used but `LIBTOOL' is undefined
src/mesa/drivers/dri/common/Makefile.am:33:   The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
src/mesa/drivers/dri/common/Makefile.am:33:   to `configure.ac' and run `aclocal' and `autoconf' again.
src/mesa/drivers/dri/common/Makefile.am:33:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/mesa/drivers/dri/common/Makefile.am:33:   its definition is in aclocal's search path.

If I set "export LIBTOOL=/usr/bin/libtool" (libtool-1.5.22-7), these get fixed - but it just dies further on down in freetype where it apparently expects an inline (newer) libtool to be used and not the (old) system one.

/usr/bin/libtool --mode=compile gcc44 -pedantic -ansi -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fPIC -I/var/tmp/tigervnc-1.8.0-1.el5-root-root/opt/tigervnc/usr/include -static-libgcc -I/usr/src/redhat/BUILD/tigervnc-1.8.0/xorg/freetype-2.3.11/objs -I./builds/unix -I/usr/src/redhat/BUILD/tigervnc-1.8.0/xorg/freetype-2.3.11/include -c -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fPIC -I/var/tmp/tigervnc-1.8.0-3.el5-root-root/opt/tigervnc/usr/include -fno-strict-aliasing -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>"  -o /usr/src/redhat/BUILD/tigervnc-1.8.0/xorg/freetype-2.3.11/objs/ftsystem.lo builds/unix/ftsystem.c
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'

Along the way I noticed that the source tarball has RPM-building tools (SOURCES & SPECS files) for RHEL 5/6/7 embedded inside of it, but trying them I still wasn't able to get past these libtool issues using newer (1.8.0) sources.

In short, I would like to know what build environment is required to successfully rebuild the 1.6.0 version on RHEL 5 - or build a newer version if 1.6.0 does not support /etc/tigervnc/vncserver-config-defaults and /etc/tigervnc/vncserver-config-mandatory.

Thanks and sorry for the length.

[Pierre Ossman]

On 07/07/2020 11:18, Riot N wrote:
>
> - Is the reason there are no post-1.6.0 RHEL 5 binaries simply due to
> lack of interest? Does the 1.6.0 binary version support

> */etc/tigervnc/vncserver-config-{defaults,mandatory}*?
>

I'm afraid we have to draw the line somewhere, and right now we
generally follow what the distributions themselves support. RHEL 7 is
the oldest version still supported by Red Hat, so it's the oldest
supported by us. Testing and developing for anything older is simply too
much work for us.

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?

[Riot N]

On Tuesday, July 7, 2020 at 2:25:33 AM UTC-7, Pierre Ossman wrote:

On 07/07/2020 11:18, Riot N wrote:
>>
>>       - Is the reason there are no post-1.6.0 RHEL 5 binaries simply due to
>> lack of interest?  Does the 1.6.0 binary version support
>> */etc/tigervnc/vncserver-config-{defaults,mandatory}*?
>
> I'm afraid we have to draw the line somewhere, and right now we
> generally follow what the distributions themselves support. RHEL 7 is
> the oldest version still supported by Red Hat, so it's the oldest
> supported by us. Testing and developing for anything older is simply too
> much work for us.

OK, fair enough, but what about the rest of my question(s) - do you remember anything about your RHEL 5 build environment where you were able to successfully build those 1.6.0 RPMs on it?

[Brian Hinz]

I *might* still have the el5 VMs that were used to build those archived.  I’m leaving to go out of town for rest of the week but if you can ping me early next week (because I will have forgotten by then :)) I’ll look.

-brian

--
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/780c87ad-b936-4c26-b000-a1f93d587a35o%40googlegroups.com.

--

Sent from Gmail Mobile

[Riot N]

On Tuesday, July 7, 2020 at 6:31:42 AM UTC-7, Brian Hinz wrote:

I *might* still have the el5 VMs that were used to build those archived.  I’m leaving to go out of town for rest of the week but if you can ping me early next week (because I will have forgotten by then :)) I’ll look.

Thanks Brian!  I would be really interested in seeing the RHEL 5 setup.

In the meantime I'm using global /etc/profile.d files/aliases to work around the problem:

-bash-3.2$ cat /etc/profile.d/vncserver.sh
alias vncserver='/usr/bin/vncserver -nolisten tcp $*'
-bash-3.2$ cat /etc/profile.d/vncserver.csh
alias vncserver '/usr/bin/vncserver -nolisten tcp \!*'

It's a bit of a kludge to be honest, but as long as the users don't notice the new vncserver alias that has snuck into their environment, it's effective 😉

[Riot N]

On Wednesday, July 8, 2020 at 3:22:50 AM UTC-7, Riot N wrote:

On Tuesday, July 7, 2020 at 6:31:42 AM UTC-7, Brian Hinz wrote:

I *might* still have the el5 VMs that were used to build those archived.  I’m leaving to go out of town for rest of the week but if you can ping me early next week (because I will have forgotten by then :)) I’ll look.

Thanks Brian!  I would be really interested in seeing the RHEL 5 setup.

P.S. I installed the Bintray RPMs for 1.6.0 on a RHEL 5.10 VM.  Unfortunately they are too old to support reading /etc/tigervnc/vncserver-config-defaults and /etc/tigervnc/vncserver-config-mandatory. 😞

So, I'm still interested in seeing if Brian can tell me something about the RHEL 5 environment that successfully built those 1.6.0 RPMs, but it's only useful to me if I can successfully build 1.8.0 (or later) RPMs on RHEL 5 to support the config files.

In the meantime I'll limp along with the aliases kludge.

[Brian Hinz]

I checked last night and I do NOT still have those VMs, sorry.

--

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/c694cb06-0aa5-4ddc-9bfc-fba8d1b3d68bo%40googlegroups.com.

[Mark Mielke]

On Tue, Jul 7, 2020 at 5:25 AM Pierre Ossman <oss...@cendio.com> wrote:

I'm afraid we have to draw the line somewhere, and right now we
generally follow what the distributions themselves support. RHEL 7 is
the oldest version still supported by Red Hat, so it's the oldest
supported by us. Testing and developing for anything older is simply too
much work for us.

RHEL 6 is still supported for normal subscriptions until November, 2020: https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle

However,  Red Hat is responsible for the Red Hat builds of TigerVNC that it comes with. Just because Red Hat still commits to supporting RHEL 6, does not mean that the upstream project needs to as well (and RHEL 5 is not really supported at all unless you pay a lot extra to Red Hat...).

That said... I also have similar needs as the original poster. Luckily, though, I have managed to almost kill RHEL 5. There are only a few machines left, and they do not require TigerVNC to be installed. And, I have used the RPM spec files that Brian has kept up-to-date (with some local customizations) to successfully build for RHEL 6. For RHEL 6, I think I left it on a custom branch of TigerVNC 1.9. It is going through the same process of getting rid of RHEL 6 wherever possible, given that support will drop as of November, 2020.

I also noticed some of the concerns of the original poster related to how arguments are passed, and we locally customize the "vncserver" script to address several of these.

The end conclusion here is that if you want something other than what is provided, you'll have to roll up your sleeves and get your hands dirty. :-) Hopefully with some helpful hints from Pierre or Brian along the way.

 

--

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

[Riot N]

I have to be semi-anonymous on here (because work).  At work let's just say we have long-lived Flight Projects in frozen CM configurations.  It gives our IT Security people fits because they say "You must upgrade to RHEL 5.11 Server with ELS, it's the only (still) supported RHEL 5 OS" and the Flight Project says "We are config frozen on RHEL 5.7, go fly a kite".

My co-worker who is our Ansible guy said "I don't want you touching the vncserver script, it's not labeled as an RPM config file so it could get overwritten".  When we discovered that the RHEL 7 TigerVNC supported config files it became obvious that the best solution would be if I could get a matching TigerVNC 1.8.0 built on RHEL 5.11 Server, which is where this all started.

As for "if you want something other than what is provided", I'll point out that as late as 1.9.0, the sources contained tigervnc-1.9.0/contrib/packages/rpm/el5/{SOURCES,SPECS}.

Yes I know it's "contrib".  But presumably at some point, someone was still maintaining that tree and it built (and maybe even worked).  How do I find out who that maintainer was/is, and how do I contact him/her?

*Somehow* it must have worked.  (For some unknown magical version of libtool.)

Trust me, I've rolled up my sleeves and gotten my hands dirty more times than I can count.  I probably have built dozens of RPMs that only exist on otherwise much newer platforms.  It's really frustrating to see software become abandonware on older platforms once the shiny new OS is released, especially for those of us dealing with frozen CM environments for Flight Projects.

[Brian Hinz]

> Yes I know it's "contrib".  But presumably 

> at some point, someone was still

> maintaining that tree and it built (and 

> maybe even worked).  How do I find out 

> who that maintainer was/is, and how do I 

> contact him/her?

I’ve been doing all of the rpm builds since we started providing them

> *Somehow* it must have worked.  (For 

> some unknown magical version of libtool.)

There wasn’t any magic version of libtool used, everything was built on a CentOS VM using no external or third party repos except for EPEL.

> It's really frustrating to see software 

> become abandonware on older platforms 

> once the shiny new OS is released, 

> especially for those of us dealing with 

> frozen CM environments for Flight

> Projects.

I understand your frustration but how could we be expected to support EL5 beyond it’s public lifecycle without access to extended lifecycle support?

Beyond that issue, there are also logistics that are outside our control.  For example, some of the prerequisites will fail to build using the versions of the toolchains supplied with the older distros (gnutls 3.x won’t build on el6 unless you use gcc from SCL). 

--
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/49b8e211-1c22-4327-943c-6ef3fb2260a2o%40googlegroups.com.

[Mark Mielke]

On Wed, Jul 8, 2020 at 8:02 AM Riot N <riot.nr...@gmail.com> wrote:

I have to be semi-anonymous on here (because work).  At work let's just say we have long-lived Flight Projects in frozen CM configurations.  It gives our IT Security people fits because they say "You must upgrade to RHEL 5.11 Server with ELS, it's the only (still) supported RHEL 5 OS" and the Flight Project says "We are config frozen on RHEL 5.7, go fly a kite".

We aren't quite this bad - but yes, similar issue. We still have builds that need to run on RHEL 5.5 / 32-bit and RHEL 5.8 / 64-bit. :-)

Just, we don't need to VNC to these boxes. SSH is fine. If you can't say the same - sucks to be you in this respect. :-)

 

My co-worker who is our Ansible guy said "I don't want you touching the vncserver script, it's not labeled as an RPM config file so it could get overwritten".  When we discovered that the RHEL 7 TigerVNC supported config files it became obvious that the best solution would be if I could get a matching TigerVNC 1.8.0 built on RHEL 5.11 Server, which is where this all started.

He is right. And, I should clarify that my local customizations go into the RPM. I do not customize the script outside of RPM. This makes it much simpler to deploy, upgrade, and so on.

I also had to add Python 2.6 and Python 2.7 support to RHEL 5.x, so that Ansible would continue to work on it. I'm curious if he had to do the same? The particularly troublesome part of this was getting the RPM/YUM Python packages to work with Ansible. :-)

As for "if you want something other than what is provided", I'll point out that as late as 1.9.0, the sources contained tigervnc-1.9.0/contrib/packages/rpm/el5/{SOURCES,SPECS}.

Yes I know it's "contrib".  But presumably at some point, someone was still maintaining that tree and it built (and maybe even worked).  How do I find out who that maintainer was/is, and how do I contact him/her?

*Somehow* it must have worked.  (For some unknown magical version of libtool.)

Yep. I'm sure it was Brian. Although, sometimes these machines become "pets", and nobody remembers what they did to it, to make it work. Just don't touch it and keep VM-level backups. :-)

 

Trust me, I've rolled up my sleeves and gotten my hands dirty more times than I can count.  I probably have built dozens of RPMs that only exist on otherwise much newer platforms.  It's really frustrating to see software become abandonware on older platforms once the shiny new OS is released, especially for those of us dealing with frozen CM environments for Flight Projects.

Yep, although to be fair -

It would be difficult for Free / Open Source community members to get access to these machines, even if they wanted to. So, it is not necessarily abandoned as much as unavailable, and this means that the community would also be unaware if they break something. A common theme here is the use of new 3rd party OSS libraries, that might be common in 2020, but didn't exist in 2010 or before. The other stuff like syntax is easier to tweak through... :-)

--

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