UBI-based Dockerfile for IntelliJ IDEA Che editor

[azatsarynnyy]

Is your task related to a problem? Please describe.

To include IntelliJ IDEA Che editor to CRW we need a UBI-based Dockerfile.

Describe the solution you'd like

Prepare a UBI-based Dockerfile for IntelliJ IDEA Che editor.

Currently used Fedora-based Dockerfile: https://github.com/che-incubator/che-editor-intellij-community/blob/master/Dockerfile

Describe alternatives you've considered

Once we have a UBI-based Dockerfile, we can get rid of a Fedora-based one to not support both.

Additional context

This issue is a sub-task of #17790

[benoitf]

how to use ubi8 there ? it's more server side oriented, here it's user
should be RHEL not ubi8 ?

[nickboldt]

UBI8 minimal is a tiny RHEL8.2 server. Use that instead of https://github.com/che-incubator/che-editor-intellij-community/blob/master/Dockerfile#L9

Then use microdnf to install whatever you need into it.

Lots of examples of this already in Che-land.

• https://github.com/che-incubator/kubernetes-image-puller-operator/blob/master/build/Dockerfile#L16
• https://github.com/eclipse/che-machine-exec/blob/master/build/dockerfiles/rhel.Dockerfile
• https://github.com/eclipse/che-jwtproxy/blob/master/build/dockerfiles/rhel.Dockerfile#L14
• https://github.com/eclipse/che-plugin-broker/blob/master/build/artifacts/rhel.Dockerfile#L13
• https://github.com/eclipse/che-operator/blob/master/Dockerfile#L16

[benoitf]

I do know but ubi8 has no packages on graphical stuff like Xwindow/vnc stuff

[nickboldt]

For examples of how to build in both online / offline mode to fetch dependencies ( https://github.com/che-incubator/che-editor-intellij-community/blob/master/Dockerfile#L13 ) you'll want to look at either the super complicated crw-theia approach:

https://github.com/redhat-developer/codeready-workspaces-theia/tree/crw-2.5-rhel-8/build.sh
https://github.com/redhat-developer/codeready-workspaces-theia/tree/crw-2.5-rhel-8/conf

or this approach for building the registries in online/offline modes:

https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.5-rhel-8/dependencies/che-plugin-registry/build.sh#L36-L38
https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.5-rhel-8/dependencies/che-plugin-registry/build/dockerfiles/rhel.Dockerfile#L32
https://github.com/redhat-developer/codeready-workspaces/blob/crw-2.5-rhel-8/dependencies/che-plugin-registry/Jenkinsfile#L185-L187

[nickboldt]

ubi8 has no packages on graphical stuff like Xwindow/vnc stuff

If they exist in RHEL8.2, they'll be available in UBI8, which uses the same repos.

https://rpmfind.net/linux/rpm2html/search.php?query=Xserver&submit=Search+...&system=centos&arch=x86_64
--> https://rpmfind.net/linux/centos/8-stream/AppStream/x86_64/os/Packages/

But bear in mind you can't easily install from EPEL and 3rd party / commercial repos. We'd have to prefetch those deps via a Jenkins job, then get them into Brew using a similar approach to what's in the crw-theia build.

[azatsarynnyy]

It could be any image available from RHEC, e.g. https://catalog.redhat.com/software/containers/search?q=rhel8

[vzhukovs]

Current state. Red Hat images catalog https://catalog.redhat.com/software/containers/search?q=ubi8&p=1 contains images which are based only for the server side deployment. This means that we don't have ability to extend some of image with desktop environment, because it doesn't exist. Image ubi8-minimal was chosen as base image. In all UBI based images there are two configurations for repository, Red Hat internal and UBI:

/etc/yum.repos.d/redhat.repo

bash-4.4# cat /etc/yum.repos.d/redhat.repo 
#
# Certificate-Based Repositories
# Managed by (rhsm) subscription-manager
#
# *** This file is auto-generated.  Changes made here will be over-written. ***
# *** Use "subscription-manager repo-override --help" if you wish to make changes. ***
#
# If this file is empty and this system is subscribed consider
# a "yum repolist" to refresh available repos
#

/etc/yum.repos.d/ubi.repo

bash-4.4# cat /etc/yum.repos.d/ubi.repo 
[ubi-8-baseos]
name = Red Hat Universal Base Image 8 (RPMs) - BaseOS
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/baseos/os
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-baseos-debug]
name = Red Hat Universal Base Image 8 (Debug RPMs) - BaseOS
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/baseos/debug
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-baseos-source]
name = Red Hat Universal Base Image 8 (Source RPMs) - BaseOS
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/baseos/source/SRPMS
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-appstream]
name = Red Hat Universal Base Image 8 (RPMs) - AppStream
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/appstream/os
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-appstream-debug]
name = Red Hat Universal Base Image 8 (Debug RPMs) - AppStream
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/appstream/debug
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-appstream-source]
name = Red Hat Universal Base Image 8 (Source RPMs) - AppStream
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/appstream/source/SRPMS
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-codeready-builder]
name = Red Hat Universal Base Image 8 (RPMs) - CodeReady Builder
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/codeready-builder/os
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-codeready-builder-debug]
name = Red Hat Universal Base Image 8 (Debug RPMs) - CodeReady Builder
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/codeready-builder/debug
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

