The /staging directory created during the Distroless builds is not being cleaned up correctly.

I believe this is due to a typo in the rm command, cleaning up dnf instead of tdnf.

This can save about 30MB

@joe-braley can you take a look?

Running this image as non-root fails, i.e. the Docker compose file below doesn't run the container as user 1001 and group 1001, as it should.

version: "3"
services:
  minecraft:
    image: mcr.microsoft.com/openjdk/jdk:17-distroless
    container_name: minecraft
    ports:
      - 25565:25565/tcp
    restart: unless-stopped
    volumes:
      - /opt/minecraft:/opt/minecraft
    command: ["-Xms8G", "-Xmx8G", "-jar", "/opt/minecraft/minecraft-server.jar", "nogui"]
    user: 1001:1001

Hi @d3r3kk we still have the issue that was supposed to be solved with issue #75
Where can we find the image that contains your fix?
We are on the latest sha of the openjdk/jdk:17-ubuntu image.

Use steps below to reproduce:

~ docker run -it mcr.microsoft.com/openjdk/jdk:17-ubuntu@sha256:d0d95b272cc49d188f5606bb28c17be56d82d9cec59f111381f5a5208ecb8f4e bash
root@11ce4397c4ff:/# cd /usr/lib/jvm/msopenjdk-17-arm64/lib/
root@11ce4397c4ff:/usr/lib/jvm/msopenjdk-17-arm64/lib# ls -la
total 143864
drwxr-xr-x 5 root root      4096 Jul 31 09:19 .
drwxr-xr-x 9 root root      4096 Jul 31 09:18 ..
-rw-r--r-- 1 root root     71443 Jul  7 17:22 classlist
-rw-r--r-- 1 root root   8264052 Jul 26 17:14 ct.sym
-rwxr-xr-x 1 root root     71016 Jul  7 17:22 jexec
drwxr-xr-x 2 root root      4096 Jul 31 09:18 jfr
-rw-r--r-- 1 root root    110488 Jul 26 17:14 jrt-fs.jar
-rwxr-xr-x 1 root root     72152 Jul  7 17:22 jspawnhelper
-rw-r--r-- 1 root root        29 Jul  7 17:22 jvm.cfg
-rw-r--r-- 1 root root     71112 Jul  7 17:22 libattach.so
-rw-r--r-- 1 root root     76752 Jul  7 17:22 libawt_headless.so
-rw-r--r-- 1 root root    826328 Jul  7 17:22 libawt.so
-rw-r--r-- 1 root root    555944 Jul  7 17:22 libawt_xawt.so
-rw-r--r-- 1 root root     73816 Jul  7 17:22 libdt_socket.so
-rw-r--r-- 1 root root     71088 Jul  7 17:22 libextnet.so
-rw-r--r-- 1 root root   2461904 Jul  7 17:22 libfontmanager.so
-rw-r--r-- 1 root root     76424 Jul  7 17:22 libinstrument.so
-rw-r--r-- 1 root root     76832 Jul  7 17:22 libj2gss.so
-rw-r--r-- 1 root root     71912 Jul  7 17:22 libj2pcsc.so
-rw-r--r-- 1 root root    147176 Jul  7 17:22 libj2pkcs11.so
-rw-r--r-- 1 root root     70144 Jul  7 17:22 libjaas.so
-rw-r--r-- 1 root root    283728 Jul  7 17:22 libjavajpeg.so
-rw-r--r-- 1 root root    240200 Jul  7 17:22 libjava.so
-rw-r--r-- 1 root root     70048 Jul  7 17:22 libjawt.so
-rw-r--r-- 1 root root    366792 Jul  7 17:22 libjdwp.so
-rw-r--r-- 1 root root    161728 Jul  7 17:22 libjimage.so
-rw-r--r-- 1 root root     78712 Jul  7 17:22 libjli.so
-rw-r--r-- 1 root root     70952 Jul  7 17:22 libjsig.so
-rw-r--r-- 1 root root     86184 Jul  7 17:22 libjsound.so
-rw-r--r-- 1 root root    589104 Jul  7 17:22 liblcms.so
-rw-r--r-- 1 root root     70120 Jul  7 17:22 libmanagement_agent.so
-rw-r--r-- 1 root root     75312 Jul  7 17:22 libmanagement_ext.so
-rw-r--r-- 1 root root     75864 Jul  7 17:22 libmanagement.so
-rw-r--r-- 1 root root    605344 Jul  7 17:22 libmlib_image.so
-rw-r--r-- 1 root root    151680 Jul  7 17:22 libnet.so
-rw-r--r-- 1 root root    155272 Jul  7 17:22 libnio.so
-rw-r--r-- 1 root root     70184 Jul  7 17:22 libprefs.so
-rw-r--r-- 1 root root     69792 Jul  7 17:22 librmi.so
-rw-r--r-- 1 root root    228720 Jul  7 17:22 libsaproc.so
-rw-r--r-- 1 root root     74024 Jul  7 17:22 libsctp.so
-rw-r--r-- 1 root root    372184 Jul  7 17:22 libsplashscreen.so
-rw-r--r-- 1 root root     69832 Jul  7 17:22 libsyslookup.so
-rw-r--r-- 1 root root     73176 Jul  7 17:22 libverify.so
-rw-r--r-- 1 root root     74968 Jul  7 17:22 libzip.so
-rw-r--r-- 1 root root 129797310 Jul  7 17:22 modules
-rw-r--r-- 1 root root     11390 Jul  7 17:22 psfontj2d.properties
-rw-r--r-- 1 root root      3793 Jul  7 17:22 psfont.properties.ja
drwxr-xr-x 2 root root      4096 Jul 31 09:18 security
drwxr-xr-x 2 root root      4096 Jul 31 09:19 server
-rw-r--r-- 1 root root    103785 Jul  7 17:22 tzdb.dat
root@11ce4397c4ff:/usr/lib/jvm/msopenjdk-17-arm64/lib# ls | grep free
root@11ce4397c4ff:/usr/lib/jvm/msopenjdk-17-arm64/lib# 

