openliberty / ci.docker Goto Github PK

The links on the Open Liberty Dockerhub page https://hub.docker.com/r/openliberty/open-liberty/ are broken when linking to the "Dockerfile" and the image on "Docker Hub".

The Dockerfile link should be: https://hub.docker.com/r/openliberty/open-liberty/~/dockerfile/
I think the Docker Hub link should be: https://hub.docker.com/u/openliberty/

Once the Spring Boot features are included in an open-liberty release (Epic OpenLiberty/open-liberty#3169) we need to create new tags in docker that include the new features for Spring Boot.

Hey,

In the documentation of the docker image on Docker Hub (https://hub.docker.com/r/openliberty/open-liberty/) you point out that there is a javaee8 tag for the openliberty/open-liberty image. Neither can I pull the javaee8 image with docker pull openliberty/open-liberty:javaee8 nor is there a tag listed on Docker Hub (https://hub.docker.com/r/openliberty/open-liberty/tags/) for Java EE 8. Pulling latest will result in a JavaEE 7 image.

$ docker pull openliberty/open-liberty
Using default tag: latest
latest: Pulling from openliberty/open-liberty
Digest: sha256:cabf6669b539ac46cc29f58fcb39fd12d4efddc5a108175c4024e6748157df39
Status: Image is up to date for openliberty/open-liberty:latest
Philips-MBP:embedded-messaging-engine-open-liberty Philip$ docker run openliberty/open-liberty:latest
Launching defaultServer (Open Liberty 18.0.0.2/wlp-1.0.21.cl180220180619-0403) on IBM J9 VM, version 8.0.5.17 - pxa6480sr5fp17-20180627_01(SR5 FP17) (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
[WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT   ] CWWKS4104A: LTPA keys created in 1.521 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
[AUDIT   ] CWPKI0803A: SSL certificate created in 2.976 seconds. SSL key file: /opt/ol/wlp/output/defaultServer/resources/security/key.jks
[AUDIT   ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
[AUDIT   ] CWWKF0012I: The server installed the following features: [servlet-3.1, beanValidation-1.1, ssl-1.0, jndi-1.0, jca-1.7, jms-2.0, ejbPersistentTimer-3.2, appSecurity-2.0, j2eeManagement-1.1, jdbc-4.1, wasJmsServer-1.0, jaxrs-2.0, javaMail-1.5, cdi-1.2, webProfile-7.0, jcaInboundSecurity-1.0, jpa-2.1, jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, ejbHome-3.2, jaxws-2.2, jsonp-1.0, el-3.0, jaxrsClient-2.0, concurrent-1.0, appClientSupport-1.0, ejbRemote-3.2, javaee-7.0, jaxb-2.2, mdb-3.2, jacc-1.5, batch-1.0, ejb-3.2, json-1.0, jaspic-1.1, jpaContainer-2.1, distributedMap-1.0, websocket-1.1, wasJmsSecurity-1.0, wasJmsClient-2.0].
[AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter planet.

In the page that specifies Ingress configuration - https://github.com/OpenLiberty/ci.docker/blob/master/docs/ingress-configurations.md in the examples section it is written:

For https://dev.foo.bar/ enter app.foo.bar as the ingress.host and / as the ingress.path.

and it should be enter dev.foo.bar , so dev instead of app.

Please add support for Java 12 since it is officially supported by OpenLiberty. https://openliberty.io/docs/ref/general/#java-se.html

Since this is a non-LTS-release it should be fine if the image is only provided as long as the Java-version is.

Example output:

$ docker run openliberty/open-liberty:full-java8-openj9-ubi
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/opt/ol/helpers/runtime/docker-server.sh: line 21: openssl: command not found
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Launching defaultServer (Open Liberty 19.0.0.12/wlp-1.0.35.cl191220191120-0300) on Eclipse OpenJ9 VM, version 1.8.0_232-b09 (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml

Inside release/javaee8/java8, there's a folder named openj9. That suggests there might be an image based on OpenJ9. But it seems it isn't published on Docker Hub.

Are there any plans to publish those?

The Dockerfile sets SCC location to cacheDir=/output/.classCache/ but when I run the server and check the location in javacore, I see it as cacheDir="/opt/ol/wlp/output/.classCache".
It appears the IBM_JAVA_OPTIONS is getting overwritten by /opt/ol/wlp/bin/server.

Also the configure.sh script ends up removing the cache at the last step.
So if some one runs configure.sh script in their Dockerfile, they won't be able to get the startup benefit that SCC can provide during the runtime.

The Dockerfile for kernel still says 17.0.0.4 at the moment:

https://github.com/OpenLiberty/ci.docker/blob/master/release/kernel/Dockerfile

Perhaps it is no longer meant to be used? Not sure so opening this issue.

When using the images from here, without host="*" set, I couldn't talk to my liberty via the docker port forward..

But adding a server.xml to set host="*" meant I overrode the one supplied as part of the tagged image, meaning I had to set the features up etc, losing me the convenience of just using the tagged image.
(Tho I guess I could have configured host via config dropins.. it would be nicer to just be able to 'use' a docker image like this, by adding in my app to dropins folder, and not have to worry about changing the host setting.. )

@meiaus commented on Sun May 17 2020

Not sure if the following SECURITY.md page is handled via "open-liberyt-operator" repo, but since the following docker build problem is experienced from running with Open Liberty Operator, tracking this ticket here:

https://github.com/OpenLiberty/ci.docker/blob/master/SECURITY.md

Recently when running docker build with Dockerfile which was tested in April, e.g.

FROM openliberty/open-liberty:full-java8-openj9-ubi

# Optional functionality
ARG TLS=true
ARG SEC_SSO_PROVIDERS="oauth oidc facebook google github twitter linkedin"
#ARG OPENJ9_SCC=false
ARG VERBOSE=true

COPY --chown=1001:0  server.xml /config/
COPY --chown=1001:0  AcmeWebClientEar.ear /config/apps

# This script will add the requested XML snippets and gow image to be fit-for-purpose
RUN configure.sh

the following failure appeared:

++ grep oauth
+ [[ -n sso-oauth2.xml ]]
+ cp /opt/ol/helpers/build/configuration_snippets/sso-oauth.xml /config/configDropins/defaults
cp: cannot stat '/opt/ol/helpers/build/configuration_snippets/sso-oauth.xml': No such file or directory

After consulting with @brutif and @leochr, it's realized, the sso provider "oauth" has been changed to "oauth2".
After updating Dockerfile to reflect the new provider "oauth2",

ARG SEC_SSO_PROVIDERS="oauth2 oidc facebook google github twitter linkedin"

the problem is the resolved.

Please update the readme accoringly:
https://github.com/OpenLiberty/ci.docker/blob/master/SECURITY.md

Now that ppc64le and s390x are supported by public travis, build scripts for pushing out the multi-arch UBI images to Dockerhub should be moved into this repo to simplify the build system.

Is there still a new image coming for the Open Liberty 20.0.0.x + Java 11?
Version 19.0.012 + Java8 is the latest version I could find here https://hub.docker.com/_/open-liberty

Seems that the last ibmsfj is based on alpine 3.7.3 which has the CVE-2019-14697.

New alpine releases aren't flagged by this CVE (apline 3.10.2).

I will look at ibmjava:8-sfj-alpine to open an issue there also.

Recent versions of docker support an experimental feature buildx that allows for pretty straightforward building and pushing of any number of CPU architectures from the a single machine.

Investigate:

• How consistently this can work within Travis CI, from a quick look this shouldn't be hard but Travis is good at causing small intermittent issues.
• What order it pushes images in and how it handles failures
• How long it takes relative to current solutions with GHE
• Whether it pushes a manifest list for images or if this needs to be done separated from the buildx command

May be a better solution than the currently blocked #139

This workitem will add the equivalent to the ifix support available in the WebSphere Liberty container, illustrated here: https://github.com/WASdev/ci.docker/tree/master/ga/applying-ifixes

So the work involves:

• adding a new applfying-ifixes page in this repository
• adding similar configure.sh support as https://github.com/WASdev/ci.docker/blob/master/ga/latest/kernel/helpers/build/configure.sh#L106

Only JDK 8, 11 and 13 images are provided. JDK 14 is the latest and is already supported in Open Liberty 20.0.5.

Hi,

We are using open-liberty:19.0.0.9-kernel-java11 as base image for our custom images.

Just wondering why open liberty hasn´t been packaged with Java 11 for 19.0.0.10 and 19.0.0.11?

What is the strategy going forward? Should we modify the kernel-image it self or can we wait for a upcoming open-liberty:19.0.0.11-kernel-java11?

we have built a Docker image using Open Liberty webprofile 8 and currently the HTTPS outbound calls to salesforce API are failing and from the log it seems that TLSV1 is only enabled and from all the reading it seems TLSV1.2 is needed to be enabled. I am very new to Open Linberty and I dont know how to do it. In My Server.xml file I have following entry:-

phx.salesforceliveagent.com/136.147.100.1:443 with timeout 0
2019-04-29T23:05:08.840527853Z 2019-04-29 23:05:08.839 DEBUG 1 --- [cutor-thread-16] o.a.h.c.ssl.SSLConnectionSocketFactory : Enabled protocols: [TLSv1]
2019-04-29T23:05:08.848027084Z 2019-04-29 23:05:08.845 DEBUG 1 --- [cutor-thread-16] o.a.h.c.ssl.SSLConnectionSocketFactory : Enabled cipher suites:[SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, SSL_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, SSL_RSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_DSS_WITH_AES_128_GCM_SHA256]
2019-04-29T23:05:08.852594802Z 2019-04-29 23:05:08.851 DEBUG 1 --- [cutor-thread-16] o.a.h.c.ssl.SSLConnectionSocketFactory : Starting handshake
2019-04-29T23:05:08.905209219Z [err] javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
2019-04-29T23:05:09.063121768Z [err] at com.ibm.jsse2.k.a(k.java:42)
2019-04-29T23:05:09.067062984Z [err] at com.ibm.jsse2.k.a(k.java:37)
2019-04-29T23:05:09.098532614Z [err] at com.ibm.jsse2.av.b(av.java:549)
2019-04-29T23:05:09.101687527Z [err] at com.ibm.jsse2.av.a(av.java:715)

Any help whats going wrong and how I can fix this issue?

Do you currently plan to update the official Docker images at https://hub.docker.com/_/open-liberty with each release of Open Liberty? Right now open-liberty:kernel-java11 is using Open Liberty 19.0.0.10 and two versions "behind".

The kernel docker files contain this:

# Configure WebSphere Liberty
RUN /opt/ol/wlp/bin/server create \
    && rm -rf $WLP_OUTPUT_DIR/.classCache /output/workarea

the problem with this is that /output/workarea doesn't exist until a later layer in the docker file. This isn't a major issue except that it probably should have been this:

# Configure WebSphere Liberty
RUN /opt/ol/wlp/bin/server create \
    && rm -rf $WLP_OUTPUT_DIR/.classCache $WLP_OUTPUT_DIR/defaultServer/workarea

which would have removed the workarea folder created by the server create step reducing (slightly) the size of the layer.

When using the OL Docker images in our applications for our guides, as well as during workshops, a common comment that I receive and have noticed is that the console output is not user friendly. The red text when running the script as well as the messages stating that the server has been stopped is is initially confusing for myself and others.

Just wanted to bring it to light :)

if the docker container uses a read-only filesystem startup fails with:
cp: cannot create regular file '/config/configDropins/overrides/trustDefault.xml': Read-only file system
even if the keystore is build into the image

a possible solution would be to copy the trustDefault.xml file during build instead at runtime.

tested with image 20.0.0.3-full-java11-openj9-ubi

It looks like the image with tag 'kernel-java11-openj9' was last build on 26th of March, (and it contains OL 19.0.0.2) while docker file for that image was updated on 30th of April (and it contains OL 19.0.0.4).

Could you please push new image to dockerhub and check why it was not done by CI pipeline.

Hi there,

The tags which the official open-liberty image currently uses are not fixed (i.e. immutable), that is, for example, open-liberty:javaee7 may refer to different images over time.

While it makes sense for generic tag names such as javaee7 that image contents change, it'd be very helpful (if not necessary) to additionally provide fixed tags, that won't be overridden by a future image, such as open-liberty:17.0.0.4, open-liberty:2018-01-30_-0151, or, open-liberty:6b4d57d. It's totally valid that the current javaee7 tag also points to the 6b4d57d image. But, without fixed versions repeatable builds are almost impossible -- then developers have to package their own OpenLiberty base image.

Recently there was a failure during Docker Inc's build of our image (see here) because an incorrect value was set for LIBERTY_VERSION inside the Dockerfile.

Our Travis build did not catch this because we're building the images by passing build-args [1], which overrides the values inside the Dockerfile.

This issue is to update our Travis builds to be consistent with Docker Inc's build, which means relying on the values from Dockerfile.

[1]

docker build -t open-liberty:webProfile8-java8-openj9 --build-arg LIBERTY_VERSION=19.0.0.9 --build-arg LIBERTY_BUILD_LABEL=cl190920190905-0148 --build-arg LIBERTY_SHA=cae152410111d34a8bf4859d67ea70f621190e55 --build-arg LIBERTY_DOWNLOAD_URL=https://repo1.maven.org/maven2/io/openliberty/openliberty-webProfile8/19.0.0.9/openliberty-webProfile8-19.0.0.9.zip ../official/latest/webProfile8/java8/openj9

OL is installed in /opt/ol in the image. In the WebSphere Liberty image, the location is /opt/IBM. I'd like to write a Dockerfile that can take a usr server package and unzip it into either of these locations in a consistent way, without reference these locations. I think this could be solved by adding ln -s /opt/ol /liberty to the Open Liberty image and ln -s /opt/ibm /liberty to the WebSphere Liberty image and so dependent images could just use /liberty for both.

See WASdev/ci.docker#145 (WL issue)

We need some docker images for Open Liberty. There are already docker images for WebSphere Liberty, but we should have them from Open Liberty too.

Some things to consider:

• Which JVM to use. IBM, Oracle, OpenJDK+OpenJ9, OpenJDK+HotSpot
• Which server templates to use
• Which architectures

It would be good to keep things simple, but issue 8 over in the open-liberty repository is discussing what the default server template should be so this should provide input.

We only really want one image in docker hub, so I think we need tags to select from these different considerations.

We are running our applocation using the docker image websphere-liberty:webProfile8

While running here, the following messages are displayed when I am running the application as non-root.

[ERROR   ] CWWKS4000E: A configuration exception has occurred. The requested TokenService instance of type Ltpa2 could not be found.

[ERROR   ] CWWKS3005E: A configuration exception has occurred. No UserRegistry implementation service is available.  Ensure that you have a user registry configured.

[ERROR   ] CWWKS5604E: A JsonWebToken Principal can't be injected because one is not available. Protect the requesting resource so authentication occurs before the resource is accessed.

They got resolved once we updated the folder permission here. But the above error messages are little not clear. It seems like a more keystore problem than the permissions related to it.

Readme : https://github.com/OpenLiberty/ci.docker/blob/master/release/kernel/README.md
says "Instructions for using the image can be found on Docker Hub"

Over on docker hub..
https://hub.docker.com/r/openliberty/open-liberty/
The text also says "Instructions for using the image can be found on Docker Hub", and the Docker Hub bit is a link, (but all the links in the text give 404 when followed)

OpenSSL will be removed from the IBM JRE Alpine base image via PR ibmruntimes/ci.docker#28

This issue is to make sure we explicitly add the OpenSSL package in Open Liberty's Alpine image.

When generating the keystore.xml (https://github.com/OpenLiberty/ci.docker/blob/master/official/javaee8/java8/ibmjava/helpers/runtime/docker-server.sh) the environment variable PASSWORD is set. This should be something less generic (perhaps KEYSTORE_PASSWORD or something similar).

One example where this caused issues was in the Kubernetes-config guide (https://openliberty.io/guides/kubernetes-microprofile-config.html), the environment variable PASSWORD is set inside the ping-container, but ends up getting overridden by the keystore password. So, later in the guide when trying to inject the value of the PASSWORD environment variable into the PingResource class, it is the wrong value.

OpenLiberty is planning to support Java 11 soon, and there are already AdoptOpenJDK OpenJ9 docker images available with Java 11:
https://hub.docker.com/r/adoptopenjdk/openjdk11-openj9/

We should create a new set of docker images that are based on these openjdk11-openj9 builds

I ran

docker image pull openliberty/daily:latest
docker image inspect openliberty/daily:latest

and got

'"Labels": {
'    "architecture": "x86_64",
'    "authoritative-source-url": "registry.access.redhat.com",
'    "build-date": "2019-12-10T17:53:44.032126",
'    "com.redhat.build-host": "cpt-1004.osbs.prod.upshift.rdu2.redhat.com",
'    "com.redhat.component": "ubi8-container",
'    "com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI",
'    "description": "This image contains the Open Liberty runtime with IBM's SFJ and Red Hat UBI minimal as the base OS.  For more information on this image please see https://github.com/OpenLiberty/ci.docker#building-an-application-image",
'    "distribution-scope": "public",
'    "io.k8s.description": "The Universal Base Image is designed and engineered to be the base layer for all of your containerized applications, middleware and utilities. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.",
'    "io.k8s.display-name": "Red Hat Universal Base Image 8",
'    "io.openshift.expose-services": "",
'    "io.openshift.tags": "base rhel8",
'    "maintainer": "Red Hat, Inc.",
'    "name": "Open Liberty",
'    "org.opencontainers.image.authors": "Arthur De Magalhaes, Chris Potter",
'    "org.opencontainers.image.revision": "cl200220200204-2100",
'    "org.opencontainers.image.source": "https://github.com/OpenLiberty/ci.docker",
'    "org.opencontainers.image.url": "https://openliberty.io/",
'    "org.opencontainers.image.vendor": "Open Liberty",
'    "org.opencontainers.image.version": "latest",
'    "release": "8",
'    "run": "docker run --rm -ti <image_name:tag> /bin/bash",
'    "summary": "Image for Open Liberty with IBM's SFJ and UBI minimal",
'    "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8/images/8.1-328",
'    "vcs-ref": "c42933bcdbf9f1c232e981a5e40de257c3534c8e",
'    "vcs-type": "git",
'    "vendor": "Open Liberty",
'    "version": "latest"
'}

When I ran

docker image pull open-liberty:latest
docker image inspect open-liberty:latest

and got following:

"Labels": {
    "org.opencontainers.image.authors": "Arthur De Magalhaes, Chris Potter",
    "org.opencontainers.image.revision": "cl200120200108-0300",
    "org.opencontainers.image.source": "https://github.com/OpenLiberty/ci.docker",
    "org.opencontainers.image.url": "https://openliberty.io/",
    "org.opencontainers.image.vendor": "Open Liberty"
}

Is that right?

If based on https://github.com/OpenLiberty/ci.docker/blob/master/releases/latest/kernel/Dockerfile.ubi.ibmjava8, there are missing labels.

Talking with @arthurdm, we will need a slight update to the OL images due to the MicroProfile 2.1 update due in 4Q2018: Epic for MicroProfile 2.1

The only updated component for MicroProfile 2.1 is OpenTracing 1.2. That piece of work is being tracked via their Epic.

The WAD review for both MP 2.1 and OT 1.2 is scheduled for next Thursday, Nov 8.

Any questions, contact either myself or Arthur. Thanks!

Hi guys.
I'm just playin' around with the openliberty as an alternative server for our jakarta EE Applications.
In the community I heard quite good reputations and the startup times mentioned in your website looks promising.
Because of our cloud native style we autoscale our servers on AWS Fargate, which makes the startup time an important parameter.
When I just start an docker container locally (i7, 4 cores, 32 gb ram, windows) and on an ubuntu docker deamon machine (2 cpus, 8gb ram EC2 m5.large) I just experienced startup times around 12 seconds (full openliberty) and around 3 seconds (kernel image), without any application deployed.
see my output here:
`docker run open-liberty:20.0.0.3-full-java8-openj9

Launching defaultServer (Open Liberty 20.0.0.3/wlp-1.0.38.cl200320200305-1433) on Eclipse OpenJ9 VM, version 1.8.0_252-b09 (en_US)
[AUDIT ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
[AUDIT ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/overrides/trustDefault.xml
[AUDIT ] CWWKG0102I: Found conflicting settings for defaultSSLConfig instance of ssl configuration.
Property trustDefaultCerts has conflicting values:
Value true is set in file:/opt/ol/wlp/usr/servers/defaultServer/server.xml.
Value ${SEC_TLS_TRUSTDEFAULTCERTS} is set in file:/opt/ol/wlp/usr/servers/defaultServer/configDropins/overrides/trustDefault.xml.
Property trustDefaultCerts will be set to ${SEC_TLS_TRUSTDEFAULTCERTS}.

[WARNING ] CWWKS3103W: There are no users defined for the BasicRegistry configuration of ID com.ibm.ws.security.registry.basic.config[basic].
[AUDIT ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT ] CWWKS4104A: LTPA keys created in 1.930 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
[AUDIT ] CWPKI0803A: SSL certificate created in 4.219 seconds. SSL key file: /opt/ol/wlp/output/defaultServer/resources/security/key.p12
[AUDIT ] CWWKF0012I: The server installed the following features: [appClientSupport-1.0, appSecurity-2.0, appSecurity-3.0, batch-1.0, beanValidation-2.0, cdi-2.0, concurrent-1.0, distributedMap-1.0, ejb-3.2, ejbHome-3.2, ejbLite-3.2, ejbPersistentTimer-3.2, ejbRemote-3.2, j2eeManagement-1.1, jacc-1.5, jaspic-1.1, javaMail-1.6, javaee-8.0, jaxb-2.2, jaxrs-2.1, jaxrsClient-2.1, jaxws-2.2, jca-1.7, jcaInboundSecurity-1.0, jdbc-4.2, jms-2.0, jndi-1.0, jpa-2.2, jpaContainer-2.2, jsf-2.3, jsonb-1.0, jsonp-1.1, managedBeans-1.0, mdb-3.2, servlet-4.0, ssl-1.0, wasJmsClient-2.0, wasJmsSecurity-1.0, wasJmsServer-1.0, webProfile-8.0, websocket-1.1].
[AUDIT ] CWWKF0013I: The server removed the following features: [servlet-3.1].
[AUDIT ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 11.364 seconds.
[AUDIT ] CWWKI0001I: The CORBA name server is now available at corbaloc:iiop:localhost:2809/NameService.
`
Is there something missing to configure?

Thanks and best regards.

Bastian

Our UBI labels need to be updated, as they still mention SFJ and UBI min.

Also, the Ubuntu variants are missing some of the labels such as version. We should make them consistent with the labels in the UBI variants.

Please, could you provide openLiberty images with OpenJDK11 Hotspot as well?

If Dockerfile has FROM open-liberty and RUN configure.sh, when build it, got this error:

The command '/bin/sh -c configure.sh' returned a non-zero code: 1

When add ARG VERBSOE=true in Dockerfile, will have following

+ chmod -R g+rwx '/output/resources/*'
chmod: cannot access '/output/resources/*': No such file or directory

The Infinispan generated secret must be mounted at /platform/bindings/secret/ but in the sample yaml the mountPath listed is /config/liberty-infinispan-secret. The mount path should be updated to /platform/bindings/secret/.

I am trying to build Open-Liberty for arm64v8 architecture.
Right now I can notice that this package depends on ibmjava:8-sfj-alipne and that also doesn't have support for arm64v8.

Is there anyway, I can proceed with building this package for ARM.
I am working to get Open-liberty support arm64v8 as official package.

Please guide, I would be happy to receive any kind of guidance.

Currently the Docker Hub README's for open-liberty and openliberty/open-liberty are not up to date in terms of how they relate to each other and what images are available.

This results in a lot of confusion about how to get the latest versions of liberty, and a lot of people unaware that the majority of our images are in the openliberty/open-liberty repo. I propose something similar to adoptopenjdk's README, which immediately highlights the differences between the two, with links to the other.

Found the following output from docker-compose up when running openliberty/daily:full

liberty             | /opt/ol/helpers/runtime/docker-server.sh: 10: [: unexpected operator
liberty             | /opt/ol/helpers/runtime/docker-server.sh: 10: [: unexpected operator

We have added a symlink to the /liberty directory, but it does not seem to be correct.

1. The symlink is not working at all:

docker run open-liberty ls /liberty
ls: cannot access '/liberty': No such file or directory

2. The symlink should be to /opt/ol

per above. keystore.xml, etc.

We need some tests to be run as part of our Travis builds for OL docker images. We can use few of the Stock Trader applications.

@meiaus commented on Sun May 17 2020

A while back when running the Open Liberty Docker images to validate the sso-### xml, the associated parameters with each sso provided were checked via trace log as documented in ayoho/Security-SSO#2.
Specifically from sso-oauth2.xml (ayoho/Security-SSO#2 (comment)), the result with userApi=https://api.github.com/user was expected. But during that time, userAPI didn't appear in the trace and I didn't get to uncover the duplication.

Wondering if the following duplicate lines can be removed:

userAPI="${SEC_SSO_OAUTH2_USERAPI}"
userApi="${SEC_SSO_OAUTH2_USERAPI}"

-sso-oauth2.xml (from the deployed container):

?xml version="1.0" encoding="UTF-8"?>
<server>

    <!-- defaults from the server metatype.xml are declared as variables here
         If nothing is passed in elsewhere, the defaults will prevail.
         Required parameters have no defaults, so are not defined here.
         The required parameters are
           clientId, clientSecret,
           tokenEndpoint, authorizationEndpoint
    -->
    <variable name="SEC_SSO_REDIRECTTORPHOSTANDPORT" defaultValue="" />
    <variable name="SEC_SSO_MAPTOUSERREGISTRY" defaultValue="false"/>
    <variable name="SEC_SSO_OAUTH2_GROUPNAMEATTRIBUTE" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_USERNAMEATTRIBUTE" defaultValue="email"/>
    <variable name="SEC_SSO_OAUTH2_DISPLAYNAME" defaultValue="oauth2Login"/>
    <variable name="SEC_SSO_OAUTH2_USERAPI" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_REALMNAMEATTRIBUTE" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_REALMNAME" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_SCOPE" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_TOKENENDPOINTAUTHMETHOD" defaultValue="client_secret_post"/>
    <variable name="SEC_SSO_OAUTH2_ACCESSTOKENHEADERNAME" defaultValue=""/>
    <variable name="SEC_SSO_OAUTH2_ACCESSTOKENREQUIRED" defaultValue="false"/>
    <variable name="SEC_SSO_OAUTH2_ACCESSTOKENSUPPORTED" defaultValue="false"/>
   <variable name="SEC_SSO_OAUTH2_USERAPITYPE" defaultValue="basic" />
    <variable name="SEC_SSO_OAUTH2_USERAPI" defaultValue="" />
    <variable name="SEC_SSO_OAUTH2_USERAPITOKEN" defaultValue="" />

    <!-- the id attribute will not be substituted  -->
        <oauth2Login
                id="oauth2"
        clientId="${SEC_SSO_OAUTH2_CLIENTID}"
        clientSecret="${SEC_SSO_OAUTH2_CLIENTSECRET}"
        redirectToRPHostAndPort="${SEC_SSO_REDIRECTTORPHOSTANDPORT}"
        tokenEndpoint="${SEC_SSO_OAUTH2_TOKENENDPOINT}"
        authorizationEndpoint="${SEC_SSO_OAUTH2_AUTHORIZATIONENDPOINT}"
        userAPI="${SEC_SSO_OAUTH2_USERAPI}"
        groupNameAttribute="${SEC_SSO_OAUTH2_GROUPNAMEATTRIBUTE}"
        userNameAttribute="${SEC_SSO_OAUTH2_USERNAMEATTRIBUTE}"
        displayName="${SEC_SSO_OAUTH2_DISPLAYNAME}"
        mapToUserRegistry="${SEC_SSO_MAPTOUSERREGISTRY}"
        realmNameAttribute="${SEC_SSO_OAUTH2_REALMNAMEATTRIBUTE}"
        realmName="${SEC_SSO_OAUTH2_REALMNAME}"
        scope="${SEC_SSO_OAUTH2_SCOPE}"
        tokenEndpointAuthMethod="${SEC_SSO_OAUTH2_TOKENENDPOINTAUTHMETHOD}"
        accessTokenHeaderName="${SEC_SSO_OAUTH2_ACCESSTOKENHEADERNAME}"
        accessTokenRequired="${SEC_SSO_OAUTH2_ACCESSTOKENREQUIRED}"
        accessTokenSupported="${SEC_SSO_OAUTH2_ACCESSTOKENSUPPORTED}"
        userApiType="${SEC_SSO_OAUTH2_USERAPITYPE}"
        userApiToken="${SEC_SSO_OAUTH2_USERAPITOKEN}"
        userApi="${SEC_SSO_OAUTH2_USERAPI}"
        ></oauth2Login>
</server>

@meiaus commented on Sun May 17 2020

fyi - @brutif

@brutif commented on Mon May 18 2020

This is spurious but harmless. Per social login metatype.xml, the correct one is <AD id="userApi" ...
userAPI is the spurious one that will be ignored and can be removed.

Add and enforce a contributor's agreement for the repository.

See parent epic for more information: https://github.ibm.com/WASCloudPrivate/roadmap-cloudpaks/issues/679

My Dockerfile is pretty simple...

FROM open-liberty:javaee8-java8-ibm

ENV KEYSTORE_REQUIRED false

COPY --chown=1001:0 . /config

I build/run using...

docker build -t ol-runtime .
docker run -d -p 9080:9080 ol-runtime

Among the config copied into the open-liberty Docker image, the following is most relevant to the current issue....

/config/configDropins/defaults/keystore.xml
/config/resources/security/key.jks

My keystore.xml file looks like...

<server>
    <keyStore id="defaultKeyStore" location="${server.output.dir}/resources/security/key.jks" password="[my password]" type="JKS"/>
</server>

Note that I've verified that (prior to copy into the Docker image) my "key.jks" file contains the certificates I expect to be there using the Java keytool, as well as successfully using this keystore file when running open-liberty directly on my local desktop. However, when I try to run my application under open-liberty in a Docker container, outbound calls to a service requiring cert-auth fail with...

[ERROR   ] CWPKI0022E: SSL HANDSHAKE FAILURE:  A signer with SubjectDN CN=somesubdomain.somedomain.com, OU=Some Certificate, OU=Some Sub-Organization, O=Some Organization, L=Some Location, ST=Some State, C=US was sent from the target host.  The signer might need to be added to local trust store /opt/ol/wlp/output/defaultServer/resources/security/key.jks, located in SSL configuration alias defaultSSLConfig.  The extended error message from the SSL handshake exception is: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
        java.security.cert.CertPathValidatorException: The certificate issued by OU=Some Intermediate Certificate, O=Some Organization, L=Some Location, ST=Some State, C=US is not trusted; internal cause is:
        java.security.cert.CertPathValidatorException: Certificate chaining error

Upon open-liberty startup under Docker, I see the following log output that I don't ever see when running open-liberty directly on my local desktop...

[AUDIT   ] CWWKS4104A: LTPA keys created in 1.527 seconds. LTPA key file: /opt/ol/wlp/output/defaultServer/resources/security/ltpa.keys
[AUDIT   ] CWPKI0803A: SSL certificate created in 6.658 seconds. SSL key file: /opt/ol/wlp/output/defaultServer/resources/security/key.jks

When I run a bash shell, within Docker, to check the keystore contents of "key.jks", I see that my original keystore contents have been wiped out, though the file maintains the password that I set in my keystore.xml config...

default@993deec726cf:/output/resources/security$ ls -lsa
total 16
4 drwxr-x--- 2 default root 4096 Apr 24 04:19 .
4 drwxrwx--- 1 root    root 4096 Apr 24 04:19 ..
4 -rw-r----- 1 default root 2171 Apr 24 04:19 key.jks
4 -rw------- 1 default root  897 Apr 24 04:19 ltpa.keys
default@993deec726cf:/output/resources/security$ keytool -v -list -keystore key.jks
Enter keystore password:

Keystore type: jks
Keystore provider: IBMJCE

Your keystore contains 1 entry

Alias name: default
Creation date: Apr 24, 2019
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=defaultServer, O=ibm, C=us
Issuer: CN=localhost, OU=defaultServer, O=ibm, C=us
Serial number: 3b7ac341
Valid from: 4/24/19 4:19 AM until: 4/23/20 4:19 AM
Certificate fingerprints:
         MD5:  C4:52:A4:B2:5A:A3:26:9C:B3:70:8C:27:09:A4:3B:5E
         SHA1: 15:0A:66:E3:57:1F:C9:C6:A4:17:C0:6A:CE:F9:84:C7:AC:FD:2D:EE
         SHA256: A4:75:5B:72:4B:B6:50:35:DA:D8:6C:CF:92:48:51:C9:D0:B5:98:02:DD:09:F8:A1:07:C3:90:64:FE:4C:79:84
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 7e 8e f2 3f b4 6e 2c bf  ab d7 80 94 73 4d d1 c2  .....n......sM..
0010: be c0 1d a5                                        ....
]
]



*******************************************
*******************************************


default@993deec726cf:/output/resources/security$

Other than this keystore issue, everything else seems to work fine in open-liberty under Docker. But this issue is so fundamental to the working of my application, that it's blocking my ability to use open-liberty under Docker. What perplexes me is how this would not already have been reported by someone else? Does no one else running open-liberty under Docker use cert-auth (thus haven't fully exercised this feature) or am I incorrectly applying my keystore configuration? That my keystore configuration works fine when running open-liberty directly on my local desktop indicates to me that it should be valid.

So, is this a bug or am I doing something wrong here?