[ubi-8-codeready-builder-source]
name = Red Hat Universal Base Image 8 (Source RPMs) - CodeReady Builder
baseurl = https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/$basearch/codeready-builder/source/SRPMS
enabled = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
gpgcheck = 1

https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/x86_64/appstream/os/Packages/x/
and
https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi8/8/x86_64/baseos/os/Packages/x/
don't contain xorg related packages.

---

There're several ways to use such packages:

1. Use third-party repositories, such as https://ftp.halifax.rwth-aachen.de/fedora/linux/releases/32/Everything/x86_64/os/Packages/x/ (for example or public EPEL repository).

This approach will allow to install all necessary rpms that are needed to run Intellij Idea on desktop environment. But according to FAQ - Universal Base Images, item №39:

Can I add non-UBI packages if something is missing from UBI?

Yes, but not if you want to freely redistribute the images. Once you add RHEL RPMs onto a UBI image, you are back to redistributing content released under the Red Hat Enterprise Linux end user license. If you are a paying Red Hat customer, this would break the agreement between you and Red Hat. Furthermore receivers of these images wouldn’t receive updates for the RPMs you added unless they have Red Hat subscriptions. This puts those end users without Red Hat subscriptions in a bad place.
If you need extra packages, don’t add RHEL packages (because they are restricted). Also, don’t add CentOS packages (because they will remove supportability). Adding CentOS packages turns the image into a Frankenstein. Neither Red Hat, nor the community will want to support it. You are better off with all UBI or CentOS content. Don’t mix and match.

... says that we can't do it, because we can loose supportability. Another way is to rebuild rpms from the sources and publish rpms internally in Red Hat infrastructure, but this approach limits end user from building the image on his local machine. Because image can be built on specific development environment.

2. Build x11 server from the sources and install it during image build from builder image.

According to FAQ - Universal Base Images, item №20:

Can I freely distribute applications built on UBI?

Yes, applications built on the Red Hat Universal Base Images and UBI-compatible tools and packages can be distributed with the embedded UBI content in the base image, as per the UBI EULA. Software vendors and community projects which build on UBI may have additional EULAs which apply to their layered software.

... says that we can distribute applications which is built in the UBI image. But this statement is applied for the deployable applications. But for the third-party software (such as xorg server, fluxbox, vnc-related software) there's nothing said.

This approach will allow us to control the whole flow of setting up desktop environment for running Intellij Idea. It doesn't require using additional repositories. It is enough to get sources for the sticked version and build them in builder images. And this allows to build image on any public CI and on local machine.