Originally posted by @dinilimento in #75 (comment)

If you would like to see AArch64 (Arm64) images published, please let us know by commenting or upvoting on this issue.

See Dockerfile for Ubuntu 11 on how LANG is set. We should document about this setting and how developers may want, if needed, change this to other locales.

To enable a full chain of trust and verify the docker image it would be relay beneficial that you sign your images.
Google distroless images for example are signed using cosign.
Link to google distroless verification instruction

Hello,
the latest update of the 17-ubuntu image to version "Java 17.0.8 Microsoft (64-bit)" got us this error:

https://community.sonarsource.com/t/analysis-failing-for-azure-devops-after-installing-new-certificate/42129

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

(we get this error without getting any new certificate, just this docker image was updated in Azure Pipelines)
Our Certificate on sonarqube instance is over a month old and renews every three months, many times before.

Thanks for suggestions or help!

Petr

Dockerfiles do not set a locale

tzdata, ca-certificates, and font packages are commonly required.

After JDK is installed, perform a -Xshare:dump for faster startup time by consuming users.

This is only required for Java 11.

See #57

Hi,
we switched our docker base image from 17-ubuntu to 17-distroless.
Our java spring boot applications itself are untouched.

Unfortunately, we have seen that our application startup times increased significantly (more than 50%) since the switch.
Can you explain what might be the reason for the increased startup duration?

I'm currently using mcr.microsoft.com/openjdk/jdk:17-distroless
I was looking for a debug version so that I can use to exec into the running container.

It looks like CBL-Mariner Distroless Debug is supported:
https://mcr.microsoft.com/en-us/product/cbl-mariner/distroless/debug/about

But the Microsoft OpenJDK equivalent doesn't exists it seems:
https://mcr.microsoft.com/en-us/product/openjdk/jdk/tags

In CBL-Mariner, the RPM package for msopenjdk-17 is not being automatically updated.

$ docker run -ti --rm mcr.microsoft.com/openjdk/jdk:17-mariner

root [ / ]# yum update
Loaded plugin: tdnfrepogpgcheck
Nothing to do.
root [ / ]# java -version
openjdk version "17" 2021-09-14
OpenJDK Runtime Environment Microsoft-26987 (build 17+35)
OpenJDK 64-Bit Server VM Microsoft-26987 (build 17+35, mixed mode, sharing)
root [ / ]# yum list msopenjdk-17
Loaded plugin: tdnfrepogpgcheck
msopenjdk-17.x86_64                           17+35-1              @System
msopenjdk-17.x86_64                           17+35-1              packages-microsoft-com-prod
msopenjdk-17.x86_64                           17.0.1+12_LTS-1      packages-microsoft-com-prod

Ubuntu 22.04 is the latest LTS release from Canonical. To ensure new container images are produced with the latest, safest, and greatest LTS versions, we shall update our Ubuntu-based images to this version.

Customers who do require 20.04 can still fallback to authoring and producing their own container images.

We got such exeptions when using the distroless images with one of our applications

What is missing here?

ava.lang.NullPointerException: null
          at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
          at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
          at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
          at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719)
          at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:379)
          at java.base/java.security.AccessController.doPrivileged(Native Method)
          at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:324)
          at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
          at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)

The published container images for openjdk are shipped with open security issues and were last pushed at 06/22/2022.

As a customer i expect regularly updates of container image so please update your base images more often (eg. every week or on a daily basis).

See PR #57

Upon build, Docker images should perform an apt/yum upgrade.

The Ubuntu images are still published using Ubuntu 20.04 even though the source states that's it's published with 22.04, in this example should the 17-ubuntu images, but I see the same issue with 11-ubuntu & 21-ubuntu

Hi,

According to https://github.com/microsoft/CBL-Mariner/releases/tag/1.0.20220307-1.0
there are quite some CVE's fixed.

Are these incorporated into the mcr.microsoft.com/openjdk/jdk:11-mariner image as well?

We don't need src.zip in the base images. This should also significantly reduce the size of the image, given this file occupies 50 MB.

👋

Today we had a bug in production because of the German ü, but the problem of course generalises.

The distroless images do not contain the en_US locale environment variables, even though the documentation mentions:

The images for Microsoft Build of OpenJDK are configured by default with the en_US.UTF-8 locale.

Which I would assume includes the distroless images

In all distros:

Distroless:

I see two paths:

1. Set env vars to make en_US the default locale in distroless (probably preferred)
2. Document that the distroless images do not specify this locale

Mariner 1.0 seems to have the same "issue", but seems to be deprecated anyway

          Hello

Had exactly the same issue yesterday as @czechdude.

Today, I created a new image and now getting an other error:

java.lang.UnsatisfiedLinkError: /usr/lib/jvm/msopenjdk-17-amd64/lib/libfontmanager.so: libfreetype.so: cannot open shared object file: No such file or directory

I quickly tested with a different image (eclipse-temurin:17-jdk-alpine) and that seems to work fine.

Please provide the fix asap.

Thank you!

Originally posted by @jegrz in #74 (comment)