Paketo Cloud Native Buildpacks behind corporate proxy - paketo

I'm trying to setup cloud native buildpacks (paketo builder) behind a corporate proxy, and I have "x509: certificate signed by unknown authority". This is because the proxy rewrites certificates.
I tried follwing https://paketo.io/docs/howto/configuration/#ca-certificates (create a "binding" folder in the project with the .pem file of the root CA of my proxy and a "type" file containing "ca-certificate"), but this had no effect.
Hints?
Is it possible to disable this check (workaroud for testing)
Logs
pack build test --builder paketobuildpacks/builder:base -e BP_JVM_VERSION=17
base: Pulling from paketobuildpacks/builder
Digest: sha256:855aaa00a7eadca9c6cdba72550889f7c618c2bf1489c29fb9e7e01588665db7
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:1e2a282085f1b7a0fa1d96bd8509378270ab752c6d8042472a95df2bf5e1d6ea
Status: Image is up to date for paketobuildpacks/run:base-cnb
Previous image with name "test" not found
===> DETECTING
9 of 24 buildpacks participating
paketo-buildpacks/ca-certificates 3.2.4
paketo-buildpacks/bellsoft-liberica 9.4.0
paketo-buildpacks/syft 1.13.0
paketo-buildpacks/maven 6.6.0
paketo-buildpacks/executable-jar 6.2.4
paketo-buildpacks/apache-tomcat 7.3.7
paketo-buildpacks/liberty 1.1.2
paketo-buildpacks/dist-zip 5.2.4
paketo-buildpacks/spring-boot 5.13.0
===> RESTORING
===> BUILDING
Paketo CA Certificates Buildpack 3.2.4
https://github.com/paketo-buildpacks/ca-certificates
Launch Helper: Contributing to layer
Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
Paketo BellSoft Liberica Buildpack 9.4.0
https://github.com/paketo-buildpacks/bellsoft-liberica
Build Configuration:
$BP_JVM_JLINK_ARGS --no-man-pages --no-header-files --strip-debug --compress=1 configure custom link arguments (--output must be omitted)
$BP_JVM_JLINK_ENABLED false enables running jlink tool to generate custom JRE
$BP_JVM_TYPE JRE the JVM type - JDK or JRE
$BP_JVM_VERSION 17 the Java version
Launch Configuration:
$BPL_DEBUG_ENABLED false enables Java remote debugging support
$BPL_DEBUG_PORT 8000 configure the remote debugging port
$BPL_DEBUG_SUSPEND false configure whether to suspend execution until a debugger has attached
$BPL_HEAP_DUMP_PATH write heap dumps on error to this path
$BPL_JAVA_NMT_ENABLED true enables Java Native Memory Tracking (NMT)
$BPL_JAVA_NMT_LEVEL summary configure level of NMT, summary or detail
$BPL_JFR_ARGS configure custom Java Flight Recording (JFR) arguments
$BPL_JFR_ENABLED false enables Java Flight Recording (JFR)
$BPL_JMX_ENABLED false enables Java Management Extensions (JMX)
$BPL_JMX_PORT 5000 configure the JMX port
$BPL_JVM_HEAD_ROOM 0 the headroom in memory calculation
$BPL_JVM_LOADED_CLASS_COUNT 35% of classes the number of loaded classes in memory calculation
$BPL_JVM_THREAD_COUNT 250 the number of threads in memory calculation
$JAVA_TOOL_OPTIONS the JVM launch flags
Using Java version 17 from BP_JVM_VERSION
BellSoft Liberica JDK 17.0.3: Contributing to layer
Downloading from https://github.com/bell-sw/Liberica/releases/download/17.0.3.1+2/bellsoft-jdk17.0.3.1+2-linux-amd64.tar.gz
unable to invoke layer creator
unable to get dependency jdk
unable to download https://github.com/bell-sw/Liberica/releases/download/17.0.3.1+2/bellsoft-jdk17.0.3.1+2-linux-amd64.tar.gz
unable to request https://github.com/bell-sw/Liberica/releases/download/17.0.3.1+2/bellsoft-jdk17.0.3.1+2-linux-amd64.tar.gz
Get "https://objects.githubusercontent.com/github-production-release-asset-2e65be/115621629/40b89c3a-208c-434b-8604-3dd53f5dfde1?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20220713%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20220713T111101Z&X-Amz-Expires=300&X-Amz-Signature=24802ad67a837b74ba5d682a5891905dd219f38f524af3d3b19b714800b40243&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=115621629&response-content-disposition=attachment%3B%20filename%3Dbellsoft-jdk17.0.3.1%2B2-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream": x509: certificate signed by unknown authority
ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle: failed with status code: 51

