Skip to content

Commit

Permalink
Merge pull request #7215 from OpenLiberty/staging
Browse files Browse the repository at this point in the history
Staging to vNExt 24001 backports
  • Loading branch information
ramkumar-k-9286 authored Feb 7, 2024
2 parents 5d98681 + bd81e8e commit b3ac7cc
Show file tree
Hide file tree
Showing 4 changed files with 53 additions and 40 deletions.
28 changes: 20 additions & 8 deletions modules/ROOT/pages/container-images.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -23,10 +23,12 @@ You can append an Open Liberty container image tag to the `icr.io/appcafe/open-l

Select from the following container image tags for the latest Open Liberty release from ICR.

* `kernel-slim-java21-openj9-ubi-minimal`
* `kernel-slim-java17-openj9-ubi`
* `kernel-slim-java11-openj9-ubi`
* `kernel-slim-java8-openj9-ubi`
* `kernel-slim-java8-ibmjava-ubi`
* `full-java21-openj9-ubi-minimal`
* `full-java17-openj9-ubi`
* `full-java11-openj9-ubi`
* `full-java8-openj9-ubi`
Expand All @@ -49,11 +51,11 @@ ibmcloud cr images --restrict appcafe/open-liberty

You can use an Open Liberty container image tag in a `Dockerfile` or `Containerfile` file to build an application image that adds a single application and its corresponding configuration. Do not configure the container manually after it is started, except for debugging purposes, because these changes are not reflected in new containers that are created from the image.

Set your image template similar to the following example, which uses the `kernel-slim-java17-openj9-ubi` tag to build an image that uses the latest Open Liberty release with the OpenJ9 distribution of Java 17.
Set your image template similar to the following example, which uses the `kernel-slim-java21-openj9-ubi-minimal` tag to build an image that uses the latest Open Liberty release with the OpenJ9 distribution of Java 21.

[source,dockerfile]
----
FROM icr.io/appcafe/open-liberty:kernel-slim-java17-openj9-ubi
FROM icr.io/appcafe/open-liberty:kernel-slim-java21-openj9-ubi-minimal
# Add a Liberty server configuration including all necessary features
COPY --chown=1001:0 server.xml /config/
Expand Down Expand Up @@ -84,15 +86,15 @@ You can also use xref:instanton.adoc[Open Liberty InstantOn] to improve the star
Open Liberty container image tags use the following naming convention.
[subs=+quotes]
----
_<optional fix pack version**-**><liberty image type>**-**<java version>**-**<java type_>**-**ubi
<optional fix pack version-><liberty image type>-<java version>-<java type>-<base image type>
----

The following tag values determine the resources that are included in a container image.

Fix pack version::
This value is optional. If you do not specify a fix pack version, your container image includes the latest release of Open Liberty. In addition to the latest release, the two most recent quarterly fix pack releases are always maintained for the `kernel-slim` and `full` image types.
+
Open Liberty quarterly release versions end in `.3`, `.6`, `.9`, or `.12`. For example, if the latest Open Liberty release is `22.0.0.10`, then the `22.0.0.9` and `22.0.0.6` releases are also maintained in ICR. To pull one of these release versions instead of the latest, add your chosen release version to the beginning of any of the `kernel-slim` or `full` image tags in the previous list. For example, if `22.0.0.9` is a recent quarterly release, you can pull an image that includes the `22.0.0.9` release with an OpenJ9 distribution of Java 8 by specifying the `22.0.0.9-full-java8-openj9-ubi` tag. The `beta` images are available only for the latest beta release.
Open Liberty quarterly release versions end in `.3`, `.6`, `.9`, or `.12`. For example, if the latest Open Liberty release is `24.0.0.1`, then the `23.0.0.12` and `23.0.0.9` releases are also maintained in ICR. To pull one of these release versions instead of the latest, add your chosen release version to the beginning of any of the `kernel-slim` or `full` image tags in the previous list. For example, if `23.0.0.12` is a recent quarterly release, you can pull an image that includes the `23.0.0.12` release with an OpenJ9 distribution of Java 8 by specifying the `23.0.0.12-full-java8-openj9-ubi` tag. The `beta` image is available only for the latest beta release of Liberty and includes the latest Java JRE.

Liberty image type::
Two different image types are available: `kernel-slim` or `full`. The `full` type provides a server with all Open Liberty features and packages installed.
Expand All @@ -103,11 +105,21 @@ Java version::
This value determines the version of Java SE that the runtime uses. Tags are available for all Java long term support (LTS) releases that are listed on the xref:java-se.adoc[Java SE Support page].

Java type::
This value determines the type of Java SE distribution that the runtime uses. Current options are IBM Semeru with Eclipse OpenJ9 and, for Java SE 8 only, the IBM SDK, Java Technology Edition.
This value determines the type of Java SE distribution that the runtime uses. Current options are IBM Semeru Runtime with Eclipse OpenJ9, named `openj9` and, for Java SE 8 only, the IBM SDK, Java Technology Edition, named `ibmjava`.

In addition to the tags that follow this naming convention, Open Liberty offers three preformatted tags that pull particular images.
Java 21 images are based on Universal Base Image (UBI) 9 minimal and include IBM Semeru Runtimes for Java 21 JRE. This combination offers a compact and effective Java runtime that is suited for applications that need Java 21.

* `latest`: This tag simplifies pulling the full latest Open Liberty release with Java 8. It is an alias for the `full-java8-openj9-ubi` tag. If you do not specify a tag value, `latest` is used by default.
* `beta`: This tag provides the most recent beta release, which includes all the features and capabilities from the most recent release, plus new and updated features that are currently in development.
Java 8, 11 and 17 images with the `openj9` type are based on Universal Base Image (UBI) 8 standard and include IBM Semeru Runtime for the respective Java version with the JDK. Images with the `ibmjava` type are based on Universal Base Image (UBI) 8 standard and include IBM Java 8 JRE.

Base image type::
Liberty images are available with two different types of Red Hat Universal Base Image (UBI): `ubi-minimal` or `ubi`.
`ubi-minimal` offers a minimized pre-installed content set and the package manager `microdnf` for adding additional packages.
`ubi` offers the standard images with access to `yum` repositories and includes utilities such as `tar` and `gzip`.


In addition to the tags that follow this naming convention, Open Liberty offers the following preformatted tags that pull particular images.

* `latest`: This tag simplifies pulling the full latest Open Liberty release with the latest Java JRE. It is an alias for the `full-java21-openj9-ubi-minimal` tag. If you do not specify a tag value, `latest` is used by default.
* `beta`: This tag is based on Universal Base Image (UBI) 9 minimal and the latest Java JRE and provides the most recent beta release of Liberty, which includes all the features and capabilities from the most recent release, plus new and updated features that are currently in development.


10 changes: 5 additions & 5 deletions modules/ROOT/pages/instanton.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -63,14 +63,14 @@ For more information about limitations with early startup code and possible work
[#prereq]
== Runtime and host build system prerequisites

Starting with Open Liberty version 23.0.0.6, all X86-64/AMD64 UBI xref:container-images.adoc[Open Liberty container images] include the prerequisites for InstantOn to checkpoint and restore Open Liberty application processes. Open Liberty Ubuntu container images are not enabled for InstantOn.
Starting with Open Liberty version 23.0.0.6, all X86-64/AMD64 UBI xref:container-images.adoc[Open Liberty container images] include the prerequisites for InstantOn to checkpoint and restore Open Liberty application processes. In version 24.0.0.1 and later, Power and Z (s390x) processor architectures are also supported when you use IBM Semeru Java version 21.0.1+. Open Liberty Ubuntu container images are not enabled for InstantOn.

Currently, InstantOn is supported with IBM Semeru Java version 11.0.19+ and IBM Semeru Java version 17.0.7+. InstantOn is expected to support new versions of IBM Semeru Java as they are released. Currently, InstantOn is not supported on other Java vendor implementations.
Currently, InstantOn is supported with IBM Semeru Java version 11.0.19+, IBM Semeru Java version 17.0.7+, and IBM Semeru Java version 21.0.1+. InstantOn is expected to support new versions of IBM Semeru Java as they are released. Currently, InstantOn is not supported on other Java vendor implementations.

To use InstantOn during an application container image build, the host machine must satisfy the following prerequisites:

- Uses the Linux Operating System with kernel version 5.9 or greater
- Uses the X86-64/AMD64 processor architecture
- Uses one of the following the processor architectures: X86-64/AMD64, Power (with IBM Semeru Java version 21.0.1+), Z (s390x) (with IBM Semeru Java version 21.0.1+)
- Allows execution of privileged container builds by using Podman or Docker
The use of privileged containers in the application container image build is required only when you build the container image with InstantOn. Running the resulting InstantOn application image does not require the use of privileged containers.
Expand Down Expand Up @@ -235,11 +235,11 @@ Special considerations are required to run an InstantOn application image locall
1. The host that is running the container image must use Linux kernel 5.9 or greater
2. The Linux capabilities CHECKPOINT_RESTORE and SETPCAP must be granted to the running container
3. The necessary system calls must be granted to the running container
4. The host processor must be X86-64/AMD64
4. The host processor must be X86-64/AMD64. If you are running IBM Semeru Java version 21.0.1+, Power and Z (s390x) processor architectures are also supported.

=== Running an InstantOn application image locally

If a host system is running the Linux kernel 5.9 or greater with the X86-64/AMD64 processor, you can run an InstantOn application image by using Podman or Docker locally. The following command runs the `liberty-app-instanton` InstantOn application image with Podman:
If a host system is running the Linux kernel 5.9 or greater with the X86-64/AMD64 processor, you can run an InstantOn application image by using Podman or Docker locally. If you are running IBM Semeru Java version 21.0.1+, Power and Z (s390x) processor architectures are also supported. The following command runs the `liberty-app-instanton` InstantOn application image with Podman:

[source,sh]
----
Expand Down
11 changes: 1 addition & 10 deletions modules/ROOT/pages/java-se.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -68,19 +68,11 @@ The following table lists the Java SE versions that Open Liberty supports and pr
|21
|Yes
|29.0.0.10
|
|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/?version=21[IBM Semeru 21]
|https://adoptium.net/temurin/releases/?version=21[Eclipse Temurin 21]
|https://docs.oracle.com/en/java/javase/21/migrate/toc.htm[Java SE 21 migration guide]
|===

////
|20
|No
|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/[IBM Semeru 20]
|https://developer.ibm.com/languages/java/semeru-runtimes/downloads/?version=20
|https://adoptium.net/temurin/releases/?version=20[Eclipse Temurin 20]
|https://docs.oracle.com/en/java/javase/20/migrate/toc.htm[Java SE 20 migration guide]
////


== Migration tools
Expand All @@ -94,4 +86,3 @@ java -jar binaryAppScanner.jar myapp.war --analyze --sourceJava=ibm8 --targetJav
```