But I'm not 100% sure that EULA allows this, studying this question at the moment.

Packages needed to support desktop environment: xorg-x11-server (with all necessary dependencies), fluxbox (builds from sources without any dependencies), noVNC (node.js application to allows to connect to VNC by accessing a web page), tigerVNC (VNC server, which also builds without dependencies).

cc @l0rd @azatsarynnyy @nickboldt @scela

[l0rd]

@pdaverh @RickJWagner @nickboldt what about referencing the upstream IntelliJ editor (fedora based) in CRW the and offer "community support" for it? Building X11 server from sources doesn't make sense.

[RickJWagner]

We have done similar things with other products. (i.e. offered 'commercially reasonable' support around proprietary third-party messaging connectors with our SOA products.)
Seems ok to me. If the user goes to upstream for the bits, it's pretty clearly not 'in the box'.

[nickboldt]

@RickJWagner making the user go upstream would mean that we...

• provide a devfile linked from a blog (not in the product itself) which would
• pull community images built on Fedora/Centos/RHEL
• w/ EPEL/Fedora dependencies installed via RPM.

That's by far easier for us to produce since

• it's not inside the Brew system, but also would be
• 100% unsupported, no CVE process, no guarantees of support/updates. Not even Technical Preview level.

I'll ask Chris O about the feasibility of build-from-source RPMs and how to get them easily into Brew. We can also reach out to Matt M about the prodsec risk around redistributing not-built-from-source RPMs (if those RPMs are build by RH for Fedora, so at least the build process is controlled/managed).

[rhopp]

Maybe I'm missing something, but if we are talking about downstream version of the image, what's the problem with having dockerfile simmilar to this for example:

FROM registry.redhat.io/ubi8/ubi-minimal
RUN microdnf install -y xorg-x11-server-common gnome-desktop3 tigervnc-server

This dockerfile builds fine if the host system is properly subscribed using subscription-manager and has the rights repos enabled. (that dockerfile builds fine on my system at least :-D)

[nickboldt]

Those RPMs don't exist in a content set that Brew can see, so we can't install them into quay.io/crw/plugin-intellij-rhel8:2.5 container.

After some digging around in Brew thx to Chris' advice, we've found 3 of the 4 deps:

brew search build tigervnc-* | sort -V
...
for d in tigervnc  xorg-x11-server ; do brew latest-build rhel-8-latest-released $d | grep -i $d | sed -r -e "s/   .+//g"; done
for d in novnc; do brew latest-build rhos-16.0-rhel-8-ga-1.2-set $d | grep -i $d | sed -r -e "s/   .+//g"; done

tigervnc-1.9.0-13.el8
xorg-x11-server-1.20.6-3.el8
novnc-1.1.0-1.el8ost

But for the 4th one...

• fluxbox (builds from sources without any dependencies)

Chris said:

you could work from source archives from upstream, put those in your lookaside...
and build the RPMs in an intermediary container, then install them into the final container layer
and make darn sure those sources get bundled up with the rest

[nickboldt]

We could also consider switching to gdm-3.28.3-29.el8, which is already included in RHEL 8.2. @azatsarynnyy WDYT?

[l0rd]

provide a devfile linked from a blog (not in the product itself)

@nickboldt not sure I know what you are referring to but we won't provide a devfile for IntelliJ based workspaces. No devfile upstream, no devfile downstream. We do publish a new plugin in the plugin registry.

fluxbox (builds from sources without any dependencies)

Maintaining the build of fluxbox from sources will have a cost and if we do it now it will be difficult to revert this decision. Since it's still unclear how much customers will use and need support on this particular editor I think it's safer to use the upstream image now and consider, when planning next releases, if we require a downstream build or not.

[nickboldt]

We can't put upstream image into the product. Period, full stop. It's not built inside Brew.

But we CAN document how to add the plugin & use the sidecar (eg., with a devfile). If you want a 100% community-supported solution here, then we won't actually put anything into CRW 2.5 for this requirement, and it can slip to 2.x.