You need to pass the binding to the pack build command, so it's present at build time.
Your command is pack build test --builder paketobuildpacks/builder:base -e BP_JVM_VERSION=17, you need to include the --volume mapping.
pack build test --builder paketobuildpacks/builder:base -e BP_JVM_VERSION=17 --volume $PWD/bindings:/platform/bindings
Where $PWD/bindings references the bindings directory you created.
$ tree bindings/
bindings/
├── ca-certificates
│   ├── support-labs-ca.crt
│   └── type
When your build runs, you'll know it's working because the CA Certificates buildpack will look like this:
Paketo CA Certificates Buildpack 3.2.4
https://github.com/paketo-buildpacks/ca-certificates
Launch Helper: Contributing to layer
Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
CA Certificates: Contributing to layer
Added 1 additional CA certificate(s) to system truststore
Writing env.build/SSL_CERT_DIR.append
Writing env.build/SSL_CERT_DIR.delim
Writing env.build/SSL_CERT_FILE.default
You can see it's Added 1 additional CA certificate(s) to system truststore. That's your CA cert.
You can also confirm by looking at the JVM buildpack, when it installs the JDK tools, it will add your certificate:
BellSoft Liberica JDK 11.0.15: Contributing to layer
Downloading from https://github.com/bell-sw/Liberica/releases/download/11.0.15.1+2/bellsoft-jdk11.0.15.1+2-linux-amd64.tar.gz
Verifying checksum
Expanding to /layers/paketo-buildpacks_bellsoft-liberica/jdk
Adding 128 container CA certificates to JVM truststore
Writing env.build/JAVA_HOME.override
Writing env.build/JDK_HOME.override
You can see it's Adding 128 container CA certificates to JVM truststore (by default there are 127 certificates, so it's default + 1).
You might also want to take a look at binding-tool, which is a small CLI you can install that will help you manage bindings, including CA Certs.
It can be used to easily create the binding folder structure. Just give it your certificate file & it'll create the structure.
You can also integrate it with your shell and it'll automatically augment your pack build command to add the --volume argument so you don't need to think about that.
It's not a requirement to use it, but thought I'd point it out as it can make working with pack and bindings easier.

Related

Phantomjs won't install: Autoconfiguration Error