Plug-ins that run a similar analysis on your application are available from Eclipse in the https://marketplace.eclipse.org/content/ibm-websphere-application-server-migration-toolkit-was-liberty[Eclipse marketplace].

44 changes: 27 additions & 17 deletions modules/ROOT/pages/verifying-package-signatures.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,21 +15,21 @@

You can use signature files and the corresponding public key to verify the authenticity and integrity of an Open Liberty release package. Signature files are produced for every package of an Open Liberty release.

Signature files are available for every Open Liberty release. The Open Liberty project uses its private key to digitally sign each Open Liberty release. You can use the Open Liberty public key to check the signature, verify that the package was released by Open Liberty, and that it was not modified since its release.
The Open Liberty project uses its private key to digitally sign each Open Liberty release. You can use the Open Liberty public key to check the signature, verify that the package was released by Open Liberty, and that it was not modified since its release.

You can verify a release package either locally, by using the `openssl` command and a `*.sig` file, or on Maven Central, by using the `gpg` command. When you verify the release locally, you can also verify the authenticity of the Open Liberty public key by using a certificate (`.cer`) file.
You can verify a release package either locally, by using the `openssl` command and a `.sig` file, or on Maven Central, by using the `gpg` command. When you verify the release locally, you can also verify the authenticity of the Open Liberty public key by using a certificate (`.cer`) file.