---

If we DO want to include a CRW-branded, RH-supported image in the CRW 2.5 payload, then it's a 3-pronged approach:

• use 2 rpms from RHEL 8 content set
• get permission to use pmr from other content set
• switch to gdm instead of fluxbox, and use RHEL8 content set (if we find that performance suffers using gdm vs. fluxbox, we could update the image in 2.6 to make it smaller and more lightweight, but the cost as you say is maintaining a fluxbox rpm build inside the container's dockerfile.

[benoitf]

sorry but using gdm is like a no-go as UX as it should be the smallest and invisible display manager (there are tons of others display manager but gnome is not fitting in this category as we only have one app)

[ericwill]

* switch to gdm instead of fluxbox, and use RHEL8 content set (if we find that performance suffers using gdm vs. fluxbox, we could update the image in 2.6 to make it smaller and more lightweight, but the cost as you say is maintaining a fluxbox rpm build inside the container's dockerfile.

If gdm is available, shouldn't the more lightweight xdm also be available?

[nickboldt]

you'd think so, but no.

$➔ brew search build xdm* | grep el8 
(nothing found)

So I guess we're stuck with either:

• build fluxbox as part of the container build, or
• don't build anything and just provide docs for how to use the community bits

[rhopp]

I never tried that... but as gnome is the only DE supported in RHEL, wouldn't be possible to use just mutter, as that's the window manager Gnome is using? That way we would have window manager without full gnome experience in the container.
(brew search build "mutter*" |grep el8 returns quite a few records, so this should be fine)

[ericwill]

I never tried that... but as gnome is the only DE supported in RHEL, wouldn't be possible to use just mutter, as that's the window manager Gnome is using? That way we would have window manager without full gnome experience in the container.
(brew search build "mutter*" |grep el8 returns quite a few records, so this should be fine)

IIRC that should work yes, though I'm not sure what dependencies that will bring in.

[azatsarynnyy]

We could also consider switching to gdm-3.28.3-29.el8, which is already included in RHEL 8.2. @azatsarynnyy WDYT?

I'm afraid that GDM is not the option for a Che Editor. It shouldn't have any visible UI parts, except for the IDEA window.

As I see, Kirk has already made great progress on it: https://github.com/redhat-developer/codeready-workspaces-images/tree/crw-2.5-rhel-8/codeready-workspaces-plugin-intellij 👍

@nickboldt do you mind assigning this upstream issue to Kirk?
After the initial Vlad's investigation, I think there's nothing more that can be done from our side.
Or should we close this one in favor of the downstream issue?

[azatsarynnyy]

Investigation of the possible approaches has been done in #18031 (comment)
Further work is tracked in CRW#1239
Work on a UBI-based CRW-compatible image is underway in this repo https://github.com/redhat-developer/codeready-workspaces-images/tree/crw-2.5-rhel-8/codeready-workspaces-plugin-intellij

[bivasda1]

How to install VNC using UBI base image?@nickboldt please provide me inputs how to create intelliJ based docker image for power(ppc64le) as that dependency isn't available.
Error: Unable to find a match: tigervnc-server The command '/bin/sh -c yum install -y tigervnc-server wget java-11-openjdk-devel which tar git && cd /tmp/assets && yum localinstall -y *.noarch.rpm *.$(uname -m).rpm # fluxbox supervisor novnc' returned a non-zero code: 1

[bivasda1]

How to install VNC using UBI base image?@nickboldt please provide me inputs how to create intelliJ based docker image for power(ppc64le) as that dependency isn't available. Error: Unable to find a match: tigervnc-server The command '/bin/sh -c yum install -y tigervnc-server wget java-11-openjdk-devel which tar git && cd /tmp/assets && yum localinstall -y *.noarch.rpm *.$(uname -m).rpm # fluxbox supervisor novnc' returned a non-zero code: 1

@nickboldt Please share you inputs regarding the above issue.