When trying to install Phantomjs on Ubuntu 22.04, I get the following error:
There are some Q.& A's here from 2015-2022, I tried all of the included suggestions.
https://github.com/ariya/phantomjs/issues/10904
https://gist.github.com/julionc/7476620
wkhtmltopdf - libfontconfig.so.1: cannot open shared object file
http://ubuntuhowtoo.blogspot.com/2019/05/linux-nodejs-phantomjs-error-loading.html
Auto configuration failed
139998593603520:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libproviders.so): libproviders.so: cannot open shared object file: No such file or directory
139998593603520:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
139998593603520:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=providers, path=providers
139998593603520:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=providers```
I had the same issue and fixed it by setting export OPENSSL_CONF=/dev/null prior to phantomJS usage. If it's not possible for you to disable openssl then you would have to pack you application with older OpenSSL version.
Explanation:
Ubuntu 22.04 uses the new OpenSSL version 3.0.2 instead of the older OpenSSL version 1.1.1 . These OpenSSL versions are not fully compatible, so this is why you see this error when PhantomJS tries to auto configure the SSL/TLS settings.
Above answer is little about as I am describing.
Step:1 First stop your node server then run this command in base directory.
Step:2 I suggest you to comment out the lines providers = provider_sectin in the
file/etc/ssl/openssl.cnf
Step:3 Start your application
Brief ref. https://github.com/nodejs/node/issues/43132

The server exited prematurely with exit code 1 GlassFish 4

I've been trying to start the glassfish server domain with the following command asadmin start-domain domain1 but the result wasn't the expected. This what the outputs is throwing out:
Waiting for domain1 to start .Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=192m; support was removed in 8.0
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-server to select the "server" VM
The default VM is server.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose:[class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
Warning: this feature is deprecated and will be removed
in a future release.
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -no-jre-restrict-search
Warning: this feature is deprecated and will be removed
in a future release.
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions with specified granularity
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions with specified granularity
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
-splash:<imagepath>
show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.
Command start-domain failed.
Btw I've already tried changing the network-listener-port number located inside glassfish folders C:\glassfish4\glassfish\domains\domain1\config\domain.xml from port 8080 to 4949 and it didn't work. Besides I also tried running the start-domain domain1 command in the asadmin batch file and nothing happened, the output still the same.
Any idea how can I fix this out?
I tried to start it with asadmin.sh and it worked on Windows 10

WolfSSL: Resume Session failure due to configuration issue of build (cmake)

I am using an Ubuntu 20.04 machine along with the CLion IDE 2020.3.2 and I want to create an app using WolfSSL which would need the TLS1.3 implementation of it.
Using CLion, I cloned the official repository https://github.com/wolfSSL/wolfssl.git. CLion automatically built the project and I was able to run all the \wolfssl\examples perfectly.
Thus, the resumption session does not work.
I run both Server/Client with these arguments: client/server -v 4 -r
And I am getting this output from the client side: didn't reuse session id!!! which I can verify from Wireshark that there was no resumption made but just another handshake.
At another build I did, where instead of cmake ( which is the default of CLion ) I used make I manged to run properly the resumption but for that I had to add in the configuration before the build this command: ./configure --enable-all which "Enables all wolfSSL features, excluding SSL v3".
What is the equivalent command of --enable-all I should use in my Cmake configuration ? Or what should I do so I can achieve properly the resumption?
I tried -DWOLFSSL_ALL -DENABLE_ALL and others but did not managed to do it. I tried including many of them separately to find which is the one that enables the resumption but nothing yet.
The specific wolfSSL option for enabling TLS sessions is HAVE_SESSION_TICKET.
There is not currently an equivalent macro for the ./configure --enable-all option, but you can use the "user_settings" method to get close:
https://github.com/wolfSSL/wolfssl/tree/master/examples/configs
Here is an example that configures most of the library options:
https://github.com/wolfSSL/wolfssl/blob/master/examples/configs/user_settings_all.h

Unable to Load SSL Module in IBM HTTP Server v8.5

Yesterday I was able to successfully install IBM HTTP Server, and everything was working great until I attempted to begin configuring the SSL settings.
When attempting to load the SSL module by adding the following to my httpd.conf file:
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
...the server will fail to start up, and I see the following in my error_log:
[Tue Feb 17 16:33:29 2015] [info] mod_unique_id: using ip addr <removed>
(20019)DSO load failed: SSL0166E: Failure attempting to load GSK library (libgsk8ssl_64.so), libgsk8ssl_64.so: cannot open sharedobject file: No such file or directory
Configuration Failed
I have confirmed that I have GSKit installed with the gskver command:
libgsk8ssl_64.so
============
#(#)CompanyName: IBM Corporation
#(#)LegalTrademarks: IBM
#(#)FileDescription: IBM Global Security Toolkit
#(#)FileVersion: 8.0.50.34
#(#)InternalName: gskssl
#(#)LegalCopyright: Licensed Materials - Property of IBM GSKit
(C) Copyright IBM Corp.1995, 2014
All Rights Reserved. US Government Users
Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
#(#)OriginalFilename: libgsk8ssl_64.so
#(#)ProductName: gsk8g (GoldCoast Build) 140910
#(#)ProductVersion: 8.0.50.34
#(#)ProductInfo: 14/08/13.01:22:06.14/09/10.13:23:58
#(#)CMVCInfo: gsk8g_140909/gsk8g_ssl gsk8g_140909/gsk8g_cms gsk8g_140909/gsk8g_support gsk8g_140731/gsk8g_pkg gsk8g_140909/gsk8g_acme gsk8g_140909/gsk8g_doc gsk8g_140909/gsk8g_ikm
No other modules seem to be causing any issues. I'm at a bit of a loss as to what is causing this. Any ideas?
Check out the apachectl and envars scripts. Especially envars. Sometimes these scripts are modified for running third party modules. The path for the GSKit libraries are typically set up in the envars script.
I found the shared library symbolic links were missing from /usr/lib and /usr/lib64. If you (re)create these links, it may clear your problem. I navigated to the library directory (/usr/lib64 in this case) and ran (as root):
for name in $(ls -1 /opt/IBM/WebSphere/HTTPServer85/gsk8/lib64);
do ln -s /opt/IBM/WebSphere/HTTPServer85/gsk8/lib64/$name ./$name;
done
Of course change the source directory to what ever your install standard is. It created all the links necessary in my case.
A.

Unable to build Worklight project for "test" server (JDBC error)

Hello worklight team and devs!
We are done working on our development project and everything works fine in the local dev server (Tomcat).
Now we are trying to build the project to be deployed to a testing WAS ND 8.0.3 server.
We've been following the manual in the infocenter and modified each required file as needed (worklight.properties and application-descriptor.xml)
We made this changes to the worklight.properties file:
publicWorkLightHostname=working.hostname.com
# http or https
publicWorkLightProtocol=http
# For default port leave empty
publicWorkLightPort=ourport
publicWorkLightContext=/worklight
wl.db.jndi.name=jdbc/WorklightDS
wl.db.type=DB2
wl.db.url=jdbc:db2:Worklight
wl.db.username=wluser
wl.db.password=passwd
We tested the jdbc source in the WAS console and it works perfectly.
We proceed to build the war, adapter and wlapp (ALL) and we get this error:
[2013-05-21 12:48:44] FWLSE4001W: Failed to resolve JNDI name: "jdbc/WorklightDS".
Application may fail to access the database in runtime. If building for remote server - ignore this warning.
[2013-05-21 12:48:44] FWLST0011E: ====== Worklight Project BPMWorklight-project-customization failed to start: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
[2013-05-21 12:48:44] Activation failed. Bundle didn't start:C:pathto\BPMWorklight-customization.jar
This happens in the developer workstation and if we install Studio in the server, where the jdbc source is created, the same happens.
I guess that Worklight is trying to "obtain" a JDBC source in TOMCAT not WAS, but we are building for WAS, so the build fails and NO files are changed after the error. NO BUILD is executed.
We also tried to execute the build.xml with ANT in studio but we get this error:
Buildfile: C:\Users\Primary User\IBM\Worklight\LIS_SampleCollection\BPMWorklight\build.xml
BUILD FAILED
C:\Pathtofile\BPMWorklight\build.xml:3: Cannot find ../../common.xml imported from
C:\Pathtofile\BPMWorklight\build.xml
Total time: 62 milliseconds
You're help is greatly appreciated!
Thanks a lot!!
Best,
Nicolas E.
If all you require is to deploy the updated-for-WAS .war file in WebSphere, you don't need to do any build operation in Worklight. After updating any file under the server\ folder in Worklight Studio (the Eclipse plug-in), the .war file is automatically being re-created.
The build operation is mainly for creating the binaries and deploying to Worklight Server (database) (again, when using the Eclipse plug-in).
So what I suggest is to:
First update application-descriptor.xml with your context root value in worklightServerRootURL, and keep your .wlapps on the side
Update worklight.properties and save them.
Now you have your app ready to deploy and the .war file ready to deploy.
Move to WAS, deploy the .war file
Hopefully things will work now, so you can load Worklight Console and deploy the .wlapp and .adapter files.
I don't know what you've read in the IBM Information Center, but you can also try going over the following training module from IBM Worklight Getting Started.
Moving from development environment to stand-alone QA and production servers
Notes:
The above is not so convenient, but it is A way to move from your
development environment to another staging environment, or
application server...
The issue might also happen even after following my steps above, and this will indicate that the real issue is in your DB2 declaration in worklight.properties.
I will update this answer tomorrow with some insight regarding the possible DB2 declaration issue.