== Verifying Open Liberty release package signatures with OpenSSL

To verify an Open Liberty release package locally, you must first download an Open Liberty `.zip` package, the corresponding `*.sig` file, and the Open Liberty public key, which is included in the certificate (`.cer`) file. You can then run the `openssl` command to verify the package signature. Optionally, you can verify the authenticity of the Open Liberty public key before you verify the release package.
To verify an Open Liberty release package locally, you must first download an Open Liberty `.zip` release package, the corresponding `.sig` file, and a `.cer` file, which includes the Open Liberty public key. After you extract the Open Liberty public key from the `.cer` file, you can run the `openssl` command to verify the package signature. Optionally, you can verify the authenticity of the Open Liberty public key before you extract it from the `.cer` file.

In the following examples, replace the `<OpenLiberty_certificate>` and `<Open_Liberty_release_package>` variables with the public key (`.cer`), signature (`.sig`), and release package (`.zip`) files that you are using to verify a release package.

1. Go to the **Download package** section of the Open Liberty https://www.openliberty.io/start/[Get Started page] and download an Open Liberty `.zip` package and the corresponding `.sig` and `.cer` files.
1. Go to the **Download package** section of the Open Liberty https://www.openliberty.io/start/[Get Started page] and download an Open Liberty `.zip` release package and the corresponding `.sig` and `.cer` files.

2. Verify the authenticity of the Open Liberty public key.
+
The Open Liberty public key is embedded in the certificate file. Before you extract the Open Liberty public key, you can verify that it was produced by Open Liberty. Run the following https://www.openssl.org/docs/man1.1.1/man1/openssl-dgst.html[openssl command] from the directory that contains the certificate file.
The Open Liberty public key is embedded in the `.cer` file. Before you extract the Open Liberty public key, you can verify that it was produced by Open Liberty. Run the following https://www.openssl.org/docs/man1.1.1/man1/openssl-dgst.html[openssl command] from the directory that contains the `.cer` file:
+
[source,sh]
----
Expand Down Expand Up @@ -62,7 +62,7 @@ Certificate:

3. Extract the public key from the `.cer` file as a `.pem` file.
+
The Open Liberty public key is embedded in the `.cer` file. To extract the key to a separate `.pem` file, run the following command from the directory that contains the certificate file.
The Open Liberty public key is embedded in the `.cer` file. To extract the key to a separate `.pem` file, run the following command from the directory that contains the `.cer` file:
+
[source,sh]
----
Expand All @@ -81,7 +81,7 @@ openssl dgst -sha256 -verify <OpenLiberty_certificate>.pem -signature <Open_Libe
----

=== Results
If the verification is successful, the command produces the following console output.
If the verification succeeds, the command produces the following console output.

[source,sh]
----
Expand All @@ -90,23 +90,27 @@ Verified OK

== Verify Open Liberty package signatures on Maven Central

To verify Open Liberty packages on Maven Central, you must first download the Open Liberty public key to your local machine by using https://gnupg.org[the gpg or gpg2 command].
You must edit the trust level for the key owner. You can then use this key to remotely verify an Open Liberty `.asc` release file on Maven Central.
To verify Open Liberty packages on Maven Central, you must download `openliberty-runtime-\*.zip` and `openliberty-runtime-*.zip.asc` files for your chosen release from Maven Central. You must also download the Open Liberty public key to your local machine and set trust level for the key owner by using https://gnupg.org[the gpg or gpg2 command]. You can then use this key to verify the Open Liberty release package signature.

1. Run the following command to download the Open Liberty public key file. The key ID value for the Open Liberty public key is `9E68CA00`.
1. Go to the link:https://repo1.maven.org/maven2/io/openliberty/openliberty-runtime[openliberty-runtime repository on Maven Central] and click the release version that you want to verify, for example, `24.0.0.1`.

2. Download the `openliberty-runtime-\*.zip` and `openliberty-runtime-*.zip.asc` files that correspond to the release you want to verify, for example `openliberty-runtime-24.0.0.1.zip` and `openliberty-runtime-24.0.0.1.zip.asc`. Make sure to save the `.asc` file from your browser as an `.asc` file.

3. Run the following command to download the Open Liberty public key file. The key ID value for the Open Liberty public key is `9E68CA00`.
+
[source,sh]
----
gpg2 --keyserver hkp://keyserver.ubuntu.com --recv-keys 9E68CA00
----

2. Use the `gpg2 --edit-key` command to https://www.gnupg.org/gph/en/manual/x334.html[set the trust for the key owner] to 5.
4. Run the `gpg2 --edit-key` command to https://www.gnupg.org/gph/en/manual/x334.html[set the trust for the key owner] to 5.
+
The following examples show the `gpg2 --edit-key` command and the console output that it generates.
+
[source,sh]
----
[root]$ gpg2 --edit-key "International Business Machines Corporation [email protected]"
gpg2 --edit-key "International Business Machines Corporation <[email protected]>"
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Expand Down Expand Up @@ -147,21 +151,27 @@ Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
----

3. Verify the file by running the `gpg2 --verify` command. The following example verifies the Open Liberty 23.0.0.2 release package.
5. Verify the release package by running the `gpg2 --verify` command from the directory that contains the Open Liberty public key and the `.zip` and `.asc` release package files that you downloaded from Maven central.
+
The following example uses the `openliberty-runtime-24.0.0.1.zip.asc` file to verify the 24.0.0.1 release package signature. Replace this value with the release package that you want to validate.
+
[source,sh]
----
gpg2 --verify openliberty-runtime-23.0.0.2.zip.asc
gpg2 --verify openliberty-runtime-24.0.0.1.zip.asc
----

=== Results

If the verification is successful, the command produces console output that is similar to the following example.
If the verification succeeds, the command produces console output that is similar to the following example:

[source,sh]
----
gpg: assuming signed data in 'openliberty-runtime-23.0.0.2.zip'
gpg: Signature made Thu 02 Mar 2023 09:02:22 AM PST
gpg: assuming signed data in 'openliberty-runtime-24.0.0.1.zip'
gpg: Signature made Thu Jan 25 08:18:11 2024 EST
gpg: using RSA key E70E5D6C3F1E452CB0F67DF1BD9FD5BE9E68CA00
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2027-02-09
gpg: Good signature from "International Business Machines Corporation <[email protected]>" [ultimate]
----

0 comments on commit b3ac7cc

Please sign in to